Le mardi 30 septembre 2014 23:57:20, Rahkonen Jukka (Tike) a écrit : > 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.
Well, that could still happen by accident if someone builds their own GDAL and for some reason forget to install GEOS first. > 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. Yes, that's both a strength and weakness of GDAL. Many ways of configuring it to adapt to your needs & constraints. Propietary software editors have a much simpler life ;-) ! > > -Jukka- > _______________________________________________ > 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
