[mkgmap-dev] Options

Mon Dec 10 13:20:35 GMT 2012

On 10.12.2012 13:34, Steve Ratcliffe wrote:
>
> 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.
okay, got it. So it means drop maxspeed processing, drop the option, and 
move it into the style instead...
So that's best anyhow.

I would propose it to be changed that way (drop the option and new 
notation for the style-file):

road_speed=4   === set current road_speed to 4 or lower - if maxspeed is 
lower, but not higher (new behaviour)
road_speed_fixed=4 == set current road_speed to 4 no matter maxspeed, 
recommended speed, or other tags (same behaviour as currently using 
--ignore-maxspeeds)
road_speed_variable == 4 set to current road_speed 4 if no maxspeed or 
other tags exist (what other tags are actually existing in osm yet?) - 
decrease or increase it based on the tags/maxspeed (current behaviour, 
at least until there are tags like average speed in OSM).

and yeah, I'm sure autorouting and time calculation gets better, if the 
speed is not increased just because maxspeed is high. That concept was 
pretty flawed in my eyes since the beginning (it works out somehow, 
because we don't set the actual speed, but a category which is usually 
handled lower by garmin algos than the maxspeed in osm).

We cannot code maxspeed like NT maps have anyhow (meaning neat popups 
reminding you if you go to fast or similar things) - and in NT maps 
maxspeed doesn't equal average speed for calculation either.
The only change for the worse could happen for people using Nuvi GPS 
devices from Garmin with mkgmap maps regulary (without sometimes 
reverting to other maps), where the device based on past speed per 
road_class, actually increased the time for calculation). I don't know 
however what happens on map updates anyhow, and if these values are 
calculated on a per map basis, or for all maps, and how map updates 
affect it. In general it would be the much better behaviour.

For road_speed_variable - we will need some rework/extension once tags 
about the typical or average speed exist in OSM. Maybe then we would 
need to add a forth mode like road_speed_typicalspeed == 4 that is 
enacted if typicalspeed doesn't exist. typicalspeed could be set from 
various tags via the style-file.
>
>> --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.
>
yip, for right now it is not possible within the style-file. Default on 
is fine, if for right now it can be switched off.
>> --delete-tags-file= It's a performance improvement. However it was once
>> broken. Someone said it's working again. I once moved it into my style
>> where it makes more sense. Don't know how much quicker it can make 
>> mkgmap.
>
> I doubt that there is much performance improvement, especially after 
> the style re-write.
>
> I thought it was mainly so you could easily remove things from the map
> while still using the default style.
>
well if I remember it correctly, it was thought to be for maps 
consisting of very few objects, e.g. a plain POI map, or a plain railway 
map, and to speed up mkgmap. Dunno how and if it is used in that way, 
and if it improves speed.
> ..Steve

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org