[geos-devel] Invalid geometries from GEOS operations

[strk]

Oh, forgot to mention: in trunk you can choose whether
or not to enable the check for validity thus giving
SnapOp a chance to give you valid result or exception.

Default is don't check (like it's always been), you can change
by defining GEOS_CHECK_COMMONBITS_VALIDITY in
include/geos/geom/BinaryOp.h (around line 120)

Note that defining that macro would make GEOS closer
to JTS in functionality.

-strk;

On Fri, Aug 27, 2010 at 04:21:43PM +0200, strk wrote:
> I've spent some days enhancing the XMLTester to check
> for validity of returned geometries and found a dozen
> or more such cases (6 couple of inputs, multi-ops for
> some of them).
> 
> All the invalidities come out from GEOS unchecked use of
> CommonBitsOp, whereas such operation is known to possibly
> yeld collapsed poligons due to loss of precision when 
> translating back (re-adding the previously stripped bits).
> 
> In JTS, an EnhancedBitsOp class is used to basically add
> a validity check around the CommonBitsOp to ensure the
> result would be checked before returning.
> In GEOS, doing a similar thing would be nice as we could
> then try something else (SnapOp). Well, I did and that
> fixed 5 over 6 tests. Unfortunately the last test broke
> completely, that is it would not return an invalid geometry 
> (as it did before) but rather an exception.
> 
> OUT OF DETAIL, INTO THE POINT
> 
> Ok, simple question for you now is:
> Should GEOS always throw an exception in preference over
> returning an invalid geometry ?
> 
> 
> --strk;
> 
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html