[gdal-dev] Binary Predicates in SQLite SQL dialect

[Even Rouault]

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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com