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.
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.)|
Deprecated in Debian Stretch (due in a year)
Misses QWebView – new replacement not on all platforms. Also misses QPainter Engine.
PyQt5 -> PyQt4
Provide ~90% backwards compatibility
|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.
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.
- 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.
- 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.
- 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.
- 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.
- 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:
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
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.
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 (firstname.lastname@example.org) 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
Monday, January 4th 2016, was the open data release date of the official Austrian street network dataset called GIP.at. As far as I know, the dataset is not totally complete yet but it should be in the upcoming months. I’ve blogged about GIP.at before in Open source IDF parser for QGIS and Open source IDF router for QGIS where I was implementing tools based on the data samples that were available then. Naturally, I was very curious if my parser and particularly the router could handle the whole country release …
Some code tweaking, patience for loading, and 9GB of RAM later, QGIS happily routes through Austria, for example from my work place to Salzburg – maybe for some skiing:
The routing request itself takes something between 1 and 2 seconds. (I should still add a timer to it.)
So far, I’ve implemented shortest distance routing for pedestrians, bikes, and cars. Since the data also contains travel speeds, it should be quite straight-forward to also add shortest travel time routing.
The code is available on Github for you to try. I’d appreciate any feedback!
Mostly interesting for dutchies A short post that there is a new 0.10 version of the pdokservicesplugin (http://plugins.qgis.org/plugins/pdokservicesplugin/), Some layers have been removed and some are new. The total number of layers is now 6723 (coming from 5298). Most important changes: Removed: – brtachtergrondtijdelijk – brtachtergrondgrijstijdelijk – top10nl (nu: top10nl2) – Noordzee Kabels en Leidingen … Continue reading PDOK services plugin update
What’s new in a nutshell
The new GRASS GIS 7.0.3RC1 release provides 160 stability fixes and manual improvements. Of particular interest is the new winGRASS 64 bit support.
About GRASS GIS 7: Its graphical user interface supports the user to make complex GIS operations as simple as possible. The updated Python interface to the C library permits users to create new GRASS GIS-Python modules in a simple way while yet obtaining powerful and fast modules. Furthermore, the libraries were significantly improved for speed and efficiency, along with support for huge files. A lot of effort has been invested to standardize parameter and flag names. Finally, GRASS GIS 7 comes with a series of new modules to analyse raster and vector data, along with a full temporal framework. For a detailed overview, see the list of new features. As a stable release series, 7.0.x enjoys long-term support.
- winGRASS 7.0.3RC1: 32bit standalone installer | 64bit standalone installer
- winGRASS 7.0.3RC1 OSGeo4W: 32bit OSGeo4W installer | 64bit OSGeo4W installer
- … further binary packages for various Linux distributions and Mac OSX will follow shortly.
Source code download:
- To get the GRASS GIS 7.0.3RC1 source code directly from SVN, see here.
See also our detailed announcement:
First time users may explore the first steps tutorial after installation.
About GRASS GIS
The Geographic Resources Analysis Support System (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).
The GRASS Development Team, December 2015
The post appeared first on GFOSS Blog | GRASS GIS Courses.
EN | PT
With the release of the first long term release (2.8 LTR), and two other stable versions (2.10 and 2.12), 2015 was a great (and busy) year for the QGIS community, with lots of improvements and new features landing on QGIS source code.
5 – Python console improvements (2.8)
Since QGIS 2.8, we can drag and drop python scripts into QGIS window and they will be executed automatically. There is also a new a toolbar icon in the plugins toolbar and a shortcut (
Ctrl-Alt-P) for quick access to the python console.
4 – Processing new algorithms (2.8)
Also in QGIS 2.8, there were introduced some new algorithms to the processing framework. If you are into spatial analysis this must have done your day (or year).
- Regular points algorithm
- Symmetrical difference algorithm
- Vector split algorithm
- Vector grid algorithm
- Hypsometric curves calculation algorithm
- Split lines with lines
- Refactor fields attributes manipulation algorithm
3 – Show rule-based renderer’s legend as a tree (2.8)
There were introduced a few nice improvements to QGIS legend. Version 2.8 brought us a tree presentation for the rule-based renderer. Better still, each node in the tree can be toggled on/off individually providing for great flexibility in which sublayers get rendered in your map.
2 – Advanced digitizing tools (2.8)
If you ever wished you could digitize lines exactly parallel or at right angles, lock lines to specific angles and so on in QGIS? Since QGIS 2.8 you can! The advanced digitizing tools are a port of the CADinput plugin and adds a new panel to QGIS. The panel becomes active when capturing new geometries or geometry parts.
1 – Rule-based labeling (2.12)
This was a very awaited feature (at least by me), and it was voted by the majority of users. Since 2.12, you can style features labels using rules. This gives us even more control over placement and styling of labels. Just like the rule based cartographic rendering, label rules can be nested to allow for extremely flexible styling options. For example, you can render labels differently based on the size of the feature they will be rendered into (as illustrated in the screenshot).
There were other new features that also made the delight of many users. For example, the Improved/consistent projection selection (2.8), PostGIS provider improvements (2.12), Geometry Checker and Geometry Snapper plugins (2.12), and Multiple styles per layer (2.8).
Obviously, this list means nothing at all. I was a mere exercise as with such a diverse QGIS crowd it would be impossible to build a list that would fit us all. Besides, there were many great enhancements, introduced during 2015, that might have fallen under the radar for most users. Check the visual changelogs for a full list of new features.
On my behalf, to all developers, sponsors and general QGIS contributors,
THANK YOU VERY MUCH FOR YOUR TREMENDOUS WORK!
I wish you a fantastic (and productive) 2016.
Sometimes is hard to debug segfaults appearing in QGIS Server when running in CGI mode.
The classic approach is attaching a
gdb to the running process.
The problem is that there is not enough time to do it!
A simple plugin filter, can provide you the time you need to attach the debugger:
from qgis.server import * from qgis.core import * import os class DelayFilter(QgsServerFilter): def __init__(self, serverIface): super(DelayFilter, self).__init__(serverIface) def responseComplete(self): request = self.serverInterface().requestHandler() params = request.parameterMap() if params.get('DELAY', ''): QgsMessageLog.logMessage("PID: %s" % os.getpid()) import time time.sleep(30)
Calling the server with
DELAY=1 will wait for 30 seconds and print the current PID in the server logs.
This will give you enough time to fire
gdb and attach it to the process.
In part 3 of my exploration of variables in QGIS 2.12, I’m going to dig into how variables are scoped in QGIS and what layer level variables are available (you can read parts 1 and 2 for a general introduction to variables).
Before we get to the good stuff, a bit of background in how variables work behind-the-scenes is important. Whenever an expression is evaluated in QGIS the context of the expression is considered. The context is built up from a set of scopes, which are all stacked on top of each other in order from least-specific to most-specific. It’s easier to explain with an example. Let’s take an expression used to set the source of a picture in a map composer. When this expression is evaluated, the context will consist of:
- The global scope, consisting of variables set in the QGIS options dialog, and other installation-wide properties
- The project scope, which includes variables set in the Project Properties dialog and the auto-generated project variables like @project_path, @project_title (you can read more about this in part 2)
- A composer scope, with any variables set for the current composer, plus variables for @layout_pagewidth, @layout_pageheight, @layout_numpages, etc.
- A composer item scope for the picture, with item-specific variables including @item_id
The more specific scopes will override any existing clashing variables from less specific scopes. So a global @my_var variable will be overridden by an @my_var variable set for the composer:
Another example. Let’s consider now an expression set for a data-defined label size. When this expression is evaluated the context will depend on where the map is being rendered. If it’s in the main map canvas then the context will be:
- The global scope
- The project scope
- A map settings scope, with variables relating to how the map is being rendered. Eg @map_rotation, @map_scale, etc
- A layer scope. More on this later, but the layer scope includes layer-level variables plus preset variables for @layer_name and @layer_id
If instead the map is being rendered inside a map item in a map composer, the context will be:
- The global scope
- The project scope
- The composer scope
- An atlas scope, if atlas is enabled. This contains variables like @atlas_pagename, @atlas_feature, @atlas_totalfeatures.
- A composer item scope for the map item
- A map settings scope (with scale and rotation determined by the map item’s settings)
- The layer scope
Using layer level variables
Ok, enough with the details. The reason I’ve explained all this is to help explain when layer level variables come into play. Basically, they’ll be available whenever an expression is evaluated inside of a particular layer. This includes data defined symbology and labeling, field calculator, and diagrams. You can’t use a layer-level variable inside a composer label, because there’s no layer scope used when evaluating this. Make sense? Great! To set a layer level variable, you use the Variables section in the Layer Properties dialog:
Any layer level variables you set will be saved inside your current project, i.e. layer variables are per-layer and per-project. You can also see in the above screenshot that as well as the layer level variables QGIS also lists the existing variables from the Project and Global scopes. This helps show exactly what variables are accessible by the layer and whether they’ve been overridden by any scopes. You can also see that there’s two automatic variables, @layer_id and @layer_name, which contain the unique layer ID and user-set layer name too.
Potential use cases for layer-level variables
In the screenshot above I’ve set two variables, @class1_threshold and @class2_threshold. I’m going to use these to sync up some manual class breaks between rule based symbology and rule based labeling. Here’s how I’ve set up the rule-based symbols for the layer:
In a similar way, I’ve also created matching rule-based labeling (another new feature in QGIS 2.12):
Here’s what my map looks like now, with label and symbol colors matched:
If I’d hard-coded the manual class breaks, it would be a pain to keep the labeling and symbology in sync. I’d have to make sure that the breaks are updated everywhere I’ve used them in both the symbology and labeling settings. Aside from being boring, tedious work, this would also prevent immediate before/after comparisons. Using variables instead means that I can update the break value in a single place (the variables panel) and have all my labeling and symbols immediately reflect this change when I hit apply!
Another recent use case I had was teaming layer-level variables along with Time Manager. I wanted my points to falloff in both transparency and size with age, and this involved data defined symbol settings scattered all throughout my layer symbology. By storing the decay fall-off rate in a variable, I could again tweak this falloff by changing the value in a single place and immediately see the result. It also helps with readability of the data defined expressions. Instead of trying to decipher a random, hard-coded value, it’s instead immediately obvious that this value relates to a decay fall-off rate. Much nicer!
I’m sure there’s going to be hundreds of novel uses of layer-level variables which I never planned for when adding this feature. I’d love to hear about them though – leave a comment if you’d like to share your ideas!
One last thing – the new “layer_property” function
This isn’t strictly related to variables, but another new feature which was introduced in QGIS 2.12 was a new “layer_property” expression function. This function allows you to retrieve any one of a bunch of properties relating to a specific map layer, including the layer CRS, metadata, source path, etc.
This function can be used anywhere in QGIS. For instance, it allows you to insert dynamic metadata about layers into a print composer layout. In the screenshot below I’ve used expressions like layer_property(‘patron’,’crs’) and layer_property(‘patron’,’source’) to insert the CRS and source path of the “patron” layer into the label. If either the CRS or the file path ever changes, this label will be automatically updated to reflect the new values.
So there you go – layer level variables and the layer_property function – here in QGIS 2.12 and making your workflow in QGIS easier. In the final part of this series, we’ll explore the magical @value variable. Trust me, I’ve saved the best for last!
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…
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.
In 2011, I wrote “How to Label Only Selected Features in QGIS” which ends with the wish that
Another “data defined setting” like “show this label (true/false)” would be more intuitive.
… and now we have it!
It’s called Show label and you can find it in the Rendering section of the labeling dialog.
The following screenshot shows a quick example of how to label only airports starting with A by setting the expression
"NAME" LIKE 'A%'
This post was motivated by a question by Eduardo here on this blog. Hope it helps!
Working on QField I had the necessity of passing values from the QtActivity.java to the Qt cpp world, here how I did it using an Intent that is sent to the QtActivity (the one you should not edit that comes with…
Following on from part 1 in which I introduced how variables can be used in map composers, I’d like to now explore how using variables can make it easier to manage your QGIS projects. As a quick refresher, variables are a new feature in QGIS 2.12 which allow you to create preset values for use anywhere you can use an expression in QGIS.
Let’s imagine a typical map project. You load up QGIS, throw a bunch of layers on your map, and then get stuck into styling and labelling them ‘just right’. Over time the project gets more and more complex, with a stack of layers all styled using different rendering and labelling rules. You keep tweaking settings until you’re almost happy with the result, but eventually realise that you made the wrong choice of font for the labelling and now need to go through all your layers and labelling rules and update each in turn to the new typeface. Ouch.
Variables to the rescue! As you may recall from part 1, you can reuse variables anywhere in QGIS where you can enter an expression. This includes using them for data defined overrides in symbology and labelling. So, lets imagine that way back at the beginning of our project we created a project level variable called @main_label_font:
Now, we can re-use that variable in a data defined override for the label font setting. In fact, QGIS makes this even easier for you by showing a “variables” sub-menu allowing easy access to all the currently defined variables accessible to the layer:
When we hit Apply all our labels will be updated to use the font face defined by the @main_label_font variable, so in this case ‘Courier New’:
In a similar way we can bind all the other layer’s label fonts to the same variable, so @main_label_font will be reused by all the layers in the project. Then, when we later realise that Courier New was a horrible choice for labelling the map, it’s just a matter of opening up the Project Properties dialog and updating the value of the @main_label_font variable:
And now when we hit Apply the font for all our labelled layers will be updated all at once:
It’s not only a huge time saver, it also makes changes like this easier because you can try out different font faces by updating the variable and hitting apply and seeing the effect that the changes have all at once. Updating multiple layers manually tends to have the consequence that you forget what the map looked like before you started making the change, making direct comparisons harder.
Of course, you could have multiple variables for other fonts used by your project too, eg @secondary_label_font and @highlighted_feature_font. Plus, this approach isn’t limited to just setting the label font. You could utilise project level variables for consolidating font sizes, symbol line thickness, marker rotation, in fact, ANYTHING that has one of those handy little data defined override buttons next to it:
One last thing before I wrap up part 2 of this series. The same underlying changes which introduced variables to QGIS also allows us to begin introducing a whole stack of new, useful functions to the expression engine. One of these which also helps with project management is the new project_color function. Just like how we can use project level variables throughout a project, project_color lets you reuse a color throughout your project. First, you need to create a named colour in the Default Styles group under the Project Properties dialog:
Then, you can set a data defined override for a symbol or label colour to the expression “project_color(‘red alert!’)“:
When you go back and change the corresponding colour in the Project Properties dialog, every symbol bound to this colour will also be updated!
So, there you have it. With a little bit of forward planning and by taking advantage of the power of expression variables in QGIS 2.12 you can help make your mapping projects much easier to manage and update!
That’s all for now, but we’re still only just getting started with variables. Part 3, coming soon!.. (Update: Part 3 is available now)
It’s been quite some time since I last had a chance to blog and a lot has happened since then. Not least of which is that QGIS 2.12 has now been released with a ton of new features that I’ve neglected to write about! To try and get things moving along here again I’m planning on writing a short series exploring how variables work in QGIS 2.12 and the exciting possibilities they unlock. First, let’s look into how variables can be used with QGIS map composer…
So, let’s get started! A new concept introduced in QGIS 2.12 is the ability to set custom variables for use in QGIS’ expression engine. The easiest way to do this is through the “Project Properties” dialog, under the “Variables” section:
You’ll see in the screenshot above that a blank project includes a number of read-only preset variables, such as @project_path and @project_title. (All variables in QGIS are prefixed with an @ character to differentiate them from fields or functions). You can add your own variables to this list by clicking the + button, as shown below:
Here I’ve added some new variables, @project_version and @author. Now, any of these variables can be used anywhere that you can use expressions in QGIS, including the field calculator, data defined symbology, labelling, map composer text, etc. So, you could make a map composer template with a label that includes the @author, @project_version and @project_path variables:
Sure, you *could* also manually enter all these details directly into the label for the same result. But what happens when you have multiple composers in your project, and need to update the version number in all of them? Or you move your project to a new folder and need to make sure the path is updated accordingly? Manually updating multiple composers is a pain – make QGIS do the work for you and instead use variables! This would especially be helpful if you’re saving map composer templates for use across multiple projects or users. Using variables will ensure that the template is automatically updated with the right details for the current project.
Another neat thing about QGIS variables is that they can be inherited and overridden, just like CSS rules. Opening the options dialog will also show a Variables group for setting “Global” variables. These variables are always available for your QGIS installation, regardless of what project you’re working on at the time. If your workplace tends to reorganise a lot and constantly shuffle your department around, you could add a global variable for @work_department, so that changing the global variable value in one place will automatically filter through to any existing and future projects you have.
And like I mentioned earlier, these variables are inherited through various “contexts” within QGIS. If I reopen the Project Properties dialog, you’ll see that a project has access to all the global variables plus the variables set within that specific project. In addition, by adding a variable with the same name to the Project variables the value of the Global variable will be overridden:
There’s also a variable editor within each individual composer’s properties tab, so variables can also be set and overridden on a composer-by-composer basis within a project. It’s a really flexible and powerful approach which both simplifies workflows and also opens up lots of new possibilities.
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: https://dl.dropboxusercontent.com/u/185489368/QGIS-Scotland2015.pdf
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: https://github.com/HeikkiVesanto/Scottish_QGIS_User_Workshop
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: https://github.com/OrdnanceSurvey/OS-VectorMap-District-stylesheets
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: https://www.flickr.com/photos/stevefaeembra/
The day finished with Pete (Lutra Consulting) releasing into the open a new Search plugin for QGIS called Discovery (http://www.lutraconsulting.co.uk/products/discovery/) based on the PostGIS Search plugin from Tim Martin (Ordnance Survey). A very useful addition to any QGIS installation.
Links to slides will be coming shortly.
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:
Anita Graser (@underdarkGIS) November 11, 2015
(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 …
Anita Graser (@underdarkGIS) November 14, 2015
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!
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 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.
- This function can only be used inside forms and it’s particularly useful when used together with the custom widget `Form Value Relation`
- If the field does not exists the function returns an empty string.
Download the example project.
This is the new widget in action: changing the field FK_PROV, the ISTAT values are filtered according to the filter expression.