Le mardi 30 septembre 2014 20:20:14, Andre Vautour a écrit : > Hi all, > > I am trying to use a geometry binary predicate (ST_Intersects) in > ExecuteSQL() with the SQLite dialect and keep getting back an > "ST_Intersect function does not exist" error back from SQLite. > > GDAL is built with SpatiaLite (HAVE_SPATIALITE is defined), but I > believe the problem is that SpatiaLite is built without GEOS in our > case, so those predicate functions end-up not being available in > SpatiaLite. The end result is that OGRSQLiteRegisterSQLFunctions does > not add the OGR-based predicate functions as SpatiaLite is present, but > SpatiaLite does not contain the predicate functions. > > 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. Some time ago, I had a look at boost geometry ( http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/index.html ). That could be used as an alternative backend to GEOS for most predicates and functions returning geometries, and the boost licence is a modified X/MIT. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
