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

Thu Aug 6 22:09:29 BST 2009

Hi Mark,

Am 06.08.2009 um 21:49 schrieb Mark Burton:
> 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.

thank you for your effort, but I would go with the "the mkgmap style  
engine has to be fixed/enhanced" approach. Of course you could add  
preprocessing, but that is already possible now (think mp-files). By  
proposing preprocessing you just divert "programming power" away from  
mkgmap - everybody starts his own preprocessor instead of improving  
mkgmap. This will make "decent mapmaking" for starters even more  
complicated as it is now.

Some thoughts about styling:
What we see right now is the move from a "conversion table" to a  
"macro/programming language". As you say, the style files were never  
intended to be able to do the things we want them to do now. So what  
can we do about that?

We could "improve" them until they are Touring complete. But I don't  
think we should. Because then we would only create another programming  
language with another syntax and all the problems that arise from  
that. What I propose is to keep the style files, perhaps even  
*stripping* features from them (action rules, default_name). To  
implement all those nifty new tricks I'd like to have a plug-in  
interface in mkgmap to add my own Java routines. That could be plug-in  
at compile time, no need to make it too complicated. It would be a  
start to sort through all the classes and provide some documented  
hooks to plug-in your own routines. Then in the style files one could  
"invoke" the plug-ins that one would like to use.

An excerpt of the lines style file might look like this:

highway=secondary [0x04 namefinder=default_highway  
filter=DouglasPeucker(keep_junctions_fixed=true)  
routebuilder=default_routable(road_class=2, road_speed=3) resolution 20]
natural=coastline [0x15 namefinder=fixed(name='coastline')  
filter=DouglasPeucker resolution 12]

By selecting the namefinder, the filter, the routebuilder etc. one has  
complete control about how the data is processed. The routines could  
accept parameters in parantheses behind their name for added  
flexibility. Some (standard) routines are supplied, but it should be  
easy to add your own. By having a defined interface it gets easier to  
interchange improvements - currently the patches need often quite some  
work to get them to compile all together.

By partitioning the work between routines each one can be relatively  
simple. So for example one namefinder routine could just be  
responsible to find a name for a highway. Another one could be  
responsible to generate a name for a POI for a building that has  
address information.

This will also mostly eliminate the need for action rules. As I think  
the action rules code is - say - quite complex, this might remove one  
area of "oddities".

By keeping the style files and out-sourcing the complex programming  
into Java plug-in-routines the style programming stays simple for the  
users that only change the style files themselves, but power-users can  
still program everything they like in plain Java. As the plug-in  
routines can be selected from the style files, the regular-users can  
also benefit from the work of the power-users, even if they can't  
program in Java themselves.

Any thoughts about that?

Regards
Thilo