ST_RemoveColinearPoints

[robe]

I was surprised we don't have something like this.

This would be a function that is kind of reverse of ST_Segmentize. Instead of adding points, it would remove points from the geometry that don't affect shape of the geometry.

[strk]

You can do that with ST_Simplify(geom, 0)

[robe]

That's what Leo tried first. Doesn't work.

WITH z (x,y) AS (
    VALUES
        (ST_GeomFromText('POLYGON((3 0, 5 0, 5 4, 3 4, 3 0))'),'A'),

        (ST_GeomFromText('POLYGON((2 0, 9 0, 9 2, 2 2, 2 0))'),'A')
        
        
) 

SELECT ST_Simplify(ST_Union(x),0) AS u FROM z;

He wanted to get rid of that bottom extra vertex -

[pramsey]

And if you run it with a very very very tiny tolerance? Probably is just that what you see as a co-linearity isn't quite one at double precision math land?

[dbaston]

Right, ST_Simplify can't remove the start/endpoint of a line. I've seen this pop up occasionally as an issue with various user workarounds, here's an example:

​http://stackoverflow.com/questions/24998203/postgis-how-to-have-the-start-point-of-a-polygon-simplified

[pramsey]

Oh duh, of course! Thanks Dan...

[strk]

That's because the DP algorithm never drops the start or end points. If you scrolled that ring to start at (2 0) it would work

strk=# select ST_AsText(ST_Simplify('POLYGON((3 0,2 0,2 2,3 2,3 4,5
4,5 2,9 2,9 0,3 0))'::geometry, 0));
                     st_astext
----------------------------------------------------
 POLYGON((3 0,2 0,2 2,3 2,3 4,5 4,5 2,9 2,9 0,3 0))
(1 row)

strk=# select ST_AsText(ST_Simplify('POLYGON((2 0,2 2,3 2,3 4,5 4,5
2,9 2,9 0,3 0,2 0))'::geometry, 0));
                   st_astext
------------------------------------------------
 POLYGON((2 0,2 2,3 2,3 4,5 4,5 2,9 2,9 0,2 0))
(1 row)

We're sill missing an ST_Scroll function, which could help here (see also #2175).

This not-crossing the "ring boundary" (structural one, as topologically speaking a ring would not have a boundary) is probably missing from other functions too, like ST_RemoveRepeatedPoints.

[pramsey]

To be able to simplify rings and include start/end points in the calculation we'd need to move to implicit closure (no duplicate end point) which would be a huge model change. First time I've seen a practical advantage to the other model.

[strk]

I don't see how implicit closure helps with the case. It's not the duplicated start-endpoint that Regina wants to get rid of, but the collinear triplet (PN-1),PN=P0,P1.

The problem is we don't detect collinearity because the central point is the end of the subject line, and we don't follow it "to the other side" because we don't intend to ever drop the start/endpoint from a ring in any case.

Is the situation correctly explained, Regina ?

[dbaston]

Can we just be able to tack a special case into the existing simplify logic to handle the start/end point of a ring? Simplify as-is, then simplify segment with startpoint and the vertex to either side, then splice back together?

[robe]

Yes correctly explained. Do not want to get rid of the start /end, but that point in the middle.

I'm happy if we do it in ST_Simplify. We have too many functions already and ST_Simplify is the logical place it should live.

[strk]

But that point in the middle _is_ the start/end point, isn't it ?

It's the substring (9 0,3 0,2 0) that bothers you, and (3 0) is the start/end pont. No way to remove it unless you bless a different vertex as the start/end one, thus my suggestion for engaging an ST_Scroll function

[robe]

Ah okay I see what you are saying. Let's table this then. It's not as serious of a concern as I thought.