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
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
