New Approaches for Map Rendering

It is quite amazing what can be done with good data and current map rendering technology. Mapnik and other renderers have continually pushed the envelope and there are many examples of beautiful maps out there.

But there is a problem: Writing stylesheets or other configuration for map renderers is getting increasingly difficult. Style sheets with thousands of lines are not unusual. The Mapnik stylesheet used for the main OSM map now has more than 9000 lines! Some pre-processors like Cascadenik and more recently Carto have been developed to help with that. And they do make the life of the cartographer easier. But I think they do not go far enough.

I think we have fallen into the same trap that many software developers have been falling into for years. You create a tool and give it a few configuration options to make it more flexible. Soon somebody asks for more functionality and more options. You add a few options. Then more requests for more options come in. You add some more options. The configuration gets increasingly complex, so you add some macro layer to make it manageable. Sooner or later you end up inventing an ad-hoc Turing complete programming language inside your application with a rather strange syntax because it pretends to still be a configuration.

We have seen the same pattern in many other places, for instances the configuration for the Exim mail server or the Apache web server (especially the rewrite module). (And if you can’t do something in their native configuration languages, you can always insert Perl code into the configuration.)

I think this approach with configuration files is fundamentally limited. We need a rendering toolkit instead of just a rendering tool. Something built upon a general purpose programming language that can use the power of that language. Programming languages have evolved over time to give us immense power by introducing such concepts as subroutines and modularization, concepts that are sorely needed in mapping. Cartographers writing mapping stylesheets still have to think in such terms as colored lines and icons. And that is just too limiting. We need higher level concepts such as “line with border”, “roads”, “road networks”, etc. Those concepts should be programmed once and for all into a “subroutine” that can be re-used again and again. The “road” renderer might be built on top of the “line” renderer, but it knows about oneways and bridges and road types. The “road network” renderer in turn is built upon the “road” renderer and knows how roads connect. When you create a new map styling you should be able to choose the “road network renderer X using data source A” and combine it with the “water features renderer Y using data source B” and the toolkit should somehow bind those together and do the rest. And if you don’t like the way the roads are rendered and the “renderer X” doesn’t give you enough ways of changing it, you can switch to “renderer Z” and plug that in. Just like with programming you mix and match libraries and your own code to create a result you could not have gotten by starting from the basics.

I don’t know yet how such as renderer would look exactly, but I have some ideas. I quite like the approach that Protovis is using. Protovis is a Javascript toolkit to render graphs like bar charts or scatterplots. Instead of giving you a limited set of graphs and some configuration language to parameterize those graphs, it gives you building blocks that can be assembled into simple or complex graphs. It might not be as easy to create a simple graph as it is in other frameworks, but it gives you an incredible amount of freedom and allows you to create complex composite graphs that other tools can not do.

I have started working on some experimental renderers to explore these ideas. They are not supposed to be complete or fast or produce nice maps. They should just help with exploring the problem space and possible solutions.