[QGIS-Developer] Feature's secondary geometry columns in expressions and python

[Nyall Dawson]

On Wed, 22 Apr 2020 at 23:22, Olivier Dalang <olivier.dalang at gmail.com> 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
> 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