Highway=footway without foot=yes defeats Garmin on device walking/hiking autorouting

I’ve discovered and verified that highway=footway without a foot=yes tag prevents the Garmin autorouting algorithm from using such ways when the routing activity is set to “Hiking” or “Pedestrian Walking”. It seems Garmin does not honor the implication that “highway=footway” implies “foot=yes”. Therefore, it is not sufficient to just tag a foot path with highway=footway and expect to include these path in Garmin autoroutes.

I verified this autorouting issues by generating a two Garmin compatible maps (.img) using mkgmap version 4897 and testing on a Garmin GPSMAP 66s. I suspect a similar issue would likely to occur for cycling autorouting when “highway=cycleway” without a “bicycle=yes” tag.

This brings up the question to the community about how to fix this. Makers of Garmin compatible maps can workaround this issue by adding “highway=footway {set foot=yes}” to their mkgmap lines style file forcing all “highway=footway” to also have a “foot=yes” (and similarly, “highway=cycleway {set bicycle=yes}”.

Doing a bulk update adding foot=yes to every highway=footway in OSM is probably out of the question. Another fix could be a modification to mkgmap to automatically add “foot=yes” to footways. Has anyone else discovered this issue or have better suggestions?

UPDATE: This appears to be a map generation problem - not a tagging issue. See thread below.

1 Like

It’s certainly not true to say that all OSM-generated maps for Garmin devices won’t route foot traffic unless foot=yes is set (I’ve just tested it).

It might depend on the map style, or the device (I’ve tried various etrex devices, a Nuvi, and Gpsmap64 and gpsmap64sx devices).

Which map styles did you try?

Edit: mkgmap_style_ajt/lines at master · SomeoneElseOSM/mkgmap_style_ajt · GitHub is an example of the rights that you’re saying should be in the style.

I think you’re correct - but I’ve never seen a mkgmap map without something like that in the style?


The maps I create are based off the style used to create the OpenTopoMap Garmin Maps available for download from https://garmin.opentopomap.org/. I actually discovered the issue using one of these downloaded maps.

I also tested using a Garmin map for the same area downloaded from GMapTool site. These autoroute hiking/walking paths with no problem.

Looking through the lines style file, I yet to find rule that sets properties that prevent autorouting. Perhaps the issue is a difference between mkgmap and say cGPSmapper? It certainly does not sound like a tagging or device issue but how the Garmin map was produced.

The style I based my maps on is available here. GitHub - der-stefan/OpenTopoMap: A topographic map from OpenStreetMap and SRTM data.

1 Like

Unless I’m missing it, that seems to add “foot=yes” on tracktype=grade1 or grade2 only:


1 Like

That what I’m seeing too and a line I’d removed from my style. Since few footways have track grades it seems this rule would rarely hit across the whole OSM data set. That would explain whey the downloaded maps do not autoroute on footways. My maps wouldn’t because of that reason and because I removed this line. Seems my fix in the original post was not a fix but the correct way to enable foot only autorouting - I just didn’t know it at the time.

1 Like

Now to get the guy who generates those OpenTopoMap downloads to update his style. I’m not looking to create these large maps myself and, of course, me generating them myself doesn’t solve this issue for other users of those maps.

opened highway=footway unroutable for pedestrians by accident · Issue #332 · der-stefan/OpenTopoMap · GitHub - though repository seems abandoned

Thanks. I added the following note to that issue.

I speculate this style was intended for rendering in Germany. A spot check of highway=footway in Germany did not find any footways tagged with tracktype. However, spot checking highway=track found almost all tracks are tagged with tracktype. Perhaps the authors intent was to make all footways, paths, and grade 1/2 tracks foot accessible. If that was the case, the logical AND (&) needs to simply be changed to a logical OR (|).

This rule makes the assumption that only track type grades 1 and 2 are walkable which is certainly not the case. It also makes the assumption all paths are open for walking access and that is certainly not the case as their are many paths that are open for cycling but closed for walking. It seems it would be safe to assume all footways are open for foot traffic and all cycleways are open for cycling but it is not safe to assume every path or track are open for foot or cycling access. The rule here needs to be refactored to not override the access settings on paths or track. Also recommend the rendering be broken out from overriding access properties.

(highway=footway|highway=path) & tracktype~‘grade[1-2]’ {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 22]

1 Like

Is there someone from Garmin who could explain this particular logic?

The problem is not related to Garmin software. It is about a style file for the mkgmap program which has it’s own logic to convert OSM data to Garmin map format.
See https://www.mkgmap.org.uk in general and esp. https://www.mkgmap.org.uk/doc/pdf/style-manual.pdf for the syntax rules.

1 Like

@IanH To add to what Gerd has already linked to, I wrote a diary entry recently to try and simplify the process. See also this readme in github. I’m running it on Linux but I’m sure it’d also run from WSL in Windows too.

You can edit that script and the map style that it uses if you want to test the effect of simple changes. Running it for an English county takes only a minute or so on my (quite old) laptop; you can also use QMapShack to look at the resulting maps.

One more thing - individual Garmin devices vary, certainly in rendering, and QMapShack doesn’t necessarily match how a map would appear on any particular one. A bit of experimentation with styles is often required.