Page 1 of 2 (28 posts)

  • talks about »
  • geospatial

Tags

Last update:
Thu May 5 11:05:14 2016

A Django site.

QGIS Planet

Exploring variables in QGIS pt 3: layer level variables

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).

Some background

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:

  1. The global scope, consisting of variables set in the QGIS options dialog, and other installation-wide properties
  2. 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)
  3. composer scope, with any variables set for the current composer, plus variables for @layout_pagewidth, @layout_pageheight, @layout_numpages, etc.
  4. 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:

overridden

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:

  1. The global scope
  2. The project scope
  3. map settings scope, with variables relating to how the map is being rendered. Eg @map_rotation, @map_scale, etc
  4. 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:

  1. The global scope
  2. The project scope
  3. The composer scope
  4. An atlas scope, if atlas is enabled. This contains variables like @atlas_pagename, @atlas_feature, @atlas_totalfeatures.
  5. composer item scope for the map item
  6. map settings scope (with scale and rotation determined by the map item’s settings)
  7. 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:

Setting a layer variablee

Setting a layer variable

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:

Rule based symbology using layer level variables

Rule based symbology using layer level variables

In a similar way, I’ve also created matching rule-based labeling (another new feature in QGIS 2.12):

Matching rule-based labels

Matching rule-based labels

Here’s what my map looks like now, with label and symbol colors matched:

*Map for illustrative purposes only... not for cartographic/visual design excellence!

*Map for illustrative purposes only… not for cartographic/visual design excellence!

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.

Inserting dynamic layer properties into a composer label

Inserting dynamic layer properties into a composer label

 

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!

Exploring variables in QGIS pt 2: project management

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:

Creating a variable for label font

Creating a variable for 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:

Binding the label font to the @main_label_font variable

Binding the label font to the @main_label_font variable

 

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’:

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:

delicious

And now when we hit Apply the font for all our labelled layers will be updated all at once:

new_labels

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:

See all those nice little yellow buttons? All those controls can be bound to variables...

See all those nice little yellow buttons? All those controls can be bound to variables…

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:

Define a colour in the project's colour scheme...

Define a colour in the project’s colour scheme…

Then, you can set a data defined override for a symbol or label colour to the expression “project_color(‘red alert!’)“:

bind_color

When you go back and change the corresponding colour in the Project Properties dialog, every symbol bound to this colour will also be updated!

blue_alert

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)

 

Exploring variables in QGIS 2.12, part 1

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:

Default project variables

Default project variables

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:

Adding new variables to a project

Adding new variables to a project

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:

Variables in a composer label

Variables in a composer label

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.

Global variables

Global variables

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:

Overridden variables

Overridden variables

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.

Stay tuned for more on this topic – this topic has only just scratched the surface of how expression variables have changed QGIS! (You can also read part 2 and part 3)

Recent labelling improvements in QGIS master

If you’re not like me and don’t keep a constant eye over at QGIS development change log (be careful – it’s addictive!), then you’re probably not aware of a bunch of labelling improvements which recently landed in QGIS master version. I’ve been working recently on a large project which involves a lot (>300) of atlas map outputs, and due to the size of this project it’s not feasible to manually tweak placements of labels. So, I’ve been totally at the mercy of QGIS’ labelling engine for automatic label placements. Generally it’s quite good but there were a few things missing which would help this project. Fortunately, due to the open-source nature of QGIS, I’ve been able to dig in and enhance the label engine to handle these requirements (insert rhetoric about beauty of open source here!). Let’s take a look at them one-by-one:

Data defined quadrant in “Around Point” placement mode

First up, it’s now possible to specify a data defined quadrant when a point label is set to the Around Point placement mode. In the past, you had a choice of either Around Point mode, in which QGIS automatically places labels around point features in order to maximise the number of labels shown, or the Offset from Point mode, in which all labels are placed at a specified position relative to the points (eg top-left). In Offset from Point mode you could use data defined properties to force labels for a feature to be placed at a specific relative position by binding the quadrant to a field in your data. This allowed you to manually tweak the placement for individual labels, but at the cost of every other label being forced to the same relative position. Now, you’ve also got the option to data define the relative position when in Around Point mode, so that the rest of the labels will fall back to being automatically placed. Here’s a quick example – I’ll start with a layer with labels in Around Point mode:

Around Point placement mode

Around Point placement mode

You can see that some labels are sitting to the top right of the points, others to the bottom right, and some in the top middle, in order to fit all the labels for these points. With this new option, I can setup a data defined quadrant for the labels, and then force the ‘Tottenham’ label (top left of the map) to display below and to the left of the point:

Setting a data-defined quadrant

Setting a data-defined quadrant

Here’s what the result looks like:

Manually setting the quadrant for the Tottenham label

Manually setting the quadrant for the Tottenham label

The majority of the labels are still auto-placed, but Tottenham is now force to the lower left corner.

Data defined label priority

Another often-requested feature which landed recently is the ability to set the priority for individual labels. QGIS has long had the ability to set the priority for an entire labelling layer, but you couldn’t control the priority of features within a layer. That would lead to situations like that shown below, where the most important central station (the green point) hasn’t been labelled:

What... no label for the largest station in Melbourne?

What… no label for the largest station in Melbourne?

By setting a data defined priority for labels, I can set the priority either via values manually entered in a field or by taking advantage of an existing “number of passengers” field present in my data. End result is that this central station is now prioritised over any others:

Much better! (in case you're wondering... I've manually forced some other non-optimal placement settings for illustrative purposes!)

Much better! (in case you’re wondering… I’ve manually forced some other non-optimal placement settings for illustrative purposes!)

Obstacle only layers

The third new labelling feature is the option for “Obstacle only” layers. What this option does is allow a non-labelled layer to act as an obstacle for the labels in other layers, so they will be discouraged from drawing labels over the features in the obstacle layer. Again, it’s best demonstrated with an example. Here’s my stations layer with labels placed automatically – you can see that some labels are placed right over the features in the rail lines layer:

Labels over rail lines...

Labels over rail lines…

Now, let’s set the rail lines layer to act as an obstacle for other labels:

... setting the layer as an obstacle...

… setting the layer as an obstacle…

The result is that labels will be placed so that they don’t cover the rail lines anymore! (Unless there’s no other choice). Much nicer.

No more clashing labels!

No more clashing labels!

Control over how polygons act as obstacles for labels

This change is something I’m really pleased about. It’s only applicable for certain situations, but when it works the improvements are dramatic.

Let’s start with my labelled stations map, this time with an administrative boundary layer in the background:

Stations with administrative boundaries

Stations with administrative boundaries

