[postgis-users] newbie question about non closed rings

Martin Davis mbdavis at refractions.net
Fri Apr 17 09:40:02 PDT 2009


I've wondered about this issue in JTS as well.  On one hand it's nice to 
require a certain level of validity, so that validity doesn't have to be 
checked for every operation, and so the user doesn't get unexpected 
failures later in processing.  On the other hand, it's convenient to be 
able to represent any possibly geometry in the model, to allow cleaning 
to be performed.

One middle ground might be to force rings to be closed by adding a 
closing point.  This preserves all input information, and allows the 
problem to either be ignored (if the closed ring is valid) or fixed 
using the same approach as for an invalid geometry.

Another option is to ensure that the tools loading the data are able to 
correct this problem.  Although they probably would correct it by simply 
adding a closing point - in which case the DB might as well do it.


Mark Cave-Ayland wrote:
> Paragon Corporation wrote:
>
>> Mark Cave-Ayland,
>> I forget were we planning on making this a switch option in later 
>> versions
>> of PostGIS?  So that you could bring in polygons with unclosed rings 
>> and fix
>> them in the db? 
>
> Well the result of the earlier investigation showed that having a 
> switch will just cause more problems than it will solve so this isn't 
> going to work :(
>
> I've always been a great believer in keeping the checking reasonably 
> strict in an attempt to try and maintain the quality of geometries 
> within the database, however recently there appears to be an 
> increasing use cases on the list of people wanting to perform 
> cleanup/processing directly in the database and it would be stupid to 
> ignore this.
>
> I think that if both Oracle Spatial and MS-SQL allow geometries to be 
> stored with deformed features (i.e. incomplete rings) then I could be 
> persuaded that the ERROR upon insertion should be downgraded to a 
> WARNING instead. Would anyone like to check this behaviour and report 
> back?
>
>
> ATB,
>
> Mark.
>

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




More information about the postgis-users mailing list