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

[Nyall Dawson]

On Fri, 16 Apr 2021 at 07:20, Martin Dobias <wonder.sk at gmail.com> wrote:
>
> 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).

Apologies for the super-delayed answer (been on leave and then
catching up due to being on leave :P )

My preference would be strongly towards the virtual raster data
provider instead of a renderer. Basically the way I see it is that a
virtual renderer is a nice symbology toy to have, but can't be used
for any real in-depth analysis work. Yet a virtual provider would work
for both visualisation AND analytical work (e.g. identify tool would
give correct calculated pixel values) and takes the feature from being
of limited use to a real killer feature.

I can also see that a virtual provider could greatly speed up certain
tasks in qgis -- eg if you had to perform a raster calculation and
then use the results for a zonal statistics operation, it would be
MUCH more efficient to use a virtual raster so that you're only
performing the raster calculation for pixels inside the zones, instead
of every pixel and then ignoring everything outside the zones. This
could potentially make an operation which is prohibitively time
consuming to calculate become instead a near-instant calculation!

That's where I sit anyway :)

Nyall