Page 1 of 58 (1155 posts)

  • talks about »

Tags

Last update:
Tue Sep 2 09:00:09 2014

A Django site.

QGIS Planet

Scottish QGIS User Group – 21 October, Edinburgh

The next QGIS user group meeting in Scotland is happening on 21st October 2014.
It is being held in the School of Informatics at Edinburgh University.  For more info about the venue: http://www.ed.ac.uk/schools-departments/informatics/about/location

This is your chance to offer a short talk or presentation or workshop so we can build an exciting programme for the day.  The final programme and agenda will be released closer to the date.  Please let me know through the contact form or comments or twitter (@mixedbredie) if you have a presentation or talk you would like to share.

Ross


WMS Legend Plugin for Leaflet

This weekend I was updating our map gallery at http://maps.kartoza.com and I wanted to have WMS legends in my maps. The maps are mostly generated using QGIS server which also produces a nice looking graphic for its getLegendGraphic requests. Since Leaflet does not seem have a legend control out of the box, I wrote a small leaflet plugin to do it.

Leaflet WMS Legend Plugin

In the future I may extend the control to automatically fetch getLegendGraphics from all loaded WMS layers, but for now it simply takes a complete legend graphic URI as parameter.

Leaflet is a great web mapping client and extending it with little plugins is very easy to do. If you want to use the plugin I wrote, head over to the plugin repository and give it a try!

Sourcepole Kursprogramm Herbst 2014

Im November 2014 bietet Sourcepole wieder sein kompetentes Kursprogramm rund um alle GDI Komponenten an. Zu allen Kursen gehört umfangreiches Kursmaterial, Mittagessen und Kaffepausen. Bei Buchung eines Grundkurses und dem darauf folgenden Aufbaukurs erhalten die Teilnehmer Rabatt auf den Kurspreis.

Geo-Datenbank:

  • PostgreSQL / PostGIS Einführung (3. - 4. November 2014)
  • PostgreSQL / PostGIS für Fortgeschrittene (5. November 2014)

Desktop GIS

  • QGIS 2.4 / Enterprise Desktop Grundkurs (10. - 11. November 2014)
  • QGIS 2.4 / Enterprise Desktop für Power User (12. November 2014)

GDI

  • Verteilte GDI mit der QGIS Suite und PostgreSQL (20. November 2014)

QGIS Programmierung

  • QGIS 2.4 / Enterprise Plugin Entwicklung mit PyQt4 und PyQGIS (17. - 18. November 2014)

Informationen zu den Kursen und die Online Anmeldung finden Sie im Kursprogramm

Wir freuen uns darauf Sie in Zürich begrüssen zu können.

Fundraising for Eloise and Heartfelt

The death of our daughter was one of the hardest things my wife and I have ever had to deal with. It's not something that I wish anyone ever have to experience and feel really sorry for those who have had to do it many times. There is something really raw about lossing your own flesh and blood. It cuts deep, really really deep. There are really no words to describe the emptiness that you feel, or the feelings that follow after the event. Even with all the pain of lossing a child there is a great Australian service that helps to capture some of the final monents. The service is called Heartfelt and we used them for Elly.

Heartfelt is a great free service that provides a photo session, including editing and prints (hard and digital) after, in the last and final days. This is the quote from their site:

Heartfelt is a volunteer organisation of professional photographers from all over Australia dedicated to giving the gift of photographic memories to families that have experienced stillbirths, premature births, or have children with serious and terminal illnesses.

Heartfelt is dedicated to providing this gift to families in a caring, compassionate manner.

All services are provided free of charge

Pretty impressive stuff. The last thing you want to have to do in a time like that is shell out for photos when you have other pressing issues.

As Elly's 1st Birthday is coming in up October Stace and I would love to raise enough money to donate a camera pack to a hospital though Heartfelt in Elly's name. We have created a fundraiser page in her name at: http://www.mycause.com.au/page/79669/eloises1stbirthdayheartfelt in order collect dontations for anyone who would like to help.

Camera packs can be donated to a hospital to allow staff at the hospital to capture photos if Heartfelt can't make it. The bonus is that Heartfelt will still edit and print the photos. How bloody awesome is that! More info on the camera packs is at: http://www.mycause.com.au/page/79669/eloises1stbirthdayheartfelt

We would be greatful for any donations, big or small, so we can donate a camera pack in Elly's name.

We love and miss you a lot Eloise.

5 meter elevation model of Vienna published

A while ago I wrote about the 5 meter elevation model of the city of Vienna. In the meantime the 5 meter model has been replaced by a 10 meter version.

For future reference, I’ve therefore published the 5 meter version on opendataportal.at.

details from the Viennese elevation model

details of the Viennese elevation model

I’ve been using the dataset to compare it to EU-DEM and NASA SRTM for energy estimation:
A. Graser, J. Asamer, M. Dragaschnig: “How to Reduce Range Anxiety? The Impact of Digital Elevation Model Quality on Energy Estimates for Electric Vehicles” (2014).

I hope someone else will find it useful as well because assembling the whole elevation model was quite a challenge.

mosaicking the rasterized WFS responses

mosaicking the rasterized WFS responses


Rendering a brain CT scan in 3D with GRASS GIS 7

