Page 1 of 29 (571 posts)

  • talks about »
  • qgis


Last update:
Tue Dec 1 01:25:13 2015

A Django site.

QGIS Planet

In brief: 4th QGIS user group in Scotland

Another sold-out event with a programme packed with useful, interesting and delightful talks. Fifty seven (57!) folk blew in from all over Scotland through a freezing rain but hot coffee and pastries were waiting in the Informatics Forum at the University of Edinburgh.

First up was an overview the current status of the QGIS project by Saber from Lutra Consulting. It was good for people new to QGIS and open-source to see how the project is organised and run and the direction it is taking. Pete, also from Lutra Consulting, then gave a quick summary of the bits of core functionality they have been working on including the new ruled based labelling system.
The group then split into two for 90 minute workshop sessions on cartographic labelling and advanced Atlas usage – a tough choice! Chris, from Ordnance Survey, presented a detailed how-to on the new ruled based labelling tools using some OS open data, interspersed with some slides on guidelines to good cartographic practices and labelling tips. The slides and material for this workshop are available here:

Heikki, from thinkWhere, lead us through the process of using Atlas in Print Composer to automate map production for a series of maps containing a main context map and an inset overview map. Nothing better than doing something once and then being able to repeat it at the click of a button! The slides and material for this workshop are available here:

A break for lunch and a good hour of catching up with users from across all sectors – local government, central government, academia, forestry, planning consultancies, developers, student life and education. QGIS is popular and is obviously a flexible tool that meets many demands.

After lunch, Neil, from thinkWhere, organised a quick-fire “quirky QGIS quiz” with random questions from all aspects of FOSS4G demanding quick thinking for true/false answers. At least half the audience grabbed prizes courtesy of thinkWhere and Ordnance Survey.

What followed was a series of lightning talks on different aspects of using QGIS. Amy, from Cawdor Forestry, gave a brief overview of the plugins available in the QGIS plugin repository and highlighted some of her personal favourites. Paul, from Scottish Water, showcased some of the complex workflows created using SAGA, QGIS and the Processing Toolbox to model hydrological process. Ross, from Inverclyde Council, demonstrated the use of the QGIS Road Graph plugin to generate walking routes to school across a custom road and path network. Seb, from West Dunbartonshire Council, showed us how QGIS had put them in a happy place and showed how a “hearts and minds” campaign championing QGIS had changed the way they worked. Steve, fae Embra, gave some information on how to give back to the QGIS project through submitting Processing scripts and plugins to the repository. Don’t reinvent the wheel! Ross, from Angus Council, gave a quick demonstration of setting up a local plugin repository that could be used to share custom plugins or control access to plugins in an internet-less environment.

By this time, tea and cake was required and it gave everyone an opportunity to mix and ask questions of the speakers.

The last session was as series of longer talks started by Gemma, from Ordnance Survey, explaining how open-source software is used extensively at Ordnance Survey to underpin a lot of the cartographic processes and workflows. They use QGIS 2.8 LTR for stability and consistency across the business and a selection of plugins from both OS developers and the community. QGIS is used to generate all the cartographic styles sheets for the OS vector products:

Tom, from EDINA, explained the processing of creating and delivering a QGIS training course to University staff and students. The first class sold out in next to no time and there is demand for more. Makes sense really, doesn’t it?

Steve, from GeoGeo, wrapped up the day with the kind of mapping we’d all like to be doing – high resolution elevation models, time series analysis of shadows, viewsheds across the Edinburgh skyline and analysis of rooftops for potential solar panels with sub 1m resolution LiDAR datasets. He uses a mix of QGIS, SAGA, Blender and other FOSS to inspiring effect. Check his Flickr stream:

