Page 1 of 1 (7 posts)

  • talks about »
  • styling

Tags

Last update:
Thu Oct 23 08:00:10 2014

A Django site.

QGIS Planet

HTML map tips in QGIS

New fresh QGIS feature! So fresh in fact you can still smell the wet paint :)

QGIS (development build) can now display map tips using HTML (a subset anyway).

To enable the new map tips: Open the Layer Properties dialog for a layer and select the Display tab

Display tab to set HTML map tips

In action

Layer properties for HTML map tip

Notice how we can also use a QGIS expression. Anything inside [% %] will be evaluated and replaced with the value in real-time. We can even use a CASE statement. Pretty cool!

And the result when hovering over a feature

HTML in QGIS map tip? Yes! WOOT!

Hold on. Pause the track! We can even use some CSS to make it more fancy.


<style>
h1 {color:red;}
p.question {color:blue;}
</style>
<h1> [% "NAME" %] </h1>
<br>
<img src="[% "image" %]" />
<br>
<p class="question">Is this place a country?</p>
<br>
[% CASE WHEN "TYPE" = 'Country' THEN 'Yes' ELSE 'No. It is a ' || "TYPE" END %]

CSS in a html map tip

Happy Mapping :)


Filed under: Open Source, qgis Tagged: FOSSGIS, gis, mapping, Open Source, qgis, styling, tips

QGIS Style Tricks: Using styles to help fix kerb line directions

We are currently working a kerb line digitization and defect capture project at work.  This process involves looking at the aerial photo along with video of the roads and drawing lines on the kerb layer using QGIS, not overly hard just tedious.  As I mentioned in my Using QGIS in local government post, the defect points are snapped to the lines in order generate the distances, or chainage, along the kerb line for reporting reasons e.g Defect 1 at 10m, Defect 2 at 11.5m.  In order for this to happen the kerb lines must be running the correct direction, the correct direction here is defined by the road direction.    The kerb line also has an attribute to define what side of the road it is on, left or right, in reference to the direction of the road center line.

So we have two conditions:

  1. Must run the same way as the road
  2. Must have the correct side of the road assigned

The problem is how to clean up any lines that are already wrong (we were 90% of the way though when the above conditions were added).

In QGIS we can add line directions by using a two layer symbol for the kerb line:

Line with direction

Showing line direction

Not too bad but I still have to focus a lot to see which direction the lines are going.  Viewing them at this scale is fine but once you start to move the arrows all become a blur after a while.  Plus this also doesn’t let me check the side of road attribute quickly. Yes I can look at the color and the label but still I would like a quick way to look at line and see if it is facing the right way and with the correct side of the road attached.

What we can do is offset the arrows on the line so that they will be on the inside of the kerb line, between the kerb line and the road direction markers when they are facing the correct direction and have the correct side of road attribute.

For the left side we will of set the marker Line offset to 3, and for the right side we offset by -3

Offset arrow

Using the 3 and -3 offsets will mean the arrows are rendered on the inside of the kerb line if the line is facing the correct direction. Lets have a look

Opps no that isn’t right

Ohh no that isn’t right!  See how the line directions are facing the wrong way and it is showing the arrows on the outside of the line, further away from the road line.  This isn’t right.  Lets swap those line directions using a plugin that I wrote called Swap Line Direction (Search for ‘Swap’ in the plugin installer).

Lines facing correct direction

So now the arrows are on the inside of the line and are facing the correct way.

But wait there is more

This styling also helps me check that it is assigned the correct side of the road.  If we assign the top line the value ‘left‘, which is wrong in this case, we will see that the arrows are now on the wrong side of the line

Wrong side of road assigned

Of course here the obvious thing here is that there is two green lines which you can’t have, but also having the arrows on the wrong side of the line lets you quickly see which one is wrong.

It is impossible to get the arrows to be on the inside and facing the correct way.  If we swap the direction of the line the arrows are now on the inside but are facing the wrong way

Wrong side running the wrong way

Using this style trick allows me to quickly see at a glance which sections might be wrong when I have more then a single road in view

Summary

This post is a quick example of how you can use QGIS styles to help you visually validate you data.  The way I have done things in the post my not work for you and you might find it less helpful and more distracting then I did; however I found it worked well with my eyes and reduced strain.


Filed under: Open Source, qgis Tagged: qgis, Quantum GIS, styling

Better date and time support in QGIS expressions and styles

Version note: This will only work in the latest dev build of QGIS – not in 1.8

The lack of uni for the next couple of weeks has left me some time at night to work on some features that I really wish QGIS had.  One of these features was better date and time support in the expression engine.  Date and time is an important concept when working on inspection data and not being able to style my features in QGIS using date operations was bugging me.  So in good open source fashion I added some.

