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. 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? -Jukka Rahkonen- _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
