Hi Even, Thanks for the clarification. I'll try to file a ticket about the issue, have to learn how to do that anyway :-) It is not a serious issue of course, the most "annoying" thing about it, from my experience, is that when you use Qgis (which uses ogr) to "zoom to layer extent" on a modified layer you might end up with a view, where your data is a tiny (or invisible) blob in one of the corners.
Best regards, Simon On Fri, Apr 8, 2011 at 11:40 AM, Even Rouault <[email protected]>wrote: > Selon Simon Lyngby Kokkendorff <[email protected]>: > > Yes indeed, you've precisely described the behaviour of the code of the OGR > shapefile driver. The shapefile format stores the extent of the shapes > stored in > the shapefile. > When you append a new shape in a shapefile, the shapefile driver will > extend the > layer extent with the shape bounding box. This works well and efficiently > when > creating a shapefile from scratch. > The same algorithm is also used when updating an existing shapefile, and > it's in > that case you can get the weird behaviour you see if you move a shape that > was > touching the layer extent. In that case the shapefile driver should > invalidate > the layer extent and recompute it entirely by iterating over all the > shapes, > which could be costly if the shapefile is big. But the current situation is > not > very satisfactory. And a an optimization, the invalidation could be only > done if > the bounding box of the old shape touches the layer extent. > The deletion of a feature could also lead to the same behaviour. > > Could you file a ticket about this in GDAL trac ? > > > Hi List, > > > > I have observed a puzzling behaviour of the reported extent of an ogr > > layer after geometries of features have been modified, with the file > opened > > in update mode. I use gdal 1.7 via the pyhton bindings, open a dataset > with > > ogr.Open(fname,update=True), then loop through layers and features and > > modify geometries like: > > geom=feature.GetGeometryRef(), new_geom=some_modification(geom), > > feature.SetGeometry(new_geom), layer.SetFeature(feature). However, ogr > (and > > Qgis, which uses ogr for that I suppose) reports the new layer extent as, > > the "minimal bounding box" of the new and old extents. So somehow, the > > extent before geometry modification is still stored somewhere in the > > dataset. The same observations also hold for a dataset which is modified > by > > hand using the editing tools in Qgis! Consider the following ogrinfo > output > > from a file with one layer, containing one point: > > INFO: Open of `qgis_test.shp' > > using driver `ESRI Shapefile' successful. > > > > Layer name: qgis_test > > Geometry: Point > > Feature Count: 1 > > Extent: (0.077586, 0.577586) - (10.670690, 31.805172) > > Layer SRS WKT: > > GEOGCS["GCS_WGS_1984", > > DATUM["WGS_1984", > > SPHEROID["WGS_1984",6378137,298.257223563]], > > PRIMEM["Greenwich",0], > > UNIT["Degree",0.017453292519943295]] > > test: String (80.0) > > OGRFeature(qgis_test):0 > > test (String) = nothing > > POINT (10.670689655172414 31.805172413793112) > > > > Even though the point clearly lies at (10.67,31.80) the previous position > is > > still included in the extent. Is this a bug or is there some reasoning > > behind this behaviour? > > > > Best Regards, > > Simon. National Survey and Cadastre of Denmark > > > > >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
