[postgis-devel] ST_Segmentize geography go back to old 2.2 behavior

[Regina Obe]

The ST_Segmentize change we put in place in PostGIS 2.3 to try to achieve
equal segments has been fraught with problems.  We've had numerous bug
reports, of which most are fixed, 
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.

https://trac.osgeo.org/postgis/ticket/3728


The old behavior was approximate equal length segments.  This one has the
annoying behavior of trying to be equal segments but then as in the 1000 seg
case below ending up with a goofy long segment for the last.

Example query: 

With f AS  (SELECT ST_Segmentize(ST_GeogFromText('SRID=4326; LINESTRING(-4.0
49.8, -4.0 59.0)'),1000) AS geog_s, ST_GeogFromText('SRID=4326;
LINESTRING(-4.0 49.8, -4.0 59.0)') AS geog),
    f2 AS (SELECT ST_NPoints(geog_s::geometry) AS geog_s_npoints, geog,
geog_s FROM F),
f3 AS (SELECT i, ST_Length(ST_MakeLine(ST_PointN(geog_s::geometry, i),
ST_PointN(geog_s::geometry, i + 1))::geography) AS lseg_length,
ST_Length(geog) As total_length
FROM f2, generate_series(1,geog_s_npoints - 1) AS i)
SELECT COUNT(lseg_length), AVG(lseg_length)::numeric(10,2),
MIN(lseg_length)::numeric(10,2), MAX(lseg_length)::numeric(10,2),
SUM(lseg_length )::numeric(10,2) AS sum_segs, total_length::numeric(10,2) ,
percentile_cont(0.5) WITHIN GROUP (ORDER BY lseg_length)::numeric(10,2) AS
median 
FROM f3
GROUP BY total_length;

-- 2.2 behavior was this:  (using 1000 length segment)
count |   avg   |  min   |   max   |  sum_segs  | total_length | median
-------+---------+--------+---------+------------+--------------+---------
  1023 | 1001.04 | 995.99 | 1003.23 | 1024067.47 |   1024067.47 | 1001.60
(1 row)

-- 2.2 behavior was this:  (using 15000 length segment) good enough for me

count |   avg    |   min    |   max    |  sum_segs  | total_length |  median
-------+----------+----------+----------+------------+--------------+-------
---
    69 | 14841.56 | 14769.28 | 14873.96 | 1024067.47 |   1024067.47 |
14850.43
(1 row)


-- 2.3.2 and above (2.3.0 was pretty broken as to not be usable in many
cases)  (using 1000 length segment) (bad scenario)

count |   avg   |   min   |    max    |  sum_segs  | total_length | median
-------+---------+---------+-----------+------------+--------------+--------
-
   893 | 1146.77 | 1000.27 | 131222.90 | 1024067.47 |   1024067.47 | 1000.95
(1 row)


-- 2.3.2 changing 1000 to 15000  (good scenario)
count |   avg    |   min    |   max    |  sum_segs  | total_length |  median
-------+----------+----------+----------+------------+--------------+-------
---
    69 | 14841.56 | 14830.20 | 14852.53 | 1024067.47 |   1024067.47 |
14841.66
(1 row)

I much preferred the consistency of old behavior and given no one seems to
want to support the new behavior because its much more complicated, I'd just
assume we go back to the good ol' 2.2 days

Thanks,
Regina