Notice anything wrong with this map? If you’re like me, you won’t be able to look past those labels which cross over the admin borders. Yuck. What’s happening here is that although my administrative regions layer is set to discourage labels being placed over features, there’s actually nowhere that labels can possibly be placed which will avoid this. The admin layer covers the entire map, so regardless of where the labels are placed they will always cover an administrative polygon feature. This is where the new option to control how polygon layers act as obstacles comes to the rescue:

...change a quick setting...

…change a quick setting…

Now, I can set the administrative layer to only avoid placing labels over feature’s boundaries! I don’t care that they’ll still be placed inside the features (since we have no choice!), but I don’t want them sitting on top of these boundaries. The result is a big improvement:

Much better!

Much better!

Now, QGIS has avoided placing labels over the boundaries between regions. Better auto-placement of labels like this means much less time required manually tweaking their positioning, and that’s always a good thing!

Draw only labels which fit inside a polygon

The last change is fairly self explanatory, so no nice screenshots here. QGIS now has the ability to prevent drawing labels which are too large to fit inside their corresponding polygon features. Again, in certain circumstances this can make a huge cartographic improvement to your map.

So there you go. Lots of new labelling goodies to look forward to when QGIS 2.12 rolls around.

 

Want to sponsor some QGIS features? Here’s some ideas…

I’ve been working on QGIS for a number of years now and, contrary to what I thought when I started, my wishlist seems to grow longer with every feature I add to QGIS! Unfortunately, almost all of my QGIS development work is done on a volunteer basis and it’s sometimes hard to justify the time required to tackle items on this list. So here’s your chance to help me fix this!

Here’s a quick list of things which I’d love to add to QGIS (or improve), but would need someone to step up and help sponsor their development:

  • Raster marker symbol type: Currently QGIS supports a number of marker symbol types (simple markers, font markers, SVG markers) but there’s no option to just use a raster image file for a symbol. A few versions back I added support for a raster image fill type, and now I’d love to do the same for markers. Options could include overriding the image size, rotation and opacity. And of course, all of these properties would be data-definable.
  • Paint effects for diagrams: The successful Kickstarter campaign meant that QGIS 2.10 includes a powerful framework for applying live effects to layers, including drop shadows, outer glows, blurs, and colour effects (plus lots of others!). I’d like to take this framework and allow effects to be applied to diagrams on a layer. Drop shadows and outer glows would really help aid the readability of diagrams by allowing them to sit on a different visual layer to the rest of the map. The effects framework was designed to allow reuse across all of QGIS, and diagrams would be the next logical step in this.

    Layer effects for diagrams! (Well... a mockup of them...)

    Layer effects for diagrams! (Well… a mockup of them…)

  • Additional diagram types/options: While we’re on the topic of diagrams, there’s lots more that we could do with QGIS’ diagram support. We’ve currently got support for pie charts, text diagrams and histograms, but there’s a lot of really nice diagram styles which we don’t yet support. Everybody loves infographics with nicely designed diagrams… so I’d love the chance to extend what’s possible using QGIS diagram engine. Some ideas include icon arrays, circle packing.
  • Adding a geometry widget in the attribute table: This feature has been on my mind a lot lately. What I’d like to add is a new “geometry widget” as the last column in a layer’s attribute table. This widget would allow you to do all sorts of modifications to the geometry attached to a feature. Possible options include clearing the geometry (resetting it to null), copying the geometry as WKT or GeoJSON, or pasting geometry into the feature from a WKT string (making it super easy to copy the geometry between features). This could also be extended in future to start incorporating the editing capabilities current possible through the Plain Geometry Editor plugin.

    Poor quality mockup of a geometry widget...

    Poor quality mockup of a geometry widget…

  • Options for non square/straight line legend patches: QGIS’ legend currently has no options for customising the shape of legend patches. Polygon layers in the legend are rectangles, line layers are straight lines — that’s it. There’s lots of room for improvement here. I’d like to add options for shapes such as circles, rounded rectangles, jagged lines, and possibly even custom shapes (via a WKT string or something similar).

    Custom legend shapes anyone?

    Custom legend shapes anyone?

  • Improving the heatmap plugin: The current heatmap plugin needs some love. The code and UI could do with a big refresh. I’d love a chance to totally revamp this plugin and move it into QGIS core code, and allow it to be used from within processing models. I’d also like to add additional hotspot techniques, such as Getis Ord Gi* hotspotting, to the plugin.
  • Extending the raster calculator: QGIS’ raster calculator was given a bunch of needed fixes and improvements in 2.10, but there’s more we could do. The major limitation with the calculator is that it currently only supports functions with at most two parameters. This needs to be fixed so that we can add a bunch of much desired functions to the calculator – eg min, max, avg, coalesce, if, etc… Lack of support for multi-parameter functions is really holding back what’s possible in the calculator.

Of course, this list is just a start. I’m always keen to chat about any other features you’d like to see added to QGIS (or even tackle specific pet-hate bugs or frustrations!). Just drop me an email at nyall.dawson@gmail.com to discuss.

Oh, one last thing – I’m in the process of preparing for my next crowd funded feature for QGIS – and this one is big! More on that shortly.

 

Customising the TimeManager time stamp

TimeManager is a fantastic plugin for QGIS which allows you to create animated maps from your data. You can read all about it here and here, and there’s a really nice demonstration of it here.

I’ve been playing with TimeManager a fair bit over the last month, and thought I’d share a quick tip on improving the appearance of TimeManager’s time stamp. TimeManager includes some basic functionality for placing a time stamp in the corner of your outputs, but it’s fairly limited. There’s only some basic appearance options, and no way to control the date or time formats displayed.

Default TimeManager time stamp

Default TimeManager time stamp

But, there’s a trick we can use to get around this: use a temporary point layer for the time stamp label. Let me elaborate:

  1. Create a throwaway point layer. It doesn’t matter what fields or format this layer has.
  2. Add a single point feature to this layer at the place you’d like the improved time stamp to appear at.

    Add a single point feature

    …add a single point feature

  3. We don’t want to see the marker, so hide the symbol for this layer by setting it to use a transparent fill and outline.

    Transparent fill and outline

    Transparent fill and outline

  4. Then, enable labels for this layer. Here’s the trick – set the label expression for the label to use “animation_datetime()” (or for QGIS 2.8, “$animation_datetime”). This is a custom function provided by the TimeManager plugin which evaluates to the current frame’s date and time.

    Setting the layer's label expression

    Setting the layer’s label expression

  5. Now, you can use all the built-in options within QGIS for styling this label. Buffers, drop shadows, background shapes… anything!

    ...tweaking the label appearance

    …tweaking the label appearance

  6. Apply and check. Much nicer!

    Formatted timestamp

    A nicely formatted time stamp

  7. To tweak the formatting of the time stamp’s date and time, you can modify the label expression using the built-in ‘format_date’, ‘year’, ‘month’, etc functions. Let’s try “format_date(animation_datetime(),’ddd dd MMM yyyy’)”:

    Tweaked expression

    Tweaked expression

