No subject
Thu Jun 7 16:37:16 CEST 2018
shapestore. In hindsight the only reason for doing so was that the
shapelib has different objects for the shapefile(s) and the dbf file,
which of course matches the way the data is organized into different
files. So the distinction between shapestore and table is an artifact
of the shapefile format. When we added the postgis support we should
have adopted the table interface for the entire shape store, making the
geometry data an additional column for those shape stores that don't
store the geometries in columns in the first place.
> + def setBoundingBox(self, bbox):
> + """Set the bounding box of this shape store
> +
> + The coordinate system used is whatever was used in the shape store.
> + """
> + self._bbox = bbox
I don't think we need setBoundingBox. That the bounding box is
determined once and is then stored in an instance variable is an
implementation detail of the ShapefileStore (and apparently
OGRShapeStore). That kind of implementation assumes that the value
never changes during a Thuban session. That was somewhat OK for the
uses we developed Thuban for originally, but especially for the
OGRShapeStore it would be better to always retrieve it from OGR.
So, I don't think we should encourage storing the bounding box in an
instance variable in the base class.
> + def BoundingBox(self):
> + """Return the bounding box of the shapes in the shape store.
> +
> + The coordinate system used is whatever was used in the shape store.
> + If the shape store is empty, return None.
> + """
> + return self._bbox
A default implementation of BoundingBox only makes sense if the bbox is
stored in an instance variable, so it should either be omitted or raise
NotImplementedError
Bernhard
--
Intevation GmbH http://intevation.de/
Skencil http://skencil.org/
Thuban http://thuban.intevation.org/
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)