Did you know that there is a version of ColorBrewer that does not require Flash?
Yesterday, I described my process to generate a basic population density map from the city of Vienna’s open government data. In the end of that post, I described some ideas for further improvement. Today, I want to follow-up on those ideas using what is known as dasymetric mapping. GIS Dictionary defines it well (much better than Wikipedia):
Dasymetric mapping is a technique in which attribute data that is organized by a large or arbitrary area unit is more accurately distributed within that unit by the overlay of geographic boundaries that exclude, restrict, or confine the attribute in question.
For example, a population attribute organized by census tract might be more accurately distributed by the overlay of water bodies, vacant land, and other land-use boundaries within which it is reasonable to infer that people do not live.
That’s exactly what I want to do: Based on subdistricts with population density values and auxiliary data – Corine Land Cover to be exact – I want to create an improved representation of population density within the city.
This is the population density map I start out with:
… and this is the Corine Land Cover dataset for the same area:
It shows built-up areas (red), parks and natural areas (green) as well as water-covered regions (blue). For further analysis, I follow the assumption that people only live in areas with Corine code 111 “Continuous urban fabric” and 112 “Discontinuous urban fabric”. Therefore, I use the Intersection tool to clip only these residential areas from the subdistrict polygons. The subdistrict population can now be distributed over these new, smaller areas (use Field Calculator) to create a more realistic visualization of population density:
For easier comparison, I put the original density and the dasymetric map into a looping animation. Some subdistricts change their population density values quite drastically, especially in regions where big parts covered by water or rail infrastructure were removed:
Corine Land Cover is not too detailed but I think it still usable on this scale. One thing to note is that I used data from 2006 with population data from 2012 so some areas in the outer districts will have been turned residential in the meantime. But I hope this doesn’t distort the overall picture too much.
We should be able to join on ZBEZ and SUB_DISTRICT_CODE, check! But what about the actual population counts? Unfortunately, there is no file which simply lists population per subdistrict. The file I found contains four lines for each subdistrict: females 2011, males 2011, females 2012 and males 2012. That’s not the perfect format for mapping general population density.
A quick way to prepare our input data is applying pivot tables, eg. in Open Office: The goal is to have one row per subdistrict and columns for population in 2011 and 2012:
Export as CSV, add CSVT and load into QGIS. Finally, we can join geometries and CSV table:
A quick look at the joined data confirms that each subdistrict now has a population value. But visualizing absolute values results in misleading maps. Big subdistricts with only average density will overrule smaller but much denser subdistricts:
That’s why we need to calculate population density. This is easy to do using Field Calculator. The subdistrict file already contains area values but even if they were missing, we could calculate it using the $area operator:
"pop2012" / ($area / 10000). The resulting population density in population per ha finally shows which subdistricts are the most densely populated:
One could argue that this is still no accurate representation of population density: Big parts of some subdistricts are actually covered by water – especially along the Danube – and therefore uninhabited. There are also big parks which could be excluded from the subdistrict area. But that’s going to be the topic of another post.
If you want to use my results so far, you can download the GeoJSON file from Github.
Today, I’ve finished my submission for the Hubway Data Visualization Challenge. All parts of the resulting dataviz were created using open source tools. My toolbox for this work contains: QGIS, Spatialite, Inkscape, Gimp and Open Office Calc. To see the complete submission and read more about it, check the project page.
QGIS Cloud is a great cloud hosting service for QGIS Server by Sourcepole. After online registration and installation of an (experimental) plugin, QGIS projects can be uploaded to the cloud quite comfortably.
For a quick test, I tried to recreate the map from “Open Data for Physical Maps”. Right now, one of the limitations is that raster layers cannot be uploaded. Instead of the SRTM data, I therefore chose OCM landscape from OpenLayers plugin to provide some hillshade. The process of uploading data and publishing the project went smoothly and I didn’t encounter any problems.
You can explore the map online at qgiscloud.com/anitagraser/corine_austria.
Considering the complexity of the Corine dataset, rendering is quite fast – certainly much better than on my notebook.
Corine Land Cover is a European program to create a land cover inventory of Europe. The data is freely available and a valuable input for many analyses. In this post, we’ll be using it to create a physical map.
For the background, reused the hillshade presented in “Mapping Open Data With Open GIS”
Instead of the standard grayscale, I defined a sand-colored colormap that looks warmer and more natural:
On top of this hillshade, I put the Corine land cover layer. Instead of the official, rather bright colors I selected a more neutral color palette and varying transparency values: Water areas are drawn with no transparency while forests are set to 50 % and built-up areas to up to 80 % transparency. I also skipped classes such as “bare rock” by setting them to be totally transparent:
On top of the land cover, I added a river dataset and styled it with the same color used for water surfaces in the Corine layer. Obviously, this is an optional step. Big rivers are visible within the land cover data too.
After adding a mask and labels, the map is ready to add the finishing touches in Print Composer: Title, explanatory text and a scale bar. I decided against adding a legend to this particular map since I hope that the color choices are intuitive enough.
If you want to create your own physical map, you can use Corine Land Cover for European regions or the National Vegetation Classification in the U.S.
This post explores some cartographic features of QGIS while mapping the river network of Tirol, Austria. All data used is freely available.
For the background, I downloaded NASA SRTM elevation data from CGIAR-CSI and created a hillshade using Terrain Analysis tools in QGIS 1.8.
To emphasize both state borders and the fact that Tirol consists of two separate areas, I created a mask using the Difference tool and styled it a transparent white.
The river network is too dense to label all rivers on an A4 map. Expression-based labels make it possible to only label selected features. For this dataset, the expression limits labeling to features with certain values of GEW_WRRL attribute:
CASE WHEN (GEW_WRRL = '10.000 km2 Fluss' OR "GEW_WRRL"= '4.000 km2 Fluss' OR "GEW_WRRL"='1.000 km2 Fluss') AND length("GEW_NAME_A") < 10 THEN "GEW_NAME_A" END
Labels of neighboring areas together with map title, descriptions and scale bar were added in Print Composer.
Working with Print Composer, it is useful to know that you can use Copy&Paste to duplicate map components and right-click to lock them from being moved. Also, every new component by default comes with a black outline and white background which can (and should) be disabled/changed in “General options”.
This is the final QGIS Print Composer output – without any further post-processing in Inkscape or Gimp:
This is a follow up post on “Guide to Advanced Labeling for OSM Roads”. This post covers how to create a map that looks similar to the classic Google Maps map based on OSM data.
Styling OSM road data is a bit tricky due to the many different possible options in OSM “type” tag. It takes some fiddling around to get results similar to Google. The easiest way to create such a style is using rule-based renderer with “Symbol levels” enabled.
I’ve excluded a number of road types from being rendered and labeled. This is done by NOT specifying a rule that fits those classes. That’s the reason why I don’t have a “no filter” rule. Instead, I’ve specified
type NOT IN ('footway','footpath','steps','cycleway','pedestrian','track','bridleway')
to cover all the roads I don’t want specifically highlighted but displayed using default style. This way I can make sure that footways and similar are neither drawn nor labeled.
Now, we can have a look at how to create those road shields Google uses:
Currently, it’s not possible to solve this using the labeling engine. And even after labels with “shields” will be implemented, there is still the problem that we want both road names and road numbers labeled – preferably without having to duplicate the layer.
For now, one possible solution for this is to create the shields using the “Marker lines” feature of new symbology. As the name suggests, you can put markers on lines. In this case, the marker will be our road shield. It basically has two parts: the colored shield plus the text. The shield can be created by putting two squares besides each other. (Adjust the offsets to move them besides each other.) Then we can put the text on top, one letter at a time.
Place the marker on the line once and deactivate “Rotate marker”.
These styles can be assigned to every road you want to decorate with a shield. If you save the style, you just need to change the text next time.
And this is how the result can look like.
Maybe the shields turned out a little too big compared with the original.
Zoomed in, more labels will be displayed and an additional layer with metro stations becomes visible. The metro symbol was created using the same technique described for the road shields.
One disadvantage of creating road shields with this technique – besides the fact that it’s rather tedious – is that there is no collision detection between labels and shields. Nonetheless, it’s a viable solution that allows you to create high-resolution maps that look very similar to Google Maps using free OSM data.
Advanced labeling in QGIS new labeling engine is mostly about data-defined settings. Almost any property of the label can be controlled.
For this example, we will try to mimic the look of the classic Google map with it’s line and label styles. The data for this post is from the OpenStreetMap project provided as Shapefiles by Cloudmade.
After importing the roads into PostGIS using PostGIS Manager Plugin, we can create a view that will contain the necessary label style information. The trick here is to use CASE statements to distinguish between different label “classes”. Motorway labels will be bigger than the rest and the buffer color will be the same color as used for the corresponding lines.
DROP VIEW IF EXISTS v_osm_roads_styled; CREATE VIEW v_osm_roads_styled AS SELECT *, CASE WHEN type = 'motorway' THEN 9 ELSE 8 END as font_size, 'black'::TEXT as font_color, false as font_bold, false as font_italic, false as font_underline, false as font_strikeout, false as font_family, 1 as buffer_size, CASE WHEN type = 'motorway' THEN '#fb9139'::TEXT WHEN type IN ( 'primary','primary_link','secondary','secondary_link') THEN '#fffb8b'::TEXT ELSE 'white'::TEXT END as buffer_color FROM osm_roads;
In QGIS, we can then load the view and start styling. First, let’s get the line style ready. Using rule-based renderer, it’s easy to create complex styles. In this case, I’ve left it rather simple and don’t distinguish between different zoom levels. That’s a topic for another post :)
Now for the labels! In “Data defined settings”, we can assign the special attributes created in the database view to the settings.
To achieve an even better look, go to “Advanced” tab and enable “curved” and “on line” placement. “Merge connected lines to avoid duplicate labels” option is very helpful too.
Finally – after adding some water objects (Cloudmade natural.shp) – this is what our result looks like:
This solution can be improved considerably by adding multiple zoom levels with corresponding styles. One obvious difference between the original Google map and this look-alike is the lack of road numbers. Tim’s post on “shield labels” can be a starting point for adding road numbers the way Google does.