Talk:Tag:highway=path

Using path in unusual cases

Paths versus fixed rope routes and climbing routes

In my view, there should be a clear distinction between a path (accessible to anyone with a reasonable fitness) and things like fixed rope routes and mountain climbing routes that require mountaineering skills and safety equipment. As pointed out here, all are currently often tagged and thus rendered as hiking paths or footways. Either one is clearly inappropriate. I am aware that a combination of highway=path, trail_visibility=... and sac_scale=... would do the job, but I believe that there should be a more strict separation between paths and (climbing) routes. A route up the Matterhorn is simply by no means a path. Any suggestions? Ukuester 08:28, 6 May 2009 (UTC)

sport=mountaineering? sport=rock_climbing? On the other hand, just because it's at high altitude or across a glacier doesn't mean it's not a path... (meaning that many mountain routes may indeed be paths). I would feel comfortable tagging anything sac_scale=T4 and below as a path. sac_scale=T5 is probably pushing the limits of a path though.

Fixed rope route (Klettersteig)

I realized, that numerous fixed rope routes (e.g., the famous Jubiläumsgrat heading east from Zugspitze) are currently tagged as highway=footway, sometimes with additional sac_scale classification, sometimes not. I think the tagging is fine in principle, nevertheless this is quite problematic since the current renderers render them as if they were usual hiking/walking ways. Compare for instance the level walking way around the Eibsee with the strenous and demanding fixed rope routes around the Zugspitze. They are rendered exactly alike. This should be changed but who should be approached with this respect? Ukuester 17:02, 2 May 2009 (UTC)

• Not just the Zugspitze, the Hörnligrat of the Matterhorn is also shown as a path. Its also graded according to the SAC scale(albeit with a FIXME), which is completely inaccurate: It's a rock climb at TD/ZS on the standard scale, and also not a path. There are therefore issues both with tagging and rendering. SK53 19:16, 2 May 2009 (UTC)

• Why not extend the scale? We just need to add sac_scale=climbing or sac_scale=via_ferrata wikipedia:Via_ferrata Basically saying this is a thing beyond sac_scale. The only bad thing about this is that this makes the key name "sac_scale" a bit inappropriate. However all of this stetches the meaning of highway path or footway. To prevent rendering one would need a generic-specific highway type like highway=sportway. This would prevent rendering, but making mappers aware of the new type would be a challenge. Katzlbt

• I just found a new tag "via_ferrata_scale=3C" Innsbrucker Klettersteig

Hi, this problem should imhao be discussed on the highway=path page. Doesn't anyone feel hurt if I move this discussion there ?. I totally agree this is quite a problem with path, but not only does it concerns via ferrata, but any activity which is one special sport path. I've allready commented some time ago on the very same problem about cross country skiing. A via_ferrata path, a cross country skiing path, a climbing path have in common that hikers might be unable to use them. (I said "unable" to differ from "not allowed" as tags such as foot=no could have been used for that) sletuffe 12:06, 9 October 2009 (UTC)

(discussion on the ski case moved down there) sletuffe 16:48, 30 November 2009 (UTC)

• Back to the first remark, In my opinion highway=path shouldn't be used for via_ferrata and climbing route. I know we could add something like via_ferrata_scale and climbing_scale and that could do the job to express it isn't a "common path" and special equipement is required, but when thinking at those who use the data, they'll need to constantally adapt the rendering/routing/any software as special options are added. The piste map project is working rather well and doesn't clutter with other uses because it created a different set of tags. I would propose we do the same and invent a :

• highway=climbing_path
• highway=via_ferrata
• + adding additionnal options such as via_ferrata_scale and climbing scale (and define them correctly in the wiki !)

sletuffe 17:03, 30 November 2009 (UTC)

5 years later, it's done, I suggest not to use highway=path for via ferrata, and instead, use highway=via_ferrata (read that proposal for more informations) sletuffe (talk) 22:58, 18 February 2015 (UTC)

Proposition to move out from path "snow only path"

Edit : After more english language research, what I wanted to refere to down there was backcountry skiing, it doesn't change the problem but I wanted to make it clear. sletuffe 16:01, 11 October 2009 (UTC)

We came accross a problem with path when they are used in snow convered only conditions (I refere to cross country skiing) The example in the front says A path for bicycles(...) and cross-country skiing could be tagged as: (...) ski=designated + bicycle=designated