brainscan1Last year (2013) I “enjoyed” a brain CT scan in order to identify a post-surgery issue – luckily nothing found. Being in Italy, like all patients I received a CD-ROM with the scan data on it: so, something to play with! In this article I’ll show how to easily turn 2D scan data into a volumetric (voxel) visualization.

The CT scan data come in a DICOM format which ImageMagick is able to read and convert. Knowing that, we furthermore need the open source software packages GRASS GIS 7 and Paraview to get the job done.

First of all, we create a new XY (unprojected) GRASS location to import the data into:

# create a new, empty location (or use the Location wizard):
grass70 -c ~/grassdata/brain_ct

We now start GRASS GIS 7 with that location. After mounting the CD-ROM we navigate into the image directory therein. The directory name depends on the type of CT scanner which was used in the hospital. The file name suffix may be .IMA.

Now we count the number of images, convert and import them into GRASS GIS:

# list and count
LIST=`ls -1 *.IMA`
MAX=`echo $LIST | wc -w`

# import into XY location:
curr=1
for i in $LIST ; do

# pretty print the numbers to 000X for easier looping:
curr=`echo $curr | awk ‘{printf “%04d\n”, $1}’`
convert “$i” brain.$curr.png
r.in.gdal in=brain.$curr.png out=brain.$curr
r.null brain.$curr setnull=0
rm -f brain.$curr.png
curr=`expr $curr + 1`

done

At this point all CT slices are imported in an ordered way. For extra fun, we can animate the 2D slices in g.gui.animation:

Animation of brain scan slices
(click to enlarge)

# enter in one line:
g.gui.animation rast=`g.mlist -e rast separator=comma pattern=”brain*”`

The tool allows to export as animated GIF or AVI:

Animation of brain scan slices (click to enlarge)

Now it is time to generate a volume:

# first count number of available layers
g.mlist rast pat=”brain*” | wc -l

# now set 3D region to number of available layers (as number of depths)
g.region rast=brain.0003 b=1 t=$MAX -p3

At this point the computational region is properly defined to our 3D raster space. Time to convert the 2D slices into voxels by stacking them on top of each other:

# convert 2D slices to 3D slices:
r.to.rast3 `g.mlist rast pat=”brain*” sep=,` out=brain_vol

We can now look at the volume with GRASS GIS’ wxNVIZ or preferably the extremely powerful Paraview. The latter requires an export of the volume to VTK format:

# fetch some environment variables
eval `g.gisenv -s`
# export GRASS voxels to VTK 3D as 3D points, with scaled z values:
SCALE=2
g.message “Exporting to VTK format, scale factor: $SCALE”
r3.out.vtk brain_vol dp=2 elevscale=$SCALE \
output=${PREFIX}_${MAPSET}_brain_vol_scaled${SCALE}.vtk -p

Eventually we can open this new VTK file in Paraview for visual exploration:

# show as volume
# In Paraview: Properties: Apply; Display Repres: volume; etc.
paraview –data=brain_s1_vol_scaled2.vtk

markus_brain_ct_scan3 markus_brain_ct_scan4 markus_brain_ct_scan2

 

 

 

 

 

 

 

 

 

 

 

 

Fairly easy!

BTW: I have a scan of my non-smoker lungs as well :-)

The post Rendering a brain CT scan in 3D with GRASS GIS 7 appeared first on GFOSS Blog | GRASS GIS Courses.

QGIS Layer Tree API (Part 2)

In the first part we have covered how to access the project’s layer tree and read the data stored in the tree. Now let’s focus on building layer trees and manipulating with them. We will also have a look at how to receive updates about changes within a layer tree.

In an empty project, first we will get access to the layer tree and create some memory layers for testing:

root = QgsProject.instance().layerTreeRoot()

layer1 = QgsVectorLayer("Point", "Layer 1", "memory")
layer2 = QgsVectorLayer("Polygon", "Layer 2", "memory")

Adding Nodes

Now let’s add some layers to the project’s layer tree. There are two ways of doing that:

  1. Explicit addition. This is done with addLayer() or insertLayer() call of QgsLayerTreeGroup class. The former one appends to the group node, while the latter allows you to specify index at which the layer should be added.

    # step 1: add the layer to registry, False means do not add to layer tree
    QgsMapLayerRegistry.instance().addMapLayer(layer1, False)
    # step 2: append layer to the root group node
    node_layer1 = root.addLayer(layer1)
    
  2. Implicit addition. Project’s layer tree is connected to the layer registry and listens to the additions and removals of layers. When a layer is added to the registry, it will automatically be added to the layer tree. It is therefore enough to add a layer to the map layer registry (leaving the second argument with default value True):

    QgsMapLayerRegistry.instance().addMapLayer(layer1)
    

    This behaviour is facilitated by QgsLayerTreeRegistryBridge class. By default it inserts layers at the first position of the root node. The insertion point for new layers can be changed – within QGIS application the insertion point is updated whenever the current selection in layer tree view changes.

Adding groups is done with addGroup() or insertGroup() calls of QgsLayerTreeGroup class:

node_group1 = root.insertGroup(0, "Group 1")
# add another sub-group to group1
node_subgroup1 = node_group1.addGroup("Sub-group 1")

There are also general addChildNode(), insertChildNode() and insertChildNodes() calls that allow addition of existing nodes:

QgsMapLayerRegistry.instance().addMapLayer(layer2, False)

node_layer2 = QgsLayerTreeLayer(layer2)
root.insertChildNode(0, node_layer2)

