[postgis-tickets] [PostGIS] #2918: Use GeographicLib functions for ST_Azimuth, ST_Distance, ST_Project, ST_Length, ST_Perimeter and ST_Area

[PostGIS]

#2918: Use GeographicLib functions for ST_Azimuth, ST_Distance, ST_Project,
ST_Length, ST_Perimeter and ST_Area
---------------------+------------------------------------------------------
 Reporter:  mwtoews  |       Owner:  pramsey      
     Type:  patch    |      Status:  new          
 Priority:  medium   |   Milestone:  PostGIS 2.2.0
Component:  postgis  |     Version:  trunk        
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by karney):

 As the author of GeographicLib, I am not a disinterested observer; so
 treat the following comments in this light...

 I recommend using the GeographicLib routines for all geodesic
 calculations rather than a hybrid of legacy code (presumably Vincenty)
 and GeographicLib. The reasons are:

 (1) Improved accuracy. Vincenty is pretty accurate (the error is about
 0.1 mm). However this error can by magnified in certain circumstances
 (a poorly conditioned triangulation, for example). GeographicLib gives
 full double-precision accuracy.

 (2) Solution to the inverse problem is always found. Vincenty fails in
 a small fraction of cases which means that all callers of the inverse
 routines need to handle a possible failure.

 (3) GeographicLib calculates differential quantities related to
 geodesics. These are useful in solving some problems, e.g., computing
 the time of closest approach for two vessels moving along geodesics.

 (4) Smaller library size. To calculate the area you need to pull in the
 GeographicLib routines anyway. It make sense to dispense with the (now
 redundant) code.

 (5) Consistency. In the case where there are multiple shortest
 geodesics, it is important that the area reported apply to the geodesic
 which is found. This is difficult to do with the hybrid approach.

 This just leaves the issue of the times. Most likely this is not a key
 issue since the times are so small -- roughly equivalent to performing a
 map projection. (In any case, many users would trade a more accurate
 and robust solution for a little speed.) The comparative times for
 randomly sampled points reported in my paper (Sec. 7) are:

 {{{
          Vincenty  GeographicLib
 direct    1.11 us     0.88 us
 line                  0.37 us
 inverse   1.34 us     2.34 us
 }}}

 The time reported for "line" is the time per point to compute several
 points along a single geodesic (duplicating this functionality with
 Vincenty is straightforward but typically isn't provided).

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2918#comment:21>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.