Those interested in QGIS development are probably aware that at the last developers’ meeting, among other things, Martin Dobias and Radim Blazek presented the QGIS FileBrowser application for data management.
QGIS Browser
QGIS FileBrowser is based on the QGIS libraries. It supports the same vector and raster formats as QGIS and can also work with WMS servers (information about connections is taken from QGIS settings). The functionality is still quite poor, right now you can:
navigate through the file system or through the WMS server layers
preview data on a map, view attribute tables and metadata
manage WMS connections
create new shapefiles
set CRS for a shapefile
The source code of the application is available in the QGIS repository, in the browser-and-customization branch.
This branch also contains Martin and Radim’s work on a QGIS interface customisation tool. The new dialogue allows you to hide unnecessary widgets and save these settings to a file for use on other machines.
QGIS UI customisation tool
Not only can you hide individual buttons on toolbars and toolbars themselves, but literally anything can be customised. For example, you can remove menu items, hide individual tabs, or dialogue controls.
What has been talked about for a long time has happened. The QGIS project has officially changed its version control system: the code has been moved from SVN to GIT. The migration process is described in detail in Tim’s blog.
This is the second global migration. A few years ago, we migrated from CVS to SVN, and that was accompanied by the migration of the repository and bugtracker from SourceForge to the OSGeo infrastructure. The current migration is even more global: in addition to the migration to GIT, we have a repository migration to GitHub (more on that below), a bug tracker change (Trac will be replaced by Redmine), and we will also create a new plugin repository integrated with the bug tracker.
The new official repository is on GitHub — qgis/QGIS. As git is a distributed version control system, access to the main repository will be restricted to a few developers (i.e., many developers who previously had access will lose it). Everyone else can work in their own repositories and either submit patches (created using git format-patch) or send a pull request (if your repository is also on GitHub).
Now a bit of grumbling. The move to Git is a good step, but I personally don’t like the fact that the official repository is on GitHub. I don’t understand why the repository can’t be on the OSGeo servers. The rest of the infrastructure will be there anyway, so everything will be interconnected, and a single login will be used to access all services (bugtracker, svn, ftp…). Now it is not very convenient, and there is also a dependency on a third party.
P.S.: despite the fact that version 1.7 has already been branched, the release will be delayed until the end of the project’s infrastructure update. The release branch is accepting fixes that do not affect strings, and package maintainers can already prepare test builds and make the necessary changes.
OSGeo4W is a special installer focused on the distribution of various free and open-source GIS software on Windows operating systems (XP, Vista, etc.). With OSGeo4W you can install GDAL/OGR, GRASS, MapServer, OpenEV, uDIG, QGIS and many other packages (see the full list).
Installing OSGeo4W requires only a few simple steps:
the selected packages and the required dependencies will be downloaded and installed automatically
After installation, desktop applications can be started from the “Start → Programs → OSGeo4W” menu. Command line utilities can be run from the OSGeo4W Shell, and web applications will be available at http://localhost/.
In this post, I will go through the main steps needed to prepare and add a new package to OSGeo4W, based on my experience of creating packages for matplotlib and TinyOWS, and information from the OSGeo4W Wiki.
Not long ago I wrote about the raster calculator in GDAL. It is a useful tool and has enough functionality to solve most tasks. But as it turns out, it is not without its bugs.
I was playing with this calculator and looked at the code. Almost immediately I noticed that it reads data “as is”, which was something to worry about, as I had already stepped on that rake some time ago (/me is immersed in memories for a few minutes. It was a fun time: two parallel projects, both related to GDAL; lots of new stuff to learn…). A little test confirmed my fears. Here is the result of an NDVI calculation for a Byte raster, performed with RasterCalc and saved as Float32.
NDVI calculated with RasterCalc for inputs with Byte data type
And this is the result of the same operation performed by gdal_calc
NDVI calculated with gdal_calc for inputs with Byte data type
You can’t get this across with an image, but the white areas aren’t really white at all — they contain a NODATA value.
What can I say, the results are very interesting. But the explanation is simple: since the data is read “as is”, when performing arithmetic operations, you can run into things like integer overflow and rounding of the result (in Python, the result of dividing two integers is also an integer).
Obviously, this is a bug. So let’s write to the author, report the issue and propose a patch.
If you are using this tool, you may not want to wait for the next version of GDAL and fix the bug yourself. To do this, open gdal_calc.py in your favourite text editor and lines 230–232
TinyOWS is a lightweight and fast WFS-T server. OSGeo4W is an installer for various free GIS software. What do they have in common? Until today, the correct answer was “nothing”.
From today, OSGeo4W users can install and use the latest version of TinyOWS 1.0.0rc1. Previously, the only reasonably easy way to get the TinyOWS server running on Windows was to use MS4W installer, but it provides the old 0.9.0 version.
I have also written a guide on how to build TinyOWS on Windows.
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.
