[postgis-users] Only allowing valid geometries to be created

[Martin Davis]

I agree with Chris.  Basically Solution #2 is to cache the results of the (expensive) isValid method.  This is the same approach currently used with the envelope, so there's good precedent for expanding this to include validity checking as well.

I considered doing this in JTS as well, but held off for the following reasons:
1. in JTS Geometry points are mutable, so it would be possible for the valid cache to become inconsistent.  (Of course, the envelope has the same problem, which is why we introduced the geometryChanged() method).
2. it would bloat the Geometry structure with yet another value.  It's not much, maybe, but still adds to the overall memory usage
3. I didn't want to force calling isValid even once for a Geometry, if it wasn't needed.

I don't see these as being as much of an issue for PostGIS.  1 can never happen (right?), 2 is minor, 3 is overhead which is worth it in the context of a database, I think.

Rather that changing GEOS, is it possible to put the isValid cache in the PostGIS structure which contains the GEOS Geometry? (or is there such a thing anymore?)

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com


> -----Original Message-----
> From: chodgson at refractions.net [mailto:chodgson at refractions.net]
> Sent: Thursday, April 10, 2003 3:45 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Only allowing valid geometries to be
> created
> 
> 
> I think #2 is the best solution. The problems with the other 
> posibilities 
> (disallowing invalid geometries, slowing down spatial 
> operators) are just 
> innacceptable in my mind, while binary incompatibility is 
> something we will 
> just have to deal with... we haven't even gotten to release 1.0 yet!
> 
> Chris
> 
> Quoting David Blasby <dblasby at refractions.net>:
> 
> > We are soon going to have functions like intersect(g1,g2), 
> xor(g1,g2),
> > union (g1,g2) - these functions pretty much require valid 
> geometries.
> > 
> > The results of a function like union(g1,g2) where g1 or g2 
> are invalid
> > could cause (1) errors (2) invalid results.
> > 
> > I've been thinking about:
> > 
> > 1. Only allow valid geometries to be created.  Basically 
> the creation
> > would look like:
> >         a) Create Geometry  like now (does very small 
> amount of validity
> > checking)
> >         b) run the isvalid() function on it.  If it fails, 
> throw an error
> > I.e.:
> > select 'LINESTRING(0 0, 0 0)'::geometry;
> > ERROR: invalid geometry
> > 
> > In this way (a) tables will only ever have valid geometries (b)
> > functions will always have valid geometries as inputs (c) 
> Only have to
> > run the isValid() function on a geometry once (at creation).
> > 
> > Unfortunately, the main disadvantage to this is sometimes 
> people want to
> > have invalid geometries.  People might have multipolygns 
> that overlap,
> > or GPS tracks that have repeated points, etc...  Unfortunately, they
> > would never be able to get these geometries inside PostGIS 
> - leading to
> > quite a bit of frustration during dataloading or querying.
> > 
> > Also, it would require geos to be installed.  As a work 
> around to this,
> > we could just ignore the validity test -  postgis would 
> behave exactly
> > as it does now.  This will not be a problem because all the
> > sensitive-to-invalid-geometry-functions are in GEOS and, therefore,
> > never callable.
> > 
> > 2. Add a flag to Geometry that is either VALID, INVALID, UNKNOWN.
> >        a) Create Geometry  like now (does very small amount 
> of validity
> > checking)
> >        b) run the isvalid() function on it.
> >                 INVALID - flag geometry
> >                 VALID     - flag geometry
> >                 geos not installed - flag geometry  UNKNOWN
> > 
> > Then the GEOS functions could throw an error if the flag is INVALID.
> >  Bad-dog geometries could still be put into the system, but 
> be unuseable
> > with GEOS .
> > The big problem with this is that these flagged geometries would be
> > binary-incompatible with the current geometries - a dump and restore
> > would be require before you could upgrade.
> > 
> > 3. Keep things as they are  - do a isvalid() whenever you do a GEOS
> > function.  This would work fine, but will be slow due to 
> always running
> > isvalid().
> > 
> > I'm leaning towards #2.
> > 
> > What think?
> > dave
> > 
> > 
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > 
> 
> 
> 
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>