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

[Martin Davis]

Mark Cave-Ayland wrote:
> 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.
Fair enough, and generally I'm in agreement with the POLS.  However, SDE 
has operated this way for years (not that that's necessarily going to be 
seen as the best example on this forum  8^)
>
>> 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.
>
Might this complicate debugging and error reporting?   There would now 
be two different modes of operation, so some bugs and errors would 
require specifiying which mode is being used, and require the coder to 
ensure they tested under that mode.  Not to mention two different 
pathways through the code...

Given all this I think I might vote for sticking with the current 
situation - Polygon Rings require >= 4 pts, as per spec.
>
> ATB,
>
> Mark.
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022