Well, it works well when in winter it is used by skiiers and in summer by mountain bikers, but what happen when this path only exists in winter for cross country skiiers ?

• highway=path + ski=designated is wrong as this is not a matter of a route has been specially designated (typically by a government) Usability by hikers or horses is not forbiden, it is just that physicaly, in summer there is no "path"
• highway=path only is not good either as there is still no summer path. The path only exists in snow conditions.

Interpretation of the data then becomes a problem as there is no way to make distinction between an hiking summer path and a winter cross-country skiing path.

One solution would be to add some tweaks like only_exist_with_snow=yes / only_exist_without_snow=yes but that would need much work on software using the data on already tagged data without.

My view is that the Proposed_features/Piste_Maps is good at dealing with snow related/only ways and we shouldn't try to cover everything within path.

I propose to explicitly remove snow related things from path (snowmobile and croos-country ski) and let something like :

• piste:type=cross_country
• piste:type=snowmobile

do the job.

In the case of a really shared path between skiier in winter and hiker in summer, we could do just like it is done for piste:type=downhill when it's a track, tag it like :

• highway=track + piste:type=downhill +...

In the path case, it would be :

• highway=path + sac_scale=* + piste:type=cross_country + piste:difficulty=bla

sletuffe 01:36, 12 September 2009 (UTC)

If there is (in summer) "something's there, usable for navigation but for some reason you can't call it at least a footway", then it's a path with suitable tags to describe what the heck then travels there - skiers in this case. And if there's in winter a maintained cross country skiing piste, then it bloody well is ski=designated. Alv 08:31, 12 September 2009 (UTC)

I'm thinking of cases where (in summer) there is nothing to make it distinct from any other place in the mountain. What "with suitable tags to describe (...)" are you refering to ? sletuffe 10:30, 12 September 2009 (UTC)

Anything =designated (or possibly =yes in some cases). Alv 13:03, 12 September 2009 (UTC)

That is not how I understand designated (as I explain above) and refering to Tag:access=designated This tag indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. Which is not the case here. The mountain I'm refering to is free for anyone to travel in. So this path has not been specifically designated as a cross-country skiing trail. But physically it is nothing. That's why I think the way to describe path would be better as "physical existence without snow" sletuffe 14:31, 12 September 2009 (UTC)

Yes, I was too much thinking of a situation like the "first example picture on a snowmobile path". ski:nordic=yes. Since there is the skiing track in winter, there won't be impenetrable bushes, steep cliffs or the like, features that might exist nearby - You'd rather follow the skiing trail route if you were lost in the wilderness and there are no specific hiking trails nearby, even when there isn't any other physical indication of pedestrians users along the skiing track - if there are, it has the foot=yes. Alv 08:59, 13 September 2009 (UTC)

(moved here for easier reading)

• • Cross country skiing should be covered in the piste: namespace piste:type=nordic Piste Maps. No problem to move, just please keep move notice and a link here or the other way round. Thanks.

