[gdal-dev] ogr2ogr error handling

[Even Rouault]

Le mercredi 07 mai 2014 20:30:45, scottm361 a écrit :
> I am a developer on an application that will potentially use ogr2ogr to
> re-project shapefiles (and potentially other ogr supported formats)
> 
> What I am wondering about is the nature of geometry error handling in
> ogr2ogr.  My assumption is that geometry errors are quite common in user
> supplied data, so I am wondering if I need to rethink the automated use of
> ogr2ogr for this purpose.
> 
> Geometry errors that I have encountered so far are:
> 
> ERROR 1: TopologyException: found non-noded intersection between LINESTRING
> (-1.77558e+006 7.46242e+006, -1.77596e+006 7.46259e+006) and LINESTRING
> (-1.77596e+006 7.46259e+006, -1.77593e+006 7.46258e+006) at
> -1775935.412652828 7462582.2040281445
> 
> ERROR 1: TopologyException: side location conflict at -1828580.797204141
> 7355153.6866245456
> 
> ERROR 1: TopologyException: unable to assign hole to a shell
> 

Those are GEOS errors. Are you doing some clipping/spatial filtering too ? What 
is your ogr2ogr command line ?

> 
> My questions:
> 
> 1. Does ogr2ogr omit the offending geometries above (or others) when
> -skipfailiures is used in the resulting output

It is difficult to tell for sure. It might depend on the call site that triggers 
the error

> 2. Are geometry errors ever "created" by reprojection?  Presumably due to
> floating point error some geometries might be shifted slightly relative to
> each other.

Reprojection could create topological weirdness. For example if you convert a 
polygon from polar projection to geodetic projection.

> 3. If the answer to 2 is "Yes", does that mean topology exceptions like
> above are thrown when detected in the source data, AND in the process of
> reprojecting the result?
> 4. Generally speaking, from a reliablility and data integrity standpoint,
> are errors such as these safe to ignore and carry on processes using
> -skipfailiures, or will users be dismayed by things such as missing
> features, which are indirectly a result of their own bad data
> 5. Is there any way to fix the geometry in the OGR context before
> attempting to reproject?
> 
> Thank you !
> Scott Morken
> 
> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/ogr2ogr-error-handling-tp5139067.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html