[Qgis-developer] Raster Meeting Tomorrow - some UML

[Tim Sutton]

Hi Martin (and others interested in raster)

General:

I made an RFC page for the work we are planning since I think it falls
into the category of 'major overhaul' and would be good to have a
formalised work specification. (Marco I took the liberty of tweaking
your rfc template a little - hope thats ok!). The rfc includes an
updated UML (created before I read Martins comments below) and the
ArgoUml sources for the UML.

Martin:

Good comments! Yes chaining of filters was something I had in mind.
Which also gets me to thinking the stretch operations could jjust be
implemented as a kind of filter. The transparency too, though we would
need to ensure that they were run in the proper place in any filter
chain. We also need to evaluate how much filter type stuff we need
since if we go ahead and eventually incorporate OSSIM functionality
into QGIS we get a lot of image processing bundled in. I guess the
same goes with grass raster processing facilities. Its something to
think about anyway. Martin could you tweak the UML to include your
ideas? I need to reread your ideas below a few times to properly
digest what you are suggesting. Will be great if you can attend the
meeting to discuss further...

Regards

Tim

2007/6/20, Martin Dobias <wonder.sk at gmail.com>:
> 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
>


-- 
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net