[Qgis-developer] OGR Buffer fails in Processing

[Even Rouault]

On vendredi 3 mars 2017 07:49:55 CET Giovanni Manghi wrote:
> Hi,
> 
> > --> Just guessing blindly. I guess that the "'geometry" column name in
> > ST_Buffer(geometry, X) must be hardcoded in processing. This is the name
> > of the geometry column used by default for OGR sources that have no
> > explicit geometry column (like shapefiles). But when the source is a
> > database, "geometry" must be replaced by the actual geometry column name
> > from the database. Typically the one you get with
> > OGR_L_GetGeometryColumn().
> > 
> > Pseudo code :
> > 
> > src_geometry_column =  OGR_L_GetGeometryColumn(layer)
> > 
> > if src_geometry_column is null or empty :
> >      sqlite_geometry_column = 'geometry'
> > 
> > else
> > 
> >      sqlite_geometry_column = src_geometry_column
> 
> the geometry column name is not hardcoded, is left to the user to
> choose what is the name.

OK, wrong guess then ;-)

> At the time I created this ogr based tools
> there was no way to retrieve the geometry name column, but may I'm
> wrong or maybe now is possible.

OGR_L_GetGeometryColumn() has always existed. That said, your point about having user 
choice is valid. Now OGR layers can expose several geometry columns depending on the 
datasource capabilities (can be the case for all database-based datasources), so 
OGR_L_GetGeometryColumn() would return only the first one. One could image a combobox 
with valid names (perhaps there's one already, just guessing again ;-) )

With GDAL >= 2 (now a requirement for master), you can get all the geometry columns with

OGR_FD_GetGeomFieldCount / feature_defn.GetGeomFieldCount()
OGR_FD_GetGeomFieldDefn / feature_defn.GetGeomFieldDefn()
OGR_GFld_GetNameRef / geom_field_defn.GetNameRef()

If there's a single geometry field and its name is NULL or empty, then 'geometry' must be 
used when SQLite dialect is used.

> 
> > Note: in the above case, the processing is a bit suboptimal as the source
> > is PostGIS. Removing -dialect sqlite would speed up things and allow the
> > buffering to be done by PostGIS itself.
> those tool were made to work with any datasource, and as I'm
> frequently asked why I created them (as they have counterparts in
> QGIS) is because I wanted provide something (especially the dissolve
> tool) that worked reasonably fast for large dataset, something that
> the qgis does not.

Understood, was just a casual remark.

> 
> To run geoprocessing operations on postgis layers, done directly by
> postgis, and with outputs directly in postgis I created a proof of
> concept Processing plugin that is actually having quite a success
> (over 25k downloads)
> 
> http://plugins.qgis.org/plugins/postgis_geoprocessing/
> 
> 
> -- G --
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170303/647973be/attachment-0001.html>