Worldwide routable Garmin maps: Missing/incorrect feature requests

This topic is for requesting/reporting missing or incorrect features in Lambertus’ Worldwide routable Garmin maps @

What should be reported/discussed here:

  • Features that exist in the OSM map and should be in the Garmin map, but aren’t. Example: gas stations mapped as building polygons don’t appear currently on the map, but on a routable map they should be there and searchable.

  • Features that are rendered incorrectly. Example: amenity=shelter appears with a tent symbol and category Lodging/Park.

  • Features that you want removed, e.g. county boundaries clutter the map and get mistaken for roads.

  • Appearance changes that you would like to see in the map, eg. colours, line thickness, POI symbols.

  • More or less detail at certain zoom levels for a feature.

What should NOT be discussed here:

Once you have a request and perhaps discussed it here we would like you to enter it into our issue tracking system here: (You need a Google account to use this.) Google Code is shutting down.

If you are interested in the configuration files for the compiler they are here.

To fix all those issues, it would be necessary to implement a default, basic typ file that comes with the installation by default.
As start, we don’t have to fill in all elements there, just the problematic types. This typ file can be very basic. Elements that are not defined appear on the default way on the map.

Problematic ones like those shelters, railways, line types that are invisible without a typ file (0x10, 0x11, 0x12, 0x13, 0x100 and higher), and you can think of overlays for bridges and tunnels, will be defined in this basic typ file.

Sounds good to me. In the end it’s up to Lambertus as to what typ he wants to include.

Any idea why abandoned rail lines are rendered thus:

railway=abandoned [0x0a road_class=0 road_speed=1 resolution 22]

If all else fails route the customer through here???

abandoned railways are often in use as cycletrack or foot trail?

For info: this is what the latest MapSource displays for all available line types and most areas without a typ file:

I understand that, but that’s not how things are supposed to be mapped. If it’s a usable trail then it should be tagged as such and I don’t think the routing s/w should make such assumptions.

I propose to change them to a non-routable line with a suitable default tag.

Check out this: Useful for typ files?

And then we need examples for every Garmin type as well :-/
I would like to see forest polygon moved from 0x50 to 0x14, but then the default Garmin label will say ‘national park’ instead of ‘forest’ and people will get confused.
This issue for example can be avoided when using a basic typ file.

I think we can work something out and then let Lambertus test it sooner or later.

Looks well on the pc but too fancy for gps units. For my cyclemaps I use which are more basic

I don’t think we’ll be able to cater for all Garmin models.

You are right, I think we should have a basic.typ and an optional mapnik.typ, if you want to do that. For my liking, the lines are too thick in the mapnik style. Haven’t tried it on my Zumo yet… I’ll post some pix once I’ve done that.

Testing: I think that’s our job! :stuck_out_tongue:

Here is what these lines look on the Zumo 660:

Ok, so I’m moving this here.

I meant 0x2b06.

I see what you mean: the shelters show up when searching for Lodging. If we use any other type they won’t be searchable at all. I can’t see a suitable Garmin searchable category.

Off to bed now…

Progress report:

1: Shelter rendered as camping : needs a typ entry
2: Garmin type 0x07 needs splitting into several line types: Minko volunteered for this one
3: Railways not showing at lower zoom: fixed, needs typ entries
4: Bridges & tunnels not shown: needs typ entries
5: Ghosting effect when zooming in on latest MS: I think this is an MS bug, but need more info for possible workaround
6: Remove admin boundaries: fixed, but may have to put state boundaries back in. Need info on which levels should be shown.
7: Gas stations tagged as polygons missing: On hold. Can’t see a fix without a change in mkgmap
8: Communication towers clutter the map; water tower not rendered: fixed, needs typ entry

Minko: over to you! You can grab the modified style files here:

When you are done please put the typ file into typ/world.

Thanks Peter, I will give it a try sooner or later :wink:

About #6:

Admin level 4 is used for States (USA) Provinces (NL) or Federal States (DEU).
We can use the mkgmap locator rules to implement it for certain countries where we want the States borders on the map.
mkgmap:country=USA & boundary=administrative & admin_level=4 [0x1d resolution 19]
mkgmap:country=DEU & boundary=administrative & admin_level=4 [0x1d resolution 19]

In the NL’s Province borders are also fetched under admin level 4, but they may clutter the map.
Maybe you can decide if Australia needs their State borders (map is quite empty there anyway ;-))

BTW: country abbrev’s can be found in the locatorconfig table:

Hiking in Switzerland, where this tag is often used, I discovered that:
is rendered as toilets (both in MapSource and on my GPSMap 60CSX) … inappropriate unless the user is a dog :slight_smile:

FWIW this tag is rendered correctly (again both in MapSource and on my GPSr) in the Kowoma leisure map of Switzerland, so there is no fundamental problem.

Thanks for pointing this out. This is a curly one.

First, the fact that this is a guidepost is actually ignored. The tags for guideposts are tourism=information and information=guidepost. Perhaps you can see where this is leading to:

tourism=information is a tourist info office. This is mapped to Garmin code 0x2f0c. If you right-click on the toilet icon on the map and select Properties you will get:

Category: “Auto services”, Subcategory: “Rest Area/Tourist Info”

Unfortunately, in their infinite wisdom Garmin have decided to render this with the toilet symbol. We need to fix this with a more appropriate icon.

Toilets proper (amenity=toilets) is rendered with a different code, no problem here.

Looking at the presets in JOSM there are two other points where toilets can be found:
highway=services and highway=rest_area, both with toilets=yes. The latter is currently not rendered at all and with the former the toilets are ignored.

We are hitting a fundamental problem here: in OSM objects can have more than one tag (like a tourist info can also have toilets), but at present we have to map that to one single object in the map.


typ file entry for tourist info with a round blue i
filter out guideposts, as I don’t think they should show on a routable map (clutter)

Created issue 9.

I need a list of poi codes that are likely to be searchable by most GPS. Working on the above issue I’ve come unstuck, as toilets and tourist info are searchable in MS, but not on my Zumo. The cgpsmapper manual wasn’t useful…

I think you can find more info on that in the mkgmap archives. I think Charlie Ferrero has done some research, maybe you can find more on his website:

Whether a feature is searchable or not also depends on the GPS model. Also the display varies, sometimes you get a toilet symbol, sometimes a ? sometimes an i for tourist info. By using a default typ file we can eliminate those Garmin issues.

Maybe this can help you further

Thanks for the link to that spreadsheet.

Issue 9 is fixed. No more guide posts. Toilets and tourist offices are now searchable, at least in MS and on my Zumo.

I had to create a typ file for that. Minko, before you start on your typ file please grab mine from the svn repository.


Issue 1 fixed.

Issues 3 & 6-9 are also fixed. There is only one important fix left, issue 2: splitting some minor ways that all get rendered as alley. We have made significant progress on that one, too, but my Zumo doesn’t show all of those lines. We may end up leaving it at that… Let’s see what other tricks Minko comes up with.

Lambertus, you may want to have a go at testing some of what we have done so far, just so that there are no hidden show-stoppers.

The mapnik typ in its current form will not be totally compatible with the new definitions, but the default typ is almost required now.