Re: [Jts-topo-suite-user] Geodetic Coordinates, Nearest Neighbor, Clustering

[Bryce L N. <bno...@gm...>]

On Fri, Apr 29, 2011 at 5:44 PM, Martin Davis <mtn...@gm...> wrote:

> Here's the prototype class structure:
>
> ---------------------------------------
> // Provides declaration of all Geometry methods
> interface Geometry
> {
>   // all generic accessor signatures
>   // all geometry operation signatures
> }
>
> interface Polygon extends Geometry
> {
>   // polygon-specific accessor signatures
> }
>
> // Implements structure of Polygon, with accessor method implementations
> class GeometryImpl implements Geometry
> {
>    // abstract accessor methods
>    // operation methods delegate to OperationsStrategy provided by the
> GeometryFactory
> }
>
> // Implements structure of Polygon, with accessor method implementations
> class PolygonImpl extends GeometryImpl implements Polygon
> {
>    // concrete accessor methods (generic and type-specificy
> }
>
> // Here's an example of structural extension
>
> class MyPolygonImpl extends GeometryImpl implements Polygon
> {
>   // my special polygon structure implementation
>
>    // concrete accessor methods
> }-----------------------------------------
>
>
That's more or less what I was thinking. :)



> Notes:
> - The GeometryFactory will contain the appropriate OperationsStrategy
> class.  As you say, this could be selected via a boolean flag.  It would be
> more flexible to simply pass the desired OperationsStrategy into the
> GeometryFactory.
>
>
Yup. Or we could have a boolean flag for the two that people are likely to
use, and allow them to pass in an arbitrary one if they get all motivated.


> Issues:
> - Where does Spheroid information live?  Probably in the GeometryFactory.
>

I think with this we've come full circle. Remember this thread started with
a KdTree that could operate on geodetic coordinates. Fiddling with
geometries buys me nothing except a better awareness of the larger context.
I'd suggest storing CRS information on the Coordinates themselves as a
reference to org.opengis.referencing.crs.CoordinateReferenceSystem. To keep
things simple, JTS should only note the distinction between "GeodeticCRS",
and "everything else, including null". Null == planar.

JTS could have a simple implementation of GeodeticCRS, EllipsoidalCS,
GeodeticDatum, Ellipsoid, and PrimeMeridian. A bit more overhead than a
simple Ellipsoid, but more interoperable. Plus, if someone already has CRS
information externally, they can keep it associated with their data when
they have JTS work on it. Separating a coordinate from its reference system
is asking for trouble. :)


> - How should per-geometry geodetic-specific information be stored?  E.g.
> Envelope3D.  Maybe this requires a new GeodeticPolygonImpl (easily supported
> by the above model)
>

I'm not sure I understand Envelope3D yet. :) But as a rule, I'd say that any
structure common to all strategies goes in the interface; and any oddball
structure unique to one strategy gets exposed via implementation directly.
I'd be reluctant to create a GeodeticPolygon interface simply because this
is very well trodden ground, and no one who has been here before has
discerned a need for it. (19107/19125-1).

Bryce