Page 3 of 88 (1746 posts)

  • talks about »


Last update:
Sun Oct 23 12:55:13 2016

A Django site.

QGIS Planet

OSM turn restriction QA with QGIS

Wrong navigation instructions can be annoying and sometimes even dangerous, but they happen. No dataset is free of errors. That’s why it’s important to assess the quality of datasets. One specific use case I previously presented at FOSS4G 2013 is the quality assessment of turn restrictions in OSM, which influence vehicle routing results.

The main idea is to compare OSM to another data source. For this example, I used turn restriction data from the City of Toronto. Of the more than 70,000 features in this dataset, I extracted a sample of about 500 turn restrictions around Ryerson University, which I had the pleasure of visiting in 2014.

As you can see from the following screenshot, OSM and the city’s dataset agree on 420 of 504 restrictions (83%), while 36 cases (7%) are in clear disagreement. The remaining cases require further visual inspection.


The following two examples show one case where the turn restriction is modelled in both datasets (on the left) and one case where OSM does not agree with the city data (on the right).
In the first case, the turn restriction (short green arrow) tells us that cars are not allowed to turn right at this location. An OSM-based router (here I used therefore finds a route (blue dashed arrow) which avoids the forbidden turn. In the second case, the router does not avoid the forbidden turn. We have to conclude that one of the two datasets is wrong.

turn restriction in both datasets missing restriction in OSM?

If you want to learn more about the methodology, please check Graser, A., Straub, M., & Dragaschnig, M. (2014). Towards an open source analysis toolbox for street network comparison: indicators, tools and results of a comparison of OSM and the official Austrian reference graph. Transactions in GIS, 18(4), 510-526. doi:10.1111/tgis.12061.

Interestingly, the disagreement in the second example has been fixed by a recent edit (only 14 hours ago). We can see this in the OSM way history, which reveals that the line direction has been switched, but this change hasn’t made it into the routing databases yet:

now before

This leads to the funny situation that the oneway is correctly displayed on the map but seemingly ignored by the routers:


To evaluate the results of the automatic analysis, I wrote a QGIS script, which allows me to step through the results and visually compare turn restrictions and routing results. It provides a function called next() which updates a project variable called myvar. This project variable controls which features (i.e. turn restriction and associated route) are rendered. Finally, the script zooms to the route feature:

def next():
    f =
    id = f['TURN_ID']
    print "Going to %s" % (id)
    if iface.mapCanvas().scale() < 500:

layer = iface.activeLayer()
features = layer.getFeatures()

You can see it in action here:

I’d love to see this as an interactive web map where users can have a look at all results, compare with other routing services – or ideally the real world – and finally fix OSM where necessary.

This work has been in the making for a while. I’d like to thank the team of who’s routing service I used (and who recently added support for North America) as well as my colleagues at Ryerson University in Toronto, who pointed me towards Toronto’s open data.

QGIS 2.16 ‘Nødebo’ is released!

We’re happy to announce the release of QGIS 2.16.0 ‘Nødebo’. The University of Copenhagen’s Department of Geoscience and Natural Resource Management Forest and Landscape College in Nødebo were hosts to the First International QGIS conference and developer meeting in May 2015. For all of us who are not fluent in Danish, Lene Fischer has prepared the following video teaching us how to pronounce the release name:

QGIS 2.16 is not designated as a Long Term Release (LTR). Users wishing to have a version of QGIS which does not change and receives bug fixes for at least 1 year are invited to use the current LTR release 2.14.
If you are upgrading from QGIS 2.14 you will find a great many new features in this release.
Whenever new features are added to software they introduce the possibility of new bugs – if you encounter any problems with this release, please file a ticket on the QGIS Bug Tracker.

We would like to thank the developers, documenters, testers and all the many folks out there who volunteer their time and effort (or fund people to do so). From the QGIS community we hope you enjoy this release! If you wish to donate time, money or otherwise get involved in making QGIS more awesome, please wander along to and lend a hand!

QGIS is supported by donors and sponsors. A current list of donors who have made financial contributions large and small to the project can be seen on our donors list. If you would like to become and official project sponsor, please visit our sponsorship page for details. Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts.

QGIS is Free software and you are under no obligation to pay anything to use it – in fact we want to encourage people far and wide to use it regardless of what your financial or social status is – we believe empowering people with spatial decision making tools will result in a better society for all of humanity. If you are able to support QGIS, you can donate here.

One “add” button to rule them all

Reducing the number of “Add layer” buttons in the QGIS GUI is a commonly voiced wish. Multiple approaches have been discussed but no decision has been made so far. One idea is to use the existing browser functionality to replace the “Add layer” dialogs. Others are envisioning completely novel approaches.

Since the topic came up again today on Twitter, I decided to implement a quick & dirty version of a unified Add layer button. This way, I can comfortably reduce my Layer toolbar to three buttons using Settings | Customization …



I pretty much just kept the “Create new layer” button and the “Add delimited text layer” button because, as far as I know, there is no way to call the dialog from the browser. (Instead, CSVs are opened with OGR, which doesn’t have nearly as many nice features.)

And here it is in action:

(I recommend to undock the Browser panel to get the dialog-like behavior that you see in the video.)

To install the plugin: download it and unzip it into your QGIS plugin folder, then activate it in the plugin manager.

I would love to hear what you think about this UX experiment.

Exploring CKAN data portals with QGIS

CKAN is for data portals what QGIS is for GIS. The project describes itself as

CKAN is a powerful data management system that makes data accessible – by providing tools to streamline publishing, sharing, finding and using data. CKAN is aimed at data publishers wanting to make their data open and available.

Many open (government) data platforms rely on CKAN and while the web interface is pretty good, there’s still the hassle of finding and downloading the data using a web browser.

This is where the QGIS CKAN-Browser plugin comes in useful. The plugin has been developed by BergWerkGIS for the state of Carinthia, Austria and added to the public plugin repo earlier this year. CKAN-Browser comes preconfigured with some Austrian and European CKAN URLs for testing, so you can get going really quickly. It is easy to search for specific datasets or explore the portal’s data categories and it is just one click to download and load the data into your QGIS map:

Screenshot 2016-06-26 22.25.00

Here’s a quick demo of loading a vector dataset as well as raster tiles:

For the full usage guide, visit the plugin’s Github page.

It’s great to see how well CKAN and QGIS can play together to enable seamless access to open data!

Slides & workshop material from #QGISConf2016

If you could not make it to Girona for this year’s QGIS user conference, here’s your chance to catch up with the many exciting presentations and workshops that made up the conference program on May 25-26th:

(Some resources are still missing but they’ll hopefully be added in the coming days.)

Update: Now you can also watch the talks online or even download them.

Thanks to everyone who was involved in making this second QGIS user conference a great experience for all participants!

Videos and slides from FOSSGIS & AGIT OSGeo Day

Last week I had the pleasure to attend the combined FOSSGIS, AGIT and GI_Forum conferences in Salzburg. It was a great joint event bringing together GIS user and developers from industry and academia, working with both open source and commercial GIS.

I was particularly impressed by the great FOSSGIS video team. Their tireless work makes it possible to re-watch all FOSSGIS talks (in German).

I also had the pleasure to give a few presentations. Most of all, it was an honor to give the AGIT opening keynote, which I dedicated to Open Source, Open Data & Open Science.

In addition, I also gave one talk related to an ongoing research project on pedestrian routing. It was really interesting to see that other people – in particular from the OSM community – also talked about this problem during FOSSGIS:

(For more details, please see the full paper (OA).)

To wrap up this great week, Astrid Emde, Andreas Hocevar, and myself took the chance to celebrate the 10th anniversary of OSGeo during AGIT2016 OSGeo Day.

And last but not least, I presented an update from the QGIS project with news about the 3.0 plans and a list of (highly subjective) top new features:

Traveltime routing & catchment extension for the QGIS IDF router

As announced in Salzburg a few days ago, I’m happy to present the lastest enhancement to my IDF router for QGIS: travel time routing and catchment computation.

Travel times for pedestrians and cyclists are computed using constant average speeds, while car travel times depend on the speed values provided by the road network data.

Catchment computations return the links that can be traversed completely within the given time (or distance limit). The current implementation does not deal with links at the edge of the catchment area, which can only be traversed partially.

Loading the whole network (2.7GB unzipped IDF) currently requires around 10GB of memory. One of the next plans therefore is to add a way to only load features within a specified bounding box.

Plans to turn this into a full-blown plugin will most likely have to wait for QGIS 3, which will ship with Python 3 and other updated libraries.

Screenshot 2016-07-17 22.04.54

QGIS workshops at FOSSGIS

We are looking forward to a hot geo summer here in Central Europe with both the German FOSSGIS (this year in conjunction with the annual AGIT conference) and the international FOSS4G just a few weeks away. It’s going to be exciting, and I still have a lot of talks (and a keynote) to prep for both events ;-)

