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@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@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 





