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

[PostGIS]

#3667: Bug in geography ST_Segmentize
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  reopened
  Priority:  blocker  |  Milestone:  PostGIS 2.3.4
 Component:  postgis  |    Version:  2.3.x
Resolution:           |   Keywords:
----------------------+---------------------------
Changes (by robe):

 * status:  closed => reopened
 * priority:  high => blocker
 * resolution:  fixed =>
 * milestone:  PostGIS 2.3.1 => PostGIS 2.3.4


Comment:

 Someone reported on IRC that this is still not fixed with this example.  I
 have confirmed it is still broken.

 I know it's a breaking change, but can we revert back to the old pre 2.3
 behavior at least for PostGIS 2.4.1  (2.3.4 would be nice to do too,
 though I'm okay with letting that one go).



 {{{
 SELECT ST_AsText(ST_Segmentize(ST_GeogFromText('LINESTRING(11.3953811
 47.2577728,11.3953811 47.257936)'), 15));


 }}}

 outputs


 {{{
                                    st_astext
 --------------------------------------------------------------------------------
  LINESTRING(11.3953811 47.2577728,0 5.68175492717434e-322,11.3953811
 47.257936)
 (1 row)

 }}}


 Which is huge.  The orginal line was only 19 meters long.  I also tested
 on 2.3.3 and got the same stupid answer.

 The old behavior may not have been as good about splitting the lines
 evenly, but at least it always gave reasonable answers.



 IRC thread


 {{{
 13:25:25        Niko_K: Can I please get some help on the ST_Segmentize
 function in Postgis 2.4.0?
 13:25:47        Niko_K: I think that the bug #3667
 (https://trac.osgeo.org/postgis/ticket/3667) is not fixed
 13:25:48        sigq:   Title: #3667 (Bug in geography ST_Segmentize) –
 PostGIS (at trac.osgeo.org)
 13:28:14        Niko_K: Just try the following SQL command
 13:28:16        Niko_K: SELECT
 ST_AsText(ST_Segmentize(ST_GeogFromText('LINESTRING(11.3953811
 47.2577728,11.3953811 47.257936)'), 15))
 13:28:26        Niko_K: For me the result is:
 13:28:28        Niko_K: LINESTRING(11.3953811
 47.2577728,8.58553798490362e-315 14376.1464672296,11.3953811 47.257936)
 13:29:11        Niko_K: the inserted point '8.58553798490362e-315
 14376.1464672296' is obviously not correct
 13:29:17        Niko_K: some information on the version used
 13:29:25        Niko_K: POSTGIS="2.4.0 r15853" PGSQL="100"
 GEOS="3.6.1-CAPI-1.10.1 r0" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL
 2.1.3, released 2017/20/01" LIBXML="2.9.4" LIBJSON="0.12.1"
 13:29:27        Niko_K: LIBPROTOBUF="1.2.1" RASTER
 13:30:07        Niko_K: System is fedora 26 with Postgis installed from
 latest PostgreSQL repo
 13:30:53        Niko_K: PostgreSQL version is: "PostgreSQL 10.0 on x86_64
 -pc-linux-gnu, compiled by gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2),
 64-bit"
 13:45:34        Niko_K: Just found out that the ST_Segmentize sometimes
 leads to intermediate points, with lat and lon close to zero and some
 (like the example above) where only one of lat or lon is close to zero
 13:45:45        Niko_K: here lat and lon become close to zero:
 13:45:47        Niko_K: SELECT
 ST_AsText(ST_Segmentize(ST_GeomFromText('LINESTRING(11.4204246
 47.2494256,11.4203095 47.2493851,11.4203095 47.2492321,11.4205452
 47.2489215)', 4326)::geography, 15))
 13:46:17        Niko_K: in the example above only one is close to zero
 while to other one is too large (larger than 180 and 90 degrees)
 13:46:22        Niko_K: SELECT
 ST_AsText(ST_Segmentize(ST_GeogFromText('LINESTRING(11.3953811
 47.2577728,11.3953811 47.257936)'), 15))
 }}}

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