Did you know that there is a version of ColorBrewer that does not require Flash?
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 to my recent “Natural Earth Quick Start Kit” post in which I presented the great quick start kit provided by the Natural Earth team. The QGIS project file they provide was written in QGIS 1.4 with both old symbology and old labeling:
Since then a lot has changed. QGIS has a new powerful labeling engine which avoids label collisions and more advanced layer symbology. If that’s not reason enough to switch, it is also worth noting that both old systems will most certainly be removed for QGIS 2.0 release. Luckily, switching is pretty easy:
In QGIS 1.7.4, switching to new symbology is very straight forward: Click the “new symbology” button in the upper right corner of the style tab and confirm the popup message. That’s it.
Changing from old to new labeling is less automated. It will help if you take notes about font, size and colors as well as scale ranges before deactivating labeling in layer properties. Enable new labeling from the labeling toolbar and fill in the settings you have written down.
One of the known issues with new labeling is that it is currently not possible to rotate the labels without also specifying the label position. In most projects, this won’t be an issue though.
Besides switching to the new infrastructure, I’ve applied some minor changes to increase readability:
I’ve uploaded the new project file version to QGIS Ressources on Github if you want to give it a try.
This week Sourcepole released a new addition to the Raster Terrain Analysis plugin: a sophisticated Relief tool. (More info in their announcement) This plugin is shipped with QGIS (developer version, not in 1.7.3 release) by default but you might have to activate it in Plugin Manager:
The plugin dialog is quite self-explanatory. You can chose the elevation file, output path and any of the numerous raster formats. The z factor is a bit more mysterious. We will have a look at that in a second. The rest of the dialog is the relief color editor. Pressing Create automatically will give you a color gradient to start with.
But what’s the z factor good for?
I’ve tried a few different settings using free NASA SRTM data and it seems that higher values lead to a smoother relief (Please ignore the water areas):
As Marco noted in the comments: The z factor is used if the x/y units are different from the z unit.
In the example above SRTM rasters are in WGS84 with heights in meters. That’s why the result using a z factor of 100000 looks so good.
In my opinion the results look great even with the coarse SRTM dataset I used. Looking forward to all the great QGIS maps we will see in the future.
Powered by Django!