[Qgis-developer] Raster algebra C++

[Marco Hugentobler]

Hi Martin

Thanks for looking at the patch. Your point about the search string makes 
sense. I decided to use the search string because of code reusage and the idea 
of introducing some comparison operators for raster algebra in the future 
(e.g. raster at 1 > 10 would return a raster with 1 for values over 10 and 0 for 
values below). But now, looking at the searchtreenode, I realise that it 
wouldn't be possible to use checkAgainst() for that since it returns a bool. 
So yes, semantics is different.

Regards,
Marco 

Am Montag, 18. Oktober 2010, um 19.41:41 schrieb Martin Dobias:
> Hi Marco
> 
> On Thu, Oct 14, 2010 at 5:40 PM, Marco Hugentobler
> 
> <marco.hugentobler at sourcepole.ch> wrote:
> > Hi devs,
> > 
> > A very cool and handy tool is Alexander Bruys raster algebra plugin. It's
> > so usefull in environmental modelling that Tim and I thought it would be
> > good to have it in our analysis library (where it can be used by 3rd
> > party applications too and without the dependency of the numpy library).
> > So here is my initial patch that implements a calculator tool as part of
> > the analysis library by extending the search string mechanism.
> > 
> > [...]
> > 
> > You can try the functionality by applying the following patch:
> > http://karlinapp.ethz.ch/101014_qgis_rastercalculator.diff
> > The menu to open the calculator is located under 'Layer->Raster
> > calculator'.
> 
> Thanks a lot for the patch. I have taken a brief look on it and I have
> one suggestion: IMHO it would be better to keep the parser (and
> interpreter) for raster algebra and "search strings" separate. I
> understand that it is easier to reuse some of the code from search
> strings with raster algebra, but the semantics is very different. And
> there are various functions and operators that work only for one of
> them, so mixing them together complicates the inner working of the
> search string interpreter. Extending the languages (e.g. usage of
> raster neighborhood, further string operations) will make the code
> even more cluttered.
> 
> My vision is that search strings should continue to evolve to support
> a reasonable subset of SQL language, while raster algebra language can
> evolve to support further raster/matrix operations. Keeping these
> different languages separately may bring brighter future for both :-)
> 
> Regards
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Webereistrasse 66, 8134 Adliswil, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee