[gdal-dev] Concurrent and efficient access to features in OGRLayer

Even Rouault even.rouault at spatialys.com
Fri Mar 23 02:41:40 PDT 2018


Julien,

> That is pretty much what I did, however I was looking for a way to avoid
> extra copies of features (maybe I am doing this wrong).
> 

In your case, you don't need to copy the features (in the CreateFeature() case 
I mentionned, I need too since ownership of the passed feature belongs to the 
caller). On a reading side, you can just pass the pointer around, can't you ?

> >> 2) I am using spatial filtering to retrieve a subset of the features
> >> corresponding to a given area, and then iterate on the area to process.
> >> My code therefore uses spatial filters quite intensively, which might be
> >> very slow without spatial indexing and a large number of features. Is
> >> there a way to add spatial indexing for in memory dataset ?
> > 
> > If you are thinking about the MEM driver, there's no implementation of
> > spatial indexing in it currently.
> > If you are using GeoPackage or Shapefiles stored in /vsimem/, then spatial
> > indexes if they exist will be used.
> 
> Would there be any interest in developing spatial indexing for the MEM
> driver ? How difficult is it to implement it ?

That could be interesting indeed. That shouldn't be hard to do. There's a 
cpl_quad_tree.h that can be used for that. It is already used by the 
OpenFileGDB driver (since the format of GDB spatial index is still not reverse 
engineered) that populates the spatial index during the first iteration phase. 
Later queries can then use the spatial index. In the case of the MEM driver, 
you would just build progressively the spatial index when features are added 
through CreateFeature()

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list