Page 1 of 4 (63 posts)

  • talks about »
  • uncategorized


Last update:
Sat May 28 10:55:21 2016

A Django site.

QGIS Planet

Call for nominations for voting members of the board.

Dear QGIS Community members
As many of you will be aware, in this last year we have been embarking on the process to transition from a loose-knit community organisation to a more formal organisation. This new organisation ‘’ will be a legal entity and will afford us a greater amount of flexibility in how we manage funds, legal agreements and so forth. You can read the statutes for the organisation for more info.
Under the statutes of the new organisation, there will be one user group voting member put forward for each registered user group (user group registration page is here). For each user group voting member we will have a community voting member elected. In addition there will be one voting member from the OSGEO leadership. It is probably best explained by way of a simple (contrived) example:

1) The Martian user group puts forward Joe Alien to be their QGIS User Group Voting Member.
2) QGIS committers put forward nominations for a matching Community Voting Member from within the community. Community member with the highest number of nominations is elected. Only people with git commit rights to an official QGIS repository or write access to the QGIS translation platform on transifex can put forward nominations. The nominated person can be any person from within the QGIS community who is willing to serve as a voting QGIS community member.
3)  The Moon user group puts forward Janet Luna to be their QGIS User Group Voting Member.
4) QGIS committers again nominate a matching Community Voting Member
5) OSGEO puts forward one person to act as the OSGEO voting member.

Voting members will elect the QGIS Board, Board Chairman and approve budgets and the annual report. Once elected, the board will make day to day decisions on behalf of the project as needed. The OSGEO voting member will also serve to ensure that there are always an odd number of voting members to avoid deadlocks. Voting members will have their continued membership confirmed on a 3 yearly basis.
Since we are bootstrapping the organisation, we have not yet elected any voting members. Currently there are 10 QGIS User Groups registered (this number may be different when you read this due to new registrations), thus we would like to invite all people who have Git commit access to any official QGIS repo, or transifex write access to make their nominations for their community voting members. The 10 consenting nominees with the highest number of nominations will be appointed as community voting members.
We will close the nomination period on Wed 11 May if at least 10 unique persons have been nominated, otherwise as soon as 10 unique persons have been nominated.
We will maintain a list of the QGIS Voting Members on the web site for public viewing.
After all of the voting members have been elected they will be asked to elect the members of the board. Board members need not be voting members, any QGIS community member can be elected to the board. For formation of the new board, existing PSC members will automatically be nominated and the community voting members can also put up additional nominations. We would then put the election of the board members to a vote (maintaining the same number of members as are currently in the PSC for now). Once the board has officially been elected, the voting members can then select a chair for the board. Note that all voting will be done electronically via an online form.
By this process we will have a democratically elected board entrusted with stewardship of the new Organisation.
Each year we will hold an annual general meeting and voting members can elect a new chair, or re-elect the existing chair. Similarly on a rotational basis, board members will be up for re-election each year. If things are a little unclear above, I have made a simple diagram which hopefully clarifies things (see below).
Note that Gary Sherman (QGIS project founder) is board member emeritus and this will not be up for re-election as he has life long tenure on the board.
So if you are eligible to nominate voting members (i.e. you are a committer on any official QGIS repo or a Transifex author), please head over to the form provided to  make your nomination!
Tim Sutton
Current QGIS Project Steering Committee Chair

QGIS: Qt5 and Python3 migration, current state

Behind the scenes a lot has happened to get ready for Qt5 and Python3. On the same codebase that is becoming the next release QGIS 2.16. This is really a great thing since we can focus work on a single

Prepare your plugins for QGIS 3

QGIS 3 is not yet there and there is still plenty of time to prepare and migrate. But I thought I would give some advice about things that you can keep in mind while working on your plugins to make

QGIS 2.14 ‘Essen’ is released!

QGIS is a user friendly Open Source Geographic Information System that runs on Linux, Unix, Mac OSX, and Windows.

We are very pleased to announce the release of QGIS 2.14 ‘Essen’.  Essen was the host city to our developer meet ups in October 2012 and 2014.

Long Term Release

This is a special release since it is designated an ‘LTR’ (Long Term Release). LTR releases will be supported with backported bug fixes for one year, and will be in permanent feature freeze (i.e. no new features will be added, only bug fixes and trivial updates). Note that we are in discussion to extend the term of our LTR releases to two years, but for technical reasons we will not do this until QGIS 3.2.

The purpose of LTR releases is to provide a stable and less frequently changing platform for enterprises and organizations that do not want to deal with updating user skills, training materials etc. more than once per year. The success of the LTR is very much down to you, our beloved users – we need your support to help funding bug fixes and making sure in your support contracts with support providers specify that any bug fixes done on your behalf are applied to the LTR branch as well as our normal development branch.

If an LTR is important to you, please consider also directly supporting the QGIS project, or encourage your commercial provider to use LTR as a basis for your enterprise solution so that everyone may benefit from a stable platform that is being continuously improved and refined. Note that for users and organizations that like to live on the frontier, our regular four monthly releases will continue unabated.

New Features in QGIS 2.14 ‘Essen’