node_group2 = QgsLayerTreeGroup("Group 2")
root.addChildNode(node_group2)

Nodes that are being added must not have any parent yet (i.e. being part of some layer tree). On the other hand, the nodes that get inserted may already have children, so it is possible to create a whole sub-tree and then add it at once to the project’s layer tree.

Removing Nodes

Removal of nodes from a layer tree is always done from parent group node. For example, nodes displayed as top-level items need to be removed from root node. There are several ways how to remove them. The most general form is to use removeChildren() method that takes two arguments: index of the first child node to be removed and how many child nodes to remove. Removal of a group node will cause all its children to be removed, too.

There are several convenience methods for removal:

root.removeChildNode(node_group2)

root.removeLayer(layer1)

If a layer tree is used with QgsLayerTreeRegistryBridge (which is true for project’s layer tree), there is also implicit removal of layer nodes of map layers from layer tree that get removed from the map layer registry.

Moving Nodes

When managing layer tree, it is often necessary to move some nodes to a different position – within the same parent node or to a different parent node (group). Moving a node is done in three steps: 1. clone the existing node, 2. add cloned node to desired place in layer tree, 3. remove the original node. The following code assumes that the existing node we move is child of the root node:

cloned_group1 = node_group1.clone()
root.insertChildNode(0, cloned_group1)
root.removeChildNode(node_group1)

Modifying Nodes

There are several operations one can do with nodes:

  1. Rename. Both group and layer nodes can be renamed. For layer nodes this will modify the name directly inside the map layers.

    node_group1.setName("Group X")
    node_layer2.setLayerName("Layer X")
    
  2. Change visibility. This is actually a check state (checked or unchecked, for group nodes also partially checked) that is associated with the node and normally it is related to visibility of layers and groups in map canvas. In GUI, the layer tree view is capable of showing a check box for changing the state.

    print node_group1.isVisible()
    node_group1.setVisible(Qt.Checked)
    node_layer2.setVisible(Qt.Unchecked)
    
  3. Change expanded state. The boolean expanded/collapsed state refers to how the node should be shown in layer tree view in GUI, whether its children should be shown or hidden.

    print node_group1.isExpanded()
    node_group1.setExpanded(False)
    
  4. Change custom properties. Each node may have some custom properties associated with it. The properties are key-value pairs, keys being strings, values being variant type (QVariant). They can be used by other components of QGIS or plugins to store some additional data. Custom properties are kept when a layer tree is saved and loaded.

    Use customProperties() call to get a list of keys of custom properties, then customProperty() method for getting value of particular key. For modification of the properties, there is setCustomProperty() method to set a key-value pair and removeCustomProperty() to remove a pair.

    node_group1.setCustomProperty("test_key", "test_value")
    print node_group1.customProperties()
    print node_group1.customProperty("test_key")
    node_group1.removeCustomProperty("test_key")
    print node_group1.customProperties()
    

Signals from Nodes

There are various signals emitted by nodes which may be used by client code to follow changes to the layer tree. Signals from children are automatically propagated to their parent node, so it is enough to connect to the root node to listen changes from any level of the tree.

Modification of Layer Tree Structure

Addition of new nodes always emits a pair of signals – before and after the actual addition. Signals pass information about which node is the parent node and the range of child indices:

  • willAddChildren(node, indexFrom, indexTo)
  • addedChildren(node, indexFrom, indexTo)

In order to be able to access the newly added nodes, it is necessary to use addedChildren signal.

The following code sample illustrates how to connect to signals emitted from layer tree. when the last line is executed, two lines from the newly defined methods should be printed to the console:

def onWillAddChildren(node, indexFrom, indexTo):
  print "WILL ADD", node, indexFrom, indexTo
def onAddedChildren(node, indexFrom, indexTo):
  print "ADDED", node, indexFrom, indexTo

root.willAddChildren.connect(onWillAddChildren)
root.addedChildren.connect(onAddedChildren)

g = root.addGroup("My Group")

Removal of nodes is handled in a very similar manner to the addition – there is also a pair of signals:

  • willRemoveChildren(node, indexFrom, indexTo)
  • removedChildren(node, indexFrom, indexTo)

This time in order to access nodes being removed it is necessary to connect to willRemoveChildren signals.

Modification of Tree Nodes

There are few more signals that allow monitoring of internal changes of nodes:

  • node gets checked or unchecked: visibilityChanged(node, state)
  • node’s custom property is defined or removed: customPropertyChanged(node, key)
  • node gets expanded or collapsed: expandedChanged(node, expanded)

Summary

We have covered how to make changes to a layer tree structure and how to listen to the changes possibly done by other pieces of code. In a post that will follow we look at how GUI components for display and modification of a layer tree and connection between map canvas and layer tree.

QGIS Layer Tree API (Part 2)

In part 1 we covered how to access the project’s layer tree and read its data. Now let’s focus on building and manipulating layer trees. We’ll also look at how to receive updates about changes within a layer tree.

Starting with an empty project, first we will get access to the layer tree and create some memory layers for testing:

root = QgsProject.instance().layerTreeRoot()

layer1 = QgsVectorLayer("Point", "Layer 1", "memory")
layer2 = QgsVectorLayer("Polygon", "Layer 2", "memory")

Adding Nodes

