[gdal-dev] Open source vector geoprocessing libraries?

[Mateusz Loskot]

Jason Roberts wrote:
> Mateusz,
> 
> Thank you very much for your insight. I have a few more questions I'm
> hoping you could answer.
> 
>> Alternative is to try to divide the tasks: 1. Query features from
>> data source using spatial index capability of data source. 2.
>> Having only subject features selected, apply geometric processing.
> 
> That sounds like a reasonable approach. Considering just the simpler 
> scenarios, such as the one I mentioned, is it possible to implement 
> efficiently it with OGR compiled with GEOS?

Should be, but OGRGeometry -> geos::Geometry translation may be an overhead.

> I believe OGR can pass through SQL directly to the data source
> driver, allowing the caller to submit SQL containing spatial
> operators. In principle, one could submit a spatial query to PostGIS
> or SpatiaLite and efficiently get back the features (including 
> geometry) that could possibly intersect a bounding box. Then one
> could use the GEOS functions on OGRGeometry to do the actual
> intersecting. Is that what you were suggesting?

Yes, that's the concept

> Of course, it may be that PostGIS or SpatiaLite can handle both steps
> 1 and 2 in a single query. If so, would it be best to do it that way?
> 
It's usually a good idea to let the DBMS engine to do as much as
possible, so looks like a good idea to me.

> It appears that the OGR shapefile driver supports a spatial indexing
> scheme (.qix file) that is respected by OGRLayer::SetSpatialFilter.
> The documentation says that "Currently this test is may be
> inaccurately implemented, but it is guaranteed that all features
> who's envelope (as returned by OGRGeometry::getEnvelope()) overlaps
> the envelope of the spatial filter will be returned." Therefore, it
> appears that the shapefile driver can implement step 1 but not step
> 2. Is that correct?

Yes.

>> The problem with OGR and GEOS is cost of translation from OGR
>> geometry to GEOS geometry. It can be a bottleneck.
> 
> Is it correct that this cost would only be incurred when you call OGR
>  functions implemented by GEOS, such as OGRGeometry::Intersects, 
> OGRGeometry::Disjoint, etc?

Yes.

Namely, here potential cost takes place:

http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrgeometry.cpp#L333

>> It's plenty of combinations and my point is that if performance
>> (it's not only in terms of speed, but any resource) is critical, it
>> would be extremely difficult to provide efficient  implementation
>> of such features in OGR with guaranteed or even determinable degree
>> of complexity. Without these guarantees, I see little of use of 
>> such solution.
> 
> Yes, I see what you mean. But I suggest to the open source community
> that there is still value in implementing such features, either as
> part of OGR or another library, even if optimal performance cannot be
> guaranteed in all scenarios.

Perhaps you'll find these inspiring:

http://trac.osgeo.org/qgis/browser/trunk/qgis/src/analysis/vector

Look at the Java camp too.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org