Frank, Thanks for your thoughts on this.
> I'd like to see something along this line happen. I to do it efficiently > it would be necessary to dig into GEOS past the C interface so that > a spatial index on a collection of features can be maintained over time > rather than created and discarded for each pairwise test of two geometries. > > I am somewhat hesitant to have this sort of processing go into GDAL/OGR > itself, especially as an extensive set of methods on OGRLayer. I think > it could be done as a layered processing library without any noticable > loss of performance. Do you know of anyone working on such a library? It sounds like such a library would sit on top of GDAL/OGR, to leverage the abstraction of data sources and layers. Although I am not yet familiar with efficient algorithms for operations with layers, I suspect that library would need spatial index support from OGR. The underlying data sources often maintain spatial indexes. OGR would either need to expose these via a new abstraction (new methods on OGRLayer, for example). Or if the underlying source did not support spatial indexes, perhaps OGR could loop through the layer, build an index with GEOS, and expose that via the same abstraction. Is that similar to what you were thinking? It sounds like there is not presently an open source project that provides this "geoprocessing with layers" functionality. If not, I will still have to use ArcGIS for my own project, but I would like to hide ArcGIS behind an abstraction that is likely to be architecturally compatible with a future library, so that maybe I could swap it in at some future point. This is why I am probing for more details on what you envision, even if those ideas are still somewhat distant. Thanks, Jason _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