Here are the current functions (more to come in the future):

  • $nowreturns the current date and time
  • age({datetime},{datetime}) - returns the difference between the two dates
  • todate({string}) - converts a string to date type
  • totime({string}) – converts a string to time type
  • tointerval({string}) – converts a string to a interval type (details below)
  • day({datetime} or {interval}) – returns the day from a datetime type or the number of days in a interval.
  • hour(…) – Same as above but for hours
  • minute(…)  - Same as above but for minutes
  • second(…)  - Same as above but for seconds
  • day(..)  - Same as above but for days
  • week(..)  - Same as above but for weeks
  • month(…)  - Same as above but for months
  • year(…) - Same as above but for years
  • {datetime} – {interval} = {new datetime} – returns a new datetime subtracting the interval 
  • {datetime} + {interval} = {new datetime} – returns a new datetime adding the interval


The interval type

Functions like age(..), tointerval(), {datetime} -/+ {interval}, day(..), hour(..), etc, use, or return, Intervals.  An Interval is a measure of time that we can use for different things.  An example of an Interval is ’1 Year 2 Months’ this is then converted to a number of seconds and used for any calculations.

For example one can take away 10 days from the current date by doing the following ( -> marks the output ):

todate($now - '10 Days')
-> 2012-06-20

as

todate($now)
-> 2012-06-30

We can also do something like:

todate($now + '2 Years 1 Month 10 Days')
-> 2014-08-10

The age() function will return an interval which we can use extract what information we need.

The number of days between two dates:

day(age('2012-06-30', '2012-06-10'))
-> 20
-- Think of it as '2012-06-30' - '2012-06-10'
-- Note: day(), month(), etc, functions return doubles so you can get
-- 21.135234 days if you are using date & time type rather than just date type
-- wrap the result in toint() to get a more sane output.

Day() will also work on a plain date:

day('2012-06-30')
-> 30

We can even get the number of seconds between two dates:

second(age('2012-06-30', '2012-06-10'))
-> 1728000

Currently the only date format supported is {year}-{month}-{day} as seen in the examples above. Shouldn’t be too hard to add support to the todate(), todatetime(), totime() functions for giving it a pattern to use when converting the string e.g. dd-mm-YYYY, or something like that.

More on this fancy new stuff

When I wrote the new expression builder dialog a while ago I made it dynamic so that any new functions added to the expression engine will show up automatically.  So here they are:

List of new date and time functions.

We can also use these functions in the rule based rending, which is where the power really comes in.  Lets see something like that in action:

Styled using days and years

Should be pretty straight forward to understand. We are using the age() and day() functions to style the events that are older than 30 days, within 30 days, for today, or in the future.  We also check the year of the event using year() and year($now) to make sure we only see this years events, or style them differently depending on if they are last years events or in the future.

This is the result of the above rules:

Result of using date functions in rule based renderer

I’m also using the date functions in the expression based labelling to label the features using the following expression:

CASE
WHEN year( "dateadded") < year($now) THEN
	'Last Year'
WHEN day(age("dateadded", $now)) < 0 THEN
	day(age("dateadded", todate($now))) || ' Days old'
ELSE
	day(age("dateadded", todate($now))) || ' Days to go'
END

Well that’s it. Hope you find it handy in your day-to-day mapping. I know I will be using it a lot.
Thanks to Martin and Jürgen for the code reviews during the process; venturing in an unknown part of the code base always makes me nervous but that is all part of learning, and sometimes you can make some pretty cool stuff.
Some other random notes: The general idea has been modelled of how Postgres handles dates and times, it’s not an exact copy but follows the same kind of ideas. The interval class also uses the same number of seconds for one year that postgres does so that we can be consistent with the output.


Filed under: Open Source, qgis Tagged: FOSSGIS, gis, map-rendering, Open Source, osgeo, qgis, Quantum GIS, styling

Styling temporal (time) data in QGIS

So this years first uni semester is done and dusted, now I have some free time.  Blog all the things!

This is a follow up post for discussion that was started on LinkedIn about showing features older, or newer, then a certain date different colours   The main post was about using free, or low cost, solutions in order to aid in mapping water networks. I recommend that everyone watch it. A very good presentation.

I recommended that you could use the rule based rendering engine but the expression engine in QGIS doesn’t have any date functions yet.  All good we can add them if we need and once I get my head around the expression engine I plan on doing exactly that. But for now we can do it a different way.

We are going to use Spatialite, but any database will do (syntax and process will vary).

Lets have a look an inspection layer we have in our Spatialite database viewed in QGIS:

Pretty boring and hard to see what has been done in the last 30 days.  Now with the lack of support for dates in the expression engine we have to use another methods.  For this example we will use the really handy DBManger plugin that now ships with QGIS from 1.8.  Load it, connect to your database, and run the following query:

SELECT id,
              CASE WHEN DATE("date_checked") > DATE('now', '-30 days') THEN
                         'Within 30 Days'
              ELSE
                         'older'
              END as age, date_checked, geom
FROM  "inspections"

As you can see anything that is within the 30 days now has the “Within 30 Days” string in the age column, or else it has “older”.  CASE statements can be very powerful things in SQL sometimes.

Now load it into QGIS, style, and label it using the new age column

and Bob’s your uncle

You now have a layer that is style based on age but is also dynamic.  Adding a new inspection point will now will be styled according to those rules. (Although you will have to edit the normal inspection layer with it turned off as views/queries are not editable – without some setup anyway)

