[gdal-dev] Open source vector geoprocessing libraries?

[Jan Hartmann]

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