logo separator

[mkgmap-dev] [PATCH v1] - clone ways that contain some tag pairs

From Thilo Hannemann thannema at gmx.de on Sun Jul 5 22:31:35 BST 2009

Am 05.07.2009 um 21:44 schrieb Mark Burton:

>
> Hi Thilo,
>
>> I think it would be advantageous to generalize this kind of  
>> behaviour.
>> What about a "continue" flag in the Garmin type definition in the
>> style files? This continue flag would indicate that a match with that
>> rule generates a copy of the way, but that the processing continues
>> with the next match. For example:
>>
>> boundary=administrative [0x1e resolution 12 continue]
>> highway=primary [0x06 level 12]
>>
>> This would have the same effect as your new command in that with the
>> boundary=... line one copy of the way is generated, but the  
>> processing
>> for that way is continued with the highway=... line and another way  
>> is
>> generated. The advantage of this is that it is also very useful for
>> POIs, where the tags on one node might indicated the generation of
>> different POI entries for the same node. It would also make the not-
>> very-well-documented and buggy overlays style file obsolete. And it
>> gives a good start to deal with the encoding of different values for
>> the same key with the ;-syntax, which is currently ignored by mkgmap.
>>
>> What do you think about it?
>
> Sounds like a good idea.
>
> I can see that my offering is very narrow in it's scope. It maybe
> solves a small problem when there's actually a somewhat bigger problem
> to solve.
>
> However, I know zilch about the style stuff (and I don't want to know
> about it, yuk!) so someone else can think about implementing your
> suggestion.

That's fine.

I have to admit that it is not that easy to implement. But I'll have a  
try at it some time. It's only that I do not feel the urge to work on  
it if it doesn't get included into trunk. In principle it is ok for me  
to implement stuff just for myself - after all I'm selfish here and  
implement the functions that I think I need. But it will need some  
changes deep in the code that will probably interfere with the ongoing  
development of mkgmap. And if it doesn't make it into trunk I'll have  
to work on my patch continuously to keep it working. So the "shallow"  
patches that are mostly orthogonal to everything else are more  
attractive to me.

Regards
Thilo




More information about the mkgmap-dev mailing list