[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 mwtoews):

 I've merged the latest `svn-trunk` to the pull request, so it should be
 all caught up. There are a few other misc. changes that caught up, such as
 using math constants for fractions of PI, and wording in the manual.

 I'm neutral for a hybrid approach. If such approach were implemented for
 inverse geodesic measures (distance), it would switch methods where there
 are known precision issues (e.g.) >0.1 mm error, and/or the difference of
 performance is negligible. It would take a bit more investigating to find
 out how to implement these limits (or to find out if that approach is too
 complicated). Area and direct geodesic (ST_Project) methods should
 definitely use GeographicLib.

 At any rate, the user has the choice of using the `use_spheroid=true`
 option if they don't want to compromise speed. But if they want to use
 more expensive and accurate geodesic methods, then they can choose to have
 it with `use_spheroid=false`.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2918#comment:23>
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.