[postgis-tickets] [PostGIS] #2093: Add extra policy argument to control ST_Simplify behavior

[PostGIS]

#2093: Add extra policy argument to control ST_Simplify behavior
-------------------------+--------------------------------------------------
 Reporter:  robe         |       Owner:  strk         
     Type:  enhancement  |      Status:  new          
 Priority:  medium       |   Milestone:  PostGIS 2.2.0
Component:  postgis      |     Version:  trunk        
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by strk):

 * cc: jatorre (added)


Comment:

 So, back to this. What would useful behaviors be in case of lines and
 polygon collapses ?
 Of course the request here is to keep something rather than returning
 NULL.
 EMPTY is likely not useful at all as you probably want the georeference.

 The smallest valid type to represent the georeference would be a point,
 but returning a point for a line or areal input might result in unexpected
 rendering, as the rendering engine may behave
 differently based on input type (for example placing markers for points).
 So we're left with the only options being returning a structurally or
 topologically invalid geometry.

 A topological invalid geometry would be a line with no interior (2
 cohincident vertices) or a polygon with no interior (4 cohincident
 vertices). A structurally invalid geometry would be a line with a single
 vertex and a polygon with a single vertex.

 I'm making the difference because some functions may choke when fed
 structurally invalid geometries, in PostGIS, so I'm wondering if the same
 may also happen in clients. For sure the structurally invalid case would
 be the smallest, which may matter in case you have million of collapsed
 polygons to transfer to the client.

 On a side note, would we want to control whether or not to keep the
 boundary of collapsed holes too ? Imagine a big swiss cheese geometry with
 all holes collapsed. Do we want to keep them all, or just keep the shell ?

 To recap, we need the following policies:

  - lines: null, structurally invalid, topological invalid, collapse to
 point
  - polygon shells: null, structurally invalid, topological invalid,
 collapse to line or point
  - polygon holes (for non-collapsed shell): remove, structurally invalid,
 topologically invalid

 I've to go check for the current behavior, as I lost track of which one it
 is.

 Also, the same set of policies would be useful to be also accepted by
 ST_SnapToGrid, so it's worth having them well defined once for all.

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