[gdal-dev] Binary Predicates in SQLite SQL dialect

[Even Rouault]

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

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