Re: [Jts-topo-suite-user] Geodetic Coordinates, Nearest Neighbor, Clustering
Brought to you by:
dr_jts
From: Bryce L N. <bno...@gm...> - 2011-04-26 15:17:18
|
On Sat, Apr 23, 2011 at 10:16 PM, Martin Davis <mtn...@te...> wrote: > My intial (rough) thoughts on a Geodetic extension for JTS are here: > > > https://docs.google.com/document/d/12RqBN16nKzDFgMqEMczAuHjx-dqCGR_B2YVkB3W-aQI/edit?hl=en > > In case it's not clear, this proposal does NOT suggest creating a Geodetic > Coordinate subclass. Instead, the existing Coordinates are used, and any > Geodetic-specific logic is provided in a Spheroid class associated with the > GeoGeometry. > A few observations: 1] A "parallel API" for geodetic geometries breaks with the notion that JTS implements Simple Features for SQL. 2] Mapping to PostGIS types would become difficult (because it has "one Geometry to rule them all", not "Projected Geometries" vs. "Geographic Geometries".) 3] The existing Coordinate type has a distance method with a Euclidean formula. If Coordinates were to store geodetic values, the distance method would return incorrect results if its behavior were not changed. 4] Units start to matter to algorithms. While a euclidean distance calculation is the same whether the units are feet, inches or meters, to calculate geodetic distances, you need to know whether the coordinate is in degrees or radians. The design choice here would be to provide some means to track units (probably on the Coordinate), or to simply declare that coordinates are in degrees/radians. In terms of just spitballing "directions" without getting too bogged down in details, what do you think of trying to implement SFS in "spirit" if not in all the specifics? Example goals: Retain as much ignorance of the coordinate system as possible: distinguish only between "projected" or "geographic". Implement the distinction either by association (srid field) or type (subclassing/implementing an interface). Coordinates have a consistent interface regardless of whether they are projected or geographic (e.g., either they both calculate distance, or neither does). There remains only one geometry API, which can leverage either kind of coordinate. Just thinking out loud. Bryce |