<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] SVN trunk parser modifications stage 2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Chris,<BR>
<BR>
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<BR>
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.<BR>
<BR>
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. <BR>
<BR>
I would be interested in knowing what that magical formula is :).<BR>
<BR>
So as far as backward compatibility goes - my point is ST_Geom... are already doing basic checks so doing basic checks by default would<BR>
not break backward compatibiliity and in fact not doing any checks at all would break backward compatibility.<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Chris Hodgson<BR>
Sent: Mon 10/27/2008 7:20 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] SVN trunk parser modifications stage 2<BR>
<BR>
The point is, that if you allow things to be loaded using "0-level" no<BR>
checking, regardless of how it gets into the database there will be a<BR>
(reasonable) expectation to be able to to use pg_dump to dump and reload<BR>
it. Thus if your default parsing level does any checks at all, it will<BR>
potentially fail to load data that had been loaded without checks.<BR>
<BR>
If we can use the postgresql-variable based approach, all it would take<BR>
is a single<BR>
<BR>
SET postgis.default_parser_check_level TO 0;<BR>
<BR>
at the top of your dump file to fix this (which is still more work than<BR>
some would find acceptable). With the approach that requires using a<BR>
special function call to load without checks, it requires a lot more<BR>
work to fix pg_dump output into something that can be reloaded - and it<BR>
has to use full INSERTs, not COPY.<BR>
<BR>
Although, I believe it is possible (perhaps even Mark's intention) for<BR>
the _in and _out functions to default to 0-level checking, while the<BR>
other parsing functions (geomfromwkt, etc.) default to "1". This way,<BR>
you have to specifically set the parse level in order to cause trouble<BR>
loading - just enough rope to hang yourself. I admit it seems a bit<BR>
inconsistent, but that seems to be the price of maintaining forwards and<BR>
backwards compatibility - forwards for being able to load less-valid<BR>
geometries, and backwards for people having the expectation that<BR>
inserted geometries should "work" with whatever functions they currently<BR>
work with).<BR>
<BR>
Chris<BR>
<BR>
Obe, Regina wrote:<BR>
><BR>
> > Right, if the default behavior is not to validate, then it will load<BR>
> > just fine. But I have been assuming that the default behavior will be<BR>
> > to validate, since all of Mark's comments point in this direction:<BR>
><BR>
> On 2008-10-20, Mark Cave-Ayland wrote:<BR>
> > 0 - No checking; all checks are disabled<BR>
> > 1 - OGC level checking; check for minimum numbers of points and<BR>
> > closure of polygons<BR>
> > 2 - GEOS level validation; check input geometries are valid as<BR>
> > per the GEOS IsValid() function<BR>
> ><BR>
> > The first time the parser/unparser is invoked then we check to see if<BR>
> > this setting is present; if it is then the current parser check<BR>
> level is<BR>
> > set this value. Otherwise a default value of 1 is chosen.<BR>
><BR>
> Hmm I interpreted that to mean 1 is the current non-breaking behavior<BR>
> which is mild checking for non-closed rings etc..<BR>
> For example if I were to stuff this in<BR>
><BR>
> SELECT ST_GeomFromEWKT('POLYGON((1 2 3, 4 5 6, 2 3 4))')<BR>
><BR>
> Even in current installs it would not load. So the 0 is actually a<BR>
> new feature - where we let true aliens such as the above into the mixture.<BR>
><BR>
> I was thinking of overloading instead of GeomFrom..WithStrict, because<BR>
> I figured first pass around<BR>
> we will not be able to control at the GUC level because of Mark's<BR>
> observations, but by overloading we will not be changing interfaces.<BR>
><BR>
> So an install with no postgis GUC ability would default the<BR>
> ST_GeomFromEWKT, ST_GeomFromEWKB to (hmm I guess 1) or use the<BR>
> overloaded functions to force stricter or less strict behavior and one<BR>
> with GUC ability later on would be<BR>
> able to read default from GUC instead of assuming 1.<BR>
><BR>
> Hope that helps,<BR>
> Regina<BR>
><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
> ------------------------------------------------------------------------<BR>
><BR>
> *The substance of this message, including any attachments, may be<BR>
> confidential, legally privileged and/or exempt from disclosure<BR>
> pursuant to Massachusetts law. It is intended solely for the<BR>
> addressee. If you received this in error, please contact the sender<BR>
> and delete the material from any computer. *<BR>
><BR>
> ------------------------------------------------------------------------<BR>
><BR>
> * Help make the earth a greener place. If at all possible resist<BR>
> printing this email and join us in saving paper. *<BR>
><BR>
> * *<BR>
><BR>
> * *<BR>
><BR>
> ------------------------------------------------------------------------<BR>
><BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
> <BR>
<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>