It might be a simple thing to some but sometimes it’s hard to find the right words to describe what you want when you are looking for this kind of thing. So hopefully this has helped a few people get started with visualizing their time/date based data in QGIS.

Happy mapping!


Filed under: Open Source, qgis Tagged: FOSSGIS, gis, Open Source, osgeo, qgis, Quantum GIS, styling

Improvements to the QGIS rule based rendering

The rule based rendering in QGIS has just got a make over to improve in some of the old usability issues it used to have.  Most of the improvements are UI related. If you would like to try them out you will need to grab a copy of the latest dev build (qgis-dev in OSGeo4W)

Main improvements include:

  • Nested rules.  If the parent rule evaluates to false none of the child rules are applied. This replaces the priority system in the old dialog.
  • Disable symbol for rules. Rules with no symbol only act as a check for the child rules e.g nothing is rendered for the rule but child rules still are (unless also disabled).
  • Drag and Drop rules (multi-selection is supported).  Rules can be dragged onto other rules in order to nest them and set up a rendering hierarchy.
  • Inline editing of rule labels, expressions, scales
  • Overall tweaks to the dialog

The new rule dialog

As you can see in the screenshot, the rules are now organized in a tree which clearly expresses which rules should be applied and when.

In the example above, all the rules under the Sealed rule will only be applied if that rule is true. The old system would have you managing all rules in one big list and dealing with priorities in order to get the rules to apply right, the new dialog is a major improvement.

And the results! As you can see below, QGIS will only render the colored squares if the Sealed rule is true otherwise it just shows a green line.

The rules applied

The work was sponsored by Ville de Morges, Switzerland and developed by Martin Dobias.  Thanks to both of them for these improvements.

More info:

Note: As this is a brand new feature there might be some bugs, or things that don’t quite work as expected. If you do find something don’t hesitate to file a bug report at hub.qgis.org so it can be fixed, or at least known about.


Filed under: Open Source, qgis Tagged: FOSSGIS, gis, map-rendering, mapping, Open Source, osgeo, qgis, Quantum GIS, styling

New Tool: MapInfo to QGIS style converter

Hopefully this tool can be of some use to people, as I know it has been very helpful to me since I made it.

As I’m a pretty heavy QGIS user now, and my work place still stores most, if not all, of our data MapInfo TAB format, one  friction point for me using QGIS was having to restyle all the MapInfo layers.  If we only had a handful of layer this wouldn’t be such a pain but we have a lot of tables and it would take me months to go though each one manually and style them.

I thought “there has to be some way I can automate this…” and so the MapInfo To QGIS Style Generator (or mapinfoToQgis.py) was born. Knowing that QGIS uses QML (a XML file format) to store it style information, and that MapInfo was able to export a style string for each object, I compared what QGIS generated for its QML using the same symbol I picked in QGIS as I had in MapInfo.   Almost a 1 to 1 conversion! Once I worked out how to convert MapInfo point size  to QGIS symbol size, and MapInfo colour value to RGB it was just a matter of generating a QML with the correct values.

Long story short, after a bit of clean up and writing a user guide I would like release version 0.1 of the MapInfo To QGIS Style Generator for wider testing.

Here is a quick example of the output.

Step 1: Take One MapInfo table.

Step 2: Run it though mapinfoToQgis.py

python mapinfoToQgis.py WaterFittings.Tab WatterFittings.qml -c FittingType --UseMapInfo

Step 3: Load QML file in QGIS

Result from running mapinfoToQGIS.py

Step 4: Get a beer?

If you are using MapInfo Font symbols or normal MapInfo 3.0 everything should come across almost exactly. mapinfoToQgis.py will use the same fonts in QGIS as you did in MapInfo and select to the correct symbol size. Although if you are using custom MapInfo 3.0 symbols you will get the default QGIS black square symbol,you can just change it to something better after loading the QML.

Currently the program only support converting symbols but I plan on adding line and region support sometime in the future.

The program can be found at https://github.com/NathanW2/MapInfo-to-QGIS-style-generator and more detailed instructions and download link can be found at https://github.com/NathanW2/MapInfo-to-QGIS-style-generator/wiki/Using-MapInfo-to-QGIS-style-generator.

Like I said at the start, hopefully other people will find this tool handy as I know I have.  If you do find it handy let me know, I would love to hear peoples feedback.  Also if you find any bugs let me know in the comments or log a issue on https://github.com/NathanW2/MapInfo-to-QGIS-style-generator/issues

Enjoy :)


Filed under: MapInfo, Open Source, qgis, QGIS for MapInfo Users Tagged: gis, mapinfo, MapInfo Professional, mapping, Open Source, qgis, qgis-vs-mapinfo, Quantum GIS, styling

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: http://www.youtube.com/watch?v=NBBYtH2svw0

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?


Filed under: Open Source, qgis Tagged: gis, map-rendering, mapping, Open Source, OSS, qgis, Quantum GIS, styling, thematics

  • Page 1 of 1 ( 7 posts )
  • styling

Back to Top

Sponsors