If you speak German and want to enhance your geo skills, the FOSSGIS program offers some great opportunities and there is still the chance to sign up for a couple of great FOSSGIS workshops:

Of course the program also features many non-QGIS workshops. If I’d have to pick one of them, it would most certainly be Marc Jansen’s and Andreas Hocevar’s OpenLayers 3 workshop because it’s always great to get the latest information first hand, directly from the developers.

Online registration closes on June 25th.

Crayfish 2.3: New Features

Crayfish 2.3 is out with FLO-2D format support and automatic export of contours

Here are the new features in more detail…

Support for new formats

We added support for FLO-2D result files.

FLO-2D format in Crayfish

Weather Research and Forecasting Model (WRF) outputs are now fully supported in Crayfish.

Export contours

Users can now directly generate vector contours from a Crayfish layer. The export-to-contour feature allows you to select type of contour (e.g. line or area contour) and contour intervals. A very handy option is that the current colour ramp can be also used for your contour intervals.

Exporting contours in Crayfish

Processing toolbox Crayfish provider

We have incorporated many algorithms from Crayfish to processing toolbox (Export grid, Export mesh elements, …). To activate the Crayfish module, from the main menu, select Processing > Options and in the new window, under Providers > Crayfish algorithms select the option for Activate.

Exporting contours in Crayfish

With the processing toolbox, user can create batch geo-processing algorithms to automate their work. For example, you can create a batch process using this module, to export several Crayfish grids to rasters.

Export to animation using the Processing Toolbox is not supported yet.

Future developments

We’d like to add support for mesh generation and also mesh calculator. If these are something of you or your organisation interest and would like to contribute financially, feel free to get in touch.

For any problems or feedback, please consider to file a ticket here.

Report back: 15th QGIS hackfest in Girona, Spain

Time flies when you are having fun! It seems like only yesterday that I was writing about the 14th Hackfest in Gran Canaria. At the end of May 2016, we held the 15th QGIS hackfest! QGIS has been on an incredible journey since the project was started by Gary Sherman 14 years ago, and the fact that the hackfest was held in tandem with the 2nd QGIS International User conference is a testament to the growth and strength of the project.

2nd International QGIS Conference

Isn’t it amazing – we just held the second international QGIS User’s Conference! We really need to give credit to the amazing team who ran a totally seamless operation to organise the event: Gemma Pons, Toni Hernández, Josep Sitjar, Alexandre Busquets, Ferran Orduña, Rosa Olivella, Laura Olivas, & Lluís Vicens

Girona Organising Team

We would like to give a special thank you to the University of Girona’s Director of GIS Service (SIGTE) – Gemma Boix who helped to organised the event as well as ensuring the institutional support for the event. In case I have missed mentioning someone by name, our thanks to all the other volunteers and the sponsors of the conference. Not only did the conference team host the conference event, they also covered a large part of the costs of the hackfest that followed the conference – for which we can’t thank them enough! OSGeo also supported the hack fest financially for which we are extremely grateful.

The conference team also extends their thanks to the attendees and presenters, instructors and developers who also actively participated on the event!  For those interested in viewing the various talks at the conference, here are some handy links:


State of QGIS

The project is in a very healthy state right now. For my talk at the user conference (video here) I got some fresh download stats from our servers and the numbers are quite astounding: QGIS 2.8 LTR (release Feb 2015) has been downloaded over 679, 000 times for the Windows Standalone installer (which includes all bug fix releases). Even after controlling for overestimates (from bot downloads, multiple downloads per user, “try and don’t use”) and underestimates (single downloads being distributed to many users) it is clear that we have an extremely large and constantly growing user base. By another metric, our most popular plugin, the OpenLayers plugin has been downloaded over 700 000 times!

Something else that is clear from the make up of the talks, workshop topics and attendees at the user conference and hackfest: QGIS is increasingly moving from single user environments to large multi-user deployments. This ‘edge of network effect’ is a common phenomenon in FOSS and is largely how Linux came to be such a lynchpin in the dev-ops world. Sys admins and (in the case of QGIS) GIS power users, test out the software on their own devices, see the potential for it in their workplace and start integrating it into their workflows in the office until eventually it has become a mission critical piece of software for an organisation.

One thing my slides probably do not make clear is that there is a huge amount of investment being made into QGIS and plugins for QGIS to fulfil a wide variety of needs. These investments are largely external to the project (i.e. not factored into the financial figures I mentioned in the talk) and happen in direct client-to-developer relationships completely bypassing (from a financial sense) the upstream  QGIS.ORG project. This is a really good model since we do not need to deal with contract delivery, competing interests etc.

If we do a simple calculation based on direct revenue for 2015/2016 (around EUR 69, 000) to downloads, the average revenue per download of QGIS 2.8.x was around EUR 0.10. All of the money we receive into the project goes into improving the QGIS, maintaining infrastructure and funding travel and accommodation for hackfests. I mention these numbers both because they are interesting and because it is good to emphasise how incredibly grateful we are to each and every one of our sponsors and donors that support the project. We really do run on a shoe-string budget and we have audacious goals and a vision to put spatial decision making tools into the hands of everyone on the planet who wants to use them. Your sponsorship and donations are a key enabler to making this vision a reality!

By the way, my apologies for not mentioning Gary Sherman (our project founder) by name at the start of my talk – that was totally unintentional! Before I talk about the main activities, let me make a quick aside to mention the small excursion we took:

Underwater autonomous vehicles & QGIS