Now let’s add some layers to the project’s layer tree. There are two ways of doing that:

  1. Explicit addition. This is done with the addLayer() or insertLayer() call of the QgsLayerTreeGroup class. The former appends to the group node, while the latter allows you to specify the index at which the layer should be added.

    # step 1: add the layer to the registry, False indicates not to add to the layer tree
    QgsMapLayerRegistry.instance().addMapLayer(layer1, False)
    # step 2: append layer to the root group node
    node_layer1 = root.addLayer(layer1)
    
  2. Implicit addition. The project’s layer tree is connected to the layer registry and listens for the addition and removal of layers. When a layer is added to the registry, it will be automatically added to the layer tree. It is therefore enough to simply add a layer to the map layer registry (leaving the second argument of addMapLayer() with its default value of True):

    QgsMapLayerRegistry.instance().addMapLayer(layer1)
    

    This behaviour is facilitated by the QgsLayerTreeRegistryBridge class. By default it inserts layers at the first position of the root node. The insertion point for new layers can be changed – within the QGIS application the insertion point is updated whenever the current selection in the layer tree view changes.

Groups can be added using the addGroup() or insertGroup() calls of the QgsLayerTreeGroup class:

node_group1 = root.insertGroup(0, "Group 1")
# add another sub-group to group1
node_subgroup1 = node_group1.addGroup("Sub-group 1")

There are also the general addChildNode(), insertChildNode() and insertChildNodes() calls that allow the addition of existing nodes:

QgsMapLayerRegistry.instance().addMapLayer(layer2, False)

node_layer2 = QgsLayerTreeLayer(layer2)
root.insertChildNode(0, node_layer2)

node_group2 = QgsLayerTreeGroup("Group 2")
root.addChildNode(node_group2)

Nodes that are being added must not have any parent yet (i.e. being part of some layer tree). On the other hand, the nodes that get inserted may already have children, so it is possible to create a whole sub-tree and then add it in one operation to the project’s layer tree.

Removing Nodes

The removal of nodes from a layer tree is always done from the parent group node. For example, nodes displayed as top-level items need to be removed from the root node. There are several ways of removing them. The most general form is to use the removeChildren() method that takes two arguments: the index of the first child node to be removed and how many child nodes to remove. Removal of a group node will also remove all of its children.

There are several convenience methods for removal:

root.removeChildNode(node_group2)

root.removeLayer(layer1)

There is one more way to remove layers from the project’s layer tree:

QgsMapLayerRegistry.instance().addMapLayer(layer1)

The project’s layer tree is notified when any map layers are being removed from the map layer registry and the layer nodes representing affected layers will be automatically removed from the layer tree. This is handled by the QgsLayerTreeRegistryBridge class mentioned earlier.

Moving Nodes

When managing the layer tree, it is often necessary to move some nodes to a different position – within the same parent node or to a different parent node (group). Moving a node is done in three steps: 1. clone the existing node, 2. add the cloned node to the desired place in layer tree, 3. remove the original node. The following code assumes that the existing node we move is a child of the root node:

cloned_group1 = node_group1.clone()
root.insertChildNode(0, cloned_group1)
root.removeChildNode(node_group1)

Modifying Nodes

There are a number of operations one can do with nodes:

  1. Rename. Both group and layer nodes can be renamed. For layer nodes this will modify the name directly inside the map layers.

    node_group1.setName("Group X")
    node_layer2.setLayerName("Layer X")
    
  2. Change visibility. This is actually a check state (checked or unchecked, for group nodes also partially checked) that is associated with the node and normally related to the visibility of layers and groups in the map canvas. In the GUI, the layer tree view is capable of showing a check box for changing the state.

    print node_group1.isVisible()
    node_group1.setVisible(Qt.Checked)
    node_layer2.setVisible(Qt.Unchecked)
    
  3. Change expanded state. The boolean expanded/collapsed state refers to how the node should be shown in layer tree view in the GUI – whether its children should be shown or hidden.

    print node_group1.isExpanded()
    node_group1.setExpanded(False)
    
  4. Change custom properties. Each node may have some associated custom properties. The properties are key-value pairs, keys being strings, values being of variant type (QVariant). They can be used by other components of QGIS or plugins to store additional data. Custom properties are preserved when a layer tree is saved and loaded.

    Use the customProperties() call to get a list of keys of custom properties, then the customProperty() method for getting the value of a particular key. To modify properties, there is a setCustomProperty() method which sets a key-value pair and a removeCustomProperty() method to remove a pair.

    node_group1.setCustomProperty("test_key", "test_value")
    print node_group1.customProperties()
    print node_group1.customProperty("test_key")
    node_group1.removeCustomProperty("test_key")
    print node_group1.customProperties()
    

Signals from Nodes

There are various signals emitted by nodes which may be used by client code to follow changes to the layer tree. Signals from children are automatically propagated to their parent node, so it is enough to connect to the root node to listen for changes from any level of the tree.

Modification of the Layer Tree Structure

The addition of new nodes always emits a pair of signals – before and after the actual addition. Signals pass information about which node is the parent node and the range of child indices:

  • willAddChildren(node, indexFrom, indexTo)
  • addedChildren(node, indexFrom, indexTo)

In order to access the newly added nodes, it is necessary to use the addedChildren signal.

The following code sample illustrates how to connect to signals emitted from the layer tree. When the last line is executed, two lines from the newly defined methods should be printed to the console:

