replace mkgmap:bike with mkgmap:bicycle for merge-roads branch

It's really unlogical why mkgmap expects the access restriction mkgmap:bike instead of mkgmap:bicycle... (a it has always been bicycle=no, b) the osm tag is bicycle not bike, c) all other tags are using the standard garmin names.... Overall I must say I'm still not too happy with the results of the branch right now. It's now much slower (about 15%), the access rules are difficult to handle in style (I can see that they are needed, but that only no is accpeted is not really useful ), bugs in reading added values and checking for them is really painful. E.g. if I add oneway=-1 to something, then I need to check for highway=* & oneway=-1 in order to get it. I'm not sure if this bug also exists in trunk - as I just rather recently 3-4 weeks ago deleted all (if mkgmap was working correctly) highway=* usages out of my style - because I thought I could speed up mkgmap by doing it. I don't really understand how the different name fields work right now, well and for what they can be applied (points only, or also polygons and lines...). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

It's really unlogical why mkgmap expects the access restriction mkgmap:bike instead of mkgmap:bicycle... (a it has always been bicycle=no, b) the osm tag is bicycle not bike, c) all other tags are using the standard garmin names....
I aggree. I think I used the mkgmap internal variable name which was bike. But mkgmap:bicycle is better than mkgmap:bike. I will change that.
Overall I must say I'm still not too happy with the results of the branch right now. It's now much slower (about 15%), the access rules are difficult to handle in style (I can see that they are needed, but that only no is accpeted is not really useful ), bugs in reading added values and checking for them is really painful.
The branch is not ready to merge. I will check its performance and think about how to speed up if there is a problem.
E.g. if I add oneway=-1 to something, then I need to check for highway=* & oneway=-1 in order to get it. I'm not sure if this bug also exists in trunk - as I just rather recently 3-4 weeks ago deleted all (if mkgmap was working correctly) highway=* usages out of my style - because I thought I could speed up mkgmap by doing it.
The style processor bug is not branch specific. It also exist in the trunk.
I don't really understand how the different name fields work right now, well and for what they can be applied (points only, or also polygons and lines...).
There is no documentation yet. But for sure I will add it before merging to trunk.
participants (2)
-
Felix Hartmann
-
WanMil