[QGIS-Developer] GSoC 2021 QGIS On-the-fly Raster Calculator proposal draft review and feedback

[Martin Dobias]

Hi Alister

On Wed, Apr 14, 2021 at 8:55 AM Alister Hood <alister.hood at gmail.com> wrote:

>
> What I'm suggesting is that a slightly more general solution would be
> useful in more situations.  In your words, it would "avoid the need to
> create derived raster files" in a lot more situations.
>
> The only downside is that the virtual raster would be created as a new
> layer in the QGIS project (if you want to reduce this "clutter", you might
> just be able to remove the original layer from the project, but sometimes
> you would want to keep it for other reasons).  But it is normal to have
> extra layers in your project just to get things to display you want - for
> example I imagine it is very common for people to duplicate a raster layer
> so they can display it both with the hillshade renderer and one or more
> other renderers.
>
> In any case, assuming you do follow the symbology approach rather than a
> provider, as a user I'd still ask if the way you're proposing to implement
> this is really the best way. Rather than adding a new render type, from a
> user's perspective I think it would be a lot simpler to instead add a Σ
> button next to all of the "band" comboboxes, allowing you to enter a raster
> calculator expression rather than selecting a band.  This approach would be
> consistent with the "value" comboboxes for selecting a field from a vector
> layer, which have a Σ button next to them, and it could also be extended to
> anywhere else in QGIS where you select a raster band.
>

I have originally suggested the approach (that Francesco took for his
project) in the GSoC ideas list and volunteered as a mentor... I was
playing with multiple ideas how this could be done: 1. new raster renderer,
2. new raster band of an existing layer, 3. new provider (as you suggest).

At the time the first option with a renderer seemed like a choice with the
least amount of hassle to add - simply reusing the concept that
hillshade/contour raster renderers already use. It seemed that the approach
with a renderer could lead to fastest feedback loop when user modifies the
raster calculator expression to immediately get results on canvas. And
contrary to what was said above, user should not be limited to raster bands
of a single input raster layer - any raster layer may be used - which may
lead to a paradox situation when the on-the-fly calculator renderer in
theory may not use any data from its layer (only the input layer's
extent+CRS may be used). The other potentially awkward thing is that raster
calculator (as of now) only supports a single output raster band, and there
would be a sub-renderer attached to actually turn output raster values to
actual colors (which I don't like that much).

For mesh layers, in recent versions of QGIS, there is support similar to
the second option (new "virtual" / "derived" raster band). This works fine,
but the feedback loop between changing the expression and seeing the
results involves much more time and clicking.

The final option with a new provider is similar to the previous option with
a virtual raster band, yet a bit more generic probably - maybe with more
room for configuration, one could possibly use not use on-the-fly raster
calculator, but also various other raster processing algorithms that would
otherwise require creation of outputs stored on disk. I guess with this
approach the raster calculator expression would be set as data provider URI
- which is cumbersome to later modify in QGIS. By the way, this option
seems to be also the approach taken in Redlands (the feature is called
"raster functions").

I can imagine either solution - raster renderer or raster data provider -
each would have some pros and cons. Many thanks for your feedback. I would
be interested to hear what other people think. The GSoC proposal is not set
in stone (and it is not accepted yet either) - if people prefer the
approach with a virtual raster, then we can think of updating the project
plan accordingly (if the project would go ahead).

Regards
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210415/b7a83107/attachment-0001.html>