Add fixed elevation range per dataset group mode for mesh layers

[nyalldawson]

This mimics the "fixed range per band" mode we have for raster layers, but allows a per-dataset group elevation range to be set for mesh layers

[nyalldawson]

@wonder-sk I'd love your eyes on this one to confirm that this is using the mesh layer APIs correctly

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 4afec6a)

[wonder-sk]

@nyalldawson it is a bit more complicated with mesh layers compared to raster layers: it is common that within a single layer, there are multiple quantities - take for example ecmwf-test-data.zip (could be used for auto-tests if needed) - it contains three quantities (Humidity, Temperature, Vorticity), each at different times and at different elevation levels. Right now, each elevation level is recognized as a separate dataset group in the styling panel:

But with the "fixed elevation range per group" mode, all these dataset groups should be collapsed into just those three quantities, so that users could switch which quantity is active for rendering.

A major problem with the current implementation is that user can both move elevation controller's slider and change active dataset groups in the styling panel, but it is unclear what the map canvas is actually showing.

In order to fix that, I think in the configuration dialog, in the table of groups with lower/upper limit, we will need one more column - the quantity (kind of "super-group" that combines multiple dataset groups into one). It would be great if the quantity could be populated from an expression as well.

With these quantity super-groups, the styling panel could then show just the super-groups instead of "normal" groups (that represent just one particular elevation level). So right now, QgsMeshRendererSettings has mActiveScalarDatasetGroup and mActiveVectorDatasetGroup - which in this mode do not make sense anymore - probably these variables can be replaced either by active group name, or by a list of active dataset groups - and QgsMeshLayerRenderer would pick which dataset group to use based on the elevation controller.

And hopefully at some point later, MDAL will report extra metadata for each dataset group: 1. what elevation does it relate to, 2. what quantity does it belong to. With those bits, QGIS should be able to auto-populate the elevation-related configuration.

[nyalldawson]

@wonder-sk thanks for the insights!

That sounds like a rather large, low level refactoring of how mesh datasets are handled in QGIS. I'd like to avoid that here, and just get the elevation part working.

What do you think about ffa6b2d as a potential workaround for now?

[wonder-sk]

Okay, let's do it like this as a workaround...

[qgis-bot]

@nyalldawson
This pull request has been tagged as requiring documentation.

A documentation ticket will be opened at https://github.com/qgis/QGIS-Documentation when this PR is merged.

Please update the description (not the comments) with helpful description and screenshot to help the work from documentors.
Also, any commit having [needs-doc] or [Needs Documentation] in will see its message pushed to the issue, so please be as verbose as you can.

Thank you!

[qgis-bot]

@nyalldawson

This pull request has been tagged for the changelog.

• The description will be harvested so please provide a "nearly-ready" text for the final changelog
• If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
• If you can, it's better to give credits to your sponsor, see below for different formats.

You can edit the description.

Format available for credits

• Funded by NAME
• Funded by URL
• Funded by NAME URL
• Sponsored by NAME
• Sponsored by URL
• Sponsored by NAME URL

Thank you!

[qgis-bot]

@nyalldawson
A documentation ticket has been opened at qgis/QGIS-Documentation#9100
It is your responsibility to visit this ticket and add as much detail as possible for the documentation team to correctly document this change.
Thank you!