One of my favorite features of QGIS – Rule based styling.

One of my favorite features of QGIS is the rule based rendering.

QGIS rule based rendering dialog
QGIS rule based rendering dialog

If you’re using MapInfo think of thematics + queries but on steroids. Rule based rendering allows you to you set, well, rules on what gets rendered and how.  The rules are based on a simple SQL style query language that’s built into QGIS.

Take for example the above screen shot.   The screen shot is from a current project I am doing in QGIS to clean up our current stormwater/drainage layer.  The layer is a in a bit of a mess at the moment so I needed a way to visualize what I have cleaned up and what I haven’t, so enter QGIS rule based styling.

For example: A pipe that has an upstream and downstream invert and is part of the trunk (main) network is then considered valid (for this situation anyway), so I created the following rule:

network_type = 'Trunk' AND Description != 'Drainage Imaginary Pipe' AND (US_Invert > 0 AND DS_Invert > 0)

We also have little connecting pipes that I don’t want to include in valid trunk  as they are only used to connect pits to pipes and are just cosmetic, I have excluded them by adding “Description !=’Drainage Imaginary Pipe’” to the above filter.

Next I wanted to show invalid trunk network pipes (ones without an up or downstream invert), so we just invert the last condition and swap the last AND for a OR:

network_type = 'Trunk' AND Description != 'Drainage Imaginary Pipe' AND (NOT US_Invert > 0 OR NOT DS_Invert > 0)

I also need to show but no highlight the non trunk pipes and the connecting pipes, so I made the next two rules and set their styles to a light gray:

NOT network_type = 'Trunk' AND NOT Description = 'Drainage Imaginary Pipe'
Description = 'Drainage Imaginary Pipe'

Finally I want to show pipe direction on all pipes but not the connecting pipes, again as they are just cosmetic:

Description != 'Drainage Imaginary Pipe'

You will also note in the screenshot above that I have a max zoom scales set on the last three rules, this is because when I zoom out all that info becomes overwhelming at that scale and distracts from showing the invalid parts of the main trunk line.

So after all that, the results:

Screenshot of rules applied
Map rendered using rules

and if I zoom out pass 5,000:

Screenshot of rules applied, zoomed past 5,000
Map rendered when zoomed out pass 5,000

I think you can see how this rule based rendering could be very powerful, in fact I have about four different rule sets I use with the drainage layer to show different things to different people.

The rules I have shown above are pretty simple, you can go pretty crazy and use them to render OpenStreetMap data:

The worst part about the rule based rendering is that I have gotten so used to their power that I feel crippled when I go back to MapInfo and try to do styling :)

Happy mapping.

What is your favorite QGIS feature?

MapInfo Pro Feature Requests – Things I would like to see – Better thematics

I have been working on a rather large mapping project over the last couple of months, and that thought I would write a blog post about some features that I would like to see implemented in MapInfo Pro to make map making a little bit easier.  This could get long so I might break in down into different posts.

Let us begin.

Linked thematic map templates:

Thematic maps are great, I use them all the time but unfortunately they are a big pain in the butt when it comes to using and applying them across a large range of maps and workspaces and using them to keep map updated.

I will elaborate a bit on that last point with a scenario.  Lets say you have a table with a series of maintenance points each with one of the following values:

  • Complete
  • Started
  • Failed

Now we can create a thematic map to show these values:

Sweet, now we can use the Save As… template option so we can save it as something like “Maintenance – Status – Standard”, we do this so that we can apply it to other maps later on.

Now I want to save a workspace because I have all sorts of maps open that need to keep their formating, so I do a Save Workspace…. as something like “Jobs.wor” , a couple of weeks later I would like to make a new set of maps, (say for a gridded map book for the field) using the same template so that I am using the same standard colors across all my maps.   I open the table, make my grid and apply the template to the maintenance layer, everything looks good, now I save the workspace… “Jobs Map book.wor”.  So by this time we have two workspaces: “Jobs.wor”;“Jobs Map book.wor”.

After a couple of weeks I realize that I have to change one of the colors that we use to show the job status.  So we open up the and apply the “Maintenance – Status – Standard” template that we have already set up, then we change the color of the Completed job status to yellow, and do a template Save As… and save it as the same name as the old template, overwriting the old one.

Now I want to generate my map book again to bring it up to the new standard colors, I open up the “Jobs Map book.wor” workspace, and what! my colors in the thematic for the maintenance job status are still the same as they were before I updated my template.  Opening up the “Jobs.wor” workspace I find the same thing, there is a disconnection between the template and where it is used.

The reason this happens is because when you save the workspace it hard codes the thematic values right into the workspace with the map. something like this:

shade 1 with Values values
“Complete” Symbol (34,16711680,12) ,
“Failed” Symbol (34,65280,12) ,
“Started” Symbol (34,255,12)
default Symbol (40,0,12)   # color 1 #

meaning that each map in the workspace now has its’ own independent thematic map regardless of the template changes.  If I would like my two workspaces to have the template  new colors I must open both of them and remove the thematic on each map that uses it and reapply it and save.  The problem with this is that it requires the user of the workspace to be aware of the changes in the template and reapply them.  In a multi user environment this becomes difficult.  I also becomes a problem when you have a large workspace 20+ maps all using the same thematic, that is 20+ changes every time you need to make a style change.

What I think would work

My idea is just like something Peter Horsboll Moller and Gentreau in this Mapinfo-l thread suggested beck in 2008, a syntax and command addition to MapBasic.
Something like the following:

Shade <tablename> Layer <layername> Using Template <full path to template> Column <column name>

This means you would be able to store templates in one place and any time somebody opens the workspace, the theme file is read and applied to the map, meaning you will always have the latest style changes.  By using the full path or just the theme name you could store theme files on a network drive or just with the workspaces if it is only going to be used for a selected job with lots of workspaces.

You could also store something like this in the tab file meta data, to use a theme file as the default shading:

\defaulttheme\path = “<full path to template>”

Why I think this word be good.

As it’s pretty obvious from the scenario that I outlined, if you are working on a large mapping project with a table and thematic being used in all the workspaces.  The ability to update just the template and not have to worry about updating each  independent  thematic stored for map in each workspace would greatly improve map making speed.  This feature become even more needed when projects become old and not knowing which workspace and maps need to be changed.


Just saving the path to a theme template file would not always be needed(sometimes templates aren’t even needed, for one-off jobs), so hard coding the thematic into the workspace still needs to be an option, but by default it should save a template and the path to the template first rather than hard coding.

Please let me know what you think.

I am writing this as a public blog rather than just sending it straight to MapInfo because I would like to see what other people also think.  Maybe this idea can be expanded? Maybe you would like to say why it shouldn’t be done? Doesn’t matter the reason, let me know.  All comments are welcome, the more people behind an idea the better.