Future Mapnik

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

osm.xml

Anyone familiar with the inner workings of OpenStreetMapwill know about the challenges of applying cartography to the wholeplanet - osm.xml(mapnik stylesheet) tells us a great deal about it (the size of thefile certainly does). So far Mapnik has handled anything thrown at it, andthe recent move to using XML entities in osm.xml (requires libxml2 parser) is a big steptowards making things a little bit more manageable. Still, the sheer numberof different Styles, Rules and Filters is overwhelming. Of course, XML is not for humanconsumption, but in reality this is how osm.xml isconstructed - 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 notthousands of them. Richard Weait has written about it here. Of course, it would be great to have customized/localizedhighwayshields and this is just about possible,but it would require hundreds of lines XML. Fortunately, Richard Weaitalso 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 existingfilter 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 canbe 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 arbitary expressions. Well,'file' actually uses special type of expressions - 'path expression' (more aboutthis 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 redundantentries in osm.xml by a factor! It also paves the way to themulti-shield world: if only we could know which country we're in:)OSM data is not very helpful here, maybe this will encourage adding newk: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 countryhas its own pattern based on that country's national flag. I knowthis is a bit far fetched, but nevertheless it shows the concept quiteclearly and the resulting map is fun. With current filter/rule logicyou'll have to create more than 250 rule objects, each with its ownfilter to catch individual countries - hmm.. nope. With the newexpressions 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 witha map like this one, great!:

Posted by artem on 08 December 2009.

Tweet