[postgis-tickets] [PostGIS] #3728: Bug in geography ST_Segmentize

[PostGIS]

#3728: Bug in geography ST_Segmentize
----------------------+---------------------------
  Reporter:  petermj  |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  high     |  Milestone:  PostGIS 2.4.0
 Component:  postgis  |    Version:  2.3.x
Resolution:           |   Keywords:
----------------------+---------------------------

Comment (by robe):

 Note brought up on IRC and Mike Toews responded.


 {{{
 https://lists.osgeo.org/pipermail/postgis-devel/2017-September/026475.html

 On 22 September 2017 at 07:47, Regina Obe <lr at pcorp.us> wrote:
 > Except for this last one which I propose we fix by switching back to 2.2
 > behavior.  The new behavior is harder to get right in all cases and I
 don't
 > see it as being that much of an improvement over the old behavior.

 I'll admit that I haven't been following the old or new behaviours of
 ST_Segmentize, but I'd suggest redesigning this based on GeographicLib
 (same library used for ST_Distance, via PROJ), since it has reliable
 methods to do parts of the technique. In particular, it will produce
 equal-length sub-segments, probably within a few nanometres.

 Charles has a few examples of interpolating points from an inverse
 geodesic line, here is one for C:
 https://geographiclib.sourceforge.io/html/C/geodesic_8h.html#a0b91285fb3cd572d2d77b2e062e8c800

 Essentially, you create an geod_geodesicline for each vertex pair,
 find the geodesic length (s12). If the geodesic segment length is
 greater than the segmentize distance, then interpolate the points
 along the geodesic line with geod_position by dividing s12 by the
 appropriate number of points required. Each sub-segment would have
 equal distance between them.

 As for performance, creating each geod_geodesicline is just as
 expensive as ST_Distance (2.62 µs), then geod_position to get the
 interpolated points is very cheap (each 0.37 µs).

 Cheers, Mike
 }}}


 with that thought in mind I guess we could live with this bug for 2.4 and
 in 2.5 reimplement with GeographicLib.

 Though that begs the question should we then in 2.5 require proj 4.9 as a
 minimum (or we put guards in place for lower proj).

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