One of the really cool things we did at the hackfest was take a little side trip to visit the Computer Vision and Robotics Institute. Natália Hurtós (who works for the institute) kindly gave a bunch of us QGIS geeks a tour. The work they are doing building [relatively] cheap underwater autonomous vehicles is really awesome and inspiring – all the more so because Natalia is planning to build the mission planning tool using QGIS libraries!

Ok so what actually happened at the hackfest? Lets dig in and find out!

Cool stuff from the QGIS Hackfest

I am only going to focus on the hackfest here because the videos from the talks at the QGIS User Conference have been posted online (see above), so you can take in all the QGIS goodness you like from those. There was a lot going on at the hackfest, so these are only the nuggets I managed to cherry-pick from the talks.

Give processing some love

Screen Shot 2016-06-12 at 22.13.15

During the hackfest and user conference, Victor Olaya (lead developer for the QGIS processing framework) really did a great job of promoting the idea of writing processing plugins rather than ‘normal’ plugins. His argument is that most plugins that are intended to provide single purpose analytical capabilities (we are looking at you geeks about to write the 300th buffer plugin!) would  be better off implemented as processing plugins:

  • the plugin author would not need to spend valuable time writing user interfaces, input validators and so on.
  • users of the plugins could chain the tool into complex workflows easily, rather than only being able to use it on a once off basis.
  • we would grow the amount of options available in the processing toolbox while at the same time reducing the sometimes overwhelming amount of choice in the QGIS Plugin Manager.

ILWIS processing tools coming soon

Also on the topic of plugins, Bas Restsios from the ILWIS Project gave a demo of the ILWIS software in order for QGIS developers to be more aware of its capabilities. Although currently Windows only, the ILWIS developers are in the process of porting the software to be based on the Qt5 framework, which means us Linux and OSX users will get to enjoy using it too soon. ILWIS is Open Source and does its rendering using OpenGL. Because of their smart rendering system, everything draws lightning fast. ILWIS packs in many remote sensing tools and raster analysis tools and should be on anyone’s radar if they are interested in FOSSGIS. The best part (from my point of view) is that Bas and his team members are also busy creating a set of processing plugins for QGIS that call out to ILWIS’s command line tools. This means you can expect a huge leap forward in the number of raster based analysis functions you can do with QGIS in the near future.

GeoPackage, JPEG2000, WFS improvements

It was really great to have Even Rouault (maintainer of GDAL/OGR) present at the hackfest. Even recently received core committer rights to the QGIS code repository and has been making great contributions by adding support for the OGC Geopackage format (death to shapefiles!). The shapefile format is long in the tooth and doesn’t serve the GIS community well as a de facto standard for GIS data interchange. It also doesn’t make a good format for intermediate  representation of data processing outputs (e.g. when using multi algorithm processing models). Even has also been working on improvements to WFS support in QGIS which many will appreciate.

Not directly related to QGIS, but Even also mentioned he has been giving the GDAL driver for JPEG2000 some love – gaining good performance increases. This gives me some hope that there will be a viable open format alternative to ECW and MrSid in the future – something which QGIS will benefit from greatly. One of the interesting things that GDAL supports with the JPEG2000 specification is embedded vectors – you can write the raster with gdal_translate and then during creation pass a shapefile or GML stream to the gdal_translate command. I look forward to the day (not currently on the roadmap) where we can ship JP2 images with embedded vector masks and use those embedded vectors  seamlessly in QGIS.

Planning for 3.0 release

We did some planning for the 3.0 release of QGIS and, in particular, fine tuned the plans for how we will manage the transition from QGIS 2.x to 3.x. In February 2016 I posted an outline of the general approach we planned to follow. Some developers felt that we would be better off having the core of the 3.0 transition work happening on the master branch of QGIS so that it has more attention and testing focussed on it. I guess there are two main interest groups to consider here, so I will break down the outcome between take-home points for developers and general users:

For developers:

  • 2.16 gets released off master.
  • After 2.16 we create a 2x branch and the 2x branch will be put into caretaker mode.
  • Support for Qt4 and Py2 will be discontinued in master and we do packaging only against Qt5 and Py3.
  • Once Qt5 and Py3 only are supported in master, nightly build packages may not be immediately available on master as we need to get the packaging systems update.
  • After 2.16 is released API breaking changes will be allowed in master (but code must build and packaging not broken, plugins will be broken).
  • All API breaking changes should be annotated by means of a Doxygen page patch to indicate what changes were made.
  • We target the API change window to end in Feb 2017 so that we can have a 3.0 release in March 2017.
  • We may do a 2.18 release off the 2x branch  if there have been substantial changes in the 2x branch. If there are no substantial changes in the 2x branch following 2.16, we will not do a 2.18 release.
  • In January 2017 we will have a review to establish if all the API breaking changes are complete. If someone has specific implementation plans that are in progress and they need more time, we will (under agreement from the dev community) extend the API breaking window and may push out the release date.
  • Following the release of 3.0 we will implement API freeze again and polish up the codebase for an LTR release based on 3.2
  • 2.14 LTR support will be extended until 3.2 is ready
  • Note: for QGIS 3.x, a minimum of Qt 5.5 is recommended
  • Note: for QGIS 3.x a minimum of Python 3.4 is recommended
  • Note: We are looking for a volunteer to set up a  windows build system using vagrant on win 7 so that we can test and build automaticallyl

For General Users

We propose that for general users, you rather share the following more easy to digest bullet list as it does not contain all the technical details above that mainly developers will care about.

  • 2.18 release is not guaranteed
  • We are planning a 3.0 release in March 2017
  • This release date may be postponed – we will do a review in January to establish whether we are on track for the release date
  • The 3.0 release will break your plugins – we will publish a migration guide and tools to help you migrate your plugin to the new platform
  • If you have any queries about the process please feel free to contact us (via the developer or user mailing lists preferably)

Style repository

Akbar Gumbira, our Google Summer of Code (GSOC) student joined us at the hackfest. For his GSOC project, Akbar is working on a unified way to share styles, symbols, ramps and markers in QGIS. The idea will be very similar to the QGIS plugin repository, where users can host their favourite cartographic elements for everyone else to enjoy. There was quite a lot of technical discussion about the exact mechanisms to use for hosting shared symbology with the key elements of the debate being about whether to use git as a hosting system, simple zip files or some other mechanism. If you wish to chat to Akbar about his work, visit this chat room or comment on the QEP.

OSX Packaging and Building

QGIS is an attractive proposition for OSX users since the big commercial vendors typically don’t support OSX. Since QGIS is built on cross platform technologies, this does not pose a huge limitation for us, but there are few OSX developers in the QGIS developer team and the platform requirements and constraints are pretty complex. Larry Shaffer has been doing awesome work to cut through the various issues and simplify the installation process – both for end users and for developers. It’s finally pretty easy to get a development environment up and running on a Mac now. Using brew (a package manager for OSX) you can install all the needed dependencies and get  QGIS compiling in Qt Creator with full debugging support. The next challenge is going to be supporting this under Qt5 for QGIS 3.0 and Larry has been doing a bunch of great work to make that happen.


There are several web client frontends for QGIS out there. Lizmap is probably the most feature rich of them. Michaël Douchin (@kimaidou on twitter) showed off the latest version of Lizmap. If you are doing any web mapping, you really should check it out!