Now, our final formatted time stamp looks like this:

Final, formatted time stamp

Final, formatted time stamp

…and there we go. Using this simple trick allows you to take advantage of all the possibilities which the QGIS labelling and expression engines allow!

*Bonus points for the first person to use this technique along with data defined controls for animating the label colour/size!

Review: Building Mapping Applications with QGIS

It seems like over the last year the amount of literature published regarding QGIS has really exploded. In the past few months alone there’s been at least three titles I can think of (Building Mapping Applications with QGISMastering QGIS, and the QGIS Python Programming Cookbook). I think this is a great sign of a healthy project. Judging by this there’s certainly a lot of demand for quality guides and documentation for QGIS.

I recently finished reading one of these titles – Building Mapping Applications with QGIS. (Erik Westra, Packt Publishing 2015) In short, I’m a huge fan of this work and think it may be my favourite QGIS book to date! I’ve read Erik’s previous work, Python Geospatial Development, and thought it was an entertaining and really well written book. He’s clearly got an in-depth knowledge about what he’s writing about and this confidence comes through in his writing. So when I first saw this title announced I knew it would be a must-read for me.

In Building Mapping Applications with QGIS, Erik has created a comprehensive guide through all the steps required to create QGIS plugins and standalone Python applications which utilise the QGIS libraries. It’s not a beginner’s guide to Python or to PyQGIS, but that’s what helps it stand out. There’s no introductory chapters on programming with Python or how to use QGIS and instead Erik dives straight into the meat of this topic. I found this approach really refreshing, as I’m often frustrated when the first few chapters of an advanced work just cover the basics. Instead, Building Mapping Applications with QGIS is packed with lessons about, well, actually building mapping applications!

So, why do I like this book so much? Personally, I think it fills a a really crucial void in the existing QGIS literature. There’s a lot of works covering using QGIS, and a few covering PyQGIS development (eg, the PyQGIS Programmer’s Guide, which I reviewed here). But to date, there hasn’t been any literature that covers developing QGIS based applications in such great depth. It’s just icing on the cake that Erik’s writing is also so interesting and easy to read.

Is there any criticisms I have with this book? Well, there’s one small omission which I would have liked to see addressed. While the chapter Learning the QGIS Python API goes into some detail about how QGIS is built using the Qt libraries and a great deal of depth about interpreting the QGIS c++ APIs, I think it could really benefit from some discussion about both the PyQt and Qt APIs themselves. Since a lot of the QGIS classes are either directly derived from Qt classes or heavily utilise them it’s really important that PyQGIS developers are also directed to the PyQt and Qt APIs. For instance, the Qt QColor class is used heavily throughout PyQGIS, but you won’t find any API documentation on QColor in QGIS’ API. Instead, you need to first consult the PyQt API docs and also the detailed Qt c++ docs. It’s often that you may think the PyQGIS API is missing a crucial method, but consulting the Qt docs reveals that the method is instead implemented in the base classes. It’s an important point to note for mastering PyQGIS development. To be fair, I’m yet to read a PyQGIS book which has nailed the interaction between the QGIS, PyQt and Qt APIs.

Honestly, that’s a really minor quibble with an otherwise outstanding work. I’m so glad Erik’s written this work and strongly recommend it to anyone wanting to take their PyQGIS development skills to the next level.

Introducing QGIS live layer effects!

I’m pleased to announce that the crowdfunded work on layer effects for QGIS is now complete and available in the current development snapshots! Let’s dive in and explore how these effects work, and check out some of the results possible using them.

I’ll start with a simple polygon layer, with some nice plain styling:

Nice and boring polygon layer

A nice and boring polygon layer

If I open the properties for this layer and switch to the Style tab, there’s a new checkbox for “Draw effects“. Let’s enable that, and then click the little customise effects button to its right:

Enabling effects for the layer

Enabling effects for the layer

A new “Effects Properties” dialog opens:

Effects Properties dialog

Effects Properties dialog

You can see that currently the only effect listed is a “Source” effect. Source effects aren’t particularly exciting – all they do is draw the original layer unchanged. I’m going to change this to a “Blur” effect by clicking the “Effect type” combo box and selecting “Blur“:

Changing to a blur effect

Changing to a blur effect

If I apply the settings now, you’ll see that the polygon layer is now blurry. Now we’re getting somewhere!

Blurry polygons!

Blurry polygons!

Ok, so back to the Effects Properties dialog. Let’s try something a bit more advanced. Instead of just a single effect, it’s possible to chain multiple effects together to create different results. Let’s make a traditional drop shadow by adding a “Drop shadow” effect under the “Source” effect:

Setting up a drop shadow

Setting up a drop shadow

Effects are drawn top-down, so the drop shadow will appear below the source polygons:

Live drop shadows!

Live drop shadows!

Of course, if you really wanted, you could rearrange the effects so that the drop shadow effect is drawn above the source!..

Hmmmm

Hmmmm…

You can stack as many effects as you like. Here’s a purple inner glow over a source effect, with a drop shadow below everything:

Inner glow, source, drop shadow...

Inner glow, source, drop shadow…

Now it’s time to get a bit more creative… Let’s explore the “transform” effect. This effect allows you to apply all kinds of transformations to your layer, including scaling, shearing, rotation and translation:

The transform effect

The transform effect

Here’s what the layer looks like if I add a horizontally shearing transform effect above an outer glow effect:

Getting freaky...

Getting tricky…

Transforms can get really freaky. Here’s what happens if we apply a 180° rotation to a continents layer (with a subtle nod to xkcd):

Change your perspective on the world!

Change your perspective on the world!

Remember that all these effects are applied when the layers are rendered, so no modifications are made to the underlying data.

Now, there’s one last concept regarding effects which really blasts open what’s possible with them, and that’s “Draw modes“. You’ll notice that this combo box contains a number of choices, including “Render“, “Modify” and “Render and Modify“:

"Draw mode" options

“Draw mode” options

These draw modes control how effects are chained together. It’s easiest to demonstrate how draw modes work with an example, so this time I’ll start with a Transform effect over a Colorise effect. The transform effect is set to a 45° rotation, and the colorise effect set to convert to grayscale. To begin, I’ll set the transform effect to a draw mode of Render only:

