blc-2 wrote
This is why I believe that the ultimate "fix" had to be a change in the consumption of OSM data and would require a mkgmap change. Again I could be wrong on this account and a mkgmap config change is all that's needed, as once again I'm depending on someone else's mkgmap run, and this would be something I should forward onto the mkgmap builder once I find out how to do it.
First you have to find out if the map was created with mkgmap. Garmins ships OSM maps which are created with a different tool. If the map was created with mkgmap, try to contact the map creator. The map creator is maintaining a so called style file which is responsible for the conversion between OSM and Garmin IMG format. The mkmap package comes with a default style which uses these rules: amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'} [*0x2a07* resolution 24] amenity=fast_food [*0x2a07* resolution 24] So an object tagged with amenity=fast_food will result in a POI of type *0x2a07*. There are more detailed rules to handle amenity=restaurant : amenity=restaurant & cuisine!=* [0x2a00 resolution 24] ... cuisine=bagel | cuisine=donut [*0x2a0d* resolution 24] So, maybe we should change the default rules for amenity=fast_food to treat cuisine=bagel and cuisine=donut in the same way as with amenity=restaurant to produce *0x2a0d*? Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html