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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