The "Render only" draw mode

The “Render only” draw mode

In this mode, the results of the effect will be drawn but won’t be used to modify the underlying effects:

Rotation effect over the grayscale effect

Rotation effect over the grayscale effect

So what we have here is that the polygon is drawn rotated by 45° by the transform effect, and then underneath that there’s a grayscale copy of the original polygon drawn by the colorise effect. The results of the transform effect have been rendered, but they haven’t affected the underlying colorise effect.

If I instead set the Transform effect’s draw mode to “Modifier only” the results are quite different:

Rotation modifier for grayscale effect

Rotation modifier for grayscale effect

Now, the transform effect is rotating the polygon by 45° but the result is not rendered. Instead, it is passed on to the subsequent colorise effect, so that now the colorise effect draws a grayscale copy of the rotated polygon. Make sense? We could potentially chain a whole stack of modifier effects together to get some great results. Here’s a transform, blur, colorise, and drop shadow effect all chained together using modifier only draw modes:

A stack of modifier effects

A stack of modifier effects

The final draw mode, “Render and modify” both renders the effect and applies its result to underlying effects. It’s a combination of the two other modes. Using draw modes to customise the way effects chain is really powerful. Here’s a combination of effects which turn an otherwise flat star marker into something quite different:

Lots of effects!

Lots of effects!

The last thing I’d like to point out is that effects can be either applied to an entire layer, or to the individual symbol layers for features within a layer. Basically, the possibilities are almost endless! Python plugins can also extend this further by implementing additional effects.

All this work was funded through the 71 generous contributors who donated to the crowdfunding campaign. A big thank you goes out to you all whole made this work possible! I honestly believe that this feature takes QGIS’ cartographic possibilities to whole new levels, and I’m really excited to see the maps which come from it.

Lastly, there’s two other crowdfunding campaigns which are currently in progress. Lutra consulting is crowdfunding for a built in auto trace feature, and Radim’s campaign to extend the functionality of the QGIS GRASS plugin. Please check these out and contribute if you’re interested in their work and would like to see these changes land in QGIS.

QGIS – live layer effects Kickstarter update

Here’s another quick video demonstration of the latest developments in layer effects – effects on polygon and polyline layers, and outer glow effects:

Time is running out to fund this campaign and make this work happen… Please donate via Kickstarter!

I’ve also been asked what will happen if funding exceeds the Kickstarter goal? Well, if this happens, the extra funds will be used to add additional layer effects to QGIS. Next up will be inner glow, inner shadow and color modification effects.

Kickstarter Alert – Live Layer Effects for QGIS

QGIS is well regarded for its fantastic cartographic abilities – it’s got a huge range of symbology styles and options which can be used to style your maps. But there’s more we can do to push this even further.

One long requested cartographic feature has been for live drop shadows on layers. Why stop there? Why not inner and outer glow effects and live blur effects? Just imagine the cartographic possibilities if this functionality was available from within a GIS, and didn’t require exporting maps to external editors…

I’ve launched a Kickstarter project to fund implementing live layer effects like this within QGIS. Please consider donating or spreading the word if you’d find this feature useful!

Exploring QGIS 2.6 – Item panel for map composer

In recent releases QGIS’ map composer has undergone some large usability improvements, such as the ability to select and interact with multiple items, and much improved navigation of compositions. Another massive usability improvement which is included in QGIS 2.6 is the new “Items” panel in the map composer. The panel shows a list of all items currently in the composition, and allows you to individually select, show or hide items, toggle their lock status, and rearrange them via drag and drop. You can also double click the item’s description to modify its ID, which makes managing items in the composition much easier.

QGIS composer’s new items panel

This change has been on my wish list for a long time. The best bit is that implementing the panel has allowed me to fix some of the composer’s other biggest usability issues. For instance, now locked items are no longer selectable in the main composer view. If you’ve ever tried to create fancy compositions with items which are stacked on top of other items, you’ll know that trying to interact with the lower items has been almost impossible in previous QGIS versions. Now, if you lock the higher stacked items you’ll be able to fully interact with all underlying items without the higher items getting in the way. Alternatively you could just temporarily hide them while you work with the lower items.

This feature brings us one more step closer to making QGIS’ map composer a powerful DTP tool in itself. If you’d like to help support further improvements like this in QGIS, please consider sponsoring my development work, or you can contact me directly for a quote on specific development.

Creating custom colour schemes in PyQGIS

In my last post I explored some of the new colour related features available in QGIS 2.6. At the end of that post I hinted at the possibility of creating QGIS colour schemes using python. Let’s take a look…

We’ll start with something nice and easy – a colour scheme which contains a predefined set of colours (e.g., standard company colours). This is done by subclassing QgsColorScheme and implementing the required methods ‘schemeName‘, ‘fetchColors‘ and ‘clone‘. It’s all fairly self explanatory – most of the important stuff happens in fetchColors, which returns a list of QColor/string pairs. Here’s a sample:

from PyQt4.QtCore import *
from PyQt4.QtGui import *

class QgsCgaLightColorScheme(QgsColorScheme):
    def __init__(self, parent=None): 
        QgsColorScheme.__init__(self)
 
    def schemeName(self):
        return "CGA Colors!"
 
    def fetchColors(self,context='', basecolor=QColor()):
        return [[QColor('#555555'),'Gray'],
                    [QColor('#5555FF'),'Light Blue'],
                    [QColor('#55FF55'),'Light Green'],
                    [QColor('#55FFFF'),'Light Cyan'],
                    [QColor('#FF5555'),'Light Red'],
                    [QColor('#FF55FF'),'Light Magenta'],
                    [QColor('#FFFF55'),'Yellow'],
                    [QColor('#FFFFFF'),'White']]
    def flags(self):
        return QgsColorScheme.ShowInAllContexts
 
    def clone(self):
        return QgsCgaLightColorScheme()

cgaScheme = QgsCgaLightColorScheme()
QgsColorSchemeRegistry.instance().addColorScheme(cgaScheme)

This scheme will now appear in all colour buttons and colour picker dialogs:

CGA colours… what your map was missing!

If you only wanted the scheme to appear in the colour picker dialog, you’d modify the flags method to return QgsColorScheme.ShowInColorDialog instead.

QgsColorSchemes can also utilise a “base colour” when generating their colour list. Here’s a sample colour scheme which generates slightly randomised variations on the base colour. The magic again happens in the fetchColors method, which copies the hue of the base colour and generates random saturation and value components for the returned colours.

from PyQt4.QtCore import *
from PyQt4.QtGui import *
import random

