[gdal-dev] ogr - layer extent weirdness after geometry update

[Simon Lyngby Kokkendorff]

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
<even.rouault at mines-paris.org>wrote:

> Selon Simon Lyngby Kokkendorff <silyko at gmail.com>:
>
> 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110408/06c5b703/attachment.html