The day finished with Pete (Lutra Consulting) releasing into the open a new Search plugin for QGIS called Discovery ( based on the PostGIS Search plugin from Tim Martin (Ordnance Survey). A very useful addition to any QGIS installation.

The day was sponsored by EDINA, thinkWhere and Ordnance Survey.

Links to slides will be coming shortly.

How to create connectivity-based line caps

It’s been a while since my last blog post mostly because I’ve been busy with some more long form writing. Most notably, I’ve been writing a paper on the QGIS Projcessing framework in the open access ISPRS International Journal of Geo-Information together with Victor Olaya and I’m still in the process of writing a new book titled “QGIS Map Design” together with Gretchen Peterson which is scheduled for early 2016.

Today’s post has been on my todo list for a while now. It’s inspired by a talk at a recent cartography conference I attended:

(For a summary of the whole event, check the storify I compiled.)

The idea of this slide and several more was to show all the attention to detail which goes into designing a good road map. One aspect seemed particularly interesting to me since I had never considered it before: what do we communicate by our choice of line caps? The speaker argued that we need different caps for different situations, such as closed square caps at the end of a road and open flat caps when a road turns into a narrower path.

I’ve been playing with this idea to see how to reproduce the effect in QGIS …

So first of all, I created a small test dataset with different types of road classes. The dataset is pretty simple but the key to recreating the style is in the attributes for the road’s end node degree values (degree_fro and degree_to), the link’s road class as well as the class of the adjacent roads (class_to and class_from). The degree value simply states how many lines connect to a certain network node. So a dead end as a degree of 1, a t-shaped intersection has a degree of 3, and so on. The adjacent class columns are only filled if the a neighbor is of class minor since I don’t have a use for any other values in this example. Filling the degree and adjacent class columns is something that certainly could be automated but I haven’t looked into that yet.



The layer is then styled using rules. There is one rule for each road class value. Rendering order is used to ensure that bridges are drawn on top of all other lines.


Now for the juicy part: the caps are defined using a data-defined expression. The goal of the expression is to detect where a road turns into a narrow path and use a flat cap there. In all other cases, square cap should be used.


Like some of you noted on Twitter after I posted the first preview, there is one issue and that is that we can only set one cap style per line and it will affect both ends of the line in the same way. In practice though, I’m not sure this will actually cause any issues in the majority of cases.

I wonder if it would be possible to automate this style in a way such that it doesn’t require any precomputed attributes but instead uses some custom functions in the data-defined expressions which determine the correct style on the fly. Let me know if you try it!

A new QGIS plugin allows dynamic filtering of values in forms



This plugin has been partially funded (50%) by ARPA Piemonte.


This is a core-enhancement QGIS plugin that makes the implementation of complex dynamic filters in QGIS attribute forms an easy task. For example, this widget can be used to implement drill-down forms, where the values available in one field depend on the values of other fields.


The plugin is available on the official QGIS Python Plugin Repository and the source code is on GitHub QGIS Form Value Relation plugin repository


The new “Form Value Relation” widget is essentially a clone of the core “Value Relation” widget with some important differences:

When the widget is created:

  • the whole unfiltered features of the related layer are loaded and cached
  • the form values of all the attributes are added to the context (see below)
  • the filtering against the expression happens every time the widget is refreshed
  • a signal is bound to the form changes and if the changed field is present in
    the filter expression, the features are filtered against the expression and
    the widget is refreshed

Using form values in the expression

A new expression function is available (in the “Custom” section):


This function returns the current value of a field in the editor form.


  1. This function can only be used inside forms and it’s particularly useful when used together with the custom widget `Form Value Relation`
  2. If the field does not exists the function returns an empty string.

Visual guide

This is the new widget in action: changing the field FK_PROV, the ISTAT values are filtered according to the filter expression.

The new widget in action

The new widget drill-down in action


Choosing the new widget

Configuring the widget

Configuring the widget

Configuring the expression

Configuring the expression to read FK_PROV value from the form

News from QGIS HackFest in Las Palmas

First I wish to thank Pablo & friends for the amazing organization, unfortunately I couldn’t spend more than two full days there, but those two days have been memorable!

Here is a picture of one of the most interesting discussions (photo: courtesy of Pablo).

QGIS discussion at the developer meeting in Las Palmas

An hack fest is an event for writing good code but what it’s really good at is to establish and cultivate relations with other coders, to exchange opinions and ideas and last but not least to have some fun and make new friends.


This time, we have had many interesting presentations and a couple of meetings where we spoke about technical aspects of the project management and infrastructure and about some important challenges, both in terms of code size and economical implications for who relies on it, that a growing project must face.


The latter was something I’ve also been considering for a while: now that pull requests (PR) for new features are coming down the pipeline, we must find a better way to manage their queue by giving a clear and transparent approval path and deadline. This management and approval process cannot rely entirely on volunteer work, the main reason being that most of the times the PR proposers have been paid for that PR and it’s not fair (nor reliable) that the (sometimes hard) job of doing a code review is not rewarded. On the other end, an investor cannot waste its time and money on a project without having a reasonable good chance to see its work eventually land into the core of QGIS.


Hugo (thanks for that!) organized a meeting to discuss this topic, that crosses personal business interests, ethical considerations and personal beliefs to a point that it’s not really easy to discuss in a calm and objective way, despite the premises, the discussion was very interesting and constructive and a QEP that tries to address at least some of this problems is open for discussion right now:


Another topic we’ve been discussing was how to manage python plugin dependencies, we’ve decided to start by adding a new metadata tag called external_deps that’s supposed to contain the PIP install string for the required packages, since PIP will be a builtin in python 3.4, that will probably solve most of our problems when we’ll integrate that into the plugin manager. At the moment the metadata is not documented nor required, but it’s there to allow for experiments.


We didn’t miss the occasion to talk about the ugly bug that affects fTools, not something I’m going to dig into in this post though.


Of course an hack fest is still a good opportunity for squashing bugs and implement new cool features, I’ve been busy mainly on the following topics:

  1. HiDPI screen support for web view widgets (help and plugin manager/installer)
  2. Form relations editing longstanding bugs
  3. New feature to optionally enter, edit and store Python form init code into the project (and DB), see the picture below
  4. Plugins website maintenance (added new metadata and fixed a few bugs, added an RPC call to export author email for admins)
New QGIS feature to store form init code


Thanks to all participants, to the organizers and to all QGIS sponsors and donors that made this possible!


Creating a Tissot’s Indicatrix in QGIS

The task of projecting, or unfolding the spherical Earth onto a flat map, is an age old problem in cartography. Projection almost always introduces distortion, most projections cannot preserve angles, areas and distances at the same time, they may be conformal (angle-preserving), equal-area (area-preserving) or equidistant (distance preserving) but not all at once. The only exception is a Globe, which preserves angles, areas and distances perfectly. Thus a projection is a compromise.

The choice of projection depends on a map’s use, scale and audience. Conformal projections, for example, are preferred for nautical charts or small scale maps because they locally preserve angles necessary for navigation and survey drawings. Equal-area projections are best suited for maps of broad continental region as they preserve the relative sizes of countries, seas and oceans and allow comparison between regions. Finally, there are hybrid projections that minimise the distortion by merging conformal and equal-area projections, these can be used to create visually pleasing maps of the entire Earth (for a guide to selecting a map projection see Fig. 9 in Jenny (2011), link below).

But how does one measure the degree and type of distortion in a map projection?

One elegant method was developed in the 1880s century by the French cartographer Monsieur Nicolas Auguste Tissot, the Tissot’s Indicatrix (or Tissot’s Ellipse). This mathematical contrivance consists of a grid of infinitely small circles that measures the degree and type of distortion caused by projection. While Monsieur Tissot’s approach is mathematical, involving infinity small circles, his technique can be approximated overlaying a regular grid of large circles and crosses to a map.

The Indicatrix Mapper plugin for QGIS by Ervin Wirth and Peter Kun creates a Tissot’s Indicatrix by adding a vector layer of circles and crosses in a gridded pattern on a map. The degree and type of distortion of the Tissot’s Indicatrix reveals the class of map projection as follows: –

  • If a projection is conformal, the area of circles and sizes of the crosses will change while the shapes of circles remain the same and intersection angle of the crosses will always meet at 90 degrees e.g. Mercator projection
  • If a projection is equal-area, the area of the circles will remain the same while the shape of the circles change and intersection angle of the crosses will not always meet at 90 degrees e.g. Mollweide projection or Hammer projection
  • If a projection preserves neither property, the area of the circles and their shape will change, and the intersection angle of the crosses will not always meet at 90 degrees e.g. Robinson

After adding the Indicatrix Mapper plugin to QGIS (menu Plugins – Manage and Install Plugins) first add a basemap using the OpenLayers plugin e.g. Bing Aerial layer, then click the Indicatrix Mapper icon and run the plugin using default settings. You can then select different projections (lower right in world icon QGIS) to see the effects of various protections on the Tissot Indicatrix. If the circles appear as squares after selecting a different projection, right click the Circles layer in the layers panel, then select the Rendering tab and deselect the Simplify geometry check box. Also, turn off the basemap layer when using different projections, unfortunately the OpenLayers plugin only supports Google Mercator projection (EPSG 3857). To create the basemap below, that can be displayed using different projections, I styled vector data downloaded from Natural Earth and OpenStreetMap.


Mercator Projection – the area of the circles and size of the crosses increase towards the poles but their shape remains the same.


Mollweide Projection – the area of the circles remain the same but their shapes are distorted, the crosses do not always intersect at 90 degrees.


Robinson Projection – both the area of the circles and intersection angle of the crosses circles vary.

It is important to note that a Tissot’s Indicatrix generated in QGIS is an approximation of mathematical ideal, we are not no longer dealing with infinity small circles. As a result, here will be some minor distortion visible towards the edge of a map independent of the projection used; notice that the circles in the Mercator projection nearest the poles are not quite symmetrical or the circles at the edge of the Mollweide projection do not appear to preserve area as they should. This anomalous distortion can be minimised by reducing the size and spacing of the circles and crosses created by the Indicatrix Mapper plugin. However, despite these limitations a Tissot’s Indicatrix elegantly reveals the distortion present. This is something to important to understand when when choosing a map projection.


Jenny, B., 2012. Adaptive composite map projections [PDF]. Visualization and Computer Graphics, IEEE Transactions on, 18, 2575–2582.

QGIS Crowdfunding: 2.5D Rendering

2.5D rendering

Spatialite and lost styles

In this blog I will explain how to recover styles that are included in a SpatiaLite database but are lost after renaming or moving the SpatiaLite database to another location. It will show how to use the QGIS Field Calculator to change the contents of de field f_table_catalog in the table layer_styles so it directs … Continue reading Spatialite and lost styles

Dica para ajustar posição de símbolos em QGIS | Hack to adjust map symbols location in QGIS

De quando em vez aparecem-me zonas com demasiado símbolos no mesmo local, e pensei como seria fantástico se os pudesse arrastar para um local mais conveniente sem ter de alterar as suas geometrias, tal como é possível fazer com as etiquetas. Esse pensamento deu-me a ideia base para a dica que vou demonstrar.

Now and then I get too many map symbols (points) in the same place, and I thought how nice it would be if we could drag n’ drop them around without messing with their geometries position, just like we do with labels. That thought gave me an idea for a cool hack.

Escolha a sua camada de pontos e comece por criar dois novos campos chamados symbX e symbY (Tipo: Decimal; Tamanho: 20; precisão: 5). No separador “Estilo” das propriedades da camada, defina para cada nível do seu símbolo o seguinte: Escolher “unidade do mapa” como a unidade para as opções de afastamento; Usar a seguinte expressão na opção afastamento das propriedades definidas por dados.

Choose your point layer and start by creating two new fields called symbX and symbY (Type: Decimal number; Size: 20; Precision: 5). Now go the layer properties and in the Style tab edit your symbol. For each level of your symbol select “map units” as the offset units, and set the following expression in the offset data define properties option:

    tostring($x - symbX) + ',' + tostring($y - symbY)

Screenshot from 2015-02-22 18:18:43

Tenha atenção que, se as coordenadas do seu mapa tiver valores negativos, será necessário uma pequena alteração ao código. E. g., se tiver valores negativos em X deverá usar-se  antes a expressão “tostring(symbX -$x)”.

Beware that if your coordinates have negative values you need to adapt the code. E.g., If you have negative values in X you should use “tostring(symbX -$x)” instead.

De forma temporária coloque etiquetas na sua camada usando um texto pequeno (eu usei o ‘+’ (sinal de mais) centrado e com um buffer branco) e defina as coordenadas X e Y dos propriedades definidadas por dados usando os campos symbX e symbY,

Now, temporarly  label your layer with a small convenient text (I used a centered ‘+’ (plus sign) with a white buffer) and set its coordinates to data defined using the symbX and symbY Fields.

Screenshot from 2015-02-22 22:42:07

A partir desse momento, quando usar a ferramenta de mover etiquetas, não só alterará a posição da etiqueta, mas também a do próprio símbolo! Fantástico, não?

From this point on, when you use the move label tool, not only the label position change but also the actual symbol! Pretty cool, isn’t it?


Note que as geometria dos elementos não são alteradas durante o processo. Para além disso, lembre-se que neste caso também poderá adicionar linhas de guia para ligar os símbolos à posição original do ponto.

Notice that the features geometries are not changed during the process. Also, remember that in this case you can also add leading lines to connect the symbols to the original position of the points.

Take part in the QGIS user survey

The QGIS project is asking for user feedback to gain a better understanding of the wishes and requirements of its user base. Please take part in the survey and share the links with other QGIS users. The survey is available in multiple languages:

Not always about new features

I love a good feature just as much as the next person but sometimes it’s great to fix a small workflow issue that has bugged you for the longest time.

If you have ever seen this kind of dialog you will know what I mean


The good old Python error dialog in QGIS.  The dialog is there to tell you that an exception was raised in Python somewhere and would dump out the error for you to debug it.   One big issue with this dialog though.  It’s blocking.  Blocking dialogs are really bad.   As a user, the blocking dialog means a broken workflow. Worst of all, there really is nothing you can do about it because the only thing you can do is close.

This dialog has now been replaced with a message bar if something goes wrong in Python code.  The message bar is non blocking and lets you continue working even if something didn’t work correctly.


The message bar has two buttons.  One will open the stack trace dialog to see the error in more detail. The other button opens the log window.


The message bar will only show a single error message for each type of error even if there are multiple exceptions in a row. A good example of this is an error in a mouse move event handler causing a error on each mouse move.

Filed under: qgis Tagged: qgis

Quick webmaps with qgis2web

In Publishing interactive web maps using QGIS, I presented two plugins for exporting web maps from QGIS. Today, I want to add an new member to this family: the qgis2web plugin is the successor of qgis-ol3 and combines exports to both OpenLayers3 as well as Leaflet.

The plugin is under active development and currently not all features are supported for both OpenLayers3 and Leaflet, but it’s a very convenient way to kick-off a quick webmapping project.

Here’s an example of an OpenLayers3 preview with enabled popups:

OpenLayers3 preview

OpenLayers3 preview

And here is the same map in Leaflet with the added bonus of a nice address search bar which can be added automatically as well:

Leaflet preview

Leaflet preview

The workflow is really straight forward: select the desired layers and popup settings, pick some appearance extras, and then don’t forget to hit the Update preview button otherwise you might be wondering why nothing happens ;)