def onWillAddChildren(node, indexFrom, indexTo):
  print "WILL ADD", node, indexFrom, indexTo
def onAddedChildren(node, indexFrom, indexTo):
  print "ADDED", node, indexFrom, indexTo

root.willAddChildren.connect(onWillAddChildren)
root.addedChildren.connect(onAddedChildren)

g = root.addGroup("My Group")

Removal of nodes is handled in a very similar manner to the addition – there is also a pair of signals:

  • willRemoveChildren(node, indexFrom, indexTo)
  • removedChildren(node, indexFrom, indexTo)

This time in order to access nodes being removed it is necessary to connect to the willRemoveChildren signal.

Modification of Tree Nodes

There are a few more signals that allow monitoring of internal changes to nodes:

  • a node is checked or unchecked: visibilityChanged(node, state)
  • a node’s custom property is defined or removed: customPropertyChanged(node, key)
  • a node gets expanded or collapsed: expandedChanged(node, expanded)

Summary

We have covered how to make changes to a layer tree structure and how to listen for changes possibly made by other pieces of code. In a future post we look at GUI components for displaying and modifying the layer tree and the connection between map canvas and layer tree.

How to quickly transform a bounding box from one CRS to another using QGIS

Today I needed to convert a bounding box for a tilemill project that I want to bring into QGIS as a tile layer (more on that in a future post if I get it to work…).  I needed to convert a bounding box from EPSG:4326 (‘Geographic’) coordinates to EPSG:3857 (Spherical Mercator). Fortunately it is a fairly trivial process if you don’t mind writing a few lines of python in the QGIS python console:

box = QgsRectangle(-19.6875,-37.9962,59.0625,37.4400)
source_crs = QgsCoordinateReferenceSystem(4326)
dest_crs = QgsCoordinateReferenceSystem(3857)
transform = QgsCoordinateTransform(source_crs, dest_crs)
new_box = transform.transformBoundingBox(box)
new_box.toString()
u'-2191602.4749925746582448,-4578889.0142234507948160 : 6574807.4249777207151055,4500615.8633687794208527'

 

It really is quite trivial to do arbitrary once-off things in QGIS if you roll up your sleeves and get to grips with the python API!

Training courses calendar: QGIS (Desktop, Server and Web) and PostGIS

We just published our Training Courses calendar for the period September 2014 – January 2015. This includes training courses about QGIS (Desktop, Server and Web) and PostgreSQL/PostGIS in both Italy and Portugal. Training courses about QGIS python programming are available on demand. For details (locations, prices, discounts, etc.) about training courses in Portugal see: http://www.faunalia.eu/pt/training.html […]

Visualizing direction-dependent values

When mapping flows or other values which relate to a certain direction, styling these layers gets interesting. I faced the same challenge when mapping direction-dependent error values. Neighboring cell pairs were connected by two lines, one in each direction, with an associated error value. This is what I came up with:

srtm_errors_1200px

Each line is drawn with an offset to the right. The size of the offset depends on the width of the line which in turn depends on the size of the error. You can see the data-defined style properties here:

directed_error_style

To indicate the direction, I added a marker line with one > marker at the center. This marker line also got assigned the same offset to match the colored line bellow. I’m quite happy with how these turned out and would love to hear about your approaches to this issue.

srtm_errors_detail

These figures are part of a recent publication with my AIT colleagues: A. Graser, J. Asamer, M. Dragaschnig: “How to Reduce Range Anxiety? The Impact of Digital Elevation Model Quality on Energy Estimates for Electric Vehicles” (2014).


Running QGIS desktop in a docker container

I love using docker – I have been tracking and learning docker since soon after it was announced and believe it is going to be a real game changer. I’ve been playing around with the different things one can do in a docker container and of course it is only natural that a ‘QGIS guy’ such as myself would start to think about using docker with QGIS. QGIS server in a docker container seems like a natural fit, but how about QGIS Desktop? Last night Richard Duivenvoorde and I were sitting around drinking tea and we thought we would give it a quick go – in fact it only took about half an hour to get something working….

 

Demo

 

Why?

I guess the first think you may ask is “why would you want to put QGIS desktop in a docker container?”. Well there are actually quite a few good reasons – here is a quick brain dump of reasons why you might want to run QGIS in a docker container:

  • Application sandboxing – keeping QGIS in a docker container means that you can keep it away from your other applications and data and frugally let it use only the resources you choose to. This is a general principle that can apply to any application you run on your desktop.
  • Capitalise on Ubuntu packages on a different host – if you are running CentOS or Arch or some other architecture, you may want to take advantage of the Ubuntu and Ubuntugis packages without trading out your entire OS. Now you can!
  • Running multiple versions of QGIS side by side – I already do this by using some little bash scripts that set paths and do magic before starting QGIS. Docker provides an alternative approach to this where each QGIS version can be in it’s own container.
  • Running different QGIS profiles – Perhaps you want to set up a profile where you have plugins x,y,z available and another where you have plugins a,b,c enabled – you could just create different docker images and launch a container based on the one that you want.
  • Known good deployment  – Setting up a linux with all the little bits and pieces needed to fully use QGIS takes some work and is vulnerable to breaking if you upgrade your OS. If you keep all that work in a docker image, the image will be unaffected by changes on the host system and you can do focussed updates to the image as needed. You can also do this one, publish the container and easily push it to your users in an enterprise environment.
  • Sharing a well integrated QGIS package – I have no love for Windows, but I must say that windows users have it good with the OSGEO4W and standalone installers for QGIS. With docker we could do something similar, where we create a well configured docker image and share it for the world to use…no more fiddling about trying to get stuff to run, just get the latest docker build and run QGIS with confidence knowing everything is set up for you.
  • Testing stuff – Testing is nice when you do it with a clean environment. With docker you can destroy and recreate the container each time you run it, reverting it to a clean state each time.

