[Qgis-developer] Raster Meeting Tomorrow - some UML

[Martin Dobias]

Hi all,

finally I took a look at the UML and also some materials about the
raster algebra / analysis. I've got some thoughts about that, some
might be worth considering:

- raster function interface - in my understanding, renderer (filter),
transparency filter, strecher are essentially functions doing
operations on raster data matrices. Does it make sense to create a
common interface for them and then create a chain of these functions
that will give input for a pixel shader? In this case any custom
raster functions could be added to arbitrary places in the chain.

- introduce one more abstraction: let's call it "raster data set" and
put it between raster layer and raster provider. How should that work:
Provider takes care of data acquiring from a specific backend. Data
set is the place where the main processing takes place. Raster layer
just accesses data set and draws it with its pixel shader. I see the
benefits in possibility to share data sets between layers, simpler
implementation of raster algebra, possibility to do some caching
already on data set level and more... (Well, a nice UML diagram would
describe the situation better)
btw. I'd like to use this approach also for vector data where all
vector editing / indexing / caching etc. would be done in vector data
set class - vector layer would only access data set for drawing and
maybe some more operations.

- raster algebra with two or more layers (data sets) - are we going to
support this?

- projections - are we going to support them?

- usage of properties for data providers - this is just a technical
thing - I think it would be good to use a mechanism of properties,
e.g.:
  void setProperty(QString name, QVariant value)
  QVariant property(QString name)
This means that provider-specific stuff could be set/get with an
unified interface, so we could avoid having e.g. setProxy() function
in QgsRasterLayer as we do have now just because WMS provider needs
it.

I don't know much about the rasters so excuse me in case I'm totally off :-)

Cheers,
Martin