Hi Even,<br><br> 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.<br>
<br> Best regards,<br> Simon<br><br><br><div class="gmail_quote">On Fri, Apr 8, 2011 at 11:40 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Selon Simon Lyngby Kokkendorff <<a href="mailto:silyko@gmail.com">silyko@gmail.com</a>>:<br>
<br>
Yes indeed, you've precisely described the behaviour of the code of the OGR<br>
shapefile driver. The shapefile format stores the extent of the shapes stored in<br>
the shapefile.<br>
When you append a new shape in a shapefile, the shapefile driver will extend the<br>
layer extent with the shape bounding box. This works well and efficiently when<br>
creating a shapefile from scratch.<br>
The same algorithm is also used when updating an existing shapefile, and it's in<br>
that case you can get the weird behaviour you see if you move a shape that was<br>
touching the layer extent. In that case the shapefile driver should invalidate<br>
the layer extent and recompute it entirely by iterating over all the shapes,<br>
which could be costly if the shapefile is big. But the current situation is not<br>
very satisfactory. And a an optimization, the invalidation could be only done if<br>
the bounding box of the old shape touches the layer extent.<br>
The deletion of a feature could also lead to the same behaviour.<br>
<br>
Could you file a ticket about this in GDAL trac ?<br>
<div><div></div><div class="h5"><br>
> Hi List,<br>
><br>
> I have observed a puzzling behaviour of the reported extent of an ogr<br>
> layer after geometries of features have been modified, with the file opened<br>
> in update mode. I use gdal 1.7 via the pyhton bindings, open a dataset with<br>
> ogr.Open(fname,update=True), then loop through layers and features and<br>
> modify geometries like:<br>
> geom=feature.GetGeometryRef(), new_geom=some_modification(geom),<br>
> feature.SetGeometry(new_geom), layer.SetFeature(feature). However, ogr (and<br>
> Qgis, which uses ogr for that I suppose) reports the new layer extent as,<br>
> the "minimal bounding box" of the new and old extents. So somehow, the<br>
> extent before geometry modification is still stored somewhere in the<br>
> dataset. The same observations also hold for a dataset which is modified by<br>
> hand using the editing tools in Qgis! Consider the following ogrinfo output<br>
> from a file with one layer, containing one point:<br>
> INFO: Open of `qgis_test.shp'<br>
> using driver `ESRI Shapefile' successful.<br>
><br>
> Layer name: qgis_test<br>
> Geometry: Point<br>
> Feature Count: 1<br>
> Extent: (0.077586, 0.577586) - (10.670690, 31.805172)<br>
> Layer SRS WKT:<br>
> GEOGCS["GCS_WGS_1984",<br>
> DATUM["WGS_1984",<br>
> SPHEROID["WGS_1984",6378137,298.257223563]],<br>
> PRIMEM["Greenwich",0],<br>
> UNIT["Degree",0.017453292519943295]]<br>
> test: String (80.0)<br>
> OGRFeature(qgis_test):0<br>
> test (String) = nothing<br>
> POINT <a href="tel:%2810.6706896551" value="+16706896551">(10.6706896551</a>72414 31.805172413793112)<br>
><br>
> Even though the point clearly lies at (10.67,31.80) the previous position is<br>
> still included in the extent. Is this a bug or is there some reasoning<br>
> behind this behaviour?<br>
><br>
> Best Regards,<br>
> Simon. National Survey and Cadastre of Denmark<br>
><br>
<br>
<br>
</div></div></blockquote></div><br>