There are probably a bunch of other good reasons to play with this approach, but the above may be enough to get you curious and play…

Before I show you how to set things up, I should mention there are also some possible downsides:

  • Extra complications – adding docker into your mix is one thing you need to learn and understand – although the approach I show here requires only the most rudimentary understanding.
  • Statelessness – the statelessness of the container needs some extra steps to deal with. e.g. if you install a plugin and then shut down QGIS, when you start it again, it will be gone. Fear note docker volumes allow us to add state.
  • Overhead – Some may argue that running QGIS in a docker container is going to add overhead, making QGIS slower to run. Honestly in my testing I could not notice any difference.

Setting up

Before you can start you need to do a bit of setup and also note that my scripts provided make a few assumptions – you may wish to edit them to meet your needs. First you need to have docker installed on your OS. Under Ubuntu 14.04 you can simply do:

sudo apt-get install docker.io

Next you need to have my Dockerfile ‘recipe’ for building the docker image. It is available on our github repository (patches and improvements welcome!)

sudo apt-get install git
git clone git://github.com/kartoza/docker-qgis-desktop

Now go into the cloned repository and build the image:

cd docker-qgis-desktop
 ./build.sh

Its going to take a little while to build. After it is done, you should have:

  • a new docker image called kartoza/qgis-desktop in your docker images list
  • a launching script in your ~/bin directory
  • a line added to you ~/.bashrc that adds ~/bin to your path
  • A .desktop shortcut file added to ~/.local/share/application

Now reload your desktop (e.g. log out and in again) and look in your applications menu. You should find a new entry called ‘QGIS 2.in Docker’. Click on it and QGIS should launch.

What happens when I click that icon?

When you click the icon, a little script runs that starts up a new docker container, mounts your home directory into it and starts QGIS, sending its windows back to your deskop. Its all pretty seamless and feels like you are just running a locally installed application.

There are still some gotchas here since this is the first version of our script:

  • QGIS runs as root in the docker container which means its probably going to screw up the file permissions of any new file you create.
  • To get the QGIS window to display on your desktop I am using xhost + which some folks might not like
  • Your home folder is mounted into the container, but you won’t be able to see other files elsewhere on the host operating system

What’s next?

Currently we have QGIS 2.4 running in the container. We are going to work on providing the most polished installation possible inside the container. That means adding support for OrpheoToolBox (already added), SAGA, GRASS, MMQGIS, MrSid, ECW, ESRI FGDB etc. etc. that the docker container works ‘batteries included’ out of the box. If you would like to contribute, please consider forking our repo and submitting a pull request!

 

Installing PySAL for OSGeo4W

Today’s post is a summary of how to install PySAL on Windows for OSGeo4W Python.

The most important resource was https://trac.osgeo.org/osgeo4w/wiki/ExternalPythonPackages

In the OSGeo4W Shell run:

C:\Users\anita_000\Desktop>curl http://python-distribute.org/distribute_setup.py | python

Then download https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py to the Desktop and run:

C:\Users\anita_000\Desktop>python get-pip.py

When pip is ready, install PySAL:

C:\Users\anita_000\Desktop>pip install pysal

Test the installation:

C:\Users\anita_000\Desktop>python
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win 32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysal

OSM Toner style town labels explained

The point table of the Spatialite database created from OSM north-eastern Austria contains more than 500,000 points. This post shows how the style works which – when applied to the point layer – wil make sure that only towns and (when zoomed in) villages will be marked and labeled.

Screenshot 2014-07-12 12.30.21

In the attribute table, we can see that there are two tags which provide context for populated places: the place and the population tag. The place tag has it’s own column created by ogr2ogr when converting from OSM to Spatialite. The population tag on the other hand is listed in the other_tags column.

Screenshot 2014-07-12 13.00.15

for example

"opengeodb:lat"=>"47.5000237","opengeodb:lon"=>"16.0334769","population"=>"623"

Overview maps would be much too crowded if we simply labeled all cities and towns. Therefore, it is necessary to filter towns based on their population and only label the bigger ones. I used limits of 5,000 and 10,000 inhabitants depending on the scale.

Screenshot 2014-07-12 12.56.33

At the core of these rules is an expression which extracts the population value from the other_tags attribute: The strpos() function is used to locate the text "population"=>" within the string attribute value. The population value is then extracted using the left() function to get the characters between "population"=>" and the next occurrence of ". This value can ten be cast to integer using toint() and then compared to the population limit:

5000 < toint( 
   left (
      substr(
         "other_tags",
         strpos("other_tags" ,'"population"=>"')+16,
         8
      ),
      strpos(
         substr(
            "other_tags",
            strpos("other_tags" ,'"population"=>"')+16,
            8
         ),
        '"'
      )
   )
) 

