[OSM-dev] Mapnik XML file?

Jon Burgess jburgess777 at googlemail.com
Fri Sep 7 21:02:28 BST 2007

On Fri, 2007-09-07 at 18:52 +0200, Andreas Volz wrote:
> Am Thu, 6 Sep 2007 19:13:56 -0400 schrieb Christopher Schmidt:
> > On Fri, Sep 07, 2007 at 12:12:14AM +0200, Andreas Volz wrote:
> > > Hello,
> > > 
> > > where is the Mapnik XML file and the icons in SVN that are used to
> > > render the official map?
> > 
> > I think this is what you're looking for:
> > http://svn.openstreetmap.org/applications/rendering/mapnik/
> Thanks for the link.
> I'm very interested in a recent XML file for Mapnik. I develop a Mapnik
> based car-navigation system. But I'm not happy with the supported
> number of POI's in the official file. For this reason I did many local
> changes and the official and my personal XML file have some
> differences. I do also not like the OSM Mapnik XML file, because the
> image path is /home/steve/symbols/. I've some ideas and questions:
> What is the current way of changing the Mapnik XML file?

It has been an evolutionary process. Generally there have only been a
handful of people making updates to the file. Things have been added
over time as people have found things they want to see on the map. e.g.
see the SVN log for osm.xml

>  I assume at
> first a definition should go its way from proposed feature/icon to the
> map features site. But who does then insert it into the XML file?

In theory anyone with SVN commit access could do it (and if not they
could raise a trac ticket). In practice almost no one does. In part this
is probably because it has not been easy to make and test changes to the

> I think a wiki is great for large amounts of more or less unordered
> information. But I think it's abused for the map features "database".
> it was good for the start, but not any longer. I'll try to explain you
> my idea.
> At first the features are collected in a database. Then there's a clear
> and well defined state for each feature. The application should be web
> based. Example:
> 1) Someone proposes a new feature.
>    a) Key, Value, Element, Comment, Example, images are stored in a
>       database
>    b) state=proposed for this database element
> 2) The voting starts at a specified date.
>    a) all voting registered users get a reminder email
>    b) each vote is saved in the database
>       Wiki could still be user for discussion if needed
>    c) If voting end date is reached it get state=approve or
>       state=disapprove in the database
> 3) A osm.xml is created (e.g. weekly) from this database.

A nice idea, do you have an implementation of this?
In my opinion this is non-trivial.

> 4) Some nice HTML pages should be created to visualize and manage the
> database. But I'm not a very experienced web designer. :-(
> This will ensure that the process of features and proposed features is
> cleaner and much faster. I've seen much bad stuff with the current way.
> There are some approved features and someone simply removed them
> without any discussion. There're a lot of features without a starting
> vote for month. Or there're approved features that nobody copies to the
> approved features page or into the Mapnik (or osmarender) file. It's a
> complete mess and I don't like it. Perhaps other people think the same
> about the current situation.
> Another first and simple step is to move the Mapnik data
> from /home/steve/symbols/ to /usr/share/osm/symbols or similar. This
> would save some useless sed work without hurting someone.

I don't have a strong opinion, whatever is set in the file I'll probably
still use sed to rewrite it anyway. Even the main tile.openstreetmap.org
installation uses different paths to the one in the osm.xml file.

> What do you think about these ideas?

Sounds OK but it may be tricky to automatically generate everything in
the osm.xml file. How about you try starting with something relatively
simple like generating a set of rules for rendering POIs?

The route which I think may be more useful is having a visual editor for
the osm.xml file. Artem has made a start on this but it needs more C++
coding effort from someone to enhance the 'editing' side of the
software, currently it only displays and renders the file leaving you
to edit it by hand. It is much easier to update the file when you can
instantly see the result. See


More information about the dev mailing list