December archive

Future Mapnik

December 8, 2009

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 OpenStreetMap will 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/localized highway 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.Spirit 2.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 arbitary 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 can be 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] &gt; &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!:

Regex replace

December 16, 2009

Regular expressions are very useful when working with text. We already had 'match' operator which can be used in filter expressions. In Mapnik2 we now also have

<mapnik-expression>.replace(<regex>,<pattern>)

Here is a small example :

>>> from mapnik import *
>>> f = Feature(123)
>>> f["name"] = 'Mapnik'
>>> expr = Expression("[name].replace('(\B)|( )','$1 ')")
>>> expr.evaluate(f)
'M a p n i k'

New Mapnik OS X Framework Installers

December 16, 2009

Download the OS X installers

Over the last year of my involvement with Mapnik I've seen a huge growth in Mapnik users running on Macs. While most ultimately deploy their mapping systems on Linux, for many it all starts on the Mac.

Macs for Mapping?

OS X, with XCode installed, is a great platform for getting up and running with Mapnik as Apple provides many of the solid *nix libraries you need to get started compiling. Apple also pre-installs a multi-architecture build of the latest Python release, which makes getting started with Python easy.

But this same batteries-includes philosophy can trip up from-source installations due to the potential for duplicate libraries and python versions, especially when users are employing open source packaging system like Macports.

Additionally...

What if you're at a conference and don't want to download the several GB's needed for the iPhone/XCode development environment just get a vanilla Mac rendering a few OpenStreetMap tiles?

What if you are deploying Mac mini's in the field and need a fast, lightweight, offline deployment setup?

Or what if you just need to get your designers up and running with Quantumnik and QGIS and don't want them to have to hassle with Python versions?

It could be easier

For all these reasons, and more, it should be easier, and it can be.

Now you can just head over to dbsgeo.com and grab the latest release or latest trunk build and you can have Mapnik running in literally minutes.

Thanks to the support from Development Seed, the great wisdom and advice of William Kyngesburye , and many months of testing from a long list of intrepid Mapnik users, these installers should be pretty solid. If you find problems or have suggestions to improve them (there are certainly lots of potential ways!) please post your reports to the Mapnik Trac site.

All News