If you are upgrading from QGIS 2.8 (our previous LTR version) you will find a
great many new features in this release. (

We encourage you to peruse the changelogs for the intermediate non LTR 2.10 and 2.12 releases as this QGIS 2.14 includes all features published in those releases too.

Note that 2.14 first enters the regular package repositories and will not immediately replace 2.8 in the LTR package repositories. That will happen when 2.16 is released.

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. (

The source code and binaries for Windows, Debian and Ubuntu are already available via the large download link on our home page:  More packages will follow as soon as the package maintainers finish their work. Please revisit the page if your platform is not available yet.


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.

Current Sponsors of QGIS:

Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts. A complete list of current sponsors is provided below – our very great thank you to all of our sponsors!

SILVER AGH University of Science and Technology, Krakow, Poland
SILVER Sourcepole AG, Switzerland
SILVER GAIA mbH, Germany
SILVER Office of Public Works, Flood Risk Management and Data Management
       Section, Ireland
SILVER Land Vorarlberg, Austria
BRONZE Cawdor Forestry, United Kingdom
BRONZE ChameleonJohn, United States
BRONZE Chartwell Consultants Ltd., Canada
BRONZE Gis3W, Italy
BRONZE Dr. Kerth + Lampe Geo-Infometric GmbH, Germany
BRONZE Gaia3D, Inc., South Korea
BRONZE GeoSynergy, Australia
BRONZE GFI – Gesellschaft für Informationstechnologie mbH, Germany
BRONZE GKG Kassel, (Dr.-Ing. Claas Leiner), Germany
BRONZE, Estonia
BRONZE Lutra Consulting, United Kingdom
BRONZE MappingGIS, Spain
BRONZE Nicholas Pearson Associates, United Kingdom
BRONZE QGIS Polska, Poland
BRONZE Royal Borough of Windsor and Maidenhead, United Kingdom
BRONZE TerreLogiche, Italy
BRONZE Trage Wegen vzw, Belgium
BRONZE Urbsol, Australia
BRONZE GIS-Support, Poland
ADLARES GmbH, Germany
BRONZE WhereGroup GmbH & Co. KG, Germany
BRONZE, Germany
BRONXE Customer Analytics, USA
BRONZE Nicholas Pearson Associates
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 using this link :

Happy QGISing!


The QGIS Team!

QGIS User & Developer conference – Extension of presentation and workshop submissions deadline

The Call for Papers and Workshops for the 2nd International QGIS User and Developer Conference, is still open!

Call for Presentations
Deadline: February 22nd

The QGIS Conference presentations are 20 minutes long, with time for Q&A at the end of each talk. Presentations may cover any aspect related with the use or development of QGIS software. Anyone can can submit a presentation proposal and take part in the conference as a presenter. The received proposals will be reviewed by the program committee.

See already submitted presentations and details:

Call for Workshops
Deadline: February 22nd

There are two kinds of workshops depending on the duration: 2 hours or 4 hours. If you want to actively participate in the 2nd Int. QGIS Conference and impart a workshop, don’t hesitate to send your workshop proposal to

The proposal should be a brief abstract pointing out the expected duration of the workshop (2 hours, 4 hours) as well as a few lines describing the content of the workshop, pre-requisites for the attendants (if needed), name of the instructor

The instructors of the selected workshops will receive a free pass for the conference.

See already submitted workshops and details:

For further details, please send an email at

QGIS 3.0 plans



Ok so quick spoiler here: there is no QGIS 3.0 ready yet, nor will there be a QGIS 3.0 for some time. This article provides a bit more detail on the plans for QGIS 3.0. A few weeks ago I wrote about some of the considerations for the 3.0 release, so you may want to read that first before continuing with this article as I do not cover the same ground here.

lot of consideration has gone into deciding what the approach will be for the development of QGIS 3.0. Unfortunately the first PSC vote regarding which proposal to follow was a split decision (4 for, 3 against, 1 abstention and 1 suggestion for an alternative in the discussion). During our PSC meeting this week we re-tabled the topic and eventually agreed on Jürgen Fischer’s proposal (Jürgen is a QGIS PSC Member and the QGIS Release Manager) by a much more unanimous margin of 8 for, 1 neutral and 1 absent. Jürgen’s proposal is largely similar to the Proposal 2 described in my previous posting. I want to make some special notes here about our discussion and subsequent decision which will hopefully help to clarify the thinking behind our decision for other interested observers.  First let me lay out Jürgen’s plan in his own words:

My preferred approach would still be:

  • Do a Qt5/PyQt5/Python3 branch in parallel, actually work on it until it’s ready, make it master and release it as 3.0
  • Meantime keep working on master (2.x) and keep releasing them every 4 months as usual

Everyone can work on the branch (s)he wants (or is hired to), but needs to consider if (s)he want to do it (or spend funds on):

  • only for 2.x: knowing that it will be released soon; but might become unusable because platforms drop support for stuff it depends on sooner or later
  • only for 3.x: not knowing when that will ever release or
  • for both: knowing that work needs to be done twice.
  • People adding features to the master branch will be responsible to ensure that their work gets merged to 3.0 branch.

As PSC we should maintain the environment for people to do something for QGIS – but we cannot tell them to – so we don’t have resources we can actually plan with and that means we can either release something when the big thing is ready or what we have in fixed intervals.” – Jürgen Fischer

What follows are some further details and clarifications to our preferred approach:

Why do parallel development?

Parallel development of 3.0 maintaining our master branch with 2.x code in it has advantages and disadvantages. First the advantages:

  • If we encounter major technical difficulties / release blockers in the 3.0 branch, it will not impact on our normal 3 monthly release cycle.
  • Our binary build systems (Linux, Windows and OSX binaries) will be unaffected until 3.0 is ready.
  • It is very likely that building 3.0 binaries on different platforms is going to have difficulties for each platform. For example OSGEO4W has no Python3 and Qt5 packages yet. Someone needs to see to the creation of the required package as a separate exercise from the actuals development of a version of QGIS that will take advantage of these updated libraries. We don’t yet know what problems may be in countered in preparing these.
  • “Don’t break what already works”: we have a working and relatively stable master branch and we don’t want to do a ‘cowboy stunt’ and break it. We prefer to wait until the 3.0 branch is mature, has passing tests and is known to work well before merging it into master and treating it as our ‘best we currently have’ master branch.

Of course nothing in life is completely easy, there are also some disadvantages:

  • Some developers may feel that running two mainstream branches is dilution of effort. To counter this, our public recommendation is that after 2.16 comes out, all QGIS contributors are strongly encouraged to provide their patches against the 3.0 branch. Any features applied to the master branch is not guaranteed to be part of the 3.0 release.
  • Regular merging of master to the 3.0 branch may prove more and more difficult over time as the two branches diverge more. Again we will strongly encourage that developers submitting new features after the 2.16 release do so against the 3.0 branch.
  • 3.0 branch won’t have auto build system for nightly binaries in the beginning. Since we expect that the initial branch of 3.0 will break these anyway, Having a separate branch is actually an advantage here as it will give binary packages some time to get their build systems up to speed.

To clarify things for developers wondering where to commit their work: we discourage people from writing new features in master after 2.16 is released and rather ask them to make their changes in the 3.0 branch. Only those who really need to see their features in the next 2.18 release would have to dual commit.

Isn’t it better to work on 3.0 in the master branch?

Some queries have been raised about whether it would be better to rather work on 3.0 in the ‘master branch’ and relegate the 2.x code base to a side branch (instead of our intended approach which is to keep master tracking 2.x until 3.0 is ready and then merge it to master). We feel that keeping master tracking the 2.x code base is more conservative – it will not break existing packaging / build systems and if there is any major hitch in 3.0 development the release process will continue unabated based on the 2.x code set. While 3.0 is under development, package builders will have time to figure out the packaging process while still keeping the regular nightly builds against 2.x running. The implication of this is that 2.18 may contain only bug fixes which were applied to the 2.x branch and no significant new features.

The schedule will not be fixed

One thing that we want to make really clear (and was a key point in our many discussions) is that there will be no fixed release date for QGIS version 3.0. There are several reasons for this:

  • As a steering committee, we can only set the QGIS ship pointing in a given direction, our power to actually make work happen is extremely limited. This is because we are a community made up largely of volunteer developers or developers working on a commission basis for third party clients. We have no say in how these contributors spend their time.
  • We do not yet know which (if any) major technical issues will be encountered during the development of 3.0. Any such issues could very well delay the roll out of QGIS 3.0.

Instead our plan is to make the 2.16 release and then effectively move all developer effort to the 3.0 branch as best we can (through close liaison with our developer community).

To clarify things for those wondering when they will give 3.0 to their users: The actual release date for 3.0 its interterminate, but the general aim is still to try to encourage everyone to get it ready for 1 year from now. Remember that as an open source community we cannot directly ensure that project timelines are met since our developer force is largely volunteer based or work according to their own companies agendas.

Will 3.0 be a Long Term Release (LTR)?

It is our recommendation that we wait until 3.2 is ready before designating it an LTR – there are going to be large changes in the code base for 3.0 and we would rather stabilise things a bit before applying the LTR label to the release.


Looking forward to 3.0

Personally I am very much looking forward to the release of QGIS 3.0 – it represents another huge milestone in our project, it affords us a great opportunity to get rid of a lot of cruft out of our code base and API’s and it will arm us with a set of modern, new libraries that will see us through the next several years. Rock on QGIS 3.0!


QGIS PSC Chairman

Increasing the stability of processing algorithms

Processing just got a new testing framework to improve the long-term stability of this important plugin. And you can help to improve it, even if you are not a software developer! This is yet another piece in our never-stopping crusade to

QGIS Features I long for while using ArcGIS

(aka Features that ArcGIS Desktop users might not know that exists)


From time to time, I read articles comparing ArcGIS vs QGIS. Since many of those articles are created from an ArcGIS user point of view, they invariably lead to biased observations on QGIS lack of features. It’s time for a QGIS user perspective, so bare with me on this (a bit) long, totally and openly biased post.

“Hello, my name is Alexandre, and I have been using… QGIS

This is something I would say at an anonymous QGIS user therapy group. I’m willing to attend one of those because being recently and temporally forced to use ArcGIS Desktop again (don’t ask!), I really really really miss QGIS in many ways.

There was a time when I have used ArcGIS on the regular basis. I used it until version 9.3.1 and then decided to move away (toward the light) into QGIS (1.7.4 I think). At that time, I missed some (or even many?) ArcGIS features, but I was willing to accept it in exchange for the freedom of the Open Source philosophy. Since then, a lot have happened in the QGIS world, and I have been watching it closely. I would expect the same have happened in ArcGIS side, but, as far I can see, it didn’t.

I’m using top shelf ArcGIS Desktop Advanced and I’m struggling to do very basic tasks that simply are nonexistent in ArcGIS. So here’s my short list of QGIS functionalities that I’m longing for. For those of you that use ArcGIS exclusively, some of this features may catch you by surprise.

Warning: For those of you that use ArcGIS exclusively, some of this features may catch you by surprise.

Transparency control

“ArcGIS have transparency! It’s in the Display tab, in the layer’s properties dialog!”

Yes, but… you can only set transparency at the layer level. That is, either it’s all transparent, or it’s not…

In QGIS on the other end, you can set transparency at layer level, feature/symbol level, and color level. You can say that this is being overrated, but check the differences in the following images.


Notice that in QGIS you can set transparency at color level everywhere (or almost everywhere) there is a color to select. This includes annotations (like the ones in the image above), labels and composers items. You can even set transparency in colors by using the RGBA function in an expression! How sweet can that be?:-)

Screenshot from 2016-01-27 14:12:34

Blending modes

This is one of QGIS’s pristine jewels. The ability to combine layers the way you would do in almost any design/photo editing software. At layer or at feature level, you can control how they will “interact” with other layers or features below. Besides the normal mode, QGIS offers 12 other blending modes:  Lighten, Screen, Dodge, Darken, Multiply, Burn, Overlay, Soft light, Hard light, Difference, and Subtract. Check this page to know more about the math behind each one and this image for some examples

It’s not easy to grasp how can this be of any use for cartography before you try it yourself. I had the chance to play around while trying to answer this question.


A very common application for this functionality is when you want to add shadows to simulate the relief by putting a hill shade on top of other layers. In ArcGIS, you can only control the layer transparency, and the result is always a bit pale. But in QGIS, you can keep the strength of the original colors by using the multiply mode in the hill shade layer.

Screenshot from 2016-01-27 15:24:38
Hypsometry original colors
Screenshot from 2016-01-27 15:25:45
Hypsometry colors paled by transparent hill shade
Screenshot from 2016-01-27 15:24:45
Hypsometry original colors with the hill shade using QGIS multiply blending

You can also use blending modes in the print composer items, allowing you to combine them with other items and textures. This gives you the opportunity to make more “artistic” things without the need to go post-processing in a design software.

Colour Picker Menu

Controlling color is a very important deal for a cartographer and QGIS allow you to control it like the professional you are. You can select your colours using many different interfaces. Interfaces that you might recognize from software like Inkscape, Photoshop, Gimp and others alike.

Screenshot from 2016-01-20 22:04:03 Screenshot from 2016-01-20 22:03:48 Screenshot from 2016-01-20 22:04:54

My favorite one is the color picker. Using color picker, you can pick colors from anywhere on your screen, either from QGIS itself or outside. This is quite handy and productive when you are trying to use a color from your map, it’s legend, a COLOURlovers palette or a company logo.

Picking a color from outside QGIS

You can also copy/paste colors between dialogs, save and import color palettes, and you can even name a color and use it in a variable. With all this available for free, it’s hard to swallow Windows color selector😦.

Untitled Capture

Vector symbols renderers “powertools”

In ArcGIS, you have a few fancy ways to symbol your vector layers. You got: Single symbol, Unique values, Unique values many fields… and so on. At the first glance, you may think that QGIS lacks some of them. Believe me, it doesn’t! In fact, QGIS offers much more flexibility when you need to symbol your layers.

For starters, it allows you to use fields or expressions on any of the symbols renderers, while ArcGIS only allows the use of fields. Powered by hundreds of functions and the ability to create your owns in python, what you can do with the expression builder has no limits. This means, for instance, that you can combine, select, recalculate, normalize an infinite number of fields to create your own “values” (not to mention that you can tweak your values labels, making it ideal to create the legend).

Screenshot from 2016-01-20 22:34:54
QGIS Graduated renderer using an expression to calculate population density

And then, in QGIS, you have the special (and kinda very specific) renderers, that make you say “wooooh”. Like the Inverted polygons that allow you to fill the the outside of polygons (nice to mask other features), the Point displacement to show points that are too close to each others, and the Heatmap that will transform, ON-THE-FLY, all your points in a layer into a nice heatmap without the need to convert them to raster (and that will update as soon as you, or anyone else, edits the point features).

Screenshot from 2016-01-20 22:58:44
Inverted Polygon Renderer masking the outside of an interest area

But I have left the best to the end. The “One rendered to Rule them all”, the Rule-based symbols. With the rule-based renderer, you can add several rules, group them in a tree structure, and set each one with a desired symbol. This gives QGIS users full control of their layer’s symbols, and, paired with expression builder and data-defined properties, opens the door to many wonderful applications.

Rule-based renderer


One of my favorite (and missed) features in QGIS is the Map Composer’s Atlas. I know that ArcGIS has its own “Atlas”, the Data Driven Pages, but frankly, it’s simply not the same.

I believe you know the basic functionally that both software allow. You create a map layout and choose a vector layer as coverage, and it will create an output panned or zoomed for each of the layer’s feature. You can also add some labels that will change according to the layers attributes.

But in QGIS, things go a little bit further…

Basically, you can use coverage layer’s attributes and geometry anywhere you can use an expression. And, in QGIS, expressions are everywhere. That way, most layers and map composer items properties can be controlled by a single coverage layer.

With the right configuration, while iterating over the atlas coverage features, you can,  choose what feature to show and what features to hide, change a theme color for your map, rotate and resize your page acording to the feature sizechoose a specific logo to came along with your map, and much more. Once again, the sky is the limit.

Auto-resized maps that fits the coverage features at specific scale using atlas

So, if you pair Atlas it with QGIS data-defined properties, rule-based symbols and expressions, ArcGIS Data Driven Pages are no match. You don’t think so? Try to answer this question then.

Tip: If you really want to leverage your map production, using Spatialite or Postgis databases you can create the perfect atlas coverage layers from views that fit your needs. No data redundancy and they are always updated.

Label and Style dialogs

This one is more of a User Experience thing than an actual feature, but you won’t imagine how refreshing it is to have all Style and Labels options in two single dialogs (with several tabs, of course).

Using the symbol menu in ArcGIS makes me feel like if I’m in the Inception movie, at some point in time, I no longer know where the hell am I. For example, to apply a dashed outline in a fill symbol I needed to open 5 different dialogs, and then go back clicking OK, OK, OK, OK …

ArcGIS “Inception” symbol settings

In QGIS, once in the properties menu, every setting is (almost) one click way. And you just need to press OK (or Apply ) once to see the result!

Screenshot from 2016-01-20 21:51:33
QGIS Style setting

As an extra, you can copy/paste styles from one layer to another, making styling several layers even faster. And now you say:

“Don’t be silly! In ArcGIS you can import symbols from other layers too.”

Symbols? yes. Labels? No! And if you had lots of work setting your fancy labels, having to do the exact same/similar thing in another layer, it will make you wanna cry… I did.

(I think I will leave the multiple styles per layer vs data frames comparison for another time)


“Say what?!!”

Yup, that’s it, ArcGIS Desktop lacks support for WFS OGC standard unless you buy an extra extension: The Data Interoperability Extention.

In a GIS world that, more and more, is evolving towards Open Data, Open Standards and OGC Web Services, this reveals a very mercantile approach by ESRI. If I were an ESRI customer, I would feel outraged. <sarcasm>Or maybe not… maybe I would thank the opportunity to yet invest some more money in it’s really advanced features…<\sarcasm>

In QGIS, like everything else, WFS is absolutely free (as in freedom, not free beer). All you need to do is add the WFS server’s URL, and you can add all the layers you want, with the absolute sure that they are as updated as you can get.

Screenshot from 2016-01-20 21:58:54

Fortunately for ArcGIS users with a low budget, they can easily make a request for a layer using the internet browser😛.

Or they can simply use QGIS to download it. But, in both cases, be aware that the layers won’t update themselves by magic.

Expression builder

I have already mentioned the use of expressions several times, but for those of you that do not know the expression Builder, I though I end my post with one of my all time favourite features in QGIS.

I do not know enough of ArcGIS expression builder to really criticize it. But, AFAIK, you can use it to create labels and to populate a field using the field calculator. I know that there are many functions that you can use (I have used just a few) but they are not visible to the common user (you probably need to consult the ArcGIS Desktop Help to know them all). And you can create your own functions in VBScript, Python, and JsScript.


On QGIS side, like I said before, the Expression Builder can be used almost everywhere, and this makes it very convenient for many different purposes. In terms of functions, you have hundreds of functions right there in the builder’s dialog, with the corresponding syntax help, and some examples. You also have the fields and values like in ArcGIS, and you even have a “recent expressions” group for re-using recent expressions with no the need to remember prior expression.


Besides, you can create your own functions using Python (no VBScript or JsScript). For this purpose, you have a separate tab with a function editor. The editor have code highlighting and save your functions in your user area, making it available for later use (even for other QGIS sessions).



These are certainly not the only QGIS features that I miss, and they are probably not the most limiting ones (for instance, not being able to fully work with Spatialite and Postgis databases will make, for sure, my life miserable in the near future), but they were the ones I noticed right away when I (re)open ArcGIS for the first time.

I also feel that, based on the QGIS current development momentum, with each QGIS Changelog, the list will grow very fast. And although I haven’t tested ArcGIS Pro, I don’t think ESRI will be able to keep the pace.

“Are there things I still miss from ArcGIS?” Sure. I miss CMYK color support while exporting maps, for instance. But not as much as I miss QGIS now. Besides, I know that those will be addressed sooner or later.

In the end, I kinda enjoyed the opportunity to go back to ArcGIS, as it reinforced the way I think about QGIS. It’s all about freedom! Not only the freedom to use the software (that I was already aware) but also the freedom to control software itself and it’s outputs. Maintaining the users friendliness for new users, a lot have been done to make power users life easier, and they feel very pleased with it (at least I am).

All this being said, the winner is… QGIS!!

The End

(of a very biased post)

Present at the 2nd International QGIS User and Developer Conference!

The Call for Presentations and Workshops for the 2nd International QGIS User and Developer Conference, is already open!

The Local Organising Committee of the 2nd International QGIS User and Developer Conference, is pleased to announce the call for Presentations and Workshops for the 2016 Conference to be held in Girona (May 25th – 26th). If you have an open source geospatial story to tell, based on QGIS, we want to hear it!

Call for Presentations
Deadline: February 15th

The QGIS Conference presentations are 20 minutes long, with time for Q&A at the end of each talk. Presentations may cover any aspect related with the use or development of QGIS software. Anyone can can submit a presentation proposal and take part in the conference as a presenter. The received proposals will be reviewed by the program committee.

See full details at

Call for Workshops
Deadline: February 15th

There are two kinds of workshops depending on the duration: 2 hours or 4 hours. If you want to actively participate in the 2nd Int. QGIS Conference and impart a workshop, don’t hesitate to send your workshop proposal to

The proposal should be a brief abstract pointing out the expected duration of the workshop (2 hours, 4 hours) as well as a few lines describing the content of the workshop, pre-requisites for the attendants (if needed), name of the instructor…

The instructors of the selected workshops will receive a free pass for the conference.

See full details at

For further details, please send an email at

Help us to plan for QGIS 3.0

Many of you out there may be wondering ‘when are we going to release QGIS 3.0?’. Last year (2015) we started investigating when and how we would release QGIS 3.0. We promised (see Anita Graser’s post about this) that we would convey clearly to our users and developers our plans well before making the QGIS 3.0 release. In this post I will try to lay out some of the considerations for a QGIS 3.0 release and at the end of this post there is an opportunity for you to present your ideas.

Why 3.0?

Typically (when following semantic versioning) a major release is reserved for times when you break the API of your software. Breaking API is not a trivial decision for the QGIS project since we have hundreds of thousands of users out there who depend on QGIS to ‘just work’, and many developers who need to maintain third party software written on top of the QGIS API.

From time to time breaking the API is necessary to accommodate updating the architecture with improved approaches, new base libraries and fixes to sub-optimal decisions made in the past.

What are the implications of breaking the API?

One of the reasons we are hesitant about releasing an API breaking QGIS 3.0 release is that it will have a huge impact, potentially breaking the hundreds of plugins in the plugin repository. Plugins would no longer compatible with new API and plugin authors would be required to manually review their plugins to identify and update  the places in their plugins where the code is no longer compatible with the new API.

The breadth of the updates required depends largely on

  • how many backwards incompatible changes we make to the API
  • how many places plugin authors have used parts of the API which have changed

I will talk more about how we can mitigate API breaking changes  further on in this article.

What will be the key changes for 3.0?

There are four key areas that we are looking to change in 3.0:

  • Updating Qt4 to Qt5: This is the basic set of libraries on which QGIS is built and provides a high level, platform independent abstraction layer for building a graphical user application. Qt also provides libraries for carrying out disk i/o, networking operations, and graphics drawing operations (key functionality for QGIS). Qt4 (on which QGIS is currently based) is now not actively being developed by the Qt library maintainers and we are expecting to experience problems in the near future building Qt4 for some platforms (e.g. OS X) or having readily accessible binaries  (e.g. Debian Testing and the upcoming release of Debian “Stretch”). Making QGIS work with Qt5 has already been worked on (chiefly by Matthias Kuhn) who together with Marco Bernasocchi produce the Android “QField” port of QGIS which is based completely on Qt5. There are however some outstanding limitations in the newer Qt5 that impact on QGIS – in particular with the embedded web browser widgets (used chiefly in the QGIS composer but also a few other places in QGIS).
  • Updating PyQt4 to PyQt5: These are the python language bindings for Qt which the QGIS python API relies on. When we shift to the Qt5 C++ library, we also want to shift to the updated PyQt5 python library so that we can benefit from the new Qt5 API within the python environment too.
  • Updating Python 2.7 to Python 3: Currently we bundle in Python 2.7 in our windows installers and require 2.7 on other platforms where we do not co-bundle Python with QGIS. Python 3 is the latest version of python and is recommended by the Python project. Python 2 is slightly incompatible with Python 3 (in much the same way as QGIS 2 -> QGIS 3 will be incompatible). The python developers have made Python 3 largely backwards compatible to Python 2, but the compatibility in the opposite direction is not as good.
  • Improving the QGIS API itself: One of the issues with maintaining API compatibility between releases is that you have to live with your design choices for a long time. In QGIS we try our best not to break the API within a minor release series – not always with success as the more hard core developers will attest to. Releasing an API incompatible version of QGIS for 3.0 will give us an opportunity to ‘clean house’ by fixing things in the API that we are unhappy with. You can see a provisional list of proposed API changes for 3.0 by looking at the 3.0 API issues list.

Mitigating 3.0 API breakages

As I mentioned the 3.0 release will break API from the 2.x release of QGIS and there is the potential that many existing plugins, applications and other code that rely on the current API will be broken. So what can we do to mitigate the changes? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias and other core developers have been looking at ways to mitigate the number of API breaking changes whilst still advancing the QGIS codebase to be based on the next generation of libraries and its own internal API. During our last QGIS Project Steering Committee meeting we ran through various possibilities. Matthias Kuhn kindly joined the meeting to help clarify our options going forward which I have tried to summarise in the table below:

QGIS 2.14 LTR QGIS 2.16 ??? QGIS 3.0
Release date End Feb 4 months after 2.14 8 month cycle?
Notes Update python code of core QGIS to be Python 3 compatible and PyQt5 compatible (partial implementation for key functionality e.g. console, python core plugins etc.)
Qt4 Yes

Deprecated in Debian Stretch (due in a year)

(webkit removed)

Yes No
Qt5 No

Misses QWebView – new replacement not on all platforms. Also misses QPainter Engine.

Yes Yes
PyQt4 Yes Yes No
PyQt5 No Yes Yes
Python 2 Yes Yes No
Python 3 No Yes Yes
API Cleanup No No Yes
PyQt5 -> PyQt4
Provide ~90% backwards compatibility
No Yes Yes
Mainstream Binary Qt4 Based Qt4 Based Qt5 Based
Funding priority Python wrappers

There are two key things to note about Matthias’ proposal:

  • In the first phase, work would be done in the QGIS 2.x series to complete support for Qt5, PyQt5, Python 3.0 whilst still supporting Qt4, PyQt4 and Python 2.7. This implies that all changes made in the first phase would be backwards compatible with previous QGIS 2.x releases. Python wrappers will be introduced so that the old PyQt4 API can still mostly be used when compiling against Qt5, PyQt5, Python 3.0. When using QGIS compiled against Qt4, PyQt4 and Python 2.7 there would be no compatibility breakage.
  • In the second phase, we would work to produce QGIS 3.0 which introduces a number of API breaking changes, completely removing Python 2.7, Qt4 and PyQt4 support. The python wrappers produced in the first phase would be kept and relied on to ensure that a large proportion of python code (plugins, scripts etc.) developed for QGIS 2.x releases continue to work in QGIS 3.x releases. In this phase we would also introduce the QGIS API changes which may break some plugins. To address this we will provide a migration guide to try to ease the process for those moving from code depending on the QGIS 2.x releases to the QGIS 3.x releases.

Caveat emptor

There are a couple of ‘gotchas’ that we should raise at this point as the above makes the migration to QGIS 3.0 sound fairly painless.

  1. The first thing we should emphasise is that while the approach laid out above tries to minimise the amount of work python script and plugins writers have to do, this will not be a 100% effort free solution for python coders using QGIS. There will very likely be cases where code needs to be adjusted and in all cases at the very least it will probably need to be reviewed in order to ensure that it still functions properly.
  2. There is no formal funding set aside to pay for developers to spend their time working on the migration process. Because of this it is going to be incredibly hard to give accurate timelines as to how long each part of the process will take. We need to take this uncertainty into account in our planning. Of course we welcome donations to help make this happen.
  3. There may be developers and institutions out there funding new features for the QGIS 2.x series and this may affect your work. You should include in your project plans and budgets some allocation to cope with the migration to the QGIS 3.x platform.
  4. If we do the work in the ‘master branch’ there may be a protracted time during which our master branch is unstable and in flux due to ongoing updates towards QGIS 3.0.
  5. If we do the work in a ‘3.0 branch’, we run the risk that the 3.0 development may drag on longer unless there is a devoted group of developers working on it and getting it ready to merge to master.


In the light of all the above information, we propose one of two courses of action:

Proposal 1:

Do an interim release of 2.16 and then commence work on 3.0 in master with an 8 month development window. Work on 3.0 related stuff could already begin in 2.16  (see python3/pytq5), only incompatible changes have to be postponed to post 2.16.

Advantage: Main focus of work would be in master branch. Work scheduled for the near future can be released in expected timelines. Plugins will continue to work with master. People can start to write and test their code in a portable manner.

Disadvantage: Difficult to determine timelines as we don’t have funding


Proposal 2:

Create a long running 3.0 branch for the port to Qt5, Python 3.0 and PyQt5 and call for developers to get their 3.0 work in there. Continue with 2.x releases with the usual frequency until 3.0 is ready.

Advantage: We can release it ‘when it’s ready’. If there is no funding for 3.0 work subsequent releases are not jeopardised.

Disadvantage: Duplication of effort as work in master coming in needs to be ported over to the 3.0 branch.

Alternative proposals

Do you have an alternative proposal? We would like to get all the proposals on the table so that we (the PSC in consultation with core developers) can make the best judgement of how to approach the nitty-gritty process of managing the QGIS 3.0 development process. If you wish to submit a proposal, please send it to me ( with the subject line ‘QGIS 3.0 Proposal‘. Please keep your proposal very short and succinct as we just need the high level concepts.


Here is the proposal submitted by Matthias Kuhn that you can use as a reference of how we might like  a proposal to look:

QGIS 2.16 Release as usual in 4 months

-> PyQt5 Support
-> Python 3 Support
-> Wrapper library for PyQt4/PyQt5
-> Maybe a helper transition script that does 80% of the rewrite
-> All old plugins still work
-> Some python code is updated (console, plugin manager, processing) to
have some guidelines and experience how to update python code
-> For future debian, mac osx… versions there’s a qt5 version around
(with almost no plugins working)

During the same time: make some noise that QGIS 3 is coming and we need
everybody to put some money and dev time aside for it and that it’s
going to be amazing.


After that: 8 months break for 3.0 (maybe some betas after 4 months and
every month after)

Back to normal, everybody happy – except the lazy plugin devs who didn’t
update –:)

QField Documentation

After getting QField up and running in Android 5, we felt it was time to start documenting how QField works, we started documenting how to install and use QField. We also added a section on how to handle your data

Crowd funding project for reading CAD documents in QGIS

Local governments on the municipality or provincial level often have to deal with DXF/DWG/DGN documents delivered from architects, urban planners or engineering companies. As an example, cadastral or utility offices or companies often have to import CAD documents to either check deliveries about correctness or import selected objects into their central database. Another requirement is being able to visualize planned objects, such as buildings or bridges alongside with the cadastral data.

QGIS lacks proper import of CAD data so far – DXF files can only be imported on very basic levels (without styling and labeling), DWG files can’t be imported at all.

A requirements document has been written to implement import of DXF/DWG (and potentially also DGN) files into QGIS, while maintaining styling, labeling, 3D, curves and blocks.

The company Norbit, with Jürgen Fischer, submitted an offer. Jürgen is a long-term QGIS developer and QGIS.ORG board member. Norbit has extensive experience with bridging GIS and CAD.

The plan is to use the Teigha library of the OpenDesign Alliance (ODA) to read the CAD documents. Either QGIS.ORG or OSGeo would become a member of the ODA, to get access to the source code and for distributing the Teigha libraries with QGIS binaries.

At this time we are looking for organisations or companies that help funding the effort. The offer from Norbit is over 32k €. We are looking for institutional crowd funders with minimum contributions of 1k Euros. If you are interested in contributing, please contact by mail at andreas (at) qgis (dot) org. We can send you an invoice for your contribution.

Addition: if you want to do smaller, targeted donations, please use the regular donation channels and mention “CAD import” in the payment instructions.


A word of thanks to the hosts of the 14th QGIS Hackfest in Gran Canaria

Last weekend (November 5th – November 8th, 2015) was a special occasion for the QGIS Project – we convened the 14th our ‘hackfest’ meeting!

QGIS hackfests are events where an organiser provides a space for collaboration and members of the community converge and self-organise to improve the QGIS project. We are very much dependent on the good will of our hosts – typically universities – for providing these spaces and the logistics needed to manage the provision of accommodation, food, internet and other needs of our participants over the duration of the hackfest. For this event our gracious hosts were Universitas de Las Palmas de Gran Canaria. Our presence at the University was endorsed and facilitated by:

  •  Rector of ULPGC: José Regidor García
  •  ULPGC Manager: Conrado Domínguez Trujillo
  •  CIO of ULPGC and Director of OSL (“oficina de software libre”, or Free Software Office): Jose Pablo Suárez Rivero.
  •  Councilor of New Technologies Area, Public Administration and Sports at Las Palmas de Gran Canaria Town Hall:  Aridany Romero Vega
  •  Senior professor of computer Science: Agustín Trujillo Pino
The local coordination team was headed up by Pablo Fernández Moniz (CTO and GIS Analyst). Pablo did an amazing job in pulling all the strands together making the event happen! He was assisted by an awesome team of helpers, and participants:
  • Design: Ramsés Cabello Developer (staff at the event): Jaisiel Santana Almedia
  •  Developer (staff at the event): Alejandro Sánchez Medina
  •  Developer (staff at the event): Chano OrtegaTrujillo
  •  Developer (staff at the event): Moises Bonilla

Our heartfelt thanks to all of the people who worked so hard to make this event happen, and to the participants who travelled from far and wide to attend the event. These events are a significant factor in the success of the QGIS project – they allow our developers and contributors to meet face to face and delve deep into technical issues that would be impossible to do under the somewhat disconnected collaboration environment provided by the internet.

Key Activities

There were just under 30 people in attendance at the hackfest – here are just a few of the activities that they were busy with during the hackfest:
  • Qt5 / Python 3 proof of concept by Matthias Kuhn
  • Topological editing with GRASS plugin (Radim Blazek) – video (not from event)
  • Geoserver explorer plugin (Luigi Pirelli)
  • General discussion and planning for the improvement of contribution workflows (pull requests, tickets, QEPs) and infrastructure (Redmine)
  • Improvement of analysis tools (ftools, processing) and their documentation
  • General bug fixes (Jürgen Fischer)
  • Improvements to the website (Richard Duivenvoorde and Anita Graser)
  • Implementation of a GitHub webhook to insert a ‘[FEATURE] issue’ so that documenters know to document new features as they are added to QGIS (Richard Duivenvoorde and Raymond Nijssen)
  • Processing support for loading Oracle data via OGR (Giovanni Manghi)
  • Launched the Italian QGIS User Group, updates to the  documentation of Lizmap web client, managed the Italian translation, the python plugin queue (Paolo Cavallini)

QGIS Sponsorship

Many of the costs not covered by our hosts were covered from central funds including food and travel costs for a number of participants. These funds originate from our donors and sponsorships and are an invaluable resource for the project to allow us to facilitate these events and move the development of QGIS forward. We encourage you to donate to the QGIS or become a sponsor if you would like to foster further innovation and support the long terms goals of the project.

More Information

If you would like further information about what was covered in the event, and to get a feel of the general atmosphere of the event, check out some of these links:

I will update the list above as more reports backs become available.


With thanks from your project chair and the whole QGIS community,


Your donations/sponsorships help to maintain and improve the quality of QGIS

The QGIS project is growing in size, number of contributors/contributions and code complexity. This introduces challenges for the project, especially for maintaining quality. Maintaining and improving quality is one of the main concerns of the QGIS.ORG board and some core developers.

Past and current QA efforts

Tim Sutton introduced a first unit test framework several years ago. But it wasn’t very visible then and passing the tests as a prerequisite to make changes to master wasn’t enforced. About a year ago, Matthias Kuhn introduced automated unit testing for the Linux builds – using Travis continuous integration testing. At our github page you can always see whether the master version builds fine and whether the tests are passing – see the green “Build passing” button at the beginning of the file.

Since then, OS X automated building/testing was added. Pull requests (new contributions from developers) can be tested prior to integration into the master branch. Another effort was to use coverity code scans to detect memory leaks. Nyall Dawson and others did a lot of improvements/fixes due to this automated code scans.

Upcoming challenges

There is still a lot to do regarding quality and automated testing. Because continuous integration tests were only introduced about a year ago, it means that still a lot of areas in the code base remain untested. Also, the current unit tests do not test GUI interactions. There is an ongoing discussion if critical classes should have unit tests enforced for any code changes. Finally, our bug queue at is still quite long, with lots of bigger and minor issues.

Your financial support really matters!

This is where your donations and sponsorships come in. For the past 3-4 releases we were able to pay 2-4 developers who worked for several days concentrating on bug fixing. For QGIS 2.12 we had Nyall Dawson, Jürgen Fischer and Larry Shaffer working on bug fixing. We also financially support Giovanni Manghi for working on our bug tracker (e.g. classifying issues correctly, trying to reproduce the issue, ask bug reporters for more details).

Now – you may wonder why they didn’t fix all the “BLOCKER”s first and then continue on with “HIGH”, “NORMAL” “LOW”  issues – and why a lot of unreported issues and issues with label “LOW” were also fixed? The answer is that it is often more efficient for the developers to concentrate on a certain part of the code – e.g. concentrating on geometry, labeling and editing issues, as Nyall did for this round of bug fixing. This means that he would not only fix issues labeled as “BLOCKER” or “HIGH” but also other bugs that are in the same code. Finally, not all of the “Blocker” and “High” bugs are reproducable or the issue may be much too hard/time consuming to fix.

Due to your financial support, the 3 developers were able to fix the following list of issues for the QGIS 2.12 release – many of the fixes also get back-ported to QGIS 2.8 LTS release:

  • Sweep of all changed dialogs, ensuring tab order is correct
  • UNREPORTED: Only save effect element if it is non-default (decreases size of qgs project files)
  • HIGH: Fix map rotation not considered for ellipse marker data defined rotation (#13367)
  • HIGH: Maintain order of recent expressions (#13461)
  • NORMAL: Make sure recent expression group is always listed last (#13462)
  • NORMAL: [diagrams] Fix initial value of transparency slider not set (#13434)
  • UNREPORTED: Fix potential crashes in renderer widgets
  • NORMAL: Fix legends are empty if presets used with filtered legend (#13300)
  • UNREPORTED: Fix crashes and inconsistent ui when atlas is set to a geometryless layer
  • BLOCKER: Fix diagrams are always shown, regardless of setting (#13501)
  • BLOCKER: Fix fill ring tool used with advanced digitising crashes QGIS (#13355)
  • NORMAL: Fix add ring/fill ring tool works on first polygon (#13069)
  • BLOCKER: Fix missing sip bindings for renderers (#13545)
  • BLOCKER: Fix crash in label property dialog (#13543)
  • NORMAL: Fix hardcoded border for raster legend items (#13540)
  • BLOCKER: Fix symbols drawn multiple times in rule based renderer if symbol (#13220)
  • BLOCKER: Use a model for node editor table, fixed hang when node tool used on large feature (#13541)
  • BLOCKER: Fix node tool duplicates nodes when topological editing and snap are both enabled (#13466)
  • NORMAL: Fix broken data defined SVG marker outline width (#13423)
  • HIGH: Scale svg marker outline width to match context (#11522)
  • HIGH: Allow coloring of svg markers and svg fills when used with graduated/categorised renderers (#11658)
  • HIGH: Fix svg outline widths are incorrectly scaled (#11522)
  • UNREPORTED: Fix snapping options dialog not correctly initialised when loading projects
  • UNREPORTED: Fix uninitialized variables in advanced digitizing dock which meant that sometimes advanced digitising tools would be activated unexpectedly
  • NORMAL: Fix curved labels ignore line orientation placement flag (#5778)
  • UNREPORTED: [console] Move run button earlier in console editor toolbar (prevents it being hidden in overflow menu on small screens)
  • UNREPORTED: Fix fill and outline color for svg markers sometimes enabled even though SVG file does not support parameters
  • UNREPORTED: Fix svg marker colors not correctly restored from project
  • UNREPORTED: If svg files with params do not have a default value set, then don’t reset the fill/border color and border width when changing svg marker/svg fill SVG files (made the behaviour consistent between the svg marker and the other marker symbols)
  • NORMAL: Fix svg symbols are shown in white and hard to see in svg picker (#10908)
  • NORMAL: Fix refining rule based renderer using expression (#10815)
  • UNREPORTED: Fix crash when changing symbol types on windows
  • BLOCKER: Fix split parts tool only leaves one of the newly created parts (#13421)
  • BLOCKER: Fix using add part tool to add part to geometryless rows (#12885, #11319)
  • UNREPORTED: Fix some potential crashes with edit tools and null geometry
  • UNREPORTED (thought I’d submitted this years ago but can’t find the issue now): Allow adding features with empty geometry via attribute table
  • HIGH: Allow delete part tool to remove geometry from single type point and line layers (#13258)
  • LOW: Fix overview canvas background color not set (#11157)
  • Add some unit tests for QgsWKBTypes
  • NORMAL: When adding ring to a geometry, add z or m dimensions to the ring geometry if required (#7400, #7401)
  • NORMAL: Also show features with modified geometry when “show edited and new features” filter is active in attribute dialog (#11684)
  • BLOCKER: Fix broken apply button in label config dialog (#13543)
  • BLOCKER: Fix area calculation when OTF active and no ellipsoid, add unit test (#13601)
  • UNREPORTED: Fix exporting geometry collections to WKT would result in invalid WKT
  • UNREPORTED: Fix unable to import WKT using MultiPoint(1 1,2 2,…) format
  • UNREPORTED: Fix GeometryCollection WKT to support collections with multi* children and GeometryCollection children (allowed by spec)
  • Add a bunch of unit tests to geometry
    – UNREPORTED: Fix calculation of area and length of mixed geometry collections
  • UNREPORTED: Fix geometry casting in python bindings (missing MultiLineString and GeometryCollection casts)
  • UNREPORTED: Fix calculation of length/perimeter for geometry collections
  • UNREPORTED: when creating geometry from WKT, upgrade dimensionality of geometry if coordinates are 3/4 dimensional
  • UNREPORTED: match dimensionality of collections to child dimensionality
  • UNREPORTED: fix area of curves was non-zero if curve is closed
  • UNREPORTED: don’t consider m values when testing for curve closedness
  • NORMAL: Fix merge attributes tool sets skipped attributes to null (#13231)
  • NORMAL: Add skip all option to merge attributes dialog (#6958)
  • UNREPORTED: Fix QgsStatisticalSummary sometimes returning 0 for StDevSample stat
  • UNREPORTED: Fix storing string representations of doubles in an int field results in NULL rather than converting value to int
  • NORMAL: Fix merge attributes/features tool resets values to null for int fields and add a warning if merged attribute value is not compatible with field type (#12842)
  • Fix a LOT of leaks relating to geometry and GEOS operations, labeling
  • UNREPORTED: [pal] Fix regression in placement for free/horizontal polygon labels
  • Add tooltips to advanced digitizing dock
  • Fix a crash in filtered legends
  • Reviewed and merged several bug fix PRs
  • #13433: Help text for rpad and lpad in field calculator are mixed up
  • #13417: missing
  • #13420: Strange behaviour of newly ‘saved as’ project
  • #13463: Identify Results panel always show newly created features in the list
  • #13538: PostGIS tables containing MultiPolygonZ crash QGIS master
  • #13546: qgis trying to update first empty text row with null in db
  • #13027: Join by location does not work when layers have equivalent field names
  • #13032: Save as… fails to populate fields if layer has similar names only different by case
  • #13052: Problem with reshape
  • #10747: Cannot copy/paste points features
  • #13506: Processing help files for QGIS algs all dead now
  • #13274: API combine method for geometry
  • #11755: Real precision (Shapefile)
  • #9208: QGIS crashes when using addAttributes on any vector data provider
  • #13579: Crash Dump 2.11 with user defined expressions
  • #10515: QGIS Crash when trying to load a point layer to georss file
  • #11276: Setting radius units to meters produces incorrect results
  • #13641: editing a feature in a PostGIS layer does not work when the PK contains NULLs
  • #13631: when ELSE rule exists in Styling, all Labels are rendered regardless of styling groups being active/inactive
  • #13638: Cannot load emptry Postgis views
  • #8255: in edit mode changing primary key discards geometry modifications
  • #13594: DB Manager – unable to add a Postgres/PostGIS raster as layer
  • #13446: MYSQL Project File
  • #13310: nightly build packages failing to install with grass error
  • (PR#2378: Allow postgis layers from queries to have multiple column primary keys)
  • (PR#2376: the test for uniqueness now also works for multiple columns by SebDieBln)
  • (#13645: ftools “line intersection” crashes qgis)
  • (#13646: Merge shapefiles from fTools crashes QGIS)
  • transifex updates & german translation
  • attribute editing: don’t allow editing without ChangeAttributeValues capability
  • vector layer: avoid some crashs when methods are called on invalid layers
  • oracle provider: fix call of sdo_filter to verify a spatial index is present
  • #13641: postgres provider: verify unique constraint if NOT NULL is not set on key columns (shortly after release)
  • Commit 6a4544f fix fetching of redirected wms capabilities (followup e95bf6d)

Open Source, why?


During my professional and personal life, I have worked with much different software, with all kinds of licenses. Most of them would be proprietary, closed and / or commercial code. So why devote my time and learning “exclusively” to Open Source?

Without going into detail about the differences between open source software and free software, there are several reasons why FOSS (Free and Open Source Software) interest me.

The first is obviously freedom. Be free to use the software in any context and for any purpose, without being limited by the costs of software acquisition and / or the rules and conditions imposed by the manufacturer (as many said free (as beer) software do). That allows me to, for example, familiarize myself with its features without having to use piracy, or, as a freelancer worker, develop my work based on my technical capacities rather than my financial ones.

Second, the community and collaborative factor. The fact that open source software is built by user and for users, where the main goal is to enhance the software functionality (and not just raise the number of sales), and wherein each enhancement introduced by an individual or company is subsequently shared for the benefit of the whole community, avoiding duplication and “reinventing the wheel”. This is done in part through a lot of volunteer work and constant sharing of knowledge, either by the programmers or users. Thus, together, we all evolve at the same time as the software itself. In addition, everyone can contribute in some way, by producing code, writing and preparing supporting documentation, translating them into other languages or just by reporting bugs.

Finally, the “costs“. The adoption of open source software in enterprises (including the public ones), allow them to focus their investments in training of the human resources and the possible (and desirable) sponsoring of new features that are essential for their workflow, usually for a small portion of the values to spend on the acquisition of commercial software (that usually “forces” the purchase of features that may never be used).

Introducing the QGIS Board

The QGIS PSC (Project Steering Committee) is in transition to becoming a Board. We are registering the project as a Swiss ‘Verein‘ (Association) which will be known as QGIS.ORG and will function as a not-for-profit company, serving the interests of the QGIS project.  The motivation for the transition to a legal entity is described in QGIS QEP (QGIS Enhancement Proposal) #16. The board will be constituted of the same members of the PSC but will gain the executive responsibilities required of our Verein statutes.

New chair and vice-chair

Our long time project founder, Gary Sherman, has stepped down from his role as project chair. I (Tim Sutton) have been elected by the QGIS PSC as Gary Sherman’s replacement by the incoming Board. In addition Paolo Cavallini has been elected as vice chair. Gary will continue to serve as an active voting member of the Board, and will maintain life-long honorary membership on the board.

A special note of thanks

In a world where proprietary GIS software licenses cost many times more than the annual income of most of its citizens, free access to spatial visualisation and analysis tools through QGIS (and its constituent projects such as GRASS, GEOS and GDAL) is a profoundly disruptive force for good.

QGIS is a available to anyone with a reasonably modern computer. It makes the wise utilisation of the earth’s scarce resources and the ability to take care of its citizen’s civic and humanitarian needs based on sound spatial decision-making, that much more possible for a huge swathe of society which would otherwise have been disenfranchised.

Even in developed societies where finance is not necessarily the limiting factor, we cannot underestimate the impact of a software platform that is a freely extensible and shared body of knowledge. QGIS is a platform that enhances the ability of governments and private organisations to deliver services that deeply enrich the lives of their citizens and customers.

Gary’s selfless contribution of the QGIS source code has thus had a far reaching affect on many people’s lives – including my own. Under Gary’s stewardship, the project has evolved from a very basic simple GIS data browser that ran on one platform and could only work with PostGIS data, to a fully-fledged production-ready GIS that can be used on the desktop, in your own custom applications and to serve web maps and services.

Gary has been and will remain an inspirational figure to all of us in the QGIS project – the project he started 13 years ago in 2002. We look forward to his continued involvement on the Board.

Going forward

Our goal as the QGIS.ORG Board is to continue the work started by Gary and to position QGIS as the de facto desktop GIS application, capable of providing a wide range of functionality and richness of features, so that it is no longer necessary to use proprietary GIS software to understand and manage our world.

We are looking for funders for the QGIS.ORG non-profit company. As a foundation project to many humanitarian, municipal, government, NGO, conservation and industry related FOSS tools, we would like to secure funding for the core QGIS project to hire full-time staff so that we can improve the quality and functionality of QGIS for all our users.

To date we have subsisted mainly on micro donations and small-scale sponsorships for which we are very grateful (keep them coming!). This has been very useful but has never take us to the point where we can employ staff full-time to work solely for the good of the project. We would like to establish a team of full-time developers, documentation writers etc.….so we have quite a mountain to climb!

Over the coming months we will be actively seeking out new sources of funding to support these goals, whilst never losing sight of our core principles of Open Governance, Open Source and Open Community. We hope you will join us and support us in this exciting new chapter of the QGIS project!

Your Board

  • Tim Sutton (Chair)
  • Paolo Cavallini (vice-Chair)
  • Andreas Neumann (Treasurer)
  • Gary Sherman (life time honorary member)
  • Anita Graser
  • Otto Dassau
  • Richard Duivenvoorde
  • Marco Hugentobler
  • Jürgen Fischer


Tim Sutton
Incoming QGIS Board Chair

QGIS Crowdfunding project: 2.5D Rendering of buildings/polygons

QGIS already supports various different renderers, such as
categorized, rule-based, point-displacement, 25d_renderingheatmap, etc. This allows for advanced cartographic representations. In addition, there are plugins available, such as “qgis2threejs” or “QGIS Globe”, which allow to view and export QGIS data in the third dimension. While these plugins are very useful, they also have limitations: they are not fully integrated with the QGIS styling mechanisms and can’t be integrated in the QGIS print composer for  high-quality printing.

This crowd funding project aims to extend QGIS renderers with oblique views. The third dimension of the polygon is controlled by an attribute or expression and global angles. The representations can be combined with other QGIS styling options, such as symbol levels, layer effects, categories and rules. Applications are rendering buildings according to their actual heights (similar to Google maps 2.5d rendering) or thematic maps where the polygons are extruded according to an attribute to be represented.

This project is primarily financed by ADUGA and the regional council of Picardy in France. However, of the 20k Euros, 5k are still missing, to fully implement the project.

Thank you for helping us out by contributing to this crowd funding campaign over at OpenGIS.

Announcing the release of QGIS 2.12

This week we have more great news from Jürgen Fischer, our release manager:

“QGIS is a user friendly Open Source Geographic Information System that runs on Linux, Unix, Mac OSX, and Windows.

We are very pleased to announce the release of QGIS 2.12 ‘Lyon’. Lyon was the host city to our developer meet up in April 2012.

Latest Release

This is another regular release following our four monthly schedule.  It again brings many nice new features to QGIS.

Please also note that we’re constantly keeping our long term release QGIS 2.8 ‘Wien’ in good shape to better suit more conservative production setups.

New Features in QGIS 2.12 ‘Lyon’

QGIS 2.12 includes many great new features, tweaks and enhancements to make the
most popular Free desktop GIS even more feature filled and useful.  Visit the visual changelog that highlights some of the new additions.

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 (

The source code and binaries for Windows, Debian and Ubuntu are already available via the large download link on our home page:  More packages will follow as soon as the package maintainers finish their work. Please revisit the page if your platform is not available yet.”


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.

  • Page 1 of 4 ( 63 posts )
  • >>
  • uncategorized

Back to Top