Highway=path wiki page additions and updates

Just posting a heads up that the highway=path wiki page has been updated recently. Some good details about real world usage of this overly broad and problematic tag have been added, and some of the previous default assumptions have been removed.

I wasn’t sure about these changes so I reached out to the author here. I think the reasoning all makes sense, but just wanted to post a bit more widely in case there is any disagreement or ideas for further improvement.


Lots of that looks good to me, particularly “When left untagged for forms of access=* as above, data users can only guess”, and “Be aware that due to the wide variety of path qualities, routing engines may apply a penalty for cycling or other modes of transportation for paths without other tags that specify surface or access conditions.”

Personally I’d replace the whole page with “This is a bad tag and you should not use it” but I realise that might not meet with universal approval :wink:


On the talk page I just suggested (somewhat in jest):

This tag barely means anything at all. To add actual meaning, please use some of the following tags as well.

1 Like

If you think that about highway=path what would you suggest for landuse=grass …?!?.. :thinking:

I see a problem: As access considered undefined, are mappers expected to add foot=yes and then all the this=no and that=no to footpaths? There should be a shorthand, will vehicle=no do?

That sentence there should be in bold letters, otherwise it may be wishful thinking forever. Not a lot of routers are as diligent as cycle.travel, as far as I can tell.


I support the notion of a shorthand very much, but I’m afraid vehicle=no is not it.

If I consider most forest area’s and other nature reserves in my country that I know, they commonly have access signs that give a default access regime for that area that state something like

  • you may walk on paths unless stated otherwise
  • you may only cycle and ride your horse on paths that designated for that use by a sign on the path
  • motor_vehicles not allowed.

Often I know the designated cycle routes, so I can use that knowledge to assign the tags “bicycle=designated” vs “bicycle=no” (or vehicle=no if you prefer shorthand) to the paths outside the cycleroute in the area.

But other users can NOT derive from that that walking on all these paths with vehicle=no (and without foot=*)is allowed ; some may very well be closed for all public traffic (such as a part of the forest that is a wildlife rest area, or paths that have become disused en therefore prohibited ). I have not established that you can walk here (didn’t visit all the paths outside the cycle routes, that takes several days) , only that you may not cycle there.

And furthermore: in some countries there is also the subtle difference between foot=yes (legally enshrined right to walk) vs foot=permissive (the owner may revoke the right to walk on that path at any moment). Some paths in the area can have the foot=yes status, while others (in my country: most) have the foot=permissive status (see also here)

And of course it really depends on the regulations in your country (right to roam enshrined by law vs access=permissive as legal default) and the situation on the ground (how often is the general access overruled by traffic signs or access signs or fences that prohibit all use or some modes of transport.

A more general shorthand (that could also serve on roads in built up area’s) might be some new tag along the lines of access_restrictions=none


1 Like

I have added two examples of routers that give a penalty for certain road types (beyond footway / bridleway) that are missing explicit access-tags for bicycle in Examples of routers that use other defaults then the tables in this wiki . Cheers.

I’m somewhat confused here - you link to this, which in turn links to this page, which seems to contain no useful content (“Use this page to suggest routing profiles for a range of different users and scenarios.”)?

More generally, the problem with “Examples of routers that use other defaults then the tables in this wiki” is that most of the examples there are pieces of software that you choose how to configure when you deploy. For example, with mkgmap (something many people here will be familiar with) someone creating a map will choose “how the want to do routing” along with all the other choices they make when they’re creating that map.

Some individual deployments of particular routers might give rubbish results, but that doesn’t mean that the router software used is inherently “bad”, just that it has been poorly configured.

Hi, I mentioned this for another reason than the the Routing profiles linked there page (I did not add that piece myself).
The examples I mentioned were cases where I added that they use a penalty for some ways that do not have explicit access-tags on the way in OSM (despite the fact that these tags are seen as default in the tables in that wiki): Brouter and Graphhopper.

Some individual deployments of particular routers might give rubbish results, but that doesn’t mean that the route software used is inherently “bad”, just that it has been poorly configured.

I did not mean to suggest by adding those links that these routers are bad, on the contrary: in my opinion it is wise for routers to give a penalty to highway=path without a positive tag on the OSM-way for cycling, at least in the country where I live. For most of the areas in my country I would advise to use bicycle=no as a default on untagged highway=path

The reason I added those examples to the wiki is that is that we have had different assumptions on the concept of defaults and routing behavior, which have led to repeated undiscussed mass deletions (example) of valid foot=yes and bicycle=yes tags from highway=path and other highways. Mapper argued that these tags are needless and should be removed because they are the same as the values in the default table (at that time, the some values in the default tables in the wiki have changed…)

Furthermore it was argued that all routers use (or should use) the country specific defaults in that wiki and that these tags are needless because deleting them would not influence routing behavior. These examples show that routers may very well use other default values and that routing results can be changed when deleting access tags that some consider “needless because they are default”.


Then we are two :slight_smile: Actually, this problem is as old as path itself. You just raise awareness. And that is highly in order.


All the default BRouter bike profiles route over highway=path (with no additional tags) if you force them to do so: BRouter web client (playing around with the two no-go areas will reveal how big of a detour they would take in order to avoid this segment).

Adding foot=yes or even bicycle=yes to such a path would only make things worse (from the perspective of these routing profiles): BRouter web client (the trekking profile is mislead by the bicycle=yes in this case).

I am not saying that this is the behavior that a router should exhibit. But those profiles do not do it that way because they are stupid. They do it because it works well most of the time (in Germany).

highway=footway is a good shorthand :slight_smile:


For most of the 8 billion people on the planet, most of the time they’re not in Germany :slight_smile:


@SomeoneElse, but Germany is only one of those countrys which have some sort of Freedom to roam which does affect the meaning of undefined access tags.

My argument would be that forcing the use of foot=yes and bicycle=yes on highway=path would actually further reduce the usability of highway=path in these countries, since there would no longer be a distinction between undefined and yes.

Can you expand on that a bit? I don’t understand what the problem is here…

for bicycle/foot/horse unset yes is the default values
, so it can not have any difference in meaning.

I see two problems:

  • if you explicitely state an implicit rule, what do you do if the implicit rule changes later on?
  • if foot=yes or bicycle=yes is already implied, people tend to use explicit foot=yes or bicycle=yes to indicate actual usability (which is wrong, but common practice). If we now change the default logic (in these countries) this might break more than it fixes.
1 Like

But this is 13 years practice and I would expect a new proposal to change this.

Your examples show that the standard Brouter trekking bike profile uses a cost factor of

  • 100 000 $/km for a bare highway=path (without any access tags) and
  • 1 050 $/km for a highway=path with bicycle=yes added

That seems just fine to me for usage in my country, and also in parts of Germany, since I understand that

Is riding a bike in certain parts of the forest forbidden?
[…] Each Bundesland has their own rules, so there’s no general answer for all of Germany. It’s possible you are only allowed to ride on gravel roads, or on pathways wider than 2 m, etc.

Which I also read sometime ago in a German cycling magazin and is also illustrated by this example:

In 1995, Baden-Württemberg tightened up §14 of the Federal Forest Act, which generally allows bicycles to ride on paths, by introducing the two-meter rule in §37.3 of the State Forest Act BW. This prohibits cycling in the forest on paths less than two meters wide.

If you worry that a path where cycling is legally allowed (bicycle=yes only means it is legal), but which is practically not really suitable for general cycling, is being used by routers, please

  • add information to the way in OSM that reflects this (such as surface= and smoothness=horrible etc.)
  • suggest to the person maintaining the routing profile to use a penalty for highway=path which is missing smoothness=* and/or surface=* tags (or to increase the penalty if they already do that)


1 Like

Yes, I misunderstood what you wrote at first, sorry.

I believe that an implicit yes and an explicit yes have a difference in meaning.