add custom raster data provider for lazy evaluation

[janzandr]

Currently we use GDAL VRTs with Python pixel functions for implementing products with lazy evaluation (e,g, spectral indices). But VRTs do have some limitations:

• input and output bands must have the same CRS
• the VRT pixel function interface is not very flexible
• each output band needs to specify it's own pixel function
• all the structural metadata like extent, size and CRS need to be specified in the (hand-written) VRT itself
• we always need to create a VRT file in the file system

A custom QgsRasterDataProvider is way more flexible:

• we can have a url on the file system storing all required information...
• ... but we could also provide all required information coded inside the url string itself without any file system operation
• we can support different CRS for inputs and outputs
• way better API support for implementing new functionality
• single processing function handling all output bands at once

It is proposed to implement a LazyEvaluatedRasterDataProvider, that offers several features. E.g.

• [ ] on-the-fly preprocessing of a raster:

  • [ ] convert data type
  • [ ] translate/warp into new target grid (extent, size and CRS)
  • [ ] subset bands
  • [ ] data scaling (band offset and scale)
  • [ ] interprete raster as a mask (mask values, ranges and bits)

• [ ] on-the-fly preprocessing of multiple rasters:

  • [ ] masking a raster with another raster mask
  • [ ] raster math, e.g. (r1+r2)/r3
  • [ ] raster aggregation:
  • [ ] mean/median/min/max/... composite
  • [ ] simple mosaicking
  • [ ] stack bands from multiple raster source with non-matching CRS! (GDAL VRTs can't do this without warping beforehand)

All the above are just a collection of functionalities that the user should be able to use out-of-the-box. For more complex/custom operations, the user can implement their owns processing functions, which will be evaluated on-the-fly.

• [ ] custom user functions

Finally, we should choose a unique file extension for the provider and register it in QGIS, so that the correct raster layer with our provider is created. Similar to the *.geojson extension for GeoJSON, it is proposed to introduce the *.lerjson or lazyjson extension representing a LazyEvaluatedRasterJSON.

[janzandr]

The specification of a lazily evaluated raster could look like this: