I can’t stop being pleased with the popularity of RasterCalc. It is a very useful and, above all, functional tool. Today, the calculator has two new functions (the initial patch was provided by Ludovic Mercier): composeRgb and extract.
The composeRgb function creates a 3-band raster from individual channels. Example of use:
The output will be a 3-band raster: band 1 of the clearcuts raster will be used as the first output band, band 5 of the clearcuts raster will be used as the second output band, and the third output band will be the average of bands 5 and 6 of the clearcuts raster.
The extract function extracts a subset of bands from a multiband raster and saves it as another raster. Example of use (assuming the Clearcuts raster has 10 bands):
extract([clearcuts]@1, 3, [5,7], 10)
The output will be a multi-band raster consisting of channels 3, 10 and all channels from the interval [5, 7]. I.e. the output image will have 5 bands (bands 3, 5, 6, 7 and 10 of the input raster).
The implementation (even with my changes) is far from optimal, but I don’t have time for proper refactoring and optimisation. Maybe I will rewrite it completely later.
Despite the fact that QGIS now has a built-in raster calculator, the RasterCalc plugin I developed is still quite popular. I don’t know how to explain it: either it’s a matter of habit, or my calculator is more convenient… I’d like to know what the reason is, maybe I should make a poll.
Why this preface? For a long time, I’ve been “terrorised” by requests to add support for conditional operators to my plugin. The one guy from Spain was particularly active. And no matter how often I pointed out that I was busy with other projects, no matter how hard I tried to avoid it, nothing helped. After a short break, the “attacks” were repeated. Apparently, they had decided to wear me down.
The inclusion of a patch that added comparison operators (submitted by Ghislain Picard) didn’t help either. It was not enough, and it was not what they were looking for. People wanted more, something similar to r.mapcalc from GRASS and preferably with the same syntax.
Well… I have to admit, they got it. Today this most wanted feature is implemented. However, the syntax is different from r.mapcalc’s, because I didn’t want to make the already complex parsing code even more complicated. Now you can do things like:
compare pixel values with a constant and replace pixel values that meet the condition with another value
compare pixel values with corresponding pixels of another raster/band, and replace pixel values that match the condition with corresponding values from the third raster/band
other similar things
This nice feature is still in my local repository. I will not commit it to the public repository until the documentation has been updated. And I really don’t have the mood or energy to do that. I don’t like writing, whether it’s an essay, an article, or anything else. There are times when it is easy to write, but those are rare.
There is another reason or two, to be precise and honest. Firstly, I’m thinking about optimising the plugin a bit: operations on large rasters use a lot of CPU and memory. And secondly, that very active Spaniard made another feature request the other day, and I have a feeling that he will be as persistent in his efforts to get me to implement it as he was before.
But I haven’t made a final decision yet. Maybe the conditional operator should be enough for a new version and I should not bother with refactoring and optimisation? Or should I wait a bit, but release an even more powerful calculator and consolidate the success of the first versions?
Yesterday I found out that my plugin — RasterCalc — was only announced on the QGIS mailing lists. I didn’t post anything on the forum or here. I don’t know how I could have forgotten. Although I have to admit that there was a lot of work going on at the time: RasterCalc itself, an experimental branch of GDAL Tools, Photo2Shape and many other things. QGIS 1.4 was released in January… I know it’s a weak excuse, especially considering that other plugins were announced all over the place, but I don’t have any others.
So… RasterCalc is a user-friendly and functional raster calculator written in Python. It was announced on the mailing lists on 16 January 2010.
RasterCalc window
RasterCalc was inspired by Barry Rowlingson’s RasterLang plugin. The main difference is the user-friendly interface and the familiar expression syntax (do you like LISP as much as Barry?). I have also added some additional features like saving and loading expressions, “templates” of formulas and extended the set of available functions and operators.
Weeks and months went by (I almost wrote “years”), nothing seemed to indicate any changes… And then, out of the blue, Marco Hugentobler and Tim Sutton decided to make RasterCalc part of the QGIS analysis library. This will allow its features to be used by other plugins, and remove the dependency on NumPy, pyparsing and other Python modules.
Marco has already published a first version of the patch. Some features are missing compared to the original plugin:
there is no support for “templates” of formulas (in RasterCalc there are two: “Difference” and “NDVI”)
the result can only be saved with Float32 data type
saving and loading of expressions is not supported
At the same time, new features have been added:
it is possible to specify the desired resolution and extent of the result. This allows rasters with different resolutions to be used in one expression. If necessary, the rasters are automatically resampled to the output resolution
result can be saved in various formats, not only GeoTiff
QGIS Raster Calculator
You can try out the new functionality by applying the patch and building QGIS from source. The calculator will appear in the “Layer → Raster calculator” menu.
The patch is still under development and some things may not work. The authors invite everyone to try it and report any bugs (if possible, attach a test dataset and steps to reproduce the issue).