There is also one additional detail concerning label placement in this style: When zoomed in closer than 1:400,000 the labels are placed on top of the points but when zoomed out further, the labels are put right of the point symbol. This is controlled using a scale-based expression in the label placement:

Screenshot 2014-07-12 13.32.47

As usual, you can find the style on Github: https://github.com/anitagraser/QGIS-resources/blob/master/qgis2/osm_spatialite/osm_spatialite_tonerlite_point.qml


Multiple map grids in the QGIS print composer

In printed maps, having several coordinate grids over one map is a very usefull feature. For instance using a meter system as output CRS, it is nice to display a latitude / longitude grid as well. Until now, the QGIS print composer allowed only one coordinate grid per composer map and it was restricted to the map output CRS.

Having that multigrid / multiCRS feature in QGIS Enterprise since 13.04 already, I’ve recently found the time to port it into the QGIS developer version. Therefore it will be part of the upcoming version 2.6 in October. The screenshot below shows how it can be used to add a wgs84 grid onto a meter map. In the composermap widget, grids can be added / removed and reordered. Additionally there is now a CRS selection button to select the coordinate system for the grid. The development of this feature has been kindly funded by Canton of Solothurn (Switzerland).

Using QGIS processing scripts

One of the area’s that QGIS is constantly improving is the ‘Processing framework’, Formerly known as the sextante framework and written in java, it is rewritten in Python by one of the original authors Victor Olaya and made part of QGIS since about QGIS 2.0. I think it is VERY usefull and in use a […]

QGIS Layer Tree API (Part 1)

This blog post will be about the QGIS component responsible for showing the list of layers. In the QGIS project we typically call this component the “legend widget”. People used to other GIS software may also use other names such as “table of contents (ToC)”.

Layers in the legend widget can be organised into groups. This grouping allows easier manipulation of layers. For example it is possible to toggle the visibility of all layers at once. In addition to layers, groups can also contain other groups, effectively creating a hierarchy of groups and layers. From now on, we will refer to this hierarchy as the layer tree.

The legend widget might look like this:

QGIS Legend Widget

Until QGIS 2.4, there has been only limited support for interacting with the legend widget using the QGIS API. There is a QgsLegendInterface class (which can be obtained with iface.legendInterface()) available for plugins. The legend interface has emerged in an ad-hoc way, leading to various issues when used in plugins. It is also worth noting that third-party applications based on QGIS have no access to the legend interface.

Layer Tree API

The layer tree API has been introduced in QGIS 2.4 to overcome these existing problems and add even more flexibility to the way the layer tree can be queried or modified.

The layer tree is a classical tree structure built of nodes. There are currently two types of nodes: group nodes and layer nodes. Group nodes can contain other (child) nodes, while layer nodes are ‘leaves’ of the tree, without any child nodes. The layer tree for the legend widget shown in the picture above looks like this:

Layer Tree Structure

The green nodes are group nodes (QgsLayerTreeGroup class) and the yellow nodes are layer nodes (QgsLayerTreeLayer class).

The legend widget also displays items using symbols, making it look like a real legend. The symbology is not part of the layer tree and will be discussed in an upcoming post.

To start working with the layer tree, we first need a reference to its root node. The project’s layer tree can be accessed easily:

root = QgsProject.instance().layerTreeRoot()

The root node is a group node – its children are shown as top-level items in the legend widget.

print root
print root.children()

This returns a list of the children of a node. The list includes only direct children – children of sub-groups need to be queried directly from those sub-groups.

Now let’s try to access the first child node in the tree and do a little bit of introspection:

child0 = root.children()[0]
print child0
print type(child0)
print isinstance(child0, QgsLayerTreeLayer)
print child0.parent()

With the children() and parent() methods it is possible to traverse the layer tree. A node is the root node of a tree if it has no parent:

print root.parent()

The following example shows how to list top-level items of the layer tree. For group nodes it will print the group name, for layer nodes it will print the layer name and ID.

for child in root.children():
  if isinstance(child, QgsLayerTreeGroup):
    print "- group: " + child.name()
  elif isinstance(child, QgsLayerTreeLayer):
    print "- layer: " child.layerName() + "  ID: " + child.layerId()

In order to traverse the full layer tree, it would be necessary to recursively call the same code for sub-groups.

There are some helper routines for common tasks like finding nodes representing layers in the tree. These take into account all descendants, not just top-level nodes.

ids = root.findLayerIds()
print ids
print root.findLayers()
print root.findLayer(ids[0])

It is assumed that a single layer is represented in a layer tree only once. There may however be temporary situations when a layer is represented by more than one node, for example when moving nodes (a new node is created before the old one is removed shortly after).

Similarly it is possible to search for group nodes by name:

print root.findGroup("POI")

Group names are not necessarily unique – if there are multiple groups with the same name, the first encountered during tree traversal will be returned.

Summary

In this blog post we have shown how to query the project’s layer tree. Upcoming blog entries will focus on modifying the layer tree and interacting with other parts of QGIS.

QGIS Layer Tree API (Part 1)

This blog post will be about the QGIS component responsible for showing the list of layers. In the QGIS project we typically call this component the “legend widget”. People used to other GIS software may also use other names such as “table of contents (ToC)”.

Layers in the legend widget can be organised into groups. This grouping allows easier manipulation of layers. For example it is possible to toggle the visibility of all layers at once. In addition to layers, groups can also contain other groups, effectively creating a hierarchy of groups and layers. From now on, we will refer to this hierarchy as the layer tree.

