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. 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. > 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. 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 [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