class QgsRandomColorScheme(QgsColorScheme):
    def __init__(self, parent=None): 
        QgsColorScheme.__init__(self)

    def schemeName(self):
        return "Random colors!"

    def fetchColors(self, context='', basecolor=QColor() ):
        noColors = random.randrange(30)
        minVal = 130;
        maxVal = 255;
        colorList = []
        for i in range(noColors):
            if basecolor.isValid():
                h = basecolor.hue()
            else:
                #generate random hue
                h = random.randrange(360);

            s = random.randrange(100,255)
            v = random.randrange(100,255)

            colorList.append( [ QColor.fromHsv( h, s, v), "random color! " + str(i) ] )

        return colorList

    def flags(self):
        return QgsColorScheme.ShowInAllContexts

    def clone(self):
        return QgsRandomColorScheme()

randomScheme = QgsRandomColorScheme()
QgsColorSchemeRegistry.instance().addColorScheme(randomScheme)

Here’s the random colour scheme in action… note how the colours are all based loosely around the current red base colour.

Randomised colours

You may also have noticed the context argument for fetchColors. This can be used to tweak the returned colour list depending on the context of the colour picker. Possible values include ‘composer‘, ‘symbology‘, ‘gui‘ or ‘labelling‘.

One final fun example… here’s a colour scheme which grabs its colours using the Colour Lovers API to fetch a random popular palette from the site:

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from xml.etree import ElementTree
import urllib2
import random

class colorLoversScheme(QgsColorScheme):

    def __init__(self, parent=None): 
        QgsColorScheme.__init__(self)
        xmlurl = 'http://www.colourlovers.com/api/palettes/top'

        headers = { 'User-Agent' : 'Mozilla/5.0' }
        req = urllib2.Request(xmlurl, None, headers)
        doc = ElementTree.parse(urllib2.urlopen(req)).getroot()

        palettes = doc.findall('palette')
        palette = random.choice(palettes)

        title = palette.find('title').text
        username = palette.find('userName').text
        attrString = title + ' by ' + username
        colors = ['#'+c.text for c in palette.find('colors').findall('hex')]

        self.color_list = [[QColor(c), attrString] for c in colors]

    def schemeName(self):
        return "Color lovers popular palette"

    def fetchColors(self, context='', basecolor=QColor()):
        return self.color_list

    def flags(self):
        return QgsColorScheme.ShowInAllContexts

    def clone(self):
        return colorLoversScheme()

loversScheme = colorLoversScheme()      
QgsColorSchemeRegistry.instance().addColorScheme( loversScheme )

Clicking a colour button will now give us some daily colour scheme inspiration…

Grabbing a palette from the Colours Lovers site

Grabbing a palette from the Colours Lovers site

Ok, now it’s over to all you PyQGIS plugin developers – time to go wild!

What’s new in QGIS 2.6 – Tons of colour improvements!

With one month left before the release of QGIS 2.6, it’s time to dive into some of the new features it will bring… starting with colours.

Working with colours is a huge part of cartography. In QGIS 2.4 I made a few changes to improve interaction with colours. These included the ability to copy and paste colours by right clicking on a colour button, and dragging-and-dropping colours between buttons. However, this was just the beginning of the awesomeness awaiting colours in QGIS 2.6… so let’s dive in!

Part 1 – New colour picker dialog

While sometimes it’s best to stick with an operating system’s native dialog boxes, colour pickers are one exception to this. That’s because most native colours pickers are woefully inadequate, and are missing a bunch of features which make working with colours much easier. So, in QGIS 2.6, we’ve taken the step of rolling out our very own colour picker:

New QGIS colour picker

Before starting work on this, I conducted a review of a number of existing colour picker implementations to find out what works and what doesn’t. Then, I shamelessly modelled this new dialog off the best bits of all of these! (GIMP users will find the new dialog especially familiar – that’s no coincidence, it’s a testament to how well crafted GIMP’s colour picker is.)