Okay, I do totally agree with using piste:type= namespace (However nordic is a bit different, I'll propose a piste:type=cross_country or else) but, do you think the piste should keep having a highway=path ? sletuffe 15:09, 11 October 2009 (UTC)

If the piste is just bushes, scree or it's otherwise not apparently visible in the landscape when there isn't any snow, it's better without a highway=path; and the other way round, if there's something usable for transport or navigation in the summer, I'd tag it as a highway=path foot=? wheelchair=yes/no etc. Alv 08:15, 12 October 2009 (UTC)

To give a feed back on this, what I meant by "cross country" seams to be called "ski touring" in english, and was added to the piste map project [piste:type=skitour]. So there shouldn't be any need to use path with it (unless it also is a walking path in summer) sletuffe 16:49, 30 November 2009 (UTC)

path common usage

foot=yes ?

Can you give an example of a path where foot=no ? -- Pieren 21:39, 6 December 2008 (UTC)

Sure. The first example on the example page, assuming foot traffic is not permitted across that rocky field. --Hawke 00:14, 7 December 2008 (UTC)

This tag implies foot=yes because it's a exception if not. -- ck3d 16:40, 4 May 2009 (UTC)

Without a tagged foot=yes it's foot=unknown - it can or could be assumed to be legal but nothing is said about if it is suitable for any pedestrian. Alv 16:51, 4 May 2009 (UTC)

Ok, I see in your example with rocky field that the path doesn't exist or exists only in winter time when there is snow. I would say outside this exceptional case, omitting foot means foot=yes. Like omitting oneway means oneway=no. -- Pieren 23:10, 28 August 2009 (UTC)

key description evolution

Recent changes

@Multimodaal: Thank you for recent changes you made to this page. I'm not sure it's all quite accurate, though. -- Ezekielf (talk) 05:07, 29 December 2022 (UTC)

Hi @Ezekielf:, thanks for your remarks, I hope I can illustrate the background of my edits, but I must admit that this tag is particulary hard to give a good definition for, as can be read in the sources at the end of the wiki. -- Multimodaal (talk) 10:08, 29 December 2022 (UTC)

I've not seen the assertion that highway=path is always too narrow for four wheeled vehicles before. -- Ezekielf (talk) 05:07, 29 December 2022 (UTC)

It is mentioned in the linked page https://wiki.openstreetmap.org/wiki/Path_controversy#Things_that_all_agree_on since that page's beginning (2009) :

Things that all agree on : [...] 
-highway=path:Something not wide enough for four wheeled vehicles [...] 
-highway=track: Implies that it's wide enough for a small motorcar to drive on, even if it's illegal.

This also reflects normal current common tag usage for mappers who are adding low level ways to OSM in an non-populated area where OSM is missing these ways when access is not known:

-if it's narrow use highway=path (and not footway/cycleway/bridleway)

-and if it's wide use highway=track

Though it is true that the tag is for ways that are not intended for or generally used by four wheeled vehicles, some paths can be quite wide and may be used very occasionally by such vehicles for repair work or emergencies. -- Ezekielf (talk) 05:07, 29 December 2022 (UTC)

I agree, I tried to catch that (and the OR following the quote above) in adding "normal" to "use", but there may be better options. I will add "typically" as well, but if you have a better text, please, let's improve it together. -- Multimodaal (talk) 10:08, 29 December 2022 (UTC)

Also the removal of "open to all non-motorized vehicles and not intended for motorized vehicles unless tagged so separately" from the first sentence seems questionable to me. Was this discussed publicly somewhere that you can link? -- Ezekielf (talk) 05:07, 29 December 2022 (UTC)

I think this point was best explained by the developer of the Brouter-routing engine in this contribution on the routing-defaults wiki: https://wiki.openstreetmap.org/w/index.php?title=OSM_tags_for_routing/Access_restrictions&diff=prev&oldid=1854724

This proposal here creates big confusion by mixing two completely independent questions: 
(1) what is the legal access if an OSM way has no access tags, 
(2) what is the legal access if a (real world) way is not signposted.

in the case of highway=path a suggested default-value got mixed up with the definition: a path is not open to non-motorised traffic by definition (when it's closed for all the public it's still a highway=path, we don't use an alternative highway-value because of this).

An assumed default of bicycle=yes will be in conflict with the legal default in some states, for example:

-in this state the legal default is bicycle=no on highway=path: https://www.dimb.de/fachberatung/interessenvertretung/projekte/2mr/

-in this country the legal default is bicycle=permissive (and not =yes): https://wiki.openstreetmap.org/wiki/NL:Toegangsrecht_in_Nederland#Juridische_basis:_toegang_bij_gedogen_van_de_rechthebbende )

-in this state the legal default is bicycle=permissive, but the de-facto default routers should assume is bicycle=no, since there are access-signs in the field that prohibit cycling on some 90% of highway=path ; more than 50% of all highway=path have the bicycle/vehicle=no tagged in OSM, and the remaining paths that are untagged for access in OSM also are bicycle=no in the far majority. So a defintion saying "bicycle=yes unlessed tagged otherwise" would be incorrect. See: https://taginfo.geofabrik.de/europe/netherlands/utrecht/tags/highway=path#combinations

And country-specific defaults that are suggested for routers in the wiki for highway=path contain many values that conflict with "open to all non-motorized vehicles and not intended for motorized vehicles unless tagged so separately" (such as horse=no ; moped=yes ; motorcycle=yes) : https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions

I will add a reference to this in the data consumers section

In addition also see above: https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dpath#foot=yes_? :

Without a tagged foot=yes it's foot=unknown

In the past confusion about( the meaning of) implied access on highway=path has led to the mass-deletion of thousands of correct access-entries (e.g. https://www.openstreetmap.org/changeset/42399529 ) my aim is to avoid such confusion and the deletion of correct data by other mappers. If you have suggestions on how to improve the text I would be happy to see them. Cheers! -- Multimodaal (talk) 10:08, 29 December 2022 (UTC)

Thanks for the in depth response. I think that all makes sense. It's certainly an overly broad and not well defined tag. Perhaps the wiki should just say "This tag barely means anything at all. To add actual meaning, please use some of the following tags as well." /s :-D. I started a discussion on the community forum in case anyone else has thoughts on the matter. --Ezekielf (talk) 16:46, 29 December 2022 (UTC)

More Recent Changes

Recently @Ezekielf: made some changes. IMO the wording that @Multimodaal: had before is better. Keep 'A generic or multi-use path that is typically not wide enough for normal use by double tracked vehicles and that may or may not be open certain modes of public traffic.'

[added by @Bradrh: on 30 jan 2023 16:38 ]

Post vote modification

During the proposition of path : Proposed_features/Path A clear sentence was available and has now disapeard from this page : highway=path is a generic path, either multi-use, or unspecified usage. The default access restriction of highway=path is "open to all non-motorized vehicles, but emergency vehicles are allowed" As it become amended somehow ? Sletuffe 10:09, 12 June 2009 (UTC)

guideline to path vs. track

The recently added clause "If a path is wide enough for four-wheel-vehicles, it should at least be tagged as a highway=track if not explicitly designated to pedestrians, biclycles, horeseriders,..." is misleading, even more so with the different interpretations of the word "designated". There's plenty of ways for walking and cycling in urban parks, that do not have any signs indicating that they can't be used by cars (any signs at all, in fact), and which are tagged as cycleways or footways (or path if you really must in your country). Yet tagging them track would be wrong. Because of the controversy around highway=path I'd rather not edit it myself right away. I'd suggest something along the lines of

"If a path is wide enough for four-wheel-vehicles, and it is not legally signposted or otherwise only allowed for pedestrians, cyclists or horseriders, it is often better tagged as a highway=track." Alv 20:13, 10 October 2009 (UTC)

Also both sentences have the same meaning, yours is much clearer in that it avoids using "designated" and insist on the "legally" and thus avoid the controversory and it's unclear (well not for every one) meaning. sletuffe 01:15, 11 October 2009 (UTC)

I'd like to add that putting it right into the introduction of "path" might be a bit too proiminent. I would prefere another chapter later in the page. sletuffe 01:17, 11 October 2009 (UTC)

Rationale

Benefit and abuse of the tag

In 2007, highway=path was proposed with the intention to replace highway=cycleway and highway=footway.

Fortunately, the depreciation of highway=cycleway and highway=footway was rejected. This way, highway=path has become a classification for narrow ways with a bad surface or vage designation.

Nevertheless, some mappers stick to the original idea and repeatedly destroy the more specific classifications, which are understood by renderers better than access-tags of a "path".

There are two unanswered questions:

• What benefit should the displacement of highway=cycleway and highway=footway have had for any user or program in 2007?
• What benefit for any user or program shall be provided today by the use of highway=path for well defined ways with good surfaces?

** Example:

• • • If a cycleway is tagged as highway=path because it is also allowed for pedestrians, some renderers don't show it as a cycleway any more. Readers of the such a map designed for showing cycleways (with highway=cycleway) can't see, if cycling is forbidden or allowed, and how is the surface.
    • If every designated/allowed and approriate for cycling is tagged highway=cycleway, pedestrians have no problem. They know that almost always there is either a shared use or an adjacent or nearby footway; they can use it at least like they can use a road.

--Ulamm (talk) 14:07, 29 September 2014 (UTC) The problem has lost most of its virulency: Now the mapniks detect path/bicycle=designated, too.--Ulamm (talk) 17:23, 30 September 2014 (UTC)

General Discussions

skiDisputed and snowmobile trailsDisputed

I propose to remove ski and snowmobile trails from list of features mappable as highway=path. Both are extremely differing from other features mappable as path and deserve a separate tags Mateusz Konieczny (talk) 07:45, 14 July 2015 (UTC)

see my reasoning in the top section of this page. In short : +1 sletuffe (talk) 10:18, 14 July 2015 (UTC)

+1: Ski and snowmobile trails may be mapped as a route-relation http://wiki.openstreetmap.org/wiki/Relation:route --geow (talk) 20:19, 8 August 2015 (UTC)

Edited Mateusz Konieczny (talk) 21:15, 28 July 2015 (UTC)

-1 Ski and snowmobile trails are an existing item on the ground. It's no different than a bike path (except permissions to use are limited to skis/snowmobiles instead of bikes.) --Hawke (talk) 14:44, 23 September 2015 (UTC)

Poorly visible / hard to pass tracks

Ways marked as highway=path are mapped in hiking apps / maps as regular trails, indistinguishable from clearly defined trails. Some hiking trails in dense vegetation are hard to see and hard to pass. What is a sensible limit to passability to map it as a proper way ? I am inclined to remove trails if a walker will not be able to follow it without help, but othere prefer to map it once it is navigatable with help (e.g. by the path being drawn on the map, similar to alpine climbing routes being mapped as 'normal' trails).

Removing link to country specific access restrictions

The tables in OSM_tags_for_routing/Access-Restrictions currently contain at least one value that is in contradiction to the approved proposal and everyones expectation. The link to the table was introduced relatively recently by this edit and in effect retroactively changed 7 years of mapping practice and changed meaning of all previously mapped paths in Austria without explicit tagging bicycle=yes/no.

Such changes should not be made without broad consensus, preferably an approved proposal.

It may be okay to reintroduce the link if it made sure that it won't reintroduce any new breakage, this would probably amount to removing fields such asfoot,bicycle etc for highway=path from the tables. RicoZ (talk) 11:30, 7 August 2015 (UTC)

Richard, is the contradiction you mentioned country-specific to Austria only? Then we should consider a specific reference for the austrian exception and not withhold the valid information in OSM_tags_for_routing/Access-Restrictions to the rest of the globe.--geow (talk) 21:16, 8 August 2015 (UTC)

I did not validate all 29 or so country specific tables for other possible pitfalls. Instead I am wondering - what valid information is there in OSM_tags_for_routing/Access-Restrictions which is a useful refinement to path and does not contradict the approved definition - "open to all non-motorized vehicles"? Belgium and a few other countries add "moped=yes" - which might be a valid extension but I wonder what those "paths" really look like and if they have additional sings etc. Swiss adds "inline_skates=yes".. for paths?? Hong Kong says for path "bicycle=yes" with a footnote "Bicycles must use a cycleway alongside if present" :)

The mofa/moped could be valid extensions - if verified that this is generally valid without additional signs etc but given the state of the "Access-Restrictions" table itself it might be better to list those in the highway=path page in a table.

To explain, the "Access-Restrictions" table it seems to be an early shot ("not yet fully drafted") and does not know about "permissive". What is worse, it seems people did massively misunderstand what the table means - especially the "unless tagged otherwise" principle of a default value. Looking at the footnotes.. "Bicycles are often allowed on pedestrian roads, but this depends on the sign used", "Restrictions for bicycles, skateboard, and rollerblade usually posted at the entrances to such area", "Allowed only when additional sign "Sallittu mopoille" is present"," If the signs "footway" and "cycleway" are posted together, or if there is no warning "no foot", foots can use cycleways", " On pavements, it is illegal to cycle unless designated (hence not a default setting here)".

The table - even when fixed - might be fine for official highways but rather useless for "OSM-defined" highways like track and path because those escape a simple legal definition. RicoZ (talk) 13:09, 9 August 2015 (UTC)

Another problem I see is that the permissions will be likely different depending on the value of key:informal. In particular I have significant doubts that informal paths in Belgium do allow mofas by default for example. RicoZ (talk) 11:06, 13 August 2015 (UTC)

Link to "UK public rights of way"

UK public rights of way redirects to "United Kingdom Tagging Guidelines" and this one has not a single mention of "highway=path". The original page supposedly moved to UK access provisions which again does not mention highway=path. So is there any reason to keep (restore) this link? RicoZ (talk)

Rendering

For those who are wondering why highway=path is now rendered as highway=footway, here're some pointers:

• issue #1698 stop displaying highway=footway and highway=path differently
• issue #1766 highway=path/footway should not be assumed to be paved by default
• pull #1713 unify=path/footway styling, show surface for highway=path/footway/cycleway

PS Personally I hope this is not the final battle in the path controversy, the outcome is disappointing. Salmin (talk) 10:09, 24 August 2015 (UTC)

Is there a way that I can get a path to render with obvious directional arrows (or to render arrows at all)? Here is an example of a mountain bike/hiking trail near me, which needs the direction of travel clearly shown on the map. --TreeStryder (talk) 03:14, 29 June 2017 (UTC)

Animal tracks

See also Talk:Animals#Animal_tracks. Jidanni (talk) 14:19, 7 December 2017 (UTC)

highway=path is defined too broadly and it is now resulting in unnecessary Search and Rescue calls

The definition sounds clear enough: "highway=path is a generic path, either multi-use or unspecified usage, open to all non-motorized vehicles and not intended for motorized vehicles unless tagged so separately. The path may have any type of surface. This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails as well as combinations of the above."

However, when combined with "sac_scale=difficult_alpine_hiking" and "trail_visibility=no" the definition is much broader and can include rambles over unmarked and unimproved boulderfields, snowfields, and glaciers that require technical equipment as well as sections that require some level of climbing with hands. That seems very inconsistent with the general description. Those routes would justify an entirely different designation and should not be captured under "highway=path".

Importantly, there are now many companies producing mobile phone apps to assist hikers and many of these maps use OSM data. Often (partly because the sac_scale is not applied consistently,) everything that is established as "highway=path" is rendered in the same way. In many areas, most of these routes are hiking trails but there are occasional mountaineering routes mixed in and they all look the same on the map.

In British Columbia, Canada, there have now been multiple Search and Rescue incidents attributable to user confusion in these scenarios.

I suggest that highway=path should not include any routes that require the use of hands to pull oneself up the mountain and/or are inaccessible to people of reasonable fitness, in good weather, with normal hiking shoes. (We must acknowledge that any hiking trail can become inaccessible during extreme weather events or when they are covered in snow.)

I agree that paths which require equipment or climbing with the use of hands are not tagged correctly, and will lead to wrong assumptions if mapped as paths. "Reasonable fitness" will maybe not be a convincing argument for those that add the climbing trails as paths anyway (can mean a lot of things, depending on the person being "reasonable") ;-) --Dieterdreist (talk) 09:48, 16 October 2018 (UTC)

"is now resulting in unnecessary Search and Rescue calls" - [citation needed]. Such claims without even a faintest reference confirming this as are worse than useless Mateusz Konieczny (talk) 17:03, 17 October 2018 (UTC)

I found one case https://www.cbc.ca/news/canada/british-columbia/michael-buckingham-vancouver-hiker-rescued-north-shore-crown-mountain-1.4857646 and it was caused by combination of inexperienced tourist without proper equipment (for example proper maps) and known maps.me issues.

"

His companion would eventually turn back, but Buckingham, an avid hiker, pushed on — planning a circular route using the Maps.me app on his phone.

He planned to descend by dark, but the hike took longer than he expected, because he says the app didn't take into account the steepness of the terrain.

"

In this case problem was caused by extreme underestimation of time required on hiking routes with significant altitude changes - that I reported in 2017 on maps.me bugtracker ( https://github.com/mapsme/omim/issues/6980 ). Report was ignored like other bug reports directed to maps.me. Note that changing data model would not solve this problem.

So I am waiting for anything confirming that "highway=path is defined too broadly and it is now resulting in unnecessary Search and Rescue calls" Mateusz Konieczny (talk) 10:59, 18 October 2018 (UTC)

Agree, but sac_scale has been around a long time and apps ignoring it are utterly broken so I would leave that. However I would very strongly argue against any further abuse of highway=path such as Proposed_features/Via_ferrata_simplified]. RicoZ (talk) 20:13, 18 October 2018 (UTC)

Singletrack/Doubletrack Distinction

Distinguishing between singletrack and doubletrack is extremely important for a number of reasons—ATV and jeep riders (including emergency first responders) need to know a path is wide enough to accommodate their vehicles. Cyclists can use the distinction to determine which bike is a best fit for the terrain. Foot travelers and equestrians may want a wider path to allow non-destructive side-by-side use, dog walkers may be seeking a wider way to allow their pets some room to roam without the leash tangling, etc. Just generally, recreational users will have a very different experience based on whether or not a given way is singletrack or doubletrack.

I (and many, many others) have been using highway=track for this distinction (there are numerous references in the wiki that would suggest such usage is appropriate when paths will accommodate a small car "even if it's illegal" or "used for various leisure activities") but have since been told this is incorrect; because of highway is a "functional" key, its tagging must be based on some sort of ineffable Platonic Ideal of what the highway=* really is, and "highway=track" is apparently reserved only for ways that are primarily "forest/agricultural use".

Assuming this is correct for the moment (and sidestepping my feelings on the subjectivity and faulty assumptions behind this philosophy), a reliable Boolean value for whether or not a way can accommodate a two-track vehicle is needed. width=* is not an acceptable proxy—aside from being sparsely used and almost always estimated, it's extremely variable, difficult to populate and render, and highly subjective. For example, in the case of the decaying roadbeds that pepper the American West, is the width=* value applied to just the worn-in path, or the distance between path-side obstacles that might obstruct a vehicle?

While numerous pathtype=* keys have been suggested in the past (because bigger picture, highway=path is a sock drawer and should be as discouraged in use as highway=road), I think something as simple as double_track=yes could accommodate this need, especially since the "default" use for highway=path in practice seems to be a way that will not accommodate a two track vehicle. --Cosmocatalano (talk) 16:50, 9 June 2020 (UTC)

Re: "is the width=* value applied to just the worn-in path, or the distance between path-side obstacles that might obstruct a vehicle?" Usually it is the width of the visible path surface which is tagged, since this can best be seen and tends to vary less. In many places it is illegal to drive a motor vehicle off of the regularly maintained road surface. Where this is allowed, then the presence of a visible roadbed or path is less important. --Jeisenbe (talk) 20:13, 9 June 2020 (UTC)

highway=path vs highway=footway vs highway=cycleway

Can someone from the "authorities" update the specification of "highway=path" and others?

1. Here on the Discussion page is stated that "Approved features/Path - the original proposal from 2007" was proposed with the intention to replace highway=cycleway and highway=footway. But "the depreciation of highway=cycleway and highway=footway was rejected", meaning that all 3 tag combinations are still valid!

2. Based on the example photo of Tag:highway=path and the comment of "surface" key and other keys it becomes clear that tag is intended for trails/hiking mostly in rural/countryside/wild areas without asphalt (or other similar) surfaces.

3. Example on Tag:highway=cycleway for "Combined cycle- and footway" is almost the same as described in point 2.

From those 3 points a question rises: why "Usage as a universal tag" of Tag:highway=path section is still valid, where it's stated that "highway=path" should be used for ways marked with combined cycleway signs? And why this tag is still default in JOSM preset? Maybe it's time to review the usage of this tag?

--Ursus (talk) 09:16, 3 March 2021 (UTC)

This tag is also in common use for mixed cycleway/footway (universal tag), not only for unpaved paths Mateusz Konieczny (talk) 10:07, 3 March 2021 (UTC)

That was exactly my point! If we have 2 tags (highway=footway and highway=cycleway) that both logically correspond to paved ways, why it was decided that highway=path that corresponds more to unpaved path should be used for combined cycleways and was put into JOSM preset instead of highway=cycleway? --Ursus (talk) 10:56, 3 March 2021 (UTC)

Is there something lesser than highway=path

This might already be explained or answered somewhere, but I couldn't find it... Is there a tag for something lesser than highway=path, in the same way that highway=track is lesser to roads?

There is a recreational wooded area with some major pedestrian/walking paths (aprox. 4 meter wide) with woodchip surface, streetlights and trail markers as highway=path. Intertwined with these are lesser dirt paths (aprox. 0.3–0.5 meter wide) without illumination. However some of these lesser paths are part of a nature trail.

I have added these lesser dirt paths to the map as highway=path, but with the unfortunate consequence of creating a confusing jumble where you cannot tell any of the major woodchip paths from the lesser dirt paths. Any ideas how to make their difference more clear? --Christoffre (talk) 22:54, 21 August 2022 (UTC)

Simply lit=no + trailblazed=no. Kovposch (talk) 07:10, 22 August 2022 (UTC)

Red path, blue path

Many parks have color coded trails. Mention if we should use colour=*. Jidanni (talk) 20:46, 30 November 2022 (UTC)

That's not clear what it is. On highway=*, surface:colour=* and ref:colour=* (maybe route:colour=* and network:colour=*) needs to be distinguished. colour=* can be used on the type=route. --- Kovposch (talk) 07:54, 1 December 2022 (UTC)

Use motorcycle as example

I generally support the changes. I suggest using motorcycle=yes instead of mofa=yes as an example since it is a more widely spread tag and readily understood. Also, use motorcycle=yes instead of motor_vehicle=yes in the example since that would be the usual case (2 track motorvehicles would not be allowed on a path). --Bradrh (talk) 17:41, 3 January 2023 (UTC)

Hi @Bradrh:, thanks for your suggestion. Personally I would prefer to keep using the current motor_vehicle instead of motorcycle example; although local differences can occur, global tagging practice shows that motor_vehicle=* (see p2) is used about 8 times more often then motorcycle=* (see p5) on highway=path (See Tagifo )

And this tagging isn't incorrect, since it includes mofa and moped and these modes of transport are often also forbidden in cases where motorcycles aren't allowed. Cheers! Multimodaal (talk) 21:47, 5 January 2023 (UTC)

I don't argue the examples with motor_vehicle=no. The taginfo results show that most of the motor_vehicle=* cases are motor_vehicle=no. I don't like the 'generic path' example with motor_vehicle=yes. I think most paths with motor_vehicle=yes are incorrectly tagged. They should be motorcycle=yes and/or ATV=yes. I found 4 cases of highway=path, motor_vehicle=yes, that should be ATV=yes, motorcar=no. --Bradrh (talk) 19:36, 6 January 2023 (UTC)

Tagging Table - Access

One of the common tagging mistakes I see is using access=no, followed by something=yes. I wonder if this could be clarified by adding this sentence (mostly borrowed from Access wiki page to the tagging table on the access row. Use the access=* key to describe a general access restriction that applies to all transport modes. In general it's clearer to use the specific (foot/bicycle/etc) access tags --Bradrh (talk) 18:10, 3 January 2023 (UTC)

Hi @Bradrh: thx! Just added a sentence in that gist after reading the description of access=no in the main table of values for key:access= Tried to put it in the tagging table first, but that didn't work out. Please feel free to improve it! Multimodaal (talk) 22:03, 5 January 2023 (UTC)

designated e-bike access

Seems there should be field for electric bikes / e-bikes / ebikes (not to be confused with "motor vehicles") on trails / paths.

Case in point: City of Boulder Open Space and Mountain Parks (CBOSMP), as of July 2023, allows category 2 ebikes on some open space dirt trails; see South Boulder Creek Trail updated trail signs previously: "human powered bikes only. e-bikes are not allowed".

Path in streambed

See Talk:Key:surface#Path_in_streambed. Jidanni (talk) 20:02, 17 September 2023 (UTC)

and/or animals

Am I reading that correctly - highway=path can now be used to map game trails? @Ezekielf: --Hungerburg (talk) 14:57, 15 October 2023 (UTC)

@Hungerburg: Hmm. It was not my intent to suggest that meaning. The wording was meant to encompass horse and stock trails (mentioned in the next sentence) as well as paths/trails used for any other livestock like sheep, goats, alpacas, llamas, donkeys, mules, etc. "animals" unqualified would include game trails though, so maybe that should be changed to "domestic animals". On the other hand, desire paths (social trails) get mapped as highway=path + informal=yes and these sometimes aren't all that different from game trails... --Ezekielf (talk) 19:15, 22 October 2023 (UTC)

@Ezekielf: Certainly, its tricky, so I called upon you; If I'd have thought, naming the animals domestic would be good, I'd had changed the fine article to mention that. Alas, cows are domestic animals and the paths they create when they cross a track on alpine pastures where it is convenient for them are mapped as paths, like needles of a tree branch. In my opinion, this adds just noise in a map for human navigation. I think this does not belong under the highway=* key at all. The new wording cements this unfortunate practice. Unfortunately, strava is not good at telling apart game trails from social trails neither - I know informal=no paths where strava shows just blank empty space. So absence of heat is no usable criterion. Distinction will always require an educated guess. Perhaps it would add guidance if such trails were mapped and rendered distinctively? --Hungerburg (talk) 21:29, 22 October 2023 (UTC)

Some maps de-emphasize highway=path when combined with informal=yes. I posted an example here: https://community.openstreetmap.org/t/request-for-assistance-from-the-norwegian-community-in-the-resolution-of-a-mapping-dispute/104524/109. I'd definitely encourage other renderers to do the same. I also wish informal paths were mapped with a separate key/value pair than highway=path. Unfortunately, much as with scrambles, it seems many mappers will not tolerate them dissapearing from the standard layer. So we have the informal=yes addon attribute instead. --Ezekielf (talk) 00:35, 23 October 2023 (UTC)

As the second sentence is not said to be exhaustive, it does not limit what the first sentence encompasses, and that is quite expansive. I resolved that to the best of my limited capabilities, now there is a bit of redundancy in the abstract. That could be shortened, but repetition is also good in manuals sometimes. --Hungerburg (talk) 20:09, 23 October 2023 (UTC)