The legend widget might look like this:

QGIS Legend Widget

Until QGIS 2.4, there has been only limited support for interacting with the legend widget using the QGIS API. There is a QgsLegendInterface class (which can be obtained with iface.legendInterface()) available for plugins. The legend interface has emerged in an ad-hoc way, leading to various issues when used in plugins. It is also worth noting that third-party applications based on QGIS have no access to the legend interface.

Layer Tree API

The layer tree API has been introduced in QGIS 2.4 to overcome these existing problems and add even more flexibility to the way the layer tree can be queried or modified.

The layer tree is a classical tree structure built of nodes. There are currently two types of nodes: group nodes and layer nodes. Group nodes can contain other (child) nodes, while layer nodes are ‘leaves’ of the tree, without any child nodes. The layer tree for the legend widget shown in the picture above looks like this:

Layer Tree Structure

The green nodes are group nodes (QgsLayerTreeGroup class) and the yellow nodes are layer nodes (QgsLayerTreeLayer class).

The legend widget also displays items using symbols, making it look like a real legend. The symbology is not part of the layer tree and will be discussed in an upcoming post.

To start working with the layer tree, we first need a reference to its root node. The project’s layer tree can be accessed easily:

root = QgsProject.instance().layerTreeRoot()

The root node is a group node – its children are shown as top-level items in the legend widget.

print root
print root.children()

This returns a list of the children of a node. The list includes only direct children – children of sub-groups need to be queried directly from those sub-groups.

Now let’s try to access the first child node in the tree and do a little bit of introspection:

child0 = root.children()[0]
print child0
print type(child0)
print isinstance(child0, QgsLayerTreeLayer)
print child0.parent()

With the children() and parent() methods it is possible to traverse the layer tree. A node is the root node of a tree if it has no parent:

print root.parent()

The following example shows how to list top-level items of the layer tree. For group nodes it will print the group name, for layer nodes it will print the layer name and ID.

for child in root.children():
  if isinstance(child, QgsLayerTreeGroup):
    print "- group: " + child.name()
  elif isinstance(child, QgsLayerTreeLayer):
    print "- layer: " child.layerName() + "  ID: " + child.layerId()

In order to traverse the full layer tree, it would be necessary to recursively call the same code for sub-groups.

There are some helper routines for common tasks like finding nodes representing layers in the tree. These take into account all descendants, not just top-level nodes.

ids = root.findLayerIds()
print ids
print root.findLayers()
print root.findLayer(ids[0])

It is assumed that a single layer is represented in a layer tree only once. There may however be temporary situations when a layer is represented by more than one node, for example when moving nodes (a new node is created before the old one is removed shortly after).

Similarly it is possible to search for group nodes by name:

print root.findGroup("POI")

Group names are not necessarily unique – if there are multiple groups with the same name, the first encountered during tree traversal will be returned.

Summary

In this blog post we have shown how to query the project’s layer tree. Upcoming blog entries will focus on modifying the layer tree and interacting with other parts of QGIS.

QGIS – Mapping Election Results, pt 2: Adding and overlaying the data in QGIS

Continuing on from the previous tutorial:-

Return to QGIS. Add the westminster_const_region.shp file if necessary

  1. Press the Add Delimitated Text file button, and select the .csv export of the cleansed electoral data
  2. The two options I changed from the default settings are:-
  • First record contains field names
  • No geometry (attribute only table)
QGIS - Create layer from text file

QGIS – Create layer from text file

Step 3 – Joining the data

Joining the polygons in westminster_const_region.shp to the data imported from the Results_Cleansed spreadsheet will allow the data to be presented in a spatial and visual format which will be much easier to interpret, allow for spatial analysis and also give the viewer an idea of the geographic spread. Using QGIS’ Join function will hopefully save a lot of copying and pasting!

Right click on westminster_const_region.shp and select Properties to open the Properties dialog

  • Select the Joins button from the left panel
  • Join Layer – the layer that you want to join to
  • Join Field – the field that you want to join to
  • Target Field – the field in this layer that contains the matching data
QGIS - Add vector layer

QGIS – Add vector layer

The join will now appear in the layer’s Joins list:-

QGIS layer properties

QGIS layer properties

The attribute table will now show the combined  data for both layers:-

QGIS attribute table

QGIS attribute table

This data can now be used to create a thematic map that colours each constituency according to party that won the seat in 2010.

I won’t go through all the steps of creating a thematic map as an earlier tutorial does this.

I’ve used the same colours that the different parties in the UK use:-

QGIS Layer properties

QGIS Layer properties

The thematic map shows the results across the entire UK. It is easy to identify patterns in the result, for example

  • The Liberal Democrats mostly won seats in Scotland, the North East, Wales and South West.
  • There is strong Labour support in South West Scotland, North West England, West Midlands, South Wales, London, Liverpool and Manchester.
  • The Conservative support covers much of the rest of England, especially South East England, excluding London.
2010 election results map

2010 election results map


Using a GPS dongle with QGIS (Linux)

Because I had this GPS dongle laying on my table, I figured I had to find out how to connect this via usb or bluetooth to my Debian Laptop so I could use it with QGIS. Read the full article here www.zuidt.nl.

  • Page 1 of 58 ( 1155 posts )
  • >>

Back to Top

Sponsors