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.
Custom plugin paths in QGIS settings
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.
In the commit 15199 Tim Sutton added tips shown on QGIS startup. Those tips can be enabled/disabled in the QGIS settings.
So far, the number of tips is very small — about a dozen. Anyone who wants to can submit their tips for inclusion. The requirements are simple:
the tip should have a concise title
brevity is the soul of wit. The content of the tip should not exceed one or two paragraphs
only basic HTML primitives are allowed: links, lists, etc. The full list of supported tags can be found here
the tip should be useful to as many users as possible, or describe functionality that is not obvious
A bit earlier, in commit 15195, a separate window was added with a list of organisations that supported (and support) the project financially, i.e. sponsors.
QGIS is not only a ready-to-use desktop GIS, but also a set of libraries that can be used to create custom GIS applications. Unfortunately, when creating such applications, developers have to implement some GUI elements from scratch. An example of such a widget is the list of loaded layers (sometimes incorrectly called a legend).
In this post I will show the process of embedding a layer list widget into a PyQGIS application. The widget was developed by Germán Carrillo and you can get the code and read how to use it in Germán’s post “Layer list widget for PyQGIS applications” on the GeoTux blog.
The weather is not good today. It’s thawing. Everything is melting, it’s damp and foggy. Normally, you would not want to do anything in weather like this, except maybe lie around with a book or watch a film. But no…
Since I did not get any feedback on the new tool in GdalTools for several days, I did some tests myself. After finally making sure that it works, I submitted the patch and wrote to Giuseppe. Since r15135 there is another tool available in GdalTools — gdaltindex.
I’ve slightly improved the symbology import/export patch (I wrote about it a few days ago) and submitted it too. Waiting for feedback now.
Then I started to improve the usability of the import/export dialogue of PostGIS and WMS connections. I decided not to bother with a patch (the changes are not that big) and cheekily committed everything directly to trunk.
I finally went into a frenzy and fixed a long-standing and nasty bug in RasterCalc, extended the set of available comparison operators and started updating the documentation.
The so-called “new symbology” in QGIS has an impressive set of features and allows users to create their own symbols from the simplest to the most complex. Unfortunately, it does not provide a mechanism for sharing symbols, and it is not possible to use multiple symbol libraries at the same time.
I decided to fix at least some of the shortcomings and prepared a patch that allows the import/export of symbols. This is the third patch of this kind among my fixes, the previous two were also import/export related (one for import/export of PostGIS and WMS connection settings, and the other for import/export of custom keyboard shortcuts).
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?
Alessandro Furieri has announced the SpatiaLite Cookbook, an excellent guide to SpatiaLite with many practical examples, optimisation tips and information on using SpatiaLite with different programming languages. You can check it out here.
Frank Warmerdam has announced that OSGeo4W is moving to the recently released GDAL 1.8.0. Instead of GDAL 1.5.4, the default version will be 1.8.0, additional packages like gdal-python, gdal-autotest, gdal-ecw etc. will also be updated or removed if no longer needed.
For compatibility with some packages that still require GDAL 1.5.4, a new package gdal15dll (with the necessary libraries) will be added. This package will be automatically installed if needed.
Since the transition to a new version of GDAL is a rather laborious and time-consuming process, the update of some packages included in OSGeo4W is temporarily suspended. In particular, this affects QGIS nightly builds.
The maintainers of the QGIS OSGeo4W package have already announced that they will rebuild the package with GDAL 1.8.0 as soon as possible, GRASS will be rebuilt after GRASS 6.4.1 is released.