I’ll continue testing these plugins and am looking forward to seeing what features the future will bring.

What went on at FOSS4G 2015?

Granted, I could only follow FOSS4G 2015 remotely on social media but what I saw was quite impressive and will keep me busy exploring for quite a while. Here’s my personal pick of this year’s highlights which I’d like to share with you:


Marco Hugentobler at FOSS4G 2015 (Photo by Jody Garnett)

Marco Hugentobler at FOSS4G 2015 (Photo by Jody Garnett)

The Sourcepole team has been particularly busy with four presentations which you can find on their blog.

Marco Hugentobler’s keynote is just great, summing up the history of the QGIS project and discussing success factor for open source projects.

Marco also gave a second presentation on new QGIS features for power users, including live layer effects, new geometry support (curves!), and geometry checker.

There has also been an update to QTiles plugin by NextGIS this week.

If you’re a bit more into webmapping, Victor Olaya presented the Web App Builder he’s been developing at Boundless. Web App Builder should appear in the official plugin repo soon.

Preview of Web App Builder from Victors presentation

Preview of Web App Builder from Victors presentation


If you work with messy, real-world data, you’ve most certainly been fighting with geocoding services, trying to make the best of a bunch of address lists. The Python Geocoder library promises to make dealing with geocoding services such as Google, Bing, OSM & many easier than ever before.

