Not unless your mkgmap compile is really strange. I can’t imagine why the base map draw priority would be set high; in fact I suspect that the base map isn’t treated the same way as other maps by GPSr (at least on my GPSMap). For instance, if you try to route, the GPS will never route on the base map if another routing layer is available. I would have thought the firmware would ensure that the base map was always drawn below any other map, but that’s just a guess.
This one I installed differently: renamed the file to gmapsupp.img and copied it into the \Garmin dir on my Zumo. For Lambertus’ maps I used Mapsource to install.
Routing uses only the OSM map. I tested it, turned the OSM map off and recalc’ed. Then it used the basemap.
I have discovered another problem with garmin maps from openstreetmap. Under the “Point of Interest” → “Food”, if I select a restaurant, it displays the Category as “African” even though the restaurant is tagged as “cuisine=indian”. It works correctly for “chinese”. Again, the “Asian” category does not display any restaurant which are tagged as “cuisine=indian”. I have Garmin nuvi 1390T.
I wanted to load the screenshots of the same but do not know how to upload my images. Any help would be appreciated.
That’s interesting. “African” is not a known Garmin restaurant category. What GPS do you have?
The following assumes you are using a map created with mkgmap’s default style.
mkgmap takes OSM key-tag pairs and converts them into Garmin objects. The OSM cuisine=indian key-tag pair does not result in an Indian restaurant in the Garmin map because Garmin GPS units do not offer an Indian restaurant category. So any restaurants tagged like this are instead given the default Garmin restaurant code (0x2a13) which on my GPS at least fall under the “Other” restaurant category.
The OSM cuisine=chinese key-tag pair does have a corresponding Garmin category, hence why it works as you expected.
The only restaurants that will appear in your Asian category are those that have been tagged with cuisine=asian, as this is the only key-tag pair that mkgmap uses to generate Garmin objects in the Asian restaurant category.
If you create your own style and compile your own maps, you can assign any key-tag combination you like to any particular Garmin restaurant category. For instance, I assign the following key-tag pairs to the Garmin Asian restaurant category:
cuisine=asian | cuisine=japanese | cuisine=korean | cuisine=malaysian | cuisine=noodle | cuisine=thai | cuisine=vietnamese
Thus I get many more restaurants falling into that category for the maps that I make.
I forgot to add that I’m using the NZOpenGPS map here in NZ, compiled with cgpsmapper and I don’t have this problem. It’s only with mkgmap compiled maps.
I have another problem with my garmin with the OSM. When I select a railway station (which is a node on the railway track) from the list of POIs under Travel (or Transport) and ask it for routing, it says “Can’t calculate route”. However, when I select any other point near the railway station node, it is able to calculate the route. Is it because of some limitation with the OSM data.
That is “by design” in the last two updates. I’m trying to make the maps a little lighter (easier on the server, less download bandwidth needed, buildings are not needed for routing, etc.). I’ve also filtered “type=communication” in the latest update as I don’t think it adds to the map.
This is the pre-processing filter before the planet data is piped into the initial Splitter run:
A station-node on a railway track is normally not connected to a road but have platforms and buildings surrounding it. Only when you come out of the platform/building, you will have roads.
And yes, it is able to route to a area where there are no roads. It just picks the nearest road. That means my Garmin 1390T allows a mixture of on and off-road routing.
Here is the screenshot of the same. The restaurant was tagged as “cuisine=indian” but displayed as “African”. It would be even good if it is displayed as “Others” instead of “African”
These two look like bugs in your GPS. Can you try another map?
Incidentally: petrol looks hyper expensive in your area!
Routing to and from railway stations works in MS, so again, I suspect a bug in your firmware. Unless you can reproduce this in an official Garmin map don’t expect Garmin to do anything about it.