Open GoogleCodeExporter opened 9 years ago
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
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
>... 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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
felix.ob...@netcologne.de
on 25 Jan 2012 at 8:47