The new QGIS colour picker features:

  • Colour sliders and spin boxes for Hue, Saturation, Value, Red, Green and Blue colour components
  • An opacity slider (no more guessing what level of transparency “189” corresponds to!)
  • A text entry box which accepts hex colours, colour names and CSS rgb(#,#,#) type colours. (The drop down arrow you can see on this box in the screenshot above allows you to specify the display format for colours, with options like #RRGGBB and #RRGGBBAA)
  • A grid of colour swatches for storing custom colours
  • A visual preview of the new colour compared to the previous colour
  • Support for dragging and dropping colours into and out of the dialog
  • A colour wheel and triangle method for tweaking colours (by the way, all these colour widgets are reusable, so you can easily dump them into your PyQGIS plugins)
    Colour wheel widget
  • A colour palettes tab. This tab supports adding and removing colours from a palette, creating new palettes and importing and exporting colours from a GPL palette file. (We’ll explore colour palettes in more detail later in this post.)
    Colour palettes
  • A colour sampler! This tab allows you to sample a colour from under the mouse pointer. Just click the “Sample color” button, and then click anywhere on the screen (or press the space bar if you’re sampling outside of the QGIS window). You even get the choice of averaging the colour sample over a range of pixels. (Note that support for sampling is operating system dependant, and currently it is not available under OSX.)
    Built in colour sampler! Woohoo!

Part 2 – New colour button menus

Just like the new colour dialog is heavily based off other colour dialog implementations, this new feature is inspired by Microsoft’s excellent colour buttons in their recent Office versions (I make no claim to originality here!). Now, all QGIS colour buttons come with a handy drop down menu which allows you to quickly choose from some frequently used colour shortcuts. You’ve got the previously available options of copying and pasting colours from 2.4, plus handy swatches for recently used colours and for other standard colours.

colour_menu

Handy colour menu for buttons

Part 3 – Colour palettes

You may have noticed in the above screenshot the “Standard colors” swatches, and wondered what these were all about.  Well, QGIS 2.6 has extensive support for color palettes. There’s a few different “built-in” color palettes:

  • The “Standard colors” palette. This palette can be modified through the Options → Colors tab. You can add, remove, edit, and rename colours, as well as import color schemes from a GPL palette file. These standard colours apply to your QGIS installation, so they’ll be available regardless of what project you’re currently working on.

    Customising the standard colours

    Customising the standard QGIS colours

  • The “Project colors” palette. This can be accessed via the Project Properties → Default styles tab. This palette is saved inside the .qgs project file, so it’s handy for setting up a project-specific colour scheme.
  • The “Recent colors” palette. This simply shows colours you’ve recently used within QGIS.

You can easily create new colour palettes directly from the colour picker dialog. Behind the scenes, these palettes are saved into your .qgis/palettes folder as standard GPL palette files, which makes it nice and easy to modify them in other apps or transfer them between installations. It’s also possible to just dump a stack of quality palettes directly into this folder and they’ll be available from within QGIS.

Perhaps the best bit about colour schemes in QGIS is that they can be created using PyQGIS plugins, which opens up tons of creative possibilities… More on this in a future blog post!

So there we go. Tons of improvements for working with colours are heading your way in QGIS 2.6, which is due out on the 24th October.

(Before we end, let’s take a quick look at what the competition offers over in MapInfo land. Yeah… no thanks. You might want to invest some development time there Pitney Bowes!)

Shapeburst fill styles in QGIS 2.4

With QGIS 2.4 getting closer (only a few weeks away now) I’d like to take some time to explore an exciting new feature which will be available in the upcoming release… shapeburst fills!

As a bit of background, QGIS 2.2 introduced a gradient fill style for polygons, which included linear, radial and conical gradients. While this was a nice feature, it was missing the much-requested ability to create so-called “buffered” gradient fills. If you’re not familiar with buffered gradients, a great example is the subtle shading of water bodies in the latest incarnation of Google maps. ArcGIS users will also be familiar with the type of effects possible using buffered gradients.

Gradient fills on water bodies in Google maps

Gradient fills on water bodies in Google maps

Implementing buffered gradients in QGIS originally started as a bit of a challenge to myself. I wanted to see if it was possible to create these fill effects without a major impact on the rendering speed of a layer. Turns out you can… well, you can get pretty close anyway. (QGIS 2.4’s new multi-threaded responsive rendering helps a lot here too).

So, without further delay, let’s dive into how shapeburst fills work in QGIS 2.4! (I’ve named this fill effect ‘shapeburst fills’, since that’s what GIMP calls it and it sounds much cooler than ‘buffered gradients’!)

Basic shapeburst fills

For those of you who aren’t familiar with this fill effect, a shapeburst fill is created by shading each pixel in the interior of a polygon by its distance to the closest edge. Here’s how a lake feature polygon looks in QGIS 2.4 with a shapeburst from a dark blue to a lighter blue colour:

A simple shapeburst fill from a dark blue to a lighter blue

A simple shapeburst fill from a dark blue to a lighter blue

You can see in the image above that both polygons are shaded with the dark blue colour at their outer boundaries through to the lighter blue at their centres. The screenshot below shows the symbol settings used to create this particular fill:

A simple shapeburst fill from a dark blue to a lighter blue

Creating a simple shapeburst fill from a dark blue to a lighter blue

Here we’ve used the ‘Two color‘ option, and chosen our shades of blue manually. You can also use the ‘Color ramp’ option, which allows shading using a complex gradient containing multi stops and alpha channels. In the image below I’ve created a red to yellow to transparent colour ramp for the shapeburst:

Colour ramp shapeburst with alpha channels

Colour ramp shapeburst with alpha channels

Controlling shading distance

In the above examples the shapeburst fill has been drawn using the whole interior of the polygon. If desired, you can change this behaviour and instead only shade to a set distance from the polygon edge. Let’s take the blue shapeburst from the first example above and set it to shade to a distance of 5 mm from the edge:

Shapeburst fills can shade to a set distance only

Shapeburst fills can also shade to a set distance from the polygon’s exterior

This distance can either be set in millimetres, so that it stays constant regardless of the map’s scale, or in map units, so that it scales along with the map. Here’s what our lake looks like shaded to a 5 millimetre distance:

Shading to 5mm from the lake's edge

Shading to 5mm from the lake’s edge

Let’s zoom in on a portion of this shape and see the result. Note how the shaded distance remains the same even though we’ve increased the scale:

Zooming in maintains a constant shaded distance

Zooming in maintains a constant shaded distance

Smoothing shapeburst fills

A pure buffered gradient fill can sometimes show an odd optical effect which gives it an undesirable ‘spiny’ look for certain polygons. This is most strongly visible when using two highly contrasting colours for the fill. Note the white lines which appear to branch toward the polygon’s exterior in the image below:

Spiny artefacts on a pure buffered gradient fill

Spiny artefacts on a pure buffered gradient fill

To overcome this effect, QGIS 2.4 offers the option to blur the results of a shapeburst fill:

Blur option for shapeburst fills

Blur option for shapeburst fills

Cranking up the blur helps smooth out these spines and results in a nicer fill:

Adding a blur to the shapeburst fill

Adding a blur to the shapeburst fill

Ignoring interior rings

Another option you can control for shapeburst fills is whether interior polygon rings should be ignored. This option is useful for shading water bodies to give the illusion of depth. In this case you may not want islands in the polygon to affect their surrounding water ‘depth’. So, checking the ‘Ignore rings in polygons while shading‘ option results in this fill:

Ignoring interior rings while shading

Ignoring interior rings while shading

Compare this image with the first image posted above, and note how the shading differs around the small island on the polygon’s left.

Some extra bonuses…

There’s two final killer features with shapeburst fills I’d like to highlight. First, every parameter for the fill can be controlled via data defined expressions. This means every feature in your layer could have a different start and end colour, distance to shade, or blur strength, and these could be controlled directly from the attributes of the features themselves! Here’s a quick and dirty example using a random colour expression to create a basic ‘tint band‘ effect:

Using a data defined expression for random colours

Using a data defined expression for random colours

Last but not least, shapeburst fills also work nicely with QGIS 2.4’s new “inverted polygon” renderer. The inverted polygon renderer flips a normal fill’s behaviour so that it shades the area outside a polygon. If we combine this with a shapeburst fill from transparent to opaque white, we can achieve this kind of masking effect:

Creating a smooth exterior mask using the "inverted polygons" renderer

Creating a smooth exterior mask using the “inverted polygons” renderer

This technique plays nicely with atlas prints, so you can now smoothly fade out the areas outside of your coverage layer’s features for every page in your atlas print!

All this and more, coming your way in a few short weeks when QGIS 2.4 is officially released…

Colour shortcuts in QGIS 2.4

Quick poll… what’s the most frustrating thing about GIS? Fighting with colour plotters? Trying to remember GDAL command line syntax? MapInfo’s new ribbon interface* [1]? All of the above?

Wrong!

It’s getting a colour from here:

colour1

…all the way over to here:

colour2

Since the dawn of GIS humanity has struggled with this simple task* [2]. We’ve come up with multiple techniques for solving this problem, ranging from the RSI inducing “select and copy red value, alt-tab, paste, alt-tab, select and copy green value, alt-tab, paste, etc….” method, through to chanting “70, 145, 160… 70, 145, 160… 70, 145, 150… 70, 145, 150” to ourselves as we frantically try and rearrange dialogs to find the destination colour picker, all the while avoiding strange looks from co-workers.

Fortunately, QGIS 2.4 is coming to the rescue! Now, you can right click on any of QGIS’ colour picker buttons for a handy copy/paste colour shortcut menu. Pasting colours works from a whole range of formats, including hex codes, color names, and css-style “rgb” and “rgba” strings.

Fixed!

Problem solved!

Even better, you can just drag colours from one colour button to another:

Fixed again...

… and solved again…

Or, drag a colour from GIMP and drop it onto a QGIS colour button:

x

… and yet again!

Or even drag a colour from a QGIS button directly onto a shape in Inkscape! All this win is coming your way in QGIS 2.4, due June 2014.

[1] Pre-empting the inevitable flood of complaints when this new interface is rolled out
[2] I assume

And now… colour preview modes in QGIS’ map canvas

As a quick follow-up to my last post on colour preview modes for the print composer in QGIS 2.4, this feature has also been added to the main map canvas window! Now it’s even easier to adjust your symbol colours and immediately see how they’d appear under a range of different circumstances:

Colour previews modes for the map canvas

Colour previews modes for the map canvas

 

Colour blindness and grayscale previews in QGIS 2.4

Since QGIS 2.4 is nearing feature freeze it seems like a good time to start exploring some of the great new features in this release. So, let’s get started with my most recent addition to QGIS’ print composer… preview modes!

As every first year cartography text book will tell you, it’s important to know your target media and audience when creating a usable map. Some important considerations are whether or not your map will be photocopied or printed in black and white, and whether you need to consider colour blind map readers in your audience. In the past, designing maps with these considerations has been a time consuming, tedious process. You’d have to export your map, open it in another graphics editing program, apply some colour transform, work out what issues there are, flip back to QGIS, make your changes and repeat. If you’re working with a tight deadline it can be difficult to justify the time this all takes.

QGIS 2.4 will help to make this whole process a lot simpler. In the print composer there’s now an option to enable a number of different live “preview modes“. These include grayscale, monochrome, and two colour blindness simulations (Protanope and Deuteranope).

Composer preview modes in QGIS 2.4

Composer preview modes in QGIS 2.4

These preview modes are live, so you can continue to edit and tweak the colours in your composition while a preview mode is active! For a quick demonstration, let’s start with this creatively coloured thematic map:

bad_colored_map

While it might not be the most aesthetically pleasing map, at least the thematic colours can be easily matched to their corresponding values in the legend. Let’s see what would happen if we photocopied this map. This is as easy as activating the “Simulate photocopy (grayscale)” preview mode:

greyscalepreview

Hmm… not so usable now. The five thematic colours have been reduced to just three discernible colours. Oh well, at least we haven’t had to export our map to find this out, and it’s nice and easy to adjust the colours and composition to work for photocopies without having to leave QGIS to test the results!

Let’s see how this map would look to someone with colour blindness, by activating the “Simulate colour blindness (Protanope)” mode:

color_blindness

In this case, our map isn’t too bad. The different classes are still discernible and the map can be interpreted by someone with protanopia.

So there we have it – now it’s easy to determine how our map outputs will look under different circumstances and adjust them to suit! Composer preview modes will be a part of the upcoming 2.4 release of QGIS, which is due out at the end of June 2014.

Update:

This feature has also been added to the main map canvas.

Composition styling in QGIS 2.2

Here’s a quick run-down on some new feature in QGIS 2.2 which I never got around to writing about before the release. I feel like I’ve got to give these features their due publicity before moving on to all the exciting new stuff which is being added for 2.4. So, without further ado, let’s take a dive into print composer shape and page styling in QGIS 2.2…

Shape styling

It’s no secret that QGIS has pretty impressive capabilities when it comes to cartographic styling of polygon features. Everything from line and point pattern fills, SVG image fills, gradients and even buffered gradients (new in 2.4 — more on that in a later post) can be used to shade polygons. That’s all in addition to the whole range of line styles which can be used to outline the edges of polygons. In QGIS 2.2 all these fill effects are now available for styling shapes in the print composer. What exactly does this mean?

Well, now you can draw a frame onto your print layout and style it with a gradient fill…

Gradient shape fill in composer

…or a line pattern fill….

Line pattern fill in composer

…or some crazy combination of everything…

Advanced fill in composer

It’s totally up to you how far you take this! Here’s a nice example of a map created in QGIS 2.2’s print composer using these new styling options.

Page styling for compositions

Why is this cool? Well, for a start, if we take a quick look at the QGIS map showcase on Flickr very few of the maps shown there have a white background. In previous versions of QGIS achieving a non-white background would require drawing a giant coloured rectangle over your whole composition, banishing it to the back of the stack, and then continually being annoyed by it getting in the way while you tried to work on the rest of the composition. Now, just like the shape styling described above, you can style the page background using any of the available options in QGIS for polygon fills!

Creating a composition with a black page background

Creating a composition with a black page background

It doesn’t end there though. Since the page background can now be styled like this, it’s also possible to have transparent or semi-transparent page backgrounds. I’ll show the result opened here in GIMP so that you can see the full transparency effect over GIMP’s checkerboard background pattern:

A composition exported with a transparent background

A QGIS 2.2 composition exported with a transparent background

Using a transparent composition background like this also allows for transparency effects in map layers to show through – so, for instance, if your map layer is set to 50% transparent then the resultant export from the composer will also be 50% transparent.

And now for the final stinger…

Have I mentioned yet that you can also use data defined symbology for both shape and page styling? No? Well, this was actually my main motivator in adding styling support to these elements. For a long time I’ve been wanting to create atlases which vary the page background based on attributes in the atlas coverage layer. Think flip-book style maps, where the page border is colour-coded to highlight areas that need attention. For example, areas with high rates showing with red borders, average rates with yellow, and low rates with green borders. Using a combination of page and shape styling, data defined symbology, and QGIS’ atlas features, this is now possible!

…And that (belatedly) wraps up my exploration of new features in QGIS 2.2. Next up I’ll start showcasing all the sweet new features which have landed for 2.4…

Two book recommendations

I recently finished reading two books which may be of interest to open-source GIS users – “PostGIS Cookbook” and “The PyQGIS Programmer’s Guide“, both of which I highly recommend:

PostGIS Cookbook

PostGIS CookbookI’ve been a fan of Stephen Mather’s blog for a while now, and have consistently found it to be a great source of trustworthy information and creative solutions to GIS problems. So when I first saw mention of his work on the PostGIS Cookbook I knew it would be a must-read for me. PostGIS is an essential part of my daily toolkit, and I’ll quickly devour any tutorial or guide which can lead me to better ways to put it to use. And that’s exactly what this book is! It’s full of tips and guides which has inspired me in a lot of techniques I’d never tried or even thought possible in PostGIS.

It’s important to point out that this book isn’t a training manual or beginner’s guide to PostGIS. It assumes readers are already familiar with using PostGIS and have a good understanding of GIS software in general. (If you’re looking for a book to start from scratch with PostGIS, PostGIS in Action is a better fit). I think that’s really what makes this book stand out though. There’s currently not a lot of books available covering PostGIS, and as far as I’m aware the PostGIS Cookbook is the only book available which is targeted to experienced PostGIS users.

Highlights for me are:

  • A great explanation and write up on optimised KNN filtering in PostGIS (something which often trips me up)
  • The detailed guide to topologically correct simplification of features
  • The exploration of PgRouting, which is a great introduction to PostGIS’ routing abilities
  • The “PostGIS and the web” chapter – I really wasn’t expecting this, but it’s quite eye opening (I’m going to have to do some digging into GeoDjango sometime)

The only criticism I have with this book is that it jumps around a lot between operating systems. While most of the code is provided for both Linux/OSX and Windows, there’s occasional examples which only have code for one specific operating system. It’s a little jarring and assumes the user is well versed in their particular operating system to workaround these omissions.

Overall, I strongly recommend the PostGIS Cookbook, and would consider it a must have for anyone serious about expanding their PostGIS abilities. (Also, looks like the publisher, Packt, have a two-for-one sale going at the moment, so it’s a good time to grab this title).

The PyQGIS Programmer’s Guide

The PyQGIS Programmer's GuideThe second book I’ve just finished reading is Gary Sherman’s “The PyQGIS Programmer’s Guide“. For those who are unaware, Gary was the original founder of QGIS back in 2002, so you can be confident that he knows exactly what he’s writing about. In The PyQGIS Programmer’s Guide  Gary has created an in-depth guide on how to get started with programming for QGIS using python. It takes readers all the way from simple scripts right through to developing QGIS plugins and standalone applications based on the QGIS API.

This book fills an important void in the literature available for QGIS. Previously, the PyQGIS Developer Cookbook was the only available guide for QGIS python scripting, and unfortunately it’s a little out-of-date now. PyQGIS scripting can be a steep learning curve and that’s why this book is so appreciated.

It would be valuable to have some python knowledge and experience prior to reading this book. While the “Python Basics” chapter quickly runs through an introduction to the language, the book makes no claims to be a comprehensive python tutorial. But if you’ve dabbled in the language before and have familiarity with the python way of doing things you’ll easily be able to follow along.

Highlights are:

  • The “Tips and Techniques” chapter, which is a great mini-reference for performing a range of common tasks in PyQGIS (including loading layers, changing symbol styles, editing feature attributes, etc).
  • A complete tutorial for creating a QGIS plugin
  • A guide to debugging PyQGIS code and plugins

I’d definitely recommend that anyone who wants to get started with PyQGIS start with Gary’s work – you’ll find it the perfect place to begin.

Atlas previews in QGIS 2.2

QGIS 2.2 includes some great additions to the map composer’s “Atlas” feature. If you’re not familiar with atlas prints they are QGIS’ equivalent of ArcGIS’s “data driven pages”, or something like a map based version of Microsoft Word’s “mail merge”. In an atlas composition you can select one of your map layers to use as a “coverage layer“, and QGIS will automatically generate multiple pages from the composition with each page highlighting a different feature from this coverage layer.

Atlas Previews

Thanks to funding from SIGE, I’ve added some useful new features to QGIS’ atlas abilities for 2.2. The first of these is the ability to preview atlas compositions before printing them. In QGIS 2.0, atlas generation took a bit of guess work. You’d set up the parameters for the atlas, then export the whole atlas in one shot and just hope you’d got the settings right. If not, you’d have to tweak the settings and export the whole lot again to see the result. But not any more! Now, in QGIS 2.2, you can switch on a live atlas preview mode by clicking “Preview Atlas” in the new atlas preview toolbar:

The new atlas preview toolbar

The new atlas preview toolbar

The composer window will switch to showing you a preview of exactly how the atlas will look when exported. You can tweak the appearance of any layout item, adjust the atlas and map parameters, or experiment with the new options for atlas feature styling to see instantly what the final export will look like.

The composer window in atlas preview mode

The composer window in atlas preview mode (complete with gratuitous use of label rotation and rounded rectangles…) 

When this Atlas Preview mode is enabled, you navigate through all the features in the coverage layer by clicking any of the navigation buttons in the atlas preview toolbar:

Navigating the atlas preview

Navigating the atlas preview

While previewing you can export individual pages from the atlas. So, if just one or two pages in your atlas need to be individually tweaked you can do that as you step through the features. A neat thing with this is that you can make temporary tweaks to the extent and scale of the map items as you go, without affecting how the rest of the atlas maps look.

(Oh, by the way, I should mention that as an added bonus QGIS 2.2 lets you control more than one map with an atlas print!)

Selecting the current atlas feature

The second part of the work funded by SIGE was creation of shortcut actions for selecting the current atlas feature. If your atlas coverage layer has many records it may not be practical to step through the atlas previews one at a time until you find a specific feature. That’s where these new shortcut actions come in handy!

There’s a few ways of jumping directly to a specific atlas feature. The first is to open a browser window for your coverage layer, then right click a row and choose “Set as atlas feature for …“:

Setting the atlas feature from the browser window

Setting the atlas feature from the browser window

Selecting this menu item will cause the composer to immediately jump to the matching atlas row. Another way of selecting the current atlas feature is to use the “Set as atlas feature” map action. You activate this by first selecting your coverage layer in the layers panel, then clicking the “Run Feature Action” tool button and selecting “Set as atlas feature…“:

The set atlas feature map action

The set atlas feature map action

The mouse cursor will change to a cross-hair, and clicking any matching feature in the map window will cause the composer atlas preview to jump straight to that feature. Lastly, you can also activate the “Set as atlas feature” action directly from the identify results window.

That’s just a small taste of some of the new atlas creation features which will be available in QGIS 2.2, coming your way by the end of February 2014!

(One last note – as mentioned, this work was kindly sponsored by SIGE. If there’s a specific composer based feature or bug you’d like me to work on, I’m available for further sponsored work. Just contact me directly for details.)

  • Page 1 of 2 ( 28 posts )
  • >>
  • geospatial

Back to Top

Sponsors