Jan Hartmann wrote:
On 13-1-2010 15:49, Ari Jolma wrote:
Jan Hartmann wrote:
Just curious, would it make sense / be possible to implement
indexing in OGR, something like a
generalized version of Mapserver's shptree, the "quadtree-based
spatial index for a shapefiles"?
http://mapserver.org/utilities/shptree.html
It could make sense to have a in-memory index for in-memory
geometries. Pehaps use GiST library(1) (I don't know whether it can
use in-memory indexes) for geometries in an OGRGeometryCollection or
OGRMemLayer if it's available.
For other formats it might not make sense because OGR is not
responsible for the actual geometries. As have been said, one should
use PostGIS format, which has this functionality built-in, for larger
and more static datasets.
Is that so? Reading the OGR API tutorial
(http://www.gdal.org/ogr/ogr_apitut.html), I see that all geometries,
frowm whatever input source, are represented internally as a generic
OGRGeometry pointer, which is a virtual base class for all real
geometry classes (http://www.gdal.org/ogr/classOGRGeometry.html). Most
of the GEOS functionality can be implemented on OGRGeometries, so in
principle the same could be done with indexing libraries (GIST,
b-tree, quadtree, etc). Such indices should be written out to disk to
be of any use at all, of course, like shptree does.
What I meant is that with other formats than the in-memory format, the
features are stored on disk (possibly even on remote servers) and only
available for indexing when retrieved. When they are retrieved, they are
of course OGR objects and accessable through the generic OGR API. Maybe
it's possible but it would probably mean that the library would need to
retrieve and go through all the features, and prepare and store into
some local(?) file the index. Thus I think that for those formats, it's
up to the format itself to provide the indexing or not.
Ari
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
