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.
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.
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.
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.
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.
@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.