[postgis-devel] Minimum number of points in a POLYGON ring?

[Mark Cave-Ayland]

Paul Ramsey wrote:
> I'm quite worried about increasing the barriers to getting data into
> PostGIS. I think we should let in anything at all, and declare it's
> validity later. Effort should be spent on tools to (a) find bad data
> and (b) make bad data better. IMO
> 
> P

Righto.

In terms of the check itself, I don't think increasing the minimum 
number of points from 3 to 4 will affect many people since I can't see 
that many people defining a POLYGON type as having anything less than 3 
distinct points anyway.

The most interesting aspect of this discussion is *where* should the 
validation of geometries take place - should it take place during 
insertion or during processing? I've spent some time looking around 
various bits of documentation on the web and thought I would try and 
summarise these below:


Oracle Spatial
==============

http://www.comp.dit.ie/btierney/Oracle11gDoc/appdev.111/b28400/sdo_objrelschema.htm

Section 2.2.4 implies that polygon rings must be closed, and should be 
specified in a particular order. But there is no mention of whether this 
is enforced at creation time.


Informix
========

http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.spatial.doc/spat310.htm
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.spatial.doc/spat50.htm

The section for ST_Polygon() specifies that polygons are always simple, 
while the second link for the definition of simple implies there are 
some shapes that can break the rules. A polygon is not listed as one of 
them, however. There is no indication of whether this is enforced at 
insertion time.


MySQL Spatial
=============

http://www.cit.gu.edu.au/doc/mysql_doc/spatial-extensions.html#gis-class-polygon

This details a list of assertions for polygons, however it is unclear 
from the documentation if these are enforced.


SQL Server 2008
===============

http://jasonfollas.com/blog/archive/2008/04/11/sql-server-2008-spatial-data-part-6.aspx
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=2816802&SiteID=1

The "ST is {something}" section mentions in the IsClosed() section that 
"by definition a polygon has to be closed" - again, no mention of the 
method of enforcement.

The second link is interesting in that the stack trace mentions an 
"IsValidExpensive" function which implies that the more expensive 
IsValid() checks are being used on insertion.


SQL/MM
======

http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf

Page 229 point 9 specifically documents that the polygon rings should be 
topologically closed; points 10 and 11 specify a couple of other 
restrictions which I'm a little hazy about - I'm not sure whether these 
checks are doable at parse time, however they look as if they might be 
computationally expensive (i.e. maybe something to leave for IsValid).


So wow. While some behaviour can be implied from the documentation, the 
point at which validation occurs is such a grey area that all I can 
suggest is that we actually try some non-closed polygons in different 
databases and see what happens. Any volunteers? ;)

Having read all of the links above, I still personally feel that we 
shouldn't drop the ring validity checks and number of point checks since 
otherwise I fear that unexpected bad things might happen. And I have 
nightmares of newbies creating so called OGC compliant WKT geometries 
which don't have the first and last points of the ring equal :(

Then again, it seems a few people are interested in being able to 
brute-force bad things into the database to fix them up later. I think 
that integrating liblwgeom into shp2pgsql/pgsql2shp would allow some 
kind of --force option that would by-pass the parser checks by calling a 
stored procedure such as "SELECT postgis_parser_check(0)" which would 
turn off the checks for the duration of that session. Does that sound 
like a reasonable compromise?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063