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

Thu Aug 6 20:49:08 BST 2009

Hi Torsten,

> > What it does is give you the possibility of doing all of the style
> > processing outside of mkgmap. If mkgmap's styling support is
> > sufficient for your needs, use that. If not, you can style your data
> > before it gets processed by mkgmap using some other application.
> 
> Also with normal mkgmap you can doo preprocessing of the osm data. But
> most people seem to try getting most out of the styles without an extra
> processing step.

Yes, that's right and from the emails we see on the list, perhaps
people are now trying to do stuff that wasn't really imagined when the
mkgmap style engine was designed and are, therefore, running into
issues.

> Right now, I don't really see, how your approach makes things easier.
> Can you provide an example, how the map generation would look like with
> your patch?

The way I see it is:

1 - the mkgmap style engine is good for moderately complex styling.

2 - for more demanding styling, either the mkgmap style engine has to
be fixed/enhanced to support whatever new demands people want to make
on it, or ...

3 - we can provide some simple hooks whereby you can do the styling with
some 3rd-party application (not mkgmap) as a pre-processing step.

To be honest, I am surprised that people haven't taken to pre-processing
the map data already.

So the sequence of steps to make the map could be:

1 - split big map into tiles

2 - pre-process tiles to add style info

3 - generate .img files using mkgmap

The pre-processing could be done by a dedicated program
(java/c/perl/python/...) or by some form of transformation process
(xslt?) or even simple text substitution (awk?)

I'm not saying this is trivial to implement but if you really want to
do some funky styling then it may be easier to create an external
pre-processor than trying to express your requirements using the mkgmap
style language.

Cheers,

Mark