logo separator

[mkgmap-dev] [PATCH v2] - styling for the power user

From Marko Mäkelä marko.makela at iki.fi on Fri Aug 7 10:22:07 BST 2009

Hi Mark, Thilo, list,

> The problem here is that in the end you cannot separate the styling  
> from the map conversion process. When I started using mkgmap I also  
> used preprocessing. But then I found that my preprocessor had to  
> duplicate a lot of the functionality of mkgmap to "do it right". For  
> example finding all the ways that belong to a relation. It was much  
> easier to patch mkgmap to get the same results, because all that  
> information is already accessible there. But of course one could argue  
> if this "convenience" is a reason in itself not to separate styling  
> and map conversion.

For what it is worth, I agree with Thilo here.  The Unix philosophy of
combining simple tools is preferrable when it works, but OSM is huge, and
all of the graph has to be kept in memory during the processing.  Command
pipelines and scripts work nicely when working with simple text files, when
linear access to the data is enough.  But I wouldn't want to load and dump
large volumes of data even more times than currently (bzip2 decompression,
splitter, mkgmap).

The mkgmap:* would be great for quick prototyping or for those who prefer
preprocessing or prefer to work with their favourite scripting language
instead of Java.  This brings about a question of dependences and coordination.
If people start writing preprocessor scripts in their favourite languages,
suddenly you might need a host of runtime environments (Perl, Python, Ruby,
...) with all sorts of libraries, in addition to the current Java dependences.

Can we have the best of both worlds?  The best preprocessing transformations
would eventually be ported to mkgmap plugins that would be linked to mkgmap
style rules.  Examples of such plugins include plugins for naming objects
and for filtering or duplicating objects (lines or points, e.g., refactoring
the current code of duplicating cycleways or transforming areas into POIs).
We can start small; I'd be happy with the naming plugin framework for now.


More information about the mkgmap-dev mailing list