You are not logged in.


*** NOTICE: By 30th of September 2022 the will be retired, please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators. We expect the migration of data will be finished by that date, you can follow its progress here.***

#1 2022-02-17 18:09:33

Registered: 2021-08-07
Posts: 34

Garmin rendering oddities


I assume, some of you may as well have stumbled over Garmins "special" treatment of several types ignoring the style, probably individual by different Garmin hardware units. Dealing with sports and outdoor devices, I've come across phenomenons like

Rails (0x14)being rendered at high(est) zoom resolution(s) only.

Plenty of points/POIs being ignored (e.g. on an Edge 1030: 0x2B01, 0x2B03, 0x2E01, 0x2E03, 0x3001, 0x3002, 0x4300, 0x4A00, 0x5000, 0x660B, 0x6116, 0x6404, 0x6411, ...) Maybe Garmin intends to declutter some units more than others this way, but it results in e.g. neither police stations nor hospitals beeing rendered on a cycling device, not even from Garmins own maps. Unless other types are used intentionally in own styles...

While level L0/resolution 24 may correspond to a zoom level of 200 m (detail: normal) on a device for lines and most of points/POIs (respecting all other levels as declared in the respective style), some point types (e.g. 0x2E05, all of 0x4E..) are rendered only at zoom levels of 80 m and below (would be something like level -1! 0x4E is dec 78 hahaha) and do not respect the style. But those types are quite helpfull to e.g. declutter downtown areas and the like for navigation focussed maps.

Since I've found the rail thingie in the web (unfortunately being aware already only), but not the other ones, I wonder, if there isn't already a collection of knowledge about such special treatments existant somewhere anyhow and somebody could just give me a pointer.
Alternatively, any additions to my trial and error generated list would be highly appreciated.

Cheers Felix

Last edited by argetlam (2022-02-17 18:12:12)


#2 2022-08-15 22:00:18

Registered: 2014-01-30
Posts: 13

Re: Garmin rendering oddities

The way the newer Garmin firmware on Edge units displays maps has me sticking with old firmware on my Edge 830. I was just given a 1030 plus so I'm taking another look at what's going on with the newer firmware.

One thing I noticed is that it looks like Garmin implemented a line scaling system. Before the lines were a fixed width regardless of zoom level, so as you zoomed out you quickly ended up with a blob of overlapping lines. With Garmin's map you can zoom out to city scale and the main arterial roads are still recognizable. It doesn't do scaling with my custom map made using mkgmap. So I suspect these new features are supported by additional properties within Garmin's maps that mkgmap doesn't support yet.

I imagine they also introduced new properties for POIs that control whether they are displayed. For my custom map I have a bunch of POIs all of which stopped appearing after the newer firmware was introduced.

I wonder if these changes are being implemented across all Garmin devices or if the fitness division is introducing their own compatibility breaking enhancements.


#3 2022-08-21 17:41:25

Registered: 2021-08-07
Posts: 34

Re: Garmin rendering oddities

Operating an Edge 1030 myself I'm not shure about Garmin using a line scaling system. But I think its good practice to assign different types to lines representing p.e. the same roads at different levels/resolution in your style, like

highway=primary      [0x10e0c road_class=4 road_speed=4 level 7-7 continue]
highway=primary      [0x10e02 road_class=4 road_speed=4 level 5-6 continue]
highway=primary      [0x10e12 road_class=4 road_speed=4 level 2-4 continue]
highway=primary      [0x3b    road_class=4 road_speed=4 level 1]

Besides other possible differences 0x10e0c could/would have less width than 0x3b, hence result in "scaling".

Regarding POIs my understanding atm would be, that Garmin not uses properties by POI but POI classes (seperate lists of types for each feature below) by Firmware (hopefully consistent by device class / Garmin division), to support the following features for the respective POIs

#1 Visibility
Only selected types/subtypes are drawn at all.
There is a standard mapping of resolution (as in style) vs. device zoom (as by scale/ruler on screen) for points, lines and polygones alike. But at least some points behave differently: show up even later than resolution 24 from the mapping, independent of assignment by style. Somewhat similar to the detail-less or least settings on device.
So far I'm not aware of such oddities at lower resolutions.

#2 Garmin Categories
Only few types are put into the on-device search categories (typically from 0x2, 0x3 type families), quite seldom multiple types into one category. Not all of these are drawn, some visible POIs are not assigned to any category (#1)!.

#3 Fulltext Search
Most (all?) of #1 and #2 but plenty more types can be searched for via the fulltext search under all POIs. This gives a list w/ proximity and heading that can be used to get a mapmarker. The search works on mkgmap:label:1.

#4 "Search on Map" Feature
This feature as well is available from the on-device POI search, but compared to #1 additional types are drawn, if defined and having an xpm assigned.

There seems to be somewhat similar behaviour in basecamp (w/o exact relation to a single device!), but I'm on Linux only.
I'm often using QMapShack, which seems to way more tolerantly draw any mkgmap type on the declared resolution but is quite sensitive to multiple type assignments to one point for the same resolution (which can be a workaround for the Garmin devices), due to POI proximity (blue dots instead of xpm, even if one type is single transparent pixel only).

Did I miss or misinterpret relevant functionality?

Last edited by argetlam (2022-08-21 17:43:31)


Board footer

Powered by FluxBB