Let me know if you tried it.

Mobmap Visualizations

Mobmap – or more specifically Mobmap2 – is an extension for Chrome which offers visualization and analysis capabilities for trajectory data. I haven’t tried it yet but their presentation certainly looks very interesting:

UI theme support now core in QGIS

I enjoy using the dark UI theme for QGIS so much I figured why not make it a core feature. In the next version of QGIS if you head to the options screen you can now find a UI Theme option.

Options | General_037

The default dark theme is called Night Mapping for all those late night mapping jobs that you do, or if you just like dark UI themes.

QGIS b789fab_029



Something you will notice with this theme is the custom icons for the layer visibility. Pretty nifty! Here is how it is done

Creating new themes

To create a new theme simply make a new folder in .qgis2\themes\ with the name of the theme you want and create a style.qss file inside there. Check out the default themes for an example

Follow the Qt style sheet guides to see what can be styled.

Something I have added on top of the normal style sheets is variable support. Variables can be declared in a variables.qss file in the theme folder.

Here is an example of some variables:

@background: #323232
@text: #aaa
@selection: #507098
@menuback: #444
@highlight: #ffaa00

Now in style.qss we can do this:

color: @text;
background-color: @background;

Great for not having to repeat your self or quick updating in a single place. When the theme is applied via the Options dialog or via the API it will replace the variables in style.qss using variables.qss. The result file is called