Marco Bernasocchi showed off the work they have been doing on QField – an Android app for your mobile device. The workflow for using QField is simple: Create a QGIS project on your desktop, copy it over to your device’s SD Card or internal storage, then open the same project on your device. Since it uses the same QGIS 2.14 backend as you are probably running on your desktop, all the cartographic elements from your desktop are supported – including the new 2.5D rendering. The main use case for QField is field data collection and new in QField is the ability to capture point data and edit / update feature attributes. This opens many possibilities for asset management and field survey work.

Marco shared some roadmap plans for QField including broader support for form elements. Value maps are already implemented, value relations, date and picture support are coming soon!. There is also beta support for digitising lines which should land in your installed version soon. I am eagerly looking forward to seeing how QField develops!

During the hackfest I did some testing of QFied using a PostGIS layer in a project with the data coming from a remote QGIS server – and it works (assuming you have internet connectivity). I also did some testing using BTSync to create a synchronised file system between my mobile device and my desktop. Edits to layers on the desktop and the mobile device can easily be pushed back and forth, making it very very easy to push out maps and new data to workers in the field.


There were lots of interesting things going on for those interested in testing. Alessandro Pasotti showed off some really cool stuff he has been working on for running python tests directly in QGIS instead of using a mock QGIS iface object. There are huge benefits to doing this since your tests run in  a ‘real’ QGIS environment. He also showed off how they are testing QGIS plugins in Docker using the above mentioned technique.

If you do need / want to use an mock iface object, Matthias Kuhn has been promoting the use of the new qgis.testing python module improvements which includes an iface object which is comprehensive in terms of API stubs. For pythonistas:

from qgis.testing import start_app, unittest 

Matthias has also created a unittest subclass that you can use which includes nice goodies like letting you do asserts that geometries match.

Matthias Kuhn, Nyall Dawson and others have really been leading the charge to build a more comprehensive test suite in QGIS and there were lots of other interesting tips and tricks been shown like how to make your travis tests run against multiple versions of QGIS – which can be very handy for plugin authors.

Victor Olaya also showed off the tester plugin – for automated GUI testing based on recorded interaction sequences.

Nice things for developers

