[postgis-devel] ST_Simplify collapse policy

[Sandro Santilli]

Brainpicking for ST_Simplify behavior, as per:
http://trac.osgeo.org/postgis/ticket/2093

What the 1.5.x and the 2.0.2 versions of PostGIS do
when you simplify a Polygon by a tolerance higher than
the maximum distance between any 2 vertices in any ring
is making the polygon disappear:

 SELECT ST_AsText(ST_Simplify(
  'POLYGON((0 0, 10 0, 10 0, 0 10, 0 0))',
  20
 )); -- returns NULL

When I changed the above to still return something:
http://trac.osgeo.org/postgis/ticket/1698
somebody complained because the old behavior was preferred:
http://trac.osgeo.org/postgis/ticket/1987
and so we're now back to the NULL return.

What concerns me the most is that the NULL return behavior
is not consistent, in that when you apply an high
simplification to lines, making them collapse, those lines
are NOT removed into nulls:

 SELECT ST_AsText(ST_Simplify(
  ST_Boundary('POLYGON((0 0, 10 0, 10 0, 0 10, 0 0))'),
  20
 )); -- returns 'LINESTRING(0 0)'

You can see for a closed line it becomes an invalid line,
and for a 2-vertices line:

 SELECT ST_AsText(ST_Simplify(
    'LINESTRING(0 0, 10 0)'::geometry,
    20
 )); -- returns 'LINESTRING(0 0, 10 0)'

It remains untouched.

This is easy to explain, in that the Douglas Peuker algorithm
picks two points (first and last) and incrementally adds the
farthest vertex from the segment connecting them.
So a closed line remains a point, a 2-vertices lines remains
that single segment.

The difference is that while for polygons the output of DP is
checked and converted to NULL when number of vertices drops
below 4, but the same is not done for lines (number of vertices
dropping below 2).

So question: should the behaviors be consistent (both NULL) or
would it become another backward compatibility concern ?

--strk;