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. ras...@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.hugentob...@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.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer