highway=footway unroutable for pedestrians by accident

[matkoniecz]

See https://community.openstreetmap.org/t/highway-footway-without-foot-yes-defeats-garmin-on-device-walking-hiking-autorouting/5232/4

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”. Unless I’m missing it, that seems to add “foot=yes” on tracktype=grade1 or grade2 only: https://github.com/der-stefan/OpenTopoMap/blob/master/garmin/style/opentopomap/lines#L172

[fortchagos]

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]

[fortchagos]

Without this fix, all downloadable maps from https://garmin.opentopomap.org/ are rarely suitable for use on Garmin devices for hiking or walking activities as it forces routing onto roads.