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

[Alister Hood]

Hi again,

On Wed, 14 Apr 2021 at 01:40, Francesco Bursi <francesco.bursi at hotmail.it>
wrote:

> Hi Alister,
>
> Thank you for the feedback.
> Well, I imagine the new feature with some properties of the existing
> Raster Calculator but not exactly the same, e.g It won't be possible to set
> layer extent / output CRS, because this would be already pre-defined by the
> layer on which the renderer is applied, in the basic mockup you should not
> see these 2 field. The same can be said for choosing other layer. It should
> work like contours/hillshade renderer, where you can style only the layer
> you have currently selected but you can choose the band.
>

Ah, the proposed calculator renderer wouldn't be able to calculate from
more than one layer.  That's an important clarification, and it means it is
a lot less useful than I thought it might have been.

I use the raster calculator mostly to calculate the difference between two
layers, both for visualisation and to display values in the value tool
plugin.  I create the rasters as temporary files, to avoid storing lots of
large raster files that are simple to regenerate if necessary.  The
downside of doing this is that if necessary I do actually need to
regenerate them .

A "virtual raster" provider would allow me to keep them around without
eating up disk space.  I imagine use cases like this are quite common.

Besides, I think that the existing Raster Calculator in the processing
> toolbox (as well as the Gdal Raster Calculator) allows the creation of a
> temporary file, enable the addition of a layer to the project that you can
> style, but maybe here I misunderstood what you meant.
>

Yes, but temporary files are obviously inconvenient enough to motivate you
to implement an on-the-fly raster calculator renderer :)


> One of the advantage of the on-the-fly (styling) is to  * avoid the need
> to create derived raster files and layers.*
>

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.

Regards,
Alister

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210414/905c9a79/attachment.html>