Frank,
Your solution seems to work for me. I don't know ArcGIS well enough to dig
into why it behaves that way, but deleting the features outside the claimed
extent (they aren't showing up as null in ogr), then using ogr2ogr does
result in a safe, non-corrupt shapefile that is usable with both A
Tom,
so far as I am aware, neither GDAL/OGR nor ArcGIS update a shapefile in situ
- I believe that ArcGIS creates a temporary dataset, performs the update as it
copies the input data over, then deletes and renames to get the replacement. I
have used a similar method with Shapelib over the
Tom Jeffery wrote:
Chaitanya,
I wrote up a method to find and delete geometries that fall outside of the
reported Extent from the shapefile. It seems to be doing the trick, though
with some strange side effects.
It finds the bad features properly, and I remove them with
layer.DeleteFeature(
Chaitanya,
I wrote up a method to find and delete geometries that fall outside of the
reported Extent from the shapefile. It seems to be doing the trick, though
with some strange side effects.
It finds the bad features properly, and I remove them with
layer.DeleteFeature(feature.GetFID()), bu
Tom,
The -skipfailures flag skips only failures to create new features. Null
geometries in non-null shapetype shapefile are not handled.
The only way I can think of to clean such a file is by checking the geometry
in each feature.
On Thu, Aug 5, 2010 at 1:01 AM, Tom Jeffery wrote:
>
> Chaitanya
Chaitanya,
I've found the issue with the particular shapefile I'm using. It actually
has some null geometries in it, which are fixable using ESRI's "Repair
Geometry" tool. I read that ogr2ogr is also suppose to remove records with
empty geometries, but it doesn't seem to be working on my file,
Tom,
GDAL/OGR updates the shapefile along with the dbf file when a feature is
changed. That means updating the extents according to the geometries in the
changed features. My guess is that there is a problem reading a feature's
geometry extents.
Call the OGRGeometry::getEnvelope method on each ge
Chaitanya,
The updated file is read properly with ogrinfo. The only difference between
ogrinfo -al between the two, besides the new field that was created, is the
extent, which looks like this:
Original file:
Extent: (1528126.013001, 45899.818172) - (1542444.478012, 61468.662925)
Updated file: