[gdal-dev] ogr2ogr error handling

[scottm361]

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


My questions:

1. Does ogr2ogr omit the offending geometries above (or others) when
-skipfailiures is used in the resulting output
2. Are geometry errors ever "created" by reprojection?  Presumably due to
floating point error some geometries might be shifted slightly relative to
each other.
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.