I decided to improve my MergeShapes plugin a bit. I added encoding selection when opening files, shapefile geometry type selection and reworked the merge algorithm. Now, the final attribute table contains all unique fields from all input files, which means you can merge files with different attribute tables. The only missing bit is a setting for the default encoding of input data.
There are plans to improve DPSimplify, Statist and RasterCalc, but I don’t know how it will go yet.
I’ve also started to slowly learn Git, or rather to organise and deepen my fragmentary knowledge. I want to try out this VCS in real tasks, as there is already a Git mirror of the main QGIS SVN repository.
Based on the report published on the Linfiity Geo Blog and my own impressions.
The 4th QGIS hackfest, held from 11 to 15 November in Wrocław, Poland, attracted 29 participants (28 people and one dog). All participants did their best to make QGIS even better. A lot was accomplished in four days: hundreds of commits, demonstrations of new features, and many productive discussions. The meeting was organised by Paweł Netzel with the help of Milena Nowotarska, Robert Szczepanek, Maciej Sieczka and Borys Jurgiel and took place at the Department of Climatology and Atmospheric Protection of the University of Wroclaw.
My contribution — numerous improvements to the fTools plugin. When using the “Merge shapefiles to one” tool, it is now possible to select not only a folder, but also individual files. The “Simplify geometry” tool has been redesigned: I added a customisable simplification threshold and the ability to simplify the whole layer or only selected features; simplification can be done “in place” or by creating a new shapefile; “in place” simplification supports undo/redo; at the end of the simplification plugin shows a report about the total number of vertices in a layer before and after simplification.
Below, you will find an overview of the most important topics that were discussed during the hackfest as well as most notable changes.
When I was young and handsome, I used to dance. Not professionally, but quite seriously. At least, our team has been given the title of “people’s”, and not so long ago it was confirmed.
I’ve uploaded some photos to Picasa, and below is one of my favourite performances. I apologise in advance for the quality: this is amateur video, and the lighting on the stage is terrible (thanks to the Palace’s sound/lighting director).
Last night, I submitted a patch to add SetIgnored support to the SQLite driver. Literally an hour later, it was applied. This means that the two most important drivers have already been made to work faster.
Frank Warmerdam today applied changes proposed by Martin Dobias in RFC 29: OGR Set Ignored Fields. Martin’s patch was developed as part of the GSoC project and aims to improve the speed of reading data from OGR datasources. The new functionality is currently only available in the shapefile driver. I think we should expect this functionality to appear in other drivers soon.
For QGIS, this news marks the beginning of a new stage in its development, as the inclusion of the patch in the GDAL code, along with other improvements made as part of the QGIS on Steroids GSoC project, will significantly increase performance when rendering vector layers.
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).
Yay! The collaborative project to translate the QGIS 1.5 User Guide into Russian is finished. It took 1 month and 18 days, and 15 people participated.
During the translation process, many typos and inaccuracies were found, which, in the best tradition of open source, were corrected not only in the translated version but also in the original manual. Thanks to the perseverance of the project members, several major problems in the English version, such as the lack of a subject index and bibliography, have been fixed.
The translated user manual (PDF format, ~10 Mb) is now available on the QGIS website.
Imagine you have a vector layer containing polygons, both single- and multipart. Your task is to get vertices of each geometry, including all rings and parts. Here is how it can be done using GDAL and Python.
Let’s start with simplest case — singlepart polygons. In that case everything is straightforward — we need to find out the number of vertices, iterate over them and get their coordinates. The code will look like this:
defdump_geometry(geom):
print "Exterior ring" ring = geom.GetGeometryRef(0)
for i in range(ring.GetPointCount()):
print i, ring.GetX(i), ring.GetY(i)
A polygon with “holes” is considered as a set of “rings”: one outer ring defining the polygon boundary and several inner rings describing the “holes”. The outer ring always comes first. Thus, the algorithm will transform as follows: loop over all rings; if it is the first iteration — this is an outer ring, otherwise — inner ring; extract vertices from the ring and output their coordinates.
defdump_geometry(geom):
nRings = geom.GetGeometryCount()
for i in range(nRings):
ring = geom.GetGeometryRef(i)
if i ==0:
print "Exterior ring"else:
print "Interior ring", i
for j in range(ring.GetPointCount()):
print j, ring.GetX(j), ring.GetY(j)
Handling multipart polygons is more complicated: they can be either singlepart polygons or contain “holes”, “islands”, or even “holes” and “islands” at the same time. Let’s try to figure out how to deal with them. A polygon consisting of several “islands” can be considered as a set of independent polygons. In turn, each of those polygons can have one or more rings. So what we have now:
if the polygon is a singlepart polygon and contains only one ring, we extract its vertices immediately
if the number of rings in polygon is greater than 1 — we loop through the rings and extract vertices from them
if the polygon is a multipart polygon — loop through the parts and for each for part perform checks starting from the step 1
So, this is a classical recursion and the final function will look like this:
defdump_geometry(geom, file):
geomType = geom.GetGeometryType() # geometry type# singlepart polygonif geomType == ogr.wkbPolygon or geomType == ogr.wkbPolygon25D:
nRings = geom.GetGeometryCount() # number of rings print "Rings", nRings
if nRings ==1: # there are no "holes" in the polygons print "Exterior ring" ring = geom.GetGeometryRef(0)
for i in range(ring.GetPointCount()):
print i, ring.GetX(i), ring.GetY(i)
else: # polygon with "holes"for i in range(nRings):
ring = geom.GetGeometryRef(i)
if i ==0:
print "Exterior ring"else:
print "Interior ring", i
for j in range(ring.GetPointCount()):
print j, ring.GetX(j), ring.GetY(j)
# multipart polygonelif geomType == ogr.wkbMultiPolygon or geomType == ogr.wkbMultiPolygon25D:
for i in range(geom.GetGeometryCount()):
subGeom = geom.GetGeometryRef(i) # for each polygon part dump_geometry(subGeom) # recursively call dump_geometry() function
The code is a bit bloated, but my aim was to demonstrate a possible way of approaching the task, not to come up with an ideal solution.
The collaborative project to translate the QGIS 1.5 User Guide into Russian is nearing completion. I’m busy with the final editing and formatting.
Recently, I had to look into the OGC CSW (Catalogue Service Web) standard. It’s an interesting and useful thing, but most of the public servers I managed to find implement various aspects of it in a strange way :-(. So I have to add a monstrous construction to the code to catch exceptions and give the user a more or less understandable error message.
I am also slowly writing Pascal wrappers for the GDAL/OGR and Proj libraries. I couldn’t find any Pascal bindings for GDAL/OGR, so I’m making my own. I already have a more or less working module for OGR and some examples of its use. A module for OSR is also ready, but has not been tested yet. Next in line is a module for GDAL.
The situation with the Proj wrapper was a bit more interesting: first, I found a Pascal module for Proj 4.4.3 (the current Proj version is 4.7.0), and this wrapper required changes to the source code of the Proj library. I didn’t like this approach and started to make my own module, partly based on the one I found. Later, when updating the FPC compiler, I accidentally noticed that the available packages included modules for Proj 4.6.1. Now I’m not sure what to do: should I continue developing my own wrapper or not?
I plan to push the results of my work upstream, and if that doesn’t work, I’ll just publish them somewhere.
A collaborative project to translate the QGIS 1.5 User Guide into Russian is announced. I will lead and coordinate the project. Please share information and get involved, and don’t hesitate to contact me if you have any questions.
