Enhance Coordinate model

[GoogleCodeExporter]

- reduce coordinate to xy
- add CoordinateM class
- add CoordinateZ class
- add CoordinateZM class

- enhance IO

Original issue reported on code.google.com by felix.ob...@netcologne.de on 25 Jan 2012 at 8:47

[GoogleCodeExporter]

Having thought about it for a while, I don't know if reducing Coordinate to x- 
and y- ordinates and let all further ordinate handling to coordinate sequences.

Any opinions?

Fürthermore, what do you think about combining these interfaces 
- http://edndoc.esri.com/arcobjects/9.2/ComponentHelp/esriGeometry/IMAware.htm
- 
http://edndoc.esri.com/arcobjects/9.2/ComponentHelp/esriGeometry/IMCollection.ht
m
- 
http://edndoc.esri.com/arcobjects/9.2/ComponentHelp/esriGeometry/IMSegmentation.
htm
- 
http://edndoc.esri.com/arcobjects/9.2/ComponentHelp/esriGeometry/IMSegmentation2
.htm

into some IMeasuredCoordinateSequence interface. Or should these interfaces be 
applied on geometry?

Original comment by felix.ob...@netcologne.de on 22 Mar 2012 at 8:21

[GoogleCodeExporter]

My preference would be to keep coordinates as 3-dimensional Cartesian 
coordinates 
(http://en.wikipedia.org/wiki/Cartesian_coordinate_system#Cartesian_coordinates_
in_three_dimensions). We use Z a lot, even geometry is normally rendered in 2D.

... or maybe we don't need ICoordinate, ICoordinateSequence, 
ICoordinateSequenceFactory  at all, just Point with double coordinates should 
be enough, read definition of  http://en.wikipedia.org/wiki/Coordinates, 
http://en.wikipedia.org/wiki/Higher_dimension, 
http://en.wikipedia.org/wiki/Geometry

Checked how KML defines coordinates - very simple, as array of doubles (tuples).
https://developers.google.com/kml/documentation/kmlreference#geometry

... the question is how far we want to go from OGC / JTS :). If we want to go 
extreme - IMHO geometry/GeoAPI can be simplified a lot in terms of number of 
interfaces / methods / properties.

public interface IGeometry
{
    ... Area, Boundary ...
}

public interface IPoint : IGeometry
{
    IReadOnlyList<double> Coordinates { get; set; }
}

public interface ILineString : IGeometry
{
    IList<IPoint> Points { get; set; }
}

...

Original comment by Gennadiy.Donchyts on 22 Mar 2012 at 7:08

[GoogleCodeExporter]

>... the question is how far we want to go from OGC / JTS :)
 I strongly disagree from moving away from JTS, actually.
My2Cents.

Original comment by diegogu...@gmail.com on 22 Mar 2012 at 8:26

[GoogleCodeExporter]

I would prefer having the measured-functions applied on Geometry-types 
(especially LineString) since it most often is where they will be used. 
(GetSubLine, ExtractPointAt etc.)

The ESRI-way of having A LOT of interfaces that expose different functionality 
on the same classes is quite hard to teach new developers and far from 
intuitive often leaving the developer testing what classes implement what 
interfaces.

Separating Coordinates to Coordinate, CoordinateZ, CoordinateM, CoordinateZM 
could be a good distinction. Hopefully this will also help making 
serializing/deserializing easier. However, it will give some overhead moving a 
geometry from 2D to 3D compared to just changing for example a ZAware-property 
from false to true.

Together with this one should also consider LineString, LineStringZ, etc. to 
make clear distinction between Geometries of different dimension. LineStringZ 
should also expose methods like Length3D() together with the 2D Length() from 
LineString 

Original comment by peter.lo...@gmail.com on 22 Mar 2012 at 9:28

[GoogleCodeExporter]

So GeoAPI will explode in case of new classes, it is not worth it (putting into 
different classes CoordinateZ, CoordinateM ...).

I think that checks if Z, M or other dimensions are supported should be 
somewhere in CoordinateSystem, GeometryFactory and hidden implementation, but 
the interface may remain more general.

Coordinate / Point class can be made more general so that all coordinates can 
be accessed as:

var point = new Point { Coordinates = { 0.0, 1.0, 0.1 } };

And then:

var x = point.Coordinates[0];
var y = point.Coordinates[1];
var z = point.Coordinates[2];

Or using properties, redirected to Coordinates array in implementation:

var x = point.X;
var y = point.Y;
var z = point.Z;

... somewhere in implementation:

class Point
{
   double[] Coordinates { get; }
   double X { get { return Coordinates[0]; } set { Coordinates[0] = value; } }
   ...
}

-----

I also think there is a huge confusion, Coordinate is currently defined as { X, 
Y, Z } but actually X, Y, Z are coordinates of the point.

Original comment by Gennadiy.Donchyts on 23 Mar 2012 at 1:04

[GoogleCodeExporter]

The problem with storing ordinates in arrays is that you cannot tell whether 
they are to be interpreted as 2DM or 3D.

That is why I like to remove Z from coordinate class and leave ordinate 
handling to coordinate sequence/geometry.

Original comment by felix.ob...@netcologne.de on 26 Mar 2012 at 10:19

[GoogleCodeExporter]

Then coordinates array should come together with flag specifying dimensionality 
of the coordinates, e.g.:

interface IPoint
{
   IReadOnlyList<double> Coordinates { get; set; }
   CoordinateDimension CoordinatesDimension { get; set; }
}

[Flags]
enum CoordinateDimension
{
   X = 0,
   Y = 1,
   Z = 2,
   M = 3,
   XYZ = X | Y | Z,
   XYZM = X | Y | Z | M,
   ...
}

Original comment by Gennadiy.Donchyts on 26 Mar 2012 at 11:19

[GoogleCodeExporter]

We already have that flag (named Ordinates) in GeoAPI.

I don't know how this behaves preformance wise (are switch branches inlined or 
not), it definatly makes the code look ugly ...

Original comment by felix.ob...@netcologne.de on 26 Mar 2012 at 11:30

[GoogleCodeExporter]

How many dimensions we use in geometry: maybe it is something to define on a 
higher level, e.g. in IGeometryFactory, similar to PrecisionModel. Once 
GeometryFactory is created and configured to use XY only (similar to precisiont 
model) - all geometries will be created using only 2 coordinates and all 
underlying algorithms will take it into account. Asking Point.HasZ would 
internally go to _factory.HasZ so no flag will need to be stored in geometries, 
only actual coordinates.

Ordinates - yes, I know, just named it here differently :). Abscissa/ordinate 
is a common use for XY 2D, chart representation, but rarely for nD world 
http://wiki.answers.com/Q/Another_name_for_the_x_coordinate_of_a_point_is. 
Abscissa is usually X and ardinate - Y.

Original comment by Gennadiy.Donchyts on 26 Mar 2012 at 12:30

[GoogleCodeExporter]

sorry that the wording is not correct. I just derived it from JTS coordinate 
sequence interface where it says:
(http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/
src/com/vividsolutions/jts/geom/CoordinateSequence.java?revision=573&view=markup
)

/**
 * Returns the ordinate of a coordinate in this sequence.
 * Ordinate indices 0 and 1 are assumed to be X and Y.
 * Ordinates indices greater than 1 have user-defined semantics
 * (for instance, they may contain other dimensions or measure values).
 *
 * @param index the coordinate index in the sequence
 * @param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-1])
 */
double getOrdinate(int index, int ordinateIndex);

Original comment by felix.ob...@netcologne.de on 27 Mar 2012 at 6:39