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

Fri Aug 7 10:47:05 BST 2009

Hi Marko,

> 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).

I agree, performance could be an issue although not a show-stopper
due to the cheapness of multi-core CPUs and RAM.

> 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.

Exactly, give people a choice.

As to the runtime requirements, what is required to be installed depends
on whatever technology is used to implement the styling filter but
unless it's seriously esoteric, you wouldn't expect it to be a
problem. These days, most of the common languages are
available for all of the major platforms at the click of a button.

> 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.

Of course.

I am not for one moment suggesting that development of the
mkgmap styling engine (MSE) should be limited. As you suggest, (with the
patch) it would be possible to prototype and develop styling schemes
outside of mkgmap. If successful, those schemes could then be
incorporated into the MSE.

Remember, the zero-style patch only disables the MSE for elements
that have a mkgmap:gtype tag, so all other elements that don't
have that tag will still be styled by the MSE. This allows "selective
styling" by an external program that could be useful for testing
styling regimes without having to implement them in a prototype form
within mkgmap.

So, unless there are compelling reasons not to incorporate the patch, I
will commit it before too long as I believe in the long-run it will
prove to be useful.

Cheers,

Mark