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

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Mon Sep 22 08:59:29 PDT 2008


Martin Davis wrote:

> Another alternative would be to detect the case where a ring has fewer 
> than 4 points or is not closed, and to add the start point a sufficient 
> number of times to make up the 4 points and close the polygon.  This 
> still allows the geometry to be entered, it will still test as invalid 
> if it originally was, but it ensures that the geometry in the database 
> is at least structurally corrrect.  This check should be pretty fast - 
> much faster than testing for full validity.

Hmmm. I'm not really a fan of that particular approach since I'm a great 
believer in the principle of least surprise. I've lost count of the 
number of hours I've spent chasing down bugs in applications which were 
caused by incorrect input, yet the programmer decided they knew how to 
correct my data by supplying what turned out to be incorrect defaults 
rather than rejecting it :(

The main reason I don't think this is a good idea is because it is a 
common mistake for people new to PostGIS to not add the closing point of 
a polygon ring in WKT. It's very easy when writing code to emit a set of 
values to miss the first/last value - so if we allow the input and 
silently correct it, then the developer is not aware his code has a 
fundamental error and carries on pushing incorrect data into the DB. Not 
  to mention that if they migrate to a database that *does* enforce the 
SFS to the letter then teaching bad habits in PostGIS is not a good idea.

> Mark, I'm not surprised that you found that:
> (a) other spatial DBs are all over the place WRT how they enforce validity
> (b) they don't document this well!
> Sadly, there is no standard covering what the DB should actually be able 
> to store, and spatial DB documentation is woefully short on detail where 
> it really counts. (Except maybe for PG now that Kevin and Regina et al 
> are in action!  8^)

Yeah, the documentation is exceptionally poor in this area :(

> One "DB" that you missed is SDE.  It has a very draconian approach to 
> correctness - geometries are forced to be 100% valid before they are 
> allowed in the DB.  I'm not sure if this is still the case, but it used 
> to be that SDE would actually attempt to alter geometry topology to 
> ensure validity.  There's a certain appeal to this, but ultimately I 
> agree with Paul - "be forgiving about what you accept and rigorous about 
> what you emit".  Ain't no chance to fix geometry if you can't get it in 
> the DB.
> 
> OGC seemed to follow this maxim to a limited extent - e.g. the SFS spec 
> doesn't care about ring orientation (which is NOT respected in some 
> DBs...).  However, they drew the line at ring structure - gotta have >= 
> 4 pts & closed.  Not sure why they did this - perhaps they felt that 
> creating this structure was easy enough that it wasn't a technical 
> barrier.  Or more likely, they just never thought about it...

It does seem to make *some* sense when I look at it. For example, 
guaranteeing that a polygon has >=4 points & closed means that it has a 
defined area, rather than being unknown.

Having slept on it, my thinking is now along the lines of what I 
suggested in my response to David's email - enforce the checks by 
default, but provide a stored procedure to allow the checks to be 
disabled for the duration of the session. Then people who want to use 
PostGIS to process invalid geometries can explicitly invoke this 
behaviour and so be aware of the consequences of doing so.


ATB,

Mark.

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



More information about the postgis-devel mailing list