Martin Dobias showed off some of the tools they have been developing including:

  • The report plugin (see that lets you trap python exceptions and send a bug report directly to a github issue tracker.
  • Martin also showed of the First Aid plugin which lets you capture tracebacks in a more elegant way and also debug your plugin, stepping through the code and execute python instructions in the current run context. The First AID plugin makes a great alternative to using remote debugging from an IDE which is time consuming to set up and technical for less experienced developers to do.

Training plugin

Victor Olaya showed of a plugin (the Lessons plugin) they are working on to facilitate interactive training in QGIS. It uses a simple dock interface to guide the user through a series of activities. Interestingly you can ask it to play recorded macros (saved as python code) of the active being explained so that you can see how it is done if you can’t figure it out yourself. Their authoring system also allows you to record these  macros.



Docker is increasingly becoming a useful building block for those wishing to deploy QGIS in server side contexts. Patrick Valsecchi and Stéphane Brunner did some really awesome work refactoring the QGIS Server docker image – you can get a preview here (read the README for usage notes). Patrick’s work strips down the size of the docker image to make it much less of an overhead to pull the image. We would like to eventually merge this into the upstream QGIS repo so that we have a versioned docker build set up for each QGIS release.



Martin Dobias showed off the Crayfish plugin. Crayfish includes some really awesome multi temporal visualisation tools – really useful if you have time slice data in NetCDF or similar formats and you want to view layers sequentially as animations. It also has cool symbology additions to show flow / directionality arrows over your raster.


GeoNode QGIS Server Demo

Etienne Trimaille demonstrated the work he, Ismail Sunni and Rizky Maulana have been doing to implement a QGIS Server backend for GeoNode. GeoNode is a spatial content management system that allows you to easily upload and share geospatial data on the web. With their implementation you can upload a shape file or TIFF along with a QGIS .qml style file and the layer is published directly as a tile service in the original QGIS styling. Bye-bye hard do create SLD’s, hello easy to create QGIS styles. (Disclaimer: I work with Etienne, Ismail and Rizky so I am tooting our own horn a bit here).


The work of the documentation team is often overlooked in the frenzy to enjoy the new cool stuff that developers churn out. Take a look over at the documentation GitHub pulse page to see how just as much effort is going on in the documentation work. During the hackfest Yves Jacolin and the rest of the documentation team were hard at work getting things ready for the next QGIS Manual release. If you are able to lend a hand with the documentation effort (no coding skills required), please do contact Otto Dassau, the QGIS Documentation Lead!

Lightning talks

Here is also a quick-fire list of features that were shown off -that are coming down the QGIS conveyor belt – mostly for QGIS 2.16 but also new plugins and other efforts:

  • Style dock in QGIS 2.16 with undo / redo – Nathan Woodrow
  • Dynamic hillside rendering – Nathan Woodrow
  • Awesome new gradient editor – Nyall Dawson
  • D3 & Plotly charting with chart interaction showing on the layer – Matteo Ghetta and Michael Douchin
  • Forms improvements: the ‘drag and drop’ editor will support multiple columns – Matthias Kuhn
  • Table view will be able to filter which columns to show (to let you hide unwanted columns) – Matthias Kuhn
  • Action widget columns in the attribute table: you can place one or more action widgets (and icons) into the attribute table making it very easy to fire off an action (e.g. python script) for a particular record – Matthias Kuhn
  • Support for changing column order display in attribute table – Matthias Kuhn
  • In composer you can get have JSON of all layer relations that you can use in your html widget – Nyall Dawson
  • Aggregation in expressions. We will explain this more in the visual changeling for the next release, but you will be able to compute attribute aggregates (e.g. sum of areas) in your reports – Nyall Dawson
  • Default values for fields – Matthias Kuhn showed upcoming work to add support for field defaults in when adding a new record to a vector layer.
  • Transaction groups / cascaded editing mode when you are editing a feature so that related tables get put into edit mode (project property needs to be enabled) – again we will explain this more in the upcoming 2.16 changelog – Matthias Kuhn
  • SectorPlot plugin: a plugin to let you make ‘pizza plots’ of your data – Raymond Nijssen and Richard Duivenvoorde
  • Denis Rouzaud showed off work he has been doing to create a standard settings dialog that you can use in your plugins. It has support for different input types and layer chooser etc. They provide a settings dialog base class that you can derive from in your plugin which will take care of reading and writing your settings to Settings.
  • User profiles plugin – lets you create customised user interface for different user categories – Alex Bruy
  • Georeferenced PDFs and outputs from composer (sorry not yet GeoPDF) but you can use composer to create a  PDF – and then add that into QGIS just like any other raster layer. Nyall Dawson
  • Nyall Dawson chatted about his work on QGIS Task manager – a tool to let you easily create concurrent background tasks and show the progress of each task in a simple UI. I believe he is looking for funding to help him get this finished, so if you are interested please contact him.
  • Bivariate legends plugin (not published yet).  Thomas Gratier showed off work he is doing to support the creation of bivariate legends.


Albireo QGIS Fork


Sandro Mani showed off an awesome new QGIS front end they have been working on at Sourcepole. Their implementation creates a brand dew ribbon based UI paradigm for QGIS (don’t scoff, it’s actually pretty cool!). They have pared down the number of features and grouped functionality into discrete areas, both the menus and ribbon icons changing based on the context of what you are doing. You can see the source code here:  Here are some bullet notes I made while watching his presentation:

  • 3D Globe updates to get it ready for production use. They have also integrated the 3D extrusion support and lots of improvements to the globe that Matthias Kuhn did as part of his masters thesis. Its really exciting to think that these improvements may make their way into the official QGIS builds sometime soon and we can all enjoy them.
  • Redlining – you can sketch onto the map without saving those geometries in a specific layer.
  • Measuring & profile tools
  • Shift-drag for zoom – just like you can do in OpenLayers and Leaflet (Nyall then went and added this to QGIS for 2.16 – yay!)
  • Switch coordinate reference systems used for cursor position display easily from the status bar

There were many other cool features – some of them may make their way into the mainstream QGIS desktop. If you are looking to support users who need a simplified QGIS user interface, Albireo QGIS spin off is something to watch.


Girona was an absolutely awesome venue for the QGIS Conference and Hackfest. I hope the participants of the conference gained good benefit from the experience. The hackfest had around 50 participants and beyond the above notes, there was such a lot going on including work on the documentation system, discussions on the proposed community voter system (more on that in a follow up blog post) and many other things. I really encourage you to attend these events if you want to keep track of the leading edge of QGIS developers.




QGIS style dock – Part 1 – Live Styles!

This post is part of a series exploring the new style dock.

  • Part 1 – Styles
  • Part 2 – Plugin pages
  • Part 3 – New panel API

A while ago did a post about the new style dock in QGIS. The first stage was getting labels working and then moving on to styles. After many iterations of the UIs and the APIs I’m pretty happy with the release state of the dock. We now have styles (vector and raster), labels, saved styles, undo redo, and plugin support (yep!)

Of all the features I have added to QGIS this is my favorite. Nothing has made me feel more productive then working on this feature and seeing the gains it allows in day to day work.

If you haven’t used the style dock yet I would strongly encourage you to grab the nightly QGIS builds and give it a crack, F7 to open anytime, or use the paint brush icon on the layers panel.   I’m not bragging when I say that it will change your life in QGIS for the better, it has become a part of my daily workflow. No going back!

Dock break down


As you can see in the image there is a few main things in the dock, the layer selection, style options selector (come back to this later), undo/redo, live update and apply.

Live Updates

One of the key things for me when doing this dock was instant feedback. I really hated the open close, change, apply, repeat workflow of the old dialogs.  Every widget in the dock can request a redraw on change so you can see feedback instantly in the canvas.  This might not always be what you want so you can disable it for those cases and use manual apply.

Undo Stack

Live updates come with a risk. What happens if you apply something you didn’t mean. There is no cancel button. Well not to fear we now have a undo/redo stack.  Any style change will now add an entry to the style undo stack so you can rollback and forward any changes. Undo/Redo now allows for fearless style changes, so style away to your hearts content and rollback anything you don’t like.

I will also add that the undo stack is stored on the layer object itself, so closing the dock doesn’t clear the stack nor does changing the active layer. You can also access the stack via the Python bindings if needed.

Style Options

On the side of the dock we have the different style options.  These buttons change the style options in the main panel.

Vector Style Options
  • Style
  • Label
  • Saved styles
  • Undo/Redo
Raster Style Options
  • Style
  • Transparency
  • Histogram
  • Saved styles
  • Undo/Redo

The Saved Styles and Undo/Redo will always be the last in the stack regardless of the active layer type.

Style UIs (Note: GIF heavy section)

Almost all the widgets have been tweaked to allow for better dock layout. Widgets are now in a more uniform layout which flows better when moving around in the dock and just generally look better.


When I talked about live updates before this applies to everything, even the data defined buttons.  Any changes in those will be reflected into the canvas without any extra clicks.


Changing renderers is now simple and quick. You go from nothing to seeing instant results in seconds.


A excellent side effect of the live updates is workflows that were never exposed before and now possible. Using the graduated renderer histogram for example. As the histogram allows for live edits we can now update the map on the fly from adjusting the histogram.


Style UIs (Raster)

As soon as I finished vectors it became pretty evident that raster layers were going to be the next main thing to move.   So the style dock fully supports raster styling.



For the final trick. Here we have the undo/redo stack in action. Unlimited undo/redo  on all layers when changing styles. Fearless change he we come


Trying to find a picture to sum up my feelings about the style dock and I think this fits

but of course I’m super bias.

Stay tuned for Part 2 where I talk about adding your own style panels to the style dock.

Filed under: Open Source, qgis

QGIS style dock – Part 2 – Plugin panels

In part 1 I talked about the new style dock and the in built functions it has in this post I would like to cover how you can extend that dock using plugin panels.

While building the dock it became evident that being able to add your own panels with be super neat, why lock the user to what styling controls we have built into core.

After one, or two, API iterations it is now possible to add your own panels to the style dock.

First we need to make a new widget using QgsLayerStylingPanel

class CustomPanel(QgsLayerStylingPanel):
    def __init__(self, layer, canvas, parent):
        super(CustomPanel, self).__init__(layer, canvas, parent)
        self.layer = layer

    def apply(self):

then we need to create a factory object (QgsLayerStylingPanelFactory) which will hold the metadata for the panel widget, things like icon, title, and the widget it self as required. The factory object looks like this:

class PanelFactory(QgsLayerStylingPanelFactory):
    def icon(self):
        return QIcon(r&quot;F:\icons\SVG\book.svg&quot;)

    def title(self):
        return &quot;&quot;

    def supportsLayer( self, layer):
        return layer.type() == QgsMapLayer.VectorLayer

    def createPanel(self, layer, canvas, parent):
        return CustomPanel(layer, canvas, parent)

# Also make a instance and tell the style dock about it
# make sure you keep a instance of the the factory around
factory = PanelFactory()

You can also see we have a supportsLayer() method. This must return True if the layer can be supported for the widget, if the layer isn’t support it’s not shown in the layer style dock. We also have the createPanel method which just returns the widget, you could also use this method to return different widgets based on layer type if you needed. This createPanel method will be called any time the item is selected in the left panel of the style dock. Using the above code we will see a new icon on the side panel


Remember, the create method is called any time this new item is selected.    If your widget is expensive to create you can create a cache here.

Now lets add some logic.  As an example I’m going to load the style xml and show it in the panel. Adding some logic to the __init__ method of the CustomPanel class

class CustomPanel(QgsLayerStylingPanel):
    def __init__(self, layer, canvas, parent):
        super(CustomPanel, self).__init__(layer, canvas, parent)
        self.layer = layer

        # Create the editor and set the xml from the layer.
        self.editor = QgsCodeEditorHTML()
        doc = QDomDocument( &quot;style&quot; ) 
        rootNode = doc.createElement( &quot;qgis&quot; )
        doc.appendChild( rootNode )
        iface.activeLayer().writeStyle( rootNode, doc, &quot;&quot;)
        xml = doc.toString()


Nifty.  Now can we 1 UP it and make it live edit?  Sure can!  The style dock will call apply() whenever we raise the widgetChanged signal.  We can just connect this to the text changed event and add some logic to the apply method.

class CustomPanel(QgsLayerStylingPanel):
    def __init__(self, layer, canvas, parent):
        super(CustomPanel, self).__init__(layer, canvas, parent)

    def apply(self):
        # Read the xml and set it back to the style.
        doc = QDomDocument( &quot;style&quot; ) 
        node = doc.documentElement()
        self.layer.readStyle(node, &quot;&quot;)



Pro Tip: Raise widgetChanged whenever you need to tell the style dock to trigger the apply method. The style state of the layer will also be saved to the undo stack so you don’t have to worry about that.

This is just an example, hand editing xml is well gross, but I’m sure you can see great uses for being able to expand the style dock.

Filed under: Open Source, qgis

Gaining more WMS speed through enabling the QGIS cache directory

Interestingly the WMS caching is not enabled by default in QGIS. To better enjoy WMS/WMS-C/WMTS connections – if you have some disk space to dedicate – it is a good idea to enable the cache in these few steps:

Go to the menu entry Settings >> Options:

Enabling the QGIS WMS cache - step 1

Enabling the QGIS WMS cache – step 1

Go to tab “Network“. Therein, in “Cache settings“, select the “Directory” and choose a folder for the cache files. Be sure that there is free space for lots of megabytes can be stored there over time. And this directory should ideally be located on a fast disk (if you have several).

Here I choose the existing “tmp/” folder in my HOME directory and create inside a new folder “qgis_wms_cache”:

Enabling the QGIS WMS cache - step 2

Enabling the QGIS WMS cache – step 2: create new “qgis_wms_cache” cache folder

Eventually we change the “Default expiration period for WMS-C/WMTS tiles (hours)” to more than 24 hours (as it would be rather useless…). Here I change to 24*30 = 720 hours. And the cache size we increase as well, here to 250MB (written as 250000 since it is to be given in kilobytes):

Enabling the QGIS WMS cache - step 3

Enabling the QGIS WMS cache – step 3: increase expiration period for tiles and cache size

Now we press “OK” and close the dialog. Time to try out a WMS service, zoom back and forth… and:

The post Gaining more WMS speed through enabling the QGIS cache directory appeared first on GFOSS Blog | GRASS GIS Courses.

New GRASS GIS 7.2.x stable release branch created

Towards the new stable release series

As of 24 May 2016, a new stable release branch was created for the upcoming GRASS GIS 7.2 release. This new branch includes all the many improvements which have been implemented in the former development version 7.1.svn.

What is a branch? In simple words, it is a kind of directory in the software development server (SVN in our case) in which no more development but only bugfixing happens. From a release branch, new stable releases are created and published.

The actual branches in the GRASS GIS project are:

  • very old stable: releasebranch_6_4 (used for bugfixing and to publish stable GRASS GIS 6.4.x releases) – very low release frequency (started in revision r34936)
  • old stable releasebranch_7_0 (used for bugfixing and to publish stable GRASS GIS 7.0.x releases) – perhaps one last release upcoming (branch started in revision r59487 but development already started in Apr 2008 in r31142)
  • new stable releasebranch_7_2 (used for bugfixing and to publish stable GRASS GIS 7.2.x releases) – upcoming series of stable releases (branch started in revision r68500)
  • trunk (used for development, with pseudo-name 7.3.svn) – under heavy development

Note to SVN users

The trunk branch with pseudo-name 7.1.svn has become 7.3.svn due to the creation of the new 7.2.svn release branch. You can simply continue to update from SVN, the version will be automatically updated.

If you used to work with the 7.0.svn release branch, consider to download the new 7.2.svn release branch, either from the weekly source code snapshot (here) or from the SVN server directly (here).


The Geographic Resources Analysis Support System (, commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The GRASS Development Team, May 2016

The post New GRASS GIS 7.2.x stable release branch created appeared first on GFOSS Blog | GRASS GIS Courses.

Introducing First Aid Plugin

First Aid Plugin

Software development often consists of a brief period of pure excitement while writing the bulk of the source code, followed by a long and dreaded period of finding bugs and fixing them. This scheme is no different when writing plugins for QGIS.

Because we also write QGIS plugins ourselves, we were thinking of how to ease the pain of getting rid of bugs — and so we ended up creating the First Aid plugin, now available in the official QGIS plugin repository.

It is meant to be a Swiss army knife for QGIS plugin developers, a tool that allows easy inspection of any Python code running within QGIS. This is important because it can potentially save developers a lot of their valuable time.

How many times did you end up adding “print” statements into the code to find out what was going wrong in your code? With First Aid plugin this should be no longer necessary.

Error Handler

So let me explain what does it do. First of all, it comes with an improved Python error handler. What this means is that whenever an error occurs in code of a plugin, a window with all the details comes up.

Previously in QGIS you could only find out what was the exception’s type, message and stack trace. First Aid plugin adds source code view, variables view and even an embedded Python console where you can further inspect the state of the plugin at the time of the error. Here is how it looks like in action:

Error Handler Screenshot


Plugins however do not always come up with errors that can be caught and handled by QGIS. More often plugins simply do not behave as one would expect them to. Here is when people usually resort to using debuggers. There are IDEs like PyDev or PyCharm – or even standalone tools like Winpdb – that allow developers to do remote debugging. Basically they can connect to the Python environment within QGIS and debug the code there. Personally, I have never been a big fan of this approach and found remote debugging cumbersome to set up and use. And trying to debug something on a client’s computer is even a greater challenge.

First Aid fortunately integrates a debugger into QGIS environment. This allows developers to simply open the debugger window, load some Python files, set breakpoints and everything is ready. Once QGIS reaches a line with a breakpoint, the debugger window will be activated and it is possible to step through the code and inspect the variables to understand what is going on in the code.

Debugger Screenshot

The great thing is that once the execution of Python code is stopped, it is possible to step into code, step over, step out or run to cursor, just like in any other debugger. It is also possible to run custom scripts from within debugger window — they will be also run in debug mode.

Debugging is active only while the debugger window is still open. While debugging, there is some extra overhead when running any Python code (even for code that you do not intend to debug), so it is better to close the debugger when not needed.

The plugin has already helped us various times to quickly identify problems in plugins. Having said that, please note that the plugin is still quite young and may not work perfectly in all cases. We would be happy to hear your feedback. Any issues or pull requests on GitHub would be greatly appreciated!

QGIS Code Sprint - FOSS4G UK - 2016

Issue Reporting

The Open Source community in the UK will get together for another great FOSS4G meeting from 14 to 16 of June in Southampton.

QGIS has already established itself as one of the major Open Source GIS applications. To help the community to contribute back to the project, we are running a code sprint.

The code sprint session will not require prior knowledge of coding, so all participants are welcome to join. Make sure you bring your laptop!

There will be several power users and plugin developers to help with the code sprint. There will be 3 topics covered during the code sprint:

  • Documentation
  • Helping with the bug fixing
  • Contributing to qgis2web plugin


If you are interested in helping with the QGIS documentation, we will run a short presentation to introduce you to the workflow.

Participants are required to have installed and configured the following software packages:

Helping with the bug fixing

For those who are interested in findings bugs, testing existing bugs and leaning up the bug queue, you will need:

  • An OSGeo ID
    • Currently requires contacting OSGeo admins on IRC (#osgeo) in order to get the registration form (!)
  • Multiple versions of QGIS
    • QGIS LTR (LTS)
    • QGIS release
    • QGIS master

If you are familiar with coding (in C++ and python) and would like to fix some bugs, you will need:

  • QGIS development environment
  • Github account

Contributing to qgis2web plugin


Help improve qgis2web by joining any of these activities:

What you’ll need

  • laptop
  • QGIS, ideally current or nightly
  • a Github account
  • whatever Git/Github client you prefer
  • your favourite text editor

Details of some specific bugs and features are listed in a dedicated Github issue. If you are not coming to FOSS4GUK 2016, we’d still really value any help you can give. We’ll keep an eye on Github, or try the qgis2web Gitter.

This is a great opportunity to take your first steps in contributing to an open-source project. Come and help – we’ll tell you everything you need to know, and help you learn the skills you don’t yet have. Rest assured that we will be at least as grateful as you for the help you give.

If you are a beginner, @archaeogeek is also running a great workshop at FOSS4GUK 2016 on getting started in open-source: Don’t be afraid to commit

Licensing requirements for QGIS plugins

One thing we have been encountering lately in the QGIS project is plugin authors not understanding the licensing requirements for publishing their QGIS plugins. In this article I will try to clarify this a little:

QGIS is Open Source Software and provides a great platform for third parties to distribute additional functionality to users through our plugin system. QGIS is licensed under the GPL version 2 or greater. This license is provided with every copy of the QGIS and in the source code and is available on our web site here:

Under the terms of this license, it is a requirement that all plugins distributed via (or through other repositories that may be self-hosted) should comply with the GPL version 2 or greater license. In particular all code included in any plugin should be made clearly and easily available in source form. It has come to our attention that some plugin authors are distributing plugins that do not comply with this condition.

We ask you to consider the fact that many thousands of hours of work and large amounts of financial outlay from individuals and companies has gone into the creation of QGIS. This work is done under the basis that in-kind contributions raise the quality and capabilities of the platform for everyone. When you create a plugin, you only need to spend a minimal amount of effort to solve your specific requirements because we have done the rest of the work needed to provide an entire platform for you and our community of users. This is a key value proposition of Open Source: ‘a rising tide floats all boats’.

By publishing the source code for your plugin, others may inspect the underlying code of your plugin and learn from it and use that knowledge to further improve the platform. Not releasing your source code breaks this model. Besides being a contravention of the licensing conditions under which you received the QGIS software, withholding your source code does not advance the body shared knowledge, and does not embrace the spirit of sharing that has made the QGIS project such a success to date.

Thus if you are a plugin author who is distributing your plugin without the accompanying source code, you need to be aware that the source code needs to be made available to each person who receives the binary sources for your plugin.

One query that plugin authors have raised is whether the requirement to publish the sources of their plugin precludes their ability to sell or otherwise commercially benefit from their plugin work. This is not the case – you can sell you plugin as long as you make  the sources of your plugin available under the same license as QGIS to each purchaser.

Should you have any queries about how to better collaborate within the QGIS community we are available to you – please direct your queries to

Using OS AddressBase for Address Search in QGIS

In this blog post we’ll learn how to use Ordnance Survey AddressBase data with the QGIS Discovery plugin for searching addresses.

Discovery Plugin for QGIS

Before we start

The AddressBase data will be loaded into a PostGIS table for Discovery to query. At this stage we should already have a functioning PostgreSQL / PostGIS installation.

A previous blog post describes how to quickly set up such an environment.

Creating the addressbase table

Let’s now create a table for storing the addressbase data. In the example below we’ll create a table called addressbase in the os_address schema.

The script below can be executed through pgAdminIII.

To run the script:

  1. Open pgAdminIII
  2. Connect to your destination database
  3. Select Query tool from the Tools menu
  4. Paste the code below into the Query tool
  5. Press F5 to execute the query (it may take a few seconds to complete)

When the query has finished you should see Query returned successfully with no result in … seconds. in the Messages panel:

pgAdminIII Messages Panel

At this point we should be able to locate the new addressbase table within the os_address schema:

addressbase Table

If you can’t see the schema / table you probably need to refresh the schemas / tables views in pgAdminIII’s Object browser panel by hitting F5.

``` — Create the destination schema if required CREATE SCHEMA IF NOT EXISTS os_address;

— Create a function which will populate the full_address and geom columns as — data are imported CREATE OR REPLACE FUNCTION create_geom_and_address() RETURNS trigger AS $$ BEGIN — The geometry — Set it based on the x_coord and y_coord fields NEW.geom = ST_SetSRID(ST_MakePoint(NEW.x_coordinate, NEW.y_coordinate), 27700); — The full address — Initialise it NEW.full_address = ‘’; — Build the full address by only including optional address components if they — exist IF NEW.organisation_name IS NOT NULL AND length(NEW.organisation_name) > 0 THEN

NEW.full_address = NEW.full_address || NEW.organisation_name || ', ';

END IF; IF NEW.department_name IS NOT NULL AND length(NEW.department_name) > 0 THEN

NEW.full_address = NEW.full_address || NEW.department_name || ', ';

END IF; IF NEW.po_box_number IS NOT NULL AND length(NEW.po_box_number) > 0 THEN

NEW.full_address = NEW.full_address || NEW.po_box_number || ', ';

END IF; IF NEW.sub_building_name IS NOT NULL AND length(NEW.sub_building_name) > 0 THEN

NEW.full_address = NEW.full_address || NEW.sub_building_name || ', ';

END IF; IF NEW.building_name IS NOT NULL AND length(NEW.building_name) > 0 THEN

NEW.full_address = NEW.full_address || NEW.building_name || ', ';

END IF; IF NEW.building_number IS NOT NULL THEN

NEW.full_address = NEW.full_address || NEW.building_number || ', ';

END IF; IF NEW.dependent_thoroughfare IS NOT NULL AND length(NEW.dependent_thoroughfare) > 0 THEN

NEW.full_address = NEW.full_address || NEW.dependent_thoroughfare || ', ';

END IF; IF NEW.thoroughfare IS NOT NULL AND length(NEW.thoroughfare) > 0 THEN

NEW.full_address = NEW.full_address || NEW.thoroughfare || ', ';


NEW.full_address = NEW.full_address || NEW.post_town || ‘, ’;

IF NEW.double_dependent_locality IS NOT NULL AND length(NEW.double_dependent_locality) > 0 THEN

NEW.full_address = NEW.full_address || NEW.double_dependent_locality || ', ';

END IF; IF NEW.dependent_locality IS NOT NULL AND length(NEW.dependent_locality) > 0 THEN

NEW.full_address = NEW.full_address || NEW.dependent_locality || ', ';


NEW.full_address = NEW.full_address || NEW.postcode;


— Drop any existing addressbase table DROP TABLE IF EXISTS os_address.addressbase CASCADE; CREATE TABLE os_address.addressbase ( — id will be the primary key, populated automatically id serial NOT NULL, uprn bigint NOT NULL, os_address_toid varchar(24) NOT NULL, — os_address_toid bigint NOT NULL, udprn integer NOT NULL, organisation_name varchar(60), department_name varchar(60), po_box_number varchar(6), sub_building_name varchar(30), building_name varchar(50), building_number smallint, dependent_thoroughfare varchar(80), thoroughfare varchar(80), post_town varchar(30) NOT NULL, double_dependent_locality varchar(35), dependent_locality varchar(35), postcode varchar(8) NOT NULL, postcode_type char(1) NOT NULL, x_coordinate numeric(8,2) NOT NULL, y_coordinate numeric(9,2) NOT NULL, latitude numeric(9,7) NOT NULL, longitude numeric(8,7) NOT NULL, rpc char(1) NOT NULL, country char(1) NOT NULL, change_type char(1) NOT NULL, la_start_date date NOT NULL, rm_start_date date NOT NULL, last_update_date date NOT NULL, class char(1) NOT NULL, — the next two fields are populated automatically on insert full_address text NOT NULL, geom geometry(Point,27700) NOT NULL, CONSTRAINT addressbase_pkey PRIMARY KEY (id) ) WITH ( OIDS=FALSE );

— Create a pg_trgm index on the full_address column — This will allow super-fast, case-insensitive search on the column CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX addressbase_full_address_gin_trgm ON os_address.addressbase USING gin (“full_address” gin_trgm_ops);

— Spatial index for the geometry column CREATE INDEX addressbase_geom_gist ON os_address.addressbase USING gist (geom);

— trigger to create points and addresses — This trigger will be executed on each row inserted, calling the function defined above CREATE TRIGGER tr_create_geom_and_address BEFORE INSERT ON os_address.addressbase FOR EACH ROW EXECUTE PROCEDURE create_geom_and_address();


The script above has:

  • Created a table
  • Added any necessary indices
  • Created two additional, derived columns, full_address and geom

full_address will be used to store various address components into a sensible, human readable address. geom will be used to store point geometry based on address eastings/northings.

See the script comments for more information / detail.

Loading AddressBase

At this point we have an empty table ready to accept our AddressBase data. We will now import the data using pgAdminIII. Extract the CSV files for the addresses, you should end up seeing one or more CSV files, for example AddressBase_FULL_2016-03-19_001.csv

In pgAdminIII:

  1. Locate the addressbase table
  2. Right click it, select Import

An import dialog should appear. Select the first CSV file and set the settings in the File Options tab as shown here:

AddressBase Import Options 1

Uncheck the id, full_address and geom columns in the Columns tab as shown here:

AddressBase Import Options 2

Click Import. After a few seconds the dialog may report (Not Responding). This is nothing to worry about, be patient.

When the import process completes, close the import dialog and repeat the above steps with any remaining CSV files.

At this stage the data has been imported and the full_address field should contain sensible, human-readable addresses.

Configuring Discovery

With the data loaded in QGIS, we can now configure Discovery to make use of it.

  1. Install the Discovery plugin if not already installed
  2. Open Discovery’s settings using the button
  3. Set the settings as follows, changing the Scale Expression if required

Discovery Settings for OS AddressBase

Congratulations! QGIS should now be set up to search your AddressBase data.

Speeding up QGIS build times with Ninja

As a developer, feedback is important when you are working.  The quicker you have the feedback the quicker you can fix the issues.  This doesn’t just apply to feedback from users/clients but also from your tooling.

Finding a new tool that increases my productivity is one of the best feelings, and this is one of those cases.   I was told about using Ninja for building instead Make, Visual Studio, Jom (Qt Build Tool).

If you are not a developer and don’t know what those tools are, they are what we use to build and compile all the code in QGIS.  If this step is slow the feedback loop is slow and it becomes annoying.  Improving this feedback loop greatly increases your workflow and happiness, and by happiness I really do mean that.

Ninja is one of these tools that did this. It’s optimized to be fast.  It does very little work in order to be faster any time it can.  Ninja was built by a developer on the Google Chrome team in order to improve their build times (read the history here)

Building QGIS with Ninja is super easy:

Install Ninja from package manager or using the ninja.exe (the whole tool is a single exe) if you are on windows

cd qgis-src
mkdir ninja-build
cd ninja-build
ccmake -GNinja ..


You can build just the targets you need using

ninja qgis
ninja pycore


The ccmake setup generates the file that ninja uses. Myself and Matthias Kuhn have already patched our QGIS cmake files to handle any odd things that got generated – only a handful of things which was nice

The best thing I find about Ninja is how smart it is on knowing if it needs to build something or not, and this is the point that I find other tools fail on. They spend ages wasting time looking for what to do. Ninja knows it in a instant.

When running Ninja with no code changes I get this (on Windows):

21:18:54: Running steps for project qgis2.15.0...
21:18:54: Starting: &quot;C:\QtCreator\bin\ninja.exe&quot; qgis
ninja: no work to do.
21:18:54: The process &quot;C:\QtCreator\bin\ninja.exe&quot; exited normally.
21:18:54: Elapsed time: 00:00. 

Not even a second. If I did the same with VS or JOM I could have written this post before it finished working out what to do.

Here is what happens changing a single file:

21:19:48: Running steps for project qgis2.15.0...
21:19:48: Starting: &quot;C:\QtCreator\bin\ninja.exe&quot; qgis
[1/6] Building CXX object src\core\CMakeFiles\qgis_core.dir\raster\qgshillshaderenderer.cpp.obj
[2/6] Linking CXX shared library output\bin\qgis_core.dll
21:19:51: The process &quot;C:\QtCreator\bin\ninja.exe&quot; exited normally.
21:19:51: Elapsed time: 00:03.

It’s super impressive. Even a cold build on Windows is shorter now. On Linux it’s even faster due to faster disk access in Linux vs Windows

If you build QGIS form source I would highly recommend giving it a crack because I know you will love it.

Filed under: Open Source, qgis

QGIS Report Plugin Release

Issue Reporting

We develop several public and private plugins for QGIS users and our clients. During the testing phase, they often come across some bugs. To enable them to report the issues and include the right type of information, we have developed The Report plugin to simplify the process Report plugin.

The Report plugin helps developers get better bug reports from users, by auto-populating the relevant information. It also simplifies the bug reporting process for users.

The Report plugin can automatically extract information from the plugin crash as well as other important information for developers. With just one click you can report the issue to the official plugin issue tracker. No need of searching for a plugin’s tracker on the internet or copy-pasting long tracebacks to your browser.

bug report plugin


  • Install Report plugin from QGIS plugin offical repository
  • Create a GitHub account if you do not have any existing
  • Create a public access token GitHub with public_repo scope
  • Click on the Report plugin toolbar button, Configure link and copy generated GitHub access token to the configuration dialog.
  • Wait for next error and report the problem to the developers


  • Feel free to download DevNull plugin from QGIS plugin offical repository to be able to test Report plugin
  • After installation fo DevNull plugin, click on the new button /dev/null in your toolbar and watch how report plugin catches the exception
  • Report any number of testing issues to DevNull Issue tracker, they are going to be deleted anyway!


  • Report plugin works only with GitHub issue trackers
  • Plugins must have “tracker” metadata filled in, so the Report plugin can detect the plugin issue tracker correctly

When/if QGIS issue tracker moves to GitHub, a similar tool can be added to the core to automatically report bugs and crashes.

  • <<
  • Page 3 of 88 ( 1746 posts )
  • >>

Back to Top