[postgis-devel] Removing geometry parsing checks for data loading

[David Fuhry]

$ shp2pgsql -D poly_1.shp poly_1 | psql
...
ERROR:  geometry contains non-closed rings
CONTEXT:  COPY poly_1, line 389, column the_geom:
"01060000000100000001030000000100000007000000F06044A5C0B53E41086D2D657C8C23413D5FFD71BFB53E4191925462..."
ROLLBACK

What's the best way to drop these geometry-parsing checks (from
lwgparse.c, I assume)?  Is commenting out the if (...) error(...); lines
in popc() sufficient and safe?

Obviously as part of my import routine, I check that the geometries are
isvalid() later.  For my uses, geometry errors are best resolved with
custom logic /after/ the data is in the db.

If Mark and others have serious concerns about people naively using
non-isvalid() geometries, then I suggest a configurable parameter to
shp2pgsql (on by default) which adds an isvalid() check constraint to
the table.  The call to AddGeometryColumn() already adds ndims,
geometrytype, and srid checks to the table; why not the equally
important isvalid() too?

Thanks,

Dave Fuhry

http://kddb1.kddb.cs.kent.edu/tmp/poly_1.zip


On Fri, Jun 20, 2008 at 5:17 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>>
>> This is a well-chewed issue, and we have come down repeatedly in
>> favour of allowing invalid geometry to be loaded. Which, I suppose,
>> means we should loosen the parser to allow even non-closed rings.
>
> Dropping the checks from the parser is a relatively straightforward 
thing to
> do. My concern would be that some of the basic routines (e.g. area
> calculations) would start to fail if rings weren't closed :(
>
>> What *does* need to be done (issue for me, it's not that hard) is a
>> few additional hooks to the GEOS isvalid routines so people can easily
>> identify WHY and WHERE their geometries are invalid.
>
> Yeah, that would be quite useful to have. Is this something that would
> require work on GEOS before the functionality could be added to PostGIS?
>
>> More difficult, probably need in of some funding to get Martin's
>> attention, is some formalized cleaning routines that go beyond what
>> Buffer(0) can accomplish.
>
> There does seem to be a lot of discussion recently about new features;
> perhaps we need to add a "How to sponsor a feature" section to the wiki
> explaining how companies can approach developers to get new features
> implemented...
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063