Future Mapnik

Recently I had chance to work on new features for Mapnik, thanks to sponsorship from Richard Weait. I'm so excited about these new features, I even named the new branch mapnik2.

osm.xml

Anyone familiar with the inner workings of OpenStreetMapwill know about the challenges of applying cartography to the whole planet - osm.xml (mapnik stylesheet) tells us a great deal about it (the size of the file certainly does). So far Mapnik has handled anything thrown at it, and the recent move to using XML entities in osm.xml (requires libxml2 parser) is a big step towards making things a little bit more manageable. Still, the sheer number of different Styles, Rules and Filters is overwhelming. Of course, XML is not for human consumption, but in reality this is how osm.xml is constructed - by human hand and that file isn't getting any smaller...

Every road needs a shield

There are lots of shields in Northern America. In fact, hundreds if not thousands of them. Richard Weait has written about it here. Of course, it would be great to have customized/localizedhighway shields and this is just about possible,but it would require hundreds of lines XML. Fortunately, Richard Weait also had an answer - dynamic parameters.Sounds good, so how can we make it work?

New expressions engine

Welcome to the new expressions engine. It's based on Boost.Spirit2.1 (the old one was spirit1 aka spirit classic). The existing filter grammar was re-implemented to support expressions. In the past,filters would be evaluated at runtime to return boolean true/false(match/not match); now, the result of evaluation is a mapnik value - it can be any of these : bool, int, double, UnicodeString.

This naturally begs the question: 'can we evaluate other things at run-time,too?'. And, sure, we can! Currently, the mapnik2 branch allows 'filters', 'name' and 'file' attributes to be arbitrary expressions. Well, 'file' actually uses special type of expressions - 'path expression' (more about this later on). And we are planning to add more support in the future. Expressions themselves canbe any valid combination of the following :

Expressions

Primary expressions
Boolean	true, false
Integer	123
Float	123.456 or -1.23e-04
Unicode String	'unicode'
Attribute	[attribute name]
Multiplicative expressions
Mult	2 * 2
Div	100 / 1.23e-4
Mod	12 % 10
Additive expressions
Plus	123 + 456
Minus	123 - 456
Relational expressions
Less than or equal to	<= , le
Less than	< , lt
Greater than or equal to	>= , ge
Greater than	> , gt
Regular expressions
regex_match	(123 + 1).match('124') [name].match('^United.*')
Equality
Equals	= , eq
Not equals	!= , <>, neq
Logic
Not	not , !
And	and , &&
Or	or , ||

I added perl-like alias operators to avoid escaping in XML.

[val] ge 1000.00

looks better then

[val] > &eq; 1000.0

Path expressions

Path expressions grammar is very simple at the moment.You're allowed to use attributes as part of a file path e.g

file="/opt/mapnik/osm/symbols/[highway]/[length].png"

While this is not complicated it reduces the number of redundant entries in osm.xml by a factor! It also paves the way to the multi-shield world: if only we could know which country we're in:)OSM data is not very helpful here, maybe this will encourage adding new k:v's , we'll see. Enough talking, let's have an example.

Flags of the world

Let's imagine you want to create a map of the world, where each country has its own pattern based on that country's national flag. I know this is a bit far fetched, but nevertheless it shows the concept quite clearly and the resulting map is fun. With current filter/rule logic you'll have to create more than 250 rule objects, each with its own filter to catch individual countries - hmm.. nope. With the new expressions approach we will get there with just one simple rule :

<PolygonPatternSymbolizer type="png" file="/opt/mapnik/mapnik-flags/flags/Flag_of_[cntry_name].png"/>

The [cntry_name] attribute is evaluated at run-time and we end up with a map like this one, great!: