[postgis-devel] Geodetic issues

[Chris Hodgson]

So I did a little more research on the subject of geodetic support.

I couldn't find much information on how Oracle provides geodetic 
support, only that prior to 9i, there was no geodetic support, and as of 
9.2  they claim the "Spatial queries return the right answers all the 
time" [1] in the context of ellipsoidal surface computations.

DB2 uses the "Hipparchus" library from Geodyssey [2]. The Geodyssey 
front page says that Microsoft has now purchased exclusive rights to 
Hipparchus - interesting. There are a few papers available about 
Hipparchus, it essentially uses a geodesic triangulation of the spheroid 
which can be arbitrarily dense to provide the level of accuracy 
required. It appears that the actual geometric calculations are done by 
reprojecting to a local planar projection for the triangle in which the 
calculation is being done.

Microsoft SQL Server 2008 claims to support geodetics but it is not 
clear whether you can perform operations such as intersection or buffer 
in geodetic space.

The proposition of supporting geodetics in JTS/GEOS was discussed a bit 
before on the JTS list [4]. The general conclusion is that it definitely 
isn't straight-forward. There was some hope that maybe the 
cartesian-based algorithms could be made to work by implementing a 
geodetic "strategy" (which would provide the basic methods such as 
calculating the intersection of two lines) - however there was also 
worry that since some of the basic assumptions of cartesian geometry are 
broken on the spheroid (parallel lines not crossing, triangles internal 
angles adding up to 180 degrees, etc), the basic premise of some of the 
algorithms might fail entirely on the sphere.

It was also noted that ESRI's ArcGIS 9.3 can only perform the buffer 
operation in geodetic space on points [5]. Since this is relatively 
trivial, I expect that it cannot perform intersections in geodetic space 
either - a bit of searching supports this assumption.

Safe's FME has a "GeographicBufferer" transformer which reprojects 
features into a "Dynamic Equal Distance" projection, buffers them and 
reproejcts them back. I couldn't find a reference to similar 
transformers for intersection or any other operations.

So, it seems that the approach of reprojecting to a local plane (or many 
local planes) seems to be the approach taken by most, if not all, of the 
existing implementations of constructive geometry in spheriodal space. 
I'm still not sure I have the time or knowledge to go any further with 
this, but I thought it might be worth sharing my research for posterity.

Cheers,
Chris


[1] 
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_cs_concepts.htm#i891851

[2] 
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/opt/csbgeo02.htm

[3] http://www.geodyssey.com/

[4] 
http://lists.refractions.net/pipermail/jts-devel/2008-November/002709.html

[5] 
http://lists.refractions.net/pipermail/jts-devel/2008-November/002709.html

>>  Are there any plans for moving
>> forward with something like that? I recognize there would be a large amount
>> of work involved (probably more than writing JTS or GEOS as is, for planar
>> geometries?). Is this the direction we would want to go? Or am I wrong and
>> these aren't big hacks but are "the way to do it" and just need further
>> tweaking to handle the ugly cases?
>>     
>
> No, you're right. The hacks as currently conceived will always have
> some kinds of issues with them. There are two ways forward though. One
> is to actually do constructive geometry in spherical space, and David
> Skea has said he's continuing to work on this stuff (in his Abundant
> Spare Time). The other is to recognize that it's possible to do
> constructive geometry in planar space for each local operation on a
> spherical object, and then back project the results when complete. So
> an approach would be to move the hack to a lower level of the
> algorithm and then deal with the corner cases. Which would probably be
> best done at the GEOS level.
>
> Paul
>
>