Today’s post was motivated by a question over on gis.stackexchange, basically: How to draw a line with a gradient?
The issue we have to deal with is there is no gradient line style yet … But there are polygon gradient fills. So we can buffer the line and style the buffers. It’s a bit of an exercise in data-defined styling though:
Before creating the buffer layer, we need to add the coordinates of the line start and end node to the line attributes. This is easy to do using the Field Calculator functions
yat, for example
xat(0) for the x coordinate of the start node and
yat(-1) for the y coordinate of the end node.
Then we can buffer the lines and start styling the buffers. As mentioned, we’ll use the Gradient fill Symbol layer type.
The interesting part happens in the Data-defined properties. The start and end colors are computed from the measurement values
to_m. Next, it’s important to use the
feature coordinate mode because this will ensure that the coordinate system for the color gradient is based on the feature extent (with [0,0] in the upper left corner of the feature bbox).
Once that’s set up, we can compute the gradient start and end positions based on the line start and end node locations which we added to the attribute table in the beginning. If you’re wondering why Reference point 1 y is based on
to_y (y coordinate of the line end point) rather than
from_y, it’s due to the difference in coordinate origins in the geometry and the color gradient coordinate space: [0,0] is the lower left corner for the geometries but the upper left corner for the color gradient.
As the title suggests, this is a really hackish solution for gradient line symbols. It will only provide reasonable results for straight – or close to straight – lines. But I’m very confident that we’ll have a real gradient line style in QGIS sooner or later.
Today’s post is a follow-up to a recent map experiment which I published in the QGIS Flickr group. It’s basically an inverted Stamen Toner style with an image in the map composition background instead of a solid color (similar to the approach described for vintage maps):
That’s nice but with this approach we only get to enjoy the complete design in the print composer but not in the main window. So what other options do we have? – SVG fills to the rescue!
But first we need a suitable SVG with this nice pastel style. I used Gimp to create a seamless version of the pastel image and then embedded the image in an SVG using Inkscape:
In QGIS, this SVG can now be used in any SVG fill. It’s important to set the Texture width setting to a quite high value when working with SVGs containing big textures, otherwise the images will be rendered very small and the repeating patterns will be very obvious.
Once the background is in place, we can add the line work and labels. The roads are white with black outlines for bridges which – together with the Lighten blending mode – produce the desired effect:
Thank you for a great 2014! It’s been a pleasure to see the open source GIS community grow and experience what we can create together. It’s great to see the interest for open source GIS all over the world:
In total, this blog has been visitied from 216 countries. Most visitors came from The United States. Germany & France were not far behind.
Since my first post in 2010, the development of this blog has exceeded all expectations I might have had by far. For 2014, the WordPress blog view counter shows a staggering 330,000 views or over 900 views per day.
In case you were wondering, the most popular posts of 2014 were:
- 3D Viz with QGIS & three.js
- A guide to GoogleMaps-like maps with OSM in QGIS
- A QGIS 2.2 preview
- Getting started writing QGIS 2.x plugins
- and Toner-lite styles for QGIS
Thank you, your feedback has been a continuous source of motivation. All the best for 2015!
It’s the end of December and time to recap 2014. Therefore, I decided to have a look at what this year has brought us. There were plenty of great posts for both casual and power users as well as developers. Here is my pick of the top 10 posts from the QGIS Planet blog aggregator.
- Tons of colour improvements! (Nyall Dawson)
- The QGIS Field calculator is dead. Long live the Field calculator bar (Nathan Woodrow)
- Why QGIS Class Names Start with Qgs (Gary Sherman)
- Atlas Previews (Nyall Dawson)
- QGIS atlas on non geometry tables (Nathan Woodrow)
- Gradient Fills (Nyall Dawson)
- What are all these QGIS file types? Why do I need them (Nathan Woodrow)
- Getting Started Writing QGIS Python Plugins (Peter Wells)
- QGIS Layer Tree API (Martin Dobias)
- Shapeburst fill styles (Nyall Dawson)
More great features and posts are sure to come next year. For example, Nyall is currently running a campaign on Kickstarter to add Live Layer Effects such as drop shadow effects to QGIS. Please support it if you can.
At FOSS4G2013, I had the pleasure to attend a presentation about the ODVIS.AT project by Marius Schebella from the FH Salzburg. The goal of the project – which ended in Summer 2014 – was “to display open data (demographic, open government data) in a quick and easy way to end users” by combining it with OpenStreetMap. Even though their visualization does not work for me (“unable to get datasets” error), not all is lost because they provide an SQL dump of their PostGIS database.
Checking the data, it quickly becomes apparent that each data publisher decided to publish a slightly different dataset: some published their population counts as timelines over multiple years, others classified population by migration background, age, or gender. Also, according to the metadata table, no data from Salzburg and Burgenland were included. Most datasets’ reference date is between 2011 and 2013 but the data of the westernmost state Vorarlberg seems to be from 2001.
Based on this database, I created a dataset combining the municipalities with the Viennese districts and joined the population data from the individual state tables. The following map shows the population density based on this dataset: it is easy to recognize the densely populated regions around Vienna, Linz, Graz, and in the big Alpine valleys.
Overall, it is incredibly time-consuming to create this seemingly simple dataset. It would be very helpful if the publishers would agree on a common scheme for releasing at least the most basic information.
Considering that OpenStreetMap already contains population data, it barely seems worth all the trouble to merge these OGD datasets. Granted, the time lines of population development would be interesting but they are not available for each state.
P.S. If anyone is interested in the edited database, I would be happy to share the SQL dump.
It’s my pleasure to announce that the updated and extended 2nd edition of Learning QGIS is available now.
I also want to take this opportunity to thank everyone who made the 1st edition such a great success!
This second edition has been updated to QGIS 2.6 and it features a completely new 6th chapter on Expanding QGIS with Python. It introduces the QGIS Python Console, shows how to create custom Processing tools, and provides a starting point for developing plugins.
Overall, the book has grown by 40 pages and the price of the print version has dropped by 3€ :-)
Correct turn restriction information is essential for the vehicle routing quality of any street network dataset – open or commercial. One of the challenges of this kind of information is that these restrictions are typically not directly visible on each map.
This post is inspired by a share on G+ which resurfaced in my notifications. In a post on the Mapbox blog, John Firebaugh presents the OSM iD editor which should make editing turn restrictions straight-forward: clicking on the source link turns the associated turn information visible. By clicking on the turn arrows, the user can easily toggle between allowed and forbidden.
But the issue of identifying wrong turn restrictions remains. One approach to solving this issue is to compare restriction information in OSM with the information in a reference data set.
This is possible by comparing routes computed on OSM and the reference data using a method I presented at FOSS4G (video): a turn restriction basically is a forbidden combination of links. If we compute the route from the start link of the forbidden combination to the end link, we can check if the resulting route geometry violates the restriction or uses an appropriate detour:
illustrative slide from my LBS2014 presentation on OSM vehicle routing quality – read more about this method and results for Vienna in our TGIS paper or the open pre-print version
It would be great to have an automated system comparing OSM and open government street network data to detect these differences. The quality of both data sets could benefit enormously by bundling their QA efforts. Unfortunately, the open government street network data sets I’m aware of don’t contain turn information.