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

Thu Aug 6 22:52:54 BST 2009

Hi Thilo,

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

I disagree.

The patch simply provides a means for those people who have complex
styling requirements to "roll their own" styling engine so they are not
obliged to use whatever is built into mkgmap. The presence of the patch
will not affect the development of the mkgmap styling system but by
providing people with an alternative mechanism, it will encourage
innovation and new thinking.

One could argue that mkgmap would be better off having no styling
function at all and it should focus on the core task of converting an
input dataset (styled OSM) into map files (.img, etc.)

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

Well it's not what I would do.

Cheers,

Mark