<div dir="ltr"><div>Hi Alister<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 14, 2021 at 8:55 AM Alister Hood <<a href="mailto:alister.hood@gmail.com">alister.hood@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><br><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div>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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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").</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards</div><div class="gmail_quote">Martin</div><div class="gmail_quote"><br></div></div>