Needs some tweaks

The default dark theme is a collection of stuff I have found around the net and stuff I have added myself. It’s far from prefect and I would love help to make it the best dark theme for QGIS. If you have another theme you think would make a good default one open a pull request on GitHub


Filed under: Open Source, qgis Tagged: qgis

QGIS Welcome Page

Whenever you start QGIS you basically do it because? Right, because you need to do GIS work. Ah, how I love rhetorical questions to start a post. And most of the time one continues to work on a QGIS project which

Syntactic sugar for PyQGIS

PyQGIS now supports a nice new addition for handling edit sessions in layers. This way, changes get committed automatically at the end of a successful (python) edit session.

with edit(layer):
    do your changes here()
See more ›

Using TimeManager for WMS-T layers

This is a guest post by Karolina Alexiou (aka carolinux), Anita’s collaborator on the Time Manager plugin.

As of version 2.1.5, TimeManager provides some support for stepping through WMS-T layers, a format about which Anita has written  in the past.  From the official definition, the OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. QGIS can display those images as a raster layer. The WMS-T standard allows the user of the service to set a time boundary in addition to a geographical boundary with their HTTP request.

We are going to add the following url as the web map provider service:

From QGIS, go to Layer>Add Layer>Add WMS/WMST Layer and add a new server and connect to it. For the service we have chosen, we only need to specify a name and the url.

