Even Rouault wrote: > 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. You are right and I feel rather relaxed. What I was worried about was that people who know what they do when they build GDAL can package the result into applications which they deliver to poor people who have no idea about all that. You read QGIS users mailing lists and for sure have noticed how users are asking why QGIS sometimes, on some computers is behaving in a different way than it used to behave because of differences in GDAL used for builds. You know, different SQLite and Spatialite versions as a typical example, or the variety of JPEG2000 drivers. -Jukka- _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
