Le mardi 30 septembre 2014 23:20:12, Jukka Rahkonen a écrit : > Even Rouault <even.rouault <at> spatialys.com> writes: > > Le mardi 30 septembre 2014 20:20:14, Andre Vautour a écrit : > ... > > > > I would build SpatiaLite with GEOS support, but unfortunately its LGPL > > > licensing is too restrictive for our application. So, would it make > > > sense to change the logic in OGRSQLiteRegisterSQLFunctions to account > > > for the case of SpatiaLite being built without GEOS? > > > > Andre, > > > > That makes sense. I guess that can only be checked at runtime though, > > probably > > > by issuing a ST_Intersects() and checking the error code. > > > > I'd note that the spatial predicates in OGR geometry are also based on > > GEOS. Except OGRGeometry::Intersects() that has a simplified > > implementation > > based on > > > bounding box intersection when GEOS is not available. > > Hi, > > From the end user's point of view this example feels unpleasant. If > "Intersects" gives different results with OGR and SQLite dialects because > of different implementations, a somewhat clever user can handle it now by > selecting the dialect.
Actually the OGR SQL dialect doesn't support directly spatial predicates. That can only be done through the SetSpatialFilter() API that is typically triggered with the -spat option of ogrinfo/ogr2ogr. What was discussed here is SQLite user functions installed by OGR. Currently even if Spatialite isn't available, there's an implementation of the most common spatial predicates that goes through the OGRGeometry methods. Kind of "poor-man" spatialite. > But if selecting SQLite dialect might still lead to > use of OGRGeometry::Intersects() depending on how Spatialite has been > built I would say that an end user can't manage the situation. > > How about renaming it into "OGR_Intersects" in such case? I'm not sure that would help for consistency, because OGRGeometry::Intersects() can be equivalent to Spatialite ST_Intersects() when GDAL is compiled with GEOS support. So OGR_Intersects would have different behaviour. Perhaps that should rather be a OGR_Envelope_Intersects() that is guaranteed to always do bounding box intersection I don't know if we must worry too much about that, as most users should have GDAL and Spatialite binaries with GEOS support. I'd say that only people that know what they do will build them without GEOS support, and in which case they must be aware of the implications. > > -Jukka Rahkonen- > > > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
