On Wed, 22 Apr 2020 at 23:22, Olivier Dalang <[email protected]> wrote: > > Dear list, > > It's not exactly clear how secondary geometry columns are to be used from > QgsExpressions or Python code. > > Just to be clear, by secondary geometry columns, I mean geometries stored in > other columns that the one that is used to display the features on the map, > typically a "center_point" field storing a Point on a Polygon layer. > > When accessing them both in expression or Python, it seems it returns a > string with the ewkt representation (at least for postgis layers). This is > not really nice, as the only way to use it with functions such as make_line > is to strip the SRID from the text to get proper wkt, then to make the create > the feature using from_wkt. > > This means instead of the nice and clear : > make_line( closest_point( $geometry, "center_point"), "center_point" ) > You need : > make_line( closest_point( $geometry, geom_from_wkt( substr( "center_point", > strpos("center_point", ';') + 1) )), geom_from_wkt( substr( "center_point", > strpos("center_point", ';') + 1) ) ) > > It's also probably quite inefficient, which is an issue when used for > geometry generators.
Good discussion! This has bothered me for a long time too. Quite some time ago I submitted a PR which exposed secondary geometry columns as proper QgsGeometry values, which meant that they could be used directly in expressions (just like you want). You can see this and some discussion at https://github.com/qgis/QGIS/pull/3950 The difficulties came in handling CRS for these secondary columns, because: 1. there's no guarantee that they match the layer's CRS 2. while we're handling (1), we should consider the case that individual values in the same field for different features MAY have different CRS to each other. This discussion was never really resolved in the PR, and it ended up getting closed as stale. There's also work required to ensure that editing features with these secondary geom columns works as expected, and doesn't corrupt the secondary geometry values. When we've worked out the overall design, we'd then need to implement this handling on a provider-by-provider basis (at least, for those providers which do support additional geometry columns). I'd love to see someone pick up my initial work (or fund its completion). I think it's a sore point in QGIS currently which would be great to address. Nyall > > Is there a limitation preventing to return QgsGeometries directly ? If not, > would it make sense to change QGIS to do so ? Does anyone have an efficient > workaround in the mean time ? > > Thanks :-) > > Olivier > _______________________________________________ > 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 _______________________________________________ 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
