A small tutorial on how to build the current version of TinyOWS (the so-called trunk) under Windows XP Professional using Microsoft Visual C++ 2008 Express Edition and libraries from OSGeo4W.
Having a raster calculator in QGIS is cool, but if you need to process a lot of rasters, it won’t be much help. There is no batch mode in the calculator (neither in the my plugin nor in the QGIS core). Well, there is an entry about it in my TODO. But knowing that won’t help if you have hundreds of images for which you need to calculate, e.g., NDVI, or perform pixel replacement by a tricky condition.
This is where GDAL and Python come to the rescue. It literally takes 10 minutes to write a script, as there is nice and detailed documentation. But again, writing almost identical scripts for every task is not very practical.
Let me tell you a little secret. GDAL 1.8.0 has a wonderful tool, modestly named gdal_calc.py. This small (about 300 lines) Python script works with rasters of the same size (no check for mismatching CRS is performed) and supports basic arithmetic and logical operations. It is easy to use:
# sum of two rastersgdal_calc.py -A input1.tif -B input2.tif --outfile=result.tif --calc="A+B"# average of two rastersgdal_calc.py -A input1.tif -B input2.tif --outfile=result.tif --calc="(A+B)/2"# difference of raster bandsgdal_calc.py -A input.tif --A_band=1 -B input.tif --B_band=2 --outfile=result.tif --calc="A-B"
It accepts up to 26 images as input, which should be sufficient for most use cases. As you can see from the examples, there is support for parentheses, you can access individual bands, and the console nature makes it easy to use the script for batch processing. It still lacks some features, but even in its current state, it is a great console calculator.
The 5th QGIS developer meeting, which according to the QGIS Wiki gathered 28 people in Lisbon (Portugal), is coming to an end. It is time to summarise the results and share impressions.
Unfortunately, I was not able to attend in person and had to participate virtually again.
As the code and strings are currently frozen, people have mainly been fixing bugs and cleaning up the bug tracker. No new functionality (at least visible to normal users) has been added.
Most of the first day was spent getting things up and running, with more or less active work only starting on Friday evening. Saturday, however, was a real blast: in addition to closing tickets and fixing bugs, several presentations were given:
Martin Dobias demonstrated the QGIS FileBrowser data management application. It is similar to ArcCatalog in some ways, but all such applications look pretty much the same
Radim Blazek presented the QGIS Customisation project, which allows you to flexibly customise the QGIS interface and save those changes to a file for use on other machines
Jean-Roc Morreale spoke about the French version of the QGIS User Guide, which is available in printed form via the Print-On-Demand (PoD) service. It is expected that all translations of the User Guide and other documentation will be distributed using this technology in the future
Vincent Picavet showed the Rumbler plugin, which allows you to add new layers to QGIS directly from PgAdmin
there was a small demo of the DTClassifier plugin I’m currently working on. This plugin is being developed for a forestry monitoring project and provides image classification and change detection functionality
Julien Malik spoke for more than an hour about OrfeoToolbox and the prospects of its integration with QGIS
We also discussed many other topics, including migrating to Git, starting a new plugins repository, further development of QGIS, and redesigning the user interface.
Some numbers. At the time of writing: 64 issues closed, 59 commits made, 26 new issues opened. By the way, the bug #7 has been fixed, and the place of the oldest issue now belongs to #40.
In my opinion, this hackfest was a bit sluggish and not as lively as the previous ones. I hope that the feature freeze is to blame and that the next meeting (in autumn in Switzerland) will be more active.
QGIS is evolving fast: The API is extended, new features appear, and functionality that was previously implemented as plugins is added to the core. This was the case with the raster calculator, and now it is the turn of fTools.
For those who don’t know, fTools is a set of tools for vector data processing (analysis, management, and geoprocessing). Originally developed as a plugin, at some point it was integrated into QGIS (menu “Vector”, and earlier “fTools”).
After merging code from the table_join branch into the main development tree, the “Join attributes” tool is no longer needed; the “Export to new projection” tool is successfully replaced by the “Save as” functionality. These tools have already been removed, as well as the About dialogue box and help files.
There is an ongoing discussion about removing the “Export/Add Geometry column” (you can get area, perimeter and coordinates using the Field Calculator) and “Select by Location” tools (there is a more powerful Spatial Query core plugin).
The new QGIS plugin repository, which was discussed at the latest developer meeting in Wrocław, is now available for testing at https://plugins.qgis.org. Everyone is welcome to try it out, login with your OSGeo ID. Any problems should be reported to https://github.com/qgis/QGIS-Django.
There is also a separate bug tracker for plugins, which can also be accessed using the OSGeo ID.
More information about the new plugin repository can be found on the QGIS Wiki.
At the last QGIS developer meeting in Wrocław we discussed the migration from SVN to Git. There was even a small workshop on using Git at the hackfest. The final decision on this topic has not yet been made, but it will be discussed again at the next meeting in Lisbon.
For those who want to try Git in action, there are several QGIS mirrors on GitHub (one, two) that can be used for development. Gary Sherman has written a good post on how to do this using git directly.
Another option is to use git-svn. This eliminates the need to create an account on GitHub and is a good option if you just want to try Git but still want to use your SVN working copy for a while. This is the option I chose.
First, we need to obtain sources, starting with some revision
If necessary, revision 15000 can be replaced with another revision. Now you can cd into the qgis directory and use all the features of git: create local branches, make and commit changes, etc. When everything is ready to be committed back to trunk, use the following command
QGIS allows you to save a default raster band combination, standard deviation and contrast enhancement algorithm for rasters.
But it seems that not many people use this feature. At least no one noticed that although the band combination and standard deviation can be saved, they are of no use because the saved values are not applied when the raster is loaded. There were also other problems (for example, when the default band combination is set to 5-4-3, in the raster properties dialogue we still see 1-2-3) that no one reported.
All this has been around for a long time, somewhere since r13582 or even earlier. And only in r15256 were all these problems finally solved.
I’ll try to explain why you might need it all this settings and how to use them.
A great new feature has been added in revision r15250: Tim Sutton implemented support for custom directories for C++ plugins. The directories are added one at a time, and the next time QGIS is started, it will load both the default plugins and the plugins from the specified directories. The plugins can then be activated as usual from the Plugin Manager.
This is useful for both users, who will find it easier to add third-party plugins, and developers. Another benefit is that there is no need to worry about copying plugins to the correct location after updates.
The epic with the patch adding support for import and export of symbols in QGIS is finished.
The path from idea to commit was not an easy one: after creation and some testing, the patch sat on my laptop for a few days; then, after minor cosmetic improvements, it was uploaded to the QGIS trac and sat there for 5 weeks. Due to a small misunderstanding, the interested parties never got to test it and give their opinion. Finally, last Sunday I contacted Martin (the “new symbology” is his brainchild). After his reply, I had to improve the code a bit. The result can be seen in r15236.
While uploading the updated patch, I remembered another improvement. Minor, but also related to the “new symbology”, namely control over overwriting symbols with the same name. And I decided that since I started pestering Martin, I should make the most of it. The second patch was applied in r15237.