Hi again,
I'm sorry too for the delay.
By the way thank you for the feedbacks. I would definitely take yours hints and
your advices in consideration and I'll let you know what my work will concern
if, of course, the proposal will be accepted.
Kind regards,
Francesco
Da: QGIS-Developer per conto di Nyall
Dawson
Inviato: martedì 27 aprile 2021 06:50
A: Martin Dobias
Cc: Alister Hood ; qgis-dev
Oggetto: Re: [QGIS-Developer] GSoC 2021 QGIS On-the-fly Raster Calculator
proposal draft review and feedback
On Fri, 16 Apr 2021 at 07:20, Martin Dobias wrote:
>
> Hi Alister
>
> On Wed, Apr 14, 2021 at 8:55 AM Alister Hood 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
