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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
