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

[strk]

Solution #2 is the best IMHO.
There has to be a way to run the check again at any time, though,
after any modification, to ensure cached status is not wrong.
This possibility may be given but not forced (if GEOS ensures to
keep valid geoms valid there is no need to check again - my simplify
function is likely to make them invalid and I would call the checker
updating the status until I make it smarter)

setValidity(geom) -> changes status checking for validity
isValid(geom) -> returns frag after checking

--strk;

dblasby wrote:
> 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