Select the top level layer, in our case named nexrad_base_reflect and click Add. Now you have added the layer to your QGIS project.

To add it to TimeManager as well, add it as a raster with the settings from the screenshot below. Start time and end time have the values 2005-08-29:03:10:00Z and 2005-08-30:03:10:00Z respectively, which is a period which overlaps with hurricane Katrina. Now, the WMS-T standard uses a handful of different time formats, and at this time, the plugin requires you to know this format and input the start and end values in this format. If there’s interest to sponsor this feature, in the future we may get the format directly from the web service description. The web service description is an XML document (see here for an example) which, among other information, contains a section that defines the format, default time and granularity of the time dimension.


If we set the time step to 2 hours and click play, we will see that TimeManager renders each interval by querying the web map service for it, as you can see in this short video.

Querying the web service and waiting for the response takes some time. So, the plugin requires some patience for looking at this particular layer format in interactive mode. If we export the frames, however, we can get a nice result. This is an animation showing hurricane Katrina progressing over a 30 minute interval.


If you want to sponsor further development of the Time Manager plugin, you can arrange a session with me – Karolina Alexiou – via Codementor.

Open source IDF router for QGIS

This is a follow-up on my previous post introducing an Open source IDF parser for QGIS. Today’s post takes the code further and adds routing functionality for foot, bike, and car routes including oneway streets and turn restrictions.

You can find the script in my QGIS-resources repository on Github. It creates an IDFRouter object based on an IDF file which you can use to compute routes.

The following screenshot shows an example car route in Vienna which gets quite complex due to driving restrictions. The dark blue line is computed by my script on GIP data while the light blue line is the route from (via the OSM route plugin) on OSM data. Minor route geometry differences are due to slight differences in the network link geometries.

Screenshot 2015-08-01 16.29.57

QGIS 2.10 RPMs for Fedora 21, Centos 7, Scientific Linux 7

qgis-icon_smallThanks to the work of Volker Fröhlich and other Fedora/EPEL packagers I was able to create RPM packages of QGIS 2.10 Pisa for Fedora 21, Centos 7, and Scientific Linux 7 using the great COPR platform.


The following packages can now be installed and tested on epel-7-x86_64 (Centos 7, Scientific Linux 7, etc.), and Fedora-21-x86_64:

  • qgis 2.10.1
  • qgis-debuginfo 2.10.1
  • qgis-devel 2.10.1
  • qgis-grass 2.10.1
  • qgis-python 2.10.1
  • qgis-server 2.10.1

Installation instructions (run as “root” user or use “sudo”):


# EPEL7:
yum install epel-release
yum update
wget -O /etc/yum.repos.d/qgis-2-10-epel-7.repo
yum update
yum install qgis qgis-grass qgis-python

# Fedora 21:
dnf copr enable neteler/QGIS-2.10-Pisa
dnf update
dnf install qgis qgis-grass qgis-python


The post QGIS 2.10 RPMs for Fedora 21, Centos 7, Scientific Linux 7 appeared first on GFOSS Blog | GRASS GIS Courses.

Open source IDF parser for QGIS

IDF is the data format used by Austrian authorities to publish the official open government street graph. It’s basically a text file describing network nodes, links, and permissions for different modes of transport.

Since, to my knowledge, there hasn’t been any open source IDF parser available so far, I’ve started to write my own using PyQGIS. You can find the script which is meant to be run in the QGIS Python console in my Github QGIS-resources repo.

I haven’t implemented all details yet but it successfully parses nodes and links from the two example IDF files that have been published so far as can be seen in the following screenshot which shows the Klagenfurt example data:

Screenshot 2015-07-23 16.23.25

If you are interested in advancing this project, just get in touch here or on Github.

Recent labelling improvements in QGIS master

If you’re not like me and don’t keep a constant eye over at QGIS development change log (be careful – it’s addictive!), then you’re probably not aware of a bunch of labelling improvements which recently landed in QGIS master version. I’ve been working recently on a large project which involves a lot (>300) of atlas map outputs, and due to the size of this project it’s not feasible to manually tweak placements of labels. So, I’ve been totally at the mercy of QGIS’ labelling engine for automatic label placements. Generally it’s quite good but there were a few things missing which would help this project. Fortunately, due to the open-source nature of QGIS, I’ve been able to dig in and enhance the label engine to handle these requirements (insert rhetoric about beauty of open source here!). Let’s take a look at them one-by-one:

Data defined quadrant in “Around Point” placement mode

First up, it’s now possible to specify a data defined quadrant when a point label is set to the Around Point placement mode. In the past, you had a choice of either Around Point mode, in which QGIS automatically places labels around point features in order to maximise the number of labels shown, or the Offset from Point mode, in which all labels are placed at a specified position relative to the points (eg top-left). In Offset from Point mode you could use data defined properties to force labels for a feature to be placed at a specific relative position by binding the quadrant to a field in your data. This allowed you to manually tweak the placement for individual labels, but at the cost of every other label being forced to the same relative position. Now, you’ve also got the option to data define the relative position when in Around Point mode, so that the rest of the labels will fall back to being automatically placed. Here’s a quick example – I’ll start with a layer with labels in Around Point mode:

Around Point placement mode

Around Point placement mode

You can see that some labels are sitting to the top right of the points, others to the bottom right, and some in the top middle, in order to fit all the labels for these points. With this new option, I can setup a data defined quadrant for the labels, and then force the ‘Tottenham’ label (top left of the map) to display below and to the left of the point:

Setting a data-defined quadrant

Setting a data-defined quadrant

Here’s what the result looks like:

Manually setting the quadrant for the Tottenham label

Manually setting the quadrant for the Tottenham label

The majority of the labels are still auto-placed, but Tottenham is now force to the lower left corner.

Data defined label priority

Another often-requested feature which landed recently is the ability to set the priority for individual labels. QGIS has long had the ability to set the priority for an entire labelling layer, but you couldn’t control the priority of features within a layer. That would lead to situations like that shown below, where the most important central station (the green point) hasn’t been labelled:

What... no label for the largest station in Melbourne?

What… no label for the largest station in Melbourne?

By setting a data defined priority for labels, I can set the priority either via values manually entered in a field or by taking advantage of an existing “number of passengers” field present in my data. End result is that this central station is now prioritised over any others:

Much better! (in case you're wondering... I've manually forced some other non-optimal placement settings for illustrative purposes!)

Much better! (in case you’re wondering… I’ve manually forced some other non-optimal placement settings for illustrative purposes!)

Obstacle only layers

The third new labelling feature is the option for “Obstacle only” layers. What this option does is allow a non-labelled layer to act as an obstacle for the labels in other layers, so they will be discouraged from drawing labels over the features in the obstacle layer. Again, it’s best demonstrated with an example. Here’s my stations layer with labels placed automatically – you can see that some labels are placed right over the features in the rail lines layer:

Labels over rail lines...

Labels over rail lines…

Now, let’s set the rail lines layer to act as an obstacle for other labels:

... setting the layer as an obstacle...

… setting the layer as an obstacle…

The result is that labels will be placed so that they don’t cover the rail lines anymore! (Unless there’s no other choice). Much nicer.

No more clashing labels!

No more clashing labels!

Control over how polygons act as obstacles for labels

This change is something I’m really pleased about. It’s only applicable for certain situations, but when it works the improvements are dramatic.

Let’s start with my labelled stations map, this time with an administrative boundary layer in the background:

Stations with administrative boundaries

Stations with administrative boundaries

Notice anything wrong with this map? If you’re like me, you won’t be able to look past those labels which cross over the admin borders. Yuck. What’s happening here is that although my administrative regions layer is set to discourage labels being placed over features, there’s actually nowhere that labels can possibly be placed which will avoid this. The admin layer covers the entire map, so regardless of where the labels are placed they will always cover an administrative polygon feature. This is where the new option to control how polygon layers act as obstacles comes to the rescue:

...change a quick setting...

…change a quick setting…

Now, I can set the administrative layer to only avoid placing labels over feature’s boundaries! I don’t care that they’ll still be placed inside the features (since we have no choice!), but I don’t want them sitting on top of these boundaries. The result is a big improvement:

Much better!

Much better!

Now, QGIS has avoided placing labels over the boundaries between regions. Better auto-placement of labels like this means much less time required manually tweaking their positioning, and that’s always a good thing!

Draw only labels which fit inside a polygon

The last change is fairly self explanatory, so no nice screenshots here. QGIS now has the ability to prevent drawing labels which are too large to fit inside their corresponding polygon features. Again, in certain circumstances this can make a huge cartographic improvement to your map.

So there you go. Lots of new labelling goodies to look forward to when QGIS 2.12 rolls around.


  • Page 1 of 29 ( 571 posts )
  • >>
  • qgis

Back to Top