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.
Mind, I agree that this sort of thing is much better done with PostGIS,
it's just that not everyone has a PostGIS database at his disposal, and
even when you have one, it sometimes is easier to use flat files. For
some projects I (have to) use SQLite instead of PostgreSQL, and the same
would be true for an indexed OGR-functionality.
Again, I really don't know how difficult/desirable this would be to
implement.
Jan
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
