[postgis-devel] SVN trunk parser modifications stage 2

Obe, Regina robe.dnd at cityofboston.gov
Mon Oct 27 16:50:37 PDT 2008


Chris,

I guess the curious question I have is how exactly do you get say a polygon with no closed rings in the database.  I've seen others
mysteriously do it, but I'm a bit perplexed how they can since I've really tried hard and can't.  Other invalid geometries I can understand. 

Unless of course there is some magical combination of postgis functions that creates not just invalid geometries, but really really invalid geometries or this was allowed a long long time ago.  

I would be interested in knowing what that magical formula is :).

So as far as backward compatibility goes - my point is ST_Geom... are already doing basic checks so doing basic checks by default would
not break backward compatibiliity and in fact not doing any checks at all would break backward compatibility.

Thanks,
Regina



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Chris Hodgson
Sent: Mon 10/27/2008 7:20 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] SVN trunk parser modifications stage 2
 
The point is, that if you allow things to be loaded using "0-level" no 
checking, regardless of how it gets into the database there will be a 
(reasonable) expectation to be able to to use pg_dump to dump and reload 
it. Thus if your default parsing level does any checks at all, it will 
potentially fail to load data that had been loaded without checks.

If we can use the postgresql-variable based approach, all it would take 
is a single

SET postgis.default_parser_check_level TO 0;

at the top of your dump file to fix this (which is still more work than 
some would find acceptable). With the approach that requires using a 
special function call to load without checks, it requires a lot more 
work to fix pg_dump output into something that can be reloaded - and it 
has to use full INSERTs, not COPY.

Although, I believe it is possible (perhaps even Mark's intention) for 
the _in and _out functions to default to 0-level checking, while the 
other parsing functions (geomfromwkt, etc.) default to "1". This way, 
you have to specifically set the parse level in order to cause trouble 
loading - just enough rope to hang yourself. I admit it seems a bit 
inconsistent, but that seems to be the price of maintaining forwards and 
backwards compatibility - forwards for being able to load less-valid 
geometries, and backwards for people having the expectation that 
inserted geometries should "work" with whatever functions they currently 
work with).

Chris

Obe, Regina wrote:
>
> > Right, if the default behavior is not to validate, then it will load
> > just fine.  But I have been assuming that the default behavior will be
> > to validate, since all of Mark's comments point in this direction:
>
> On 2008-10-20, Mark Cave-Ayland wrote:
>  >     0 - No checking; all checks are disabled
>  >     1 - OGC level checking; check for minimum numbers of points and
>  >         closure of polygons
>  >     2 - GEOS level validation; check input geometries are valid as
>  >         per the GEOS IsValid() function
>  >
>  > The first time the parser/unparser is invoked then we check to see if
>  > this setting is present; if it is then the current parser check 
> level is
>  > set this value. Otherwise a default value of 1 is chosen.
>
> Hmm I interpreted that to mean 1 is the current non-breaking behavior 
> which is mild checking for non-closed rings etc.. 
> For example if I were to stuff this in
>
> SELECT ST_GeomFromEWKT('POLYGON((1 2 3, 4 5 6, 2 3 4))')
>
> Even in current installs it would not load.  So the 0 is actually a 
> new feature - where we let true aliens such as the above into the mixture.
>
> I was thinking of overloading instead of GeomFrom..WithStrict, because 
> I figured first pass around
> we will not be able to control at the GUC level because of Mark's 
> observations, but by overloading we will not be changing interfaces.
>
> So an install with no postgis GUC ability would default the 
> ST_GeomFromEWKT, ST_GeomFromEWKB to (hmm I guess 1) or use the 
> overloaded functions to force stricter or less strict behavior and one 
> with GUC ability later on would be
> able to read default from GUC instead of assuming 1.
>
> Hope that helps,
> Regina
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *The substance of this message, including any attachments, may be 
> confidential, legally privileged and/or exempt from disclosure 
> pursuant to Massachusetts law. It is intended solely for the 
> addressee. If you received this in error, please contact the sender 
> and delete the material from any computer. *
>
> ------------------------------------------------------------------------
>
> * Help make the earth a greener place. If at all possible resist 
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel




-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081027/46910a2e/attachment.html>


More information about the postgis-devel mailing list