logo separator

[mkgmap-dev] Options

From Henning Scholland osm at aighes.de on Mon Dec 10 12:45:17 GMT 2012

Am 10.12.2012 13:34, schrieb Steve Ratcliffe:
> Hi Felix
>
> Thanks for your thoughts.
>
>> --ignore-maxspeeds  , Strong Objection. For a bicycle map it is really
>> needed. I don't want mkgmap messing around with maxspeeds. It's also
>> about performance, why calculate something if it's not needed.
> What do you object to?
>
> I'll explain what I mean by "move to style".
>
> My idea of the style system was that everything that determines how
> osm tags get converted into garmin terms was to be controlled by the
> style file. The mkgmap code should not be looking at a hardwired tag
> like maxspeed at all. If you want to change road_speed based on
> maxspeed it should be written in the style.
>
> For a start maxspeed is the wrong tag to use, a tag for average or
> typical speed would be better where such a thing exists.  At the very
> least, it should only revise the speed down, never up (I think you
> might have made that point before), because a good road going through
> a town may be be slower because of speed restrictions but a single
> track road is usually not suitable for driving a 60mph just because
> that is the speed limit.
>
>> --ignore-turn-restrictions ,Strong Objection again. We don't have
> The same applies, the style should be able to select cycle relevent
> turn restrictions if they exist, based on the style that you
> write.
>
> So OK, that's not going to happen soon, because the style system would
> have to be extended a bit to make it possible. So we will probably
> have to retain the option for now. But only because there isn't a way
> of specifying which tags should be used for turn restrictions in the
> style.
I'm using:

type=restriction & except ~ '.*bicycle*.' { delete type ; delete 
restriction }
type=restriction:bicycle { set restriction = '${restriction:bicycle}' }

in relations-file. It should work, if mkgmap handles restrictons after 
style-processing.

Henning



More information about the mkgmap-dev mailing list