From OpenStreetMap Wiki
Jump to navigation Jump to search


Need category to differentiate 2-wheeled motor vehicles from 4-wheeled

We probably need to be able to categorise "4-wheeled" (i.e. large) traffic from smaller "2-wheeled" traffic. There is a "motor_vehicle" category that includes both motorbike and cars, but below that there should also be a "4-wheeled/large motor vehicle" category to differentiate all of those vehicle types from motorbikes and other 2-wheeled/small vehicles. (User:Spod)

motorcar is the category for vehicles with two tracks/four wheels! Wheter motorcycle includes moped or not is disputed.. --t-i 12:42, 14 October 2010 (BST)
This isn't entirely clear from the description though. Since motorcar and the other keys are aligned, one can be lead to believe that there isn't a hierarchy. --Olejorgenb 21:17, 13 May 2011 (BST)
motorcar is not a general category for all motor vehicles with two tracks. Not in normal usage and not in the hierarchical listing here. So it seems like we do need a tag (as well as a heading) to cover all two-tracked (motor) vehicles. Perhaps the confusion arises because the symbol used on the entry forbidden sign for all motor vehicles is indeed an automobile. Frankl2009 (talk) 13:09, 31 January 2014 (UTC)

why is horse no vehicle?

IMO is a horse also a subgroup of vehilce_type=vehicle. --Cbm 16:34, 13 March 2009 (UTC)

I guess it all depends on legislation. I consider "vehicle" here anything that's been "driven" as Belgian traffic rules talks about "drivers" rather than "vehicles". And someone on a horse is a driver, just like someone driving a group of cows. To exclude those from the vehicle group will just complicate matters a lot. --Eimai 16:54, 13 March 2009 (UTC)
in OSM-context we only have vehicle_types to catch these things. And even if belgium laws talks about "drivers" these drivers are also "driving a type of vehicle". So there should be no big difference to e.g. german law. --Cbm 17:40, 13 March 2009 (UTC)

Miscellaneous topics

Wow, you've been busy! I think the "general statutory restrictions" might be better rephrased as "size restrictions", as in some cases (railways, waterways) the maximum size is defined by the structures along the route, not by statute/order. In addition, maxdraught would be useful for waterways. --Richard 18:06, 17 Mar 2006 (UTC)

Done Blackadder 18:15, 17 Mar 2006 (UTC)

Will this work/work well for roads which are closed to private cars at some points of some days, but open to buses+bikes at all times? (eg no cars 8am-7pm Monday-Saturday, but open for bikes + buses + motorcycles + taxis all the time) Gagravarr 11:41, 24 Jun 2006 (UTC)

It doesn't look like this can be effectively tagged... Speed-time-restriction.jpg Dtucny 18:39, 26 March 2007 (BST)

There is an international standard called GDF ("Geographical Data Files", see Wikipedia) that otherwise probably is irrelevant for OSM, but it includes a textual specification syntax for what they call "Time Domains". As far as I can see this is exactly what we would need here, instead of trying to come up with an own way of tagging using day_on, day_off, hour_on etc tags. The actual ISO GDF standard is not freely available and is quite expensive, but contains in section A1.15 the time domain syntax. --Tml 13:22, 23 October 2007 (BST)

Can someone confirm how to tag a seassonal access, such as a back country road not being snow plowed between 1st Dec through 30th Apr (which are use at your own risk during these times). Is it 'date_on=xxxx-12-1' or 'date_on=12-1'? --Mungewell 19:22, 14 March 2008 (UTC)

This is a question that I've had as well. I've used "****--99" where the asterisks are literal and the nines are actual numbers. What is the standard? — Val42 18:04, 27 September 2008 (UTC)

What if there are several restrictions for a street and some of them are time limited? Is there a way to tie one time limit to one restriction? --Erik Lundin 09:38, 30 August 2008 (UTC)

Will be dealt with in the proposal Proposed_features/Access_restrictions. Current tags don't handle it. --Eimai 11:05, 30 August 2008 (UTC)

I propose to reduce the current six tags for time limited access one tag with the scheme of Key:opening_hours. Also read about a general time-related proposal here --Peter Dörrie 15:34, 22 May 2009 (UTC)

Thanks for the link.--Skyper 18:01, 19 July 2010 (UTC)

Bus and High Occupancy Vehicle

In the area in which I live, there are two restricted roadway types which are sort-of similar. Specifically, busway and HOV access. "HOV" refers to any vehicle with X passengers or greater. Busways are limited-access slipways for bus stops aside freeways.

It appears to me that the busways can be marked with the tags <access="private"> and <psv="yes">, but how would HOV ways be marked? (note, HOV ways have different occupancy minimums on different ways) --cohort

minpassengers=X (like maxweight, minheight, etc.)? -- 3247 13:17, 9 February 2008 (UTC)

Bus contraflow

I know of at least two roads in London (Tottenham High Road, and part of Picadilly) which are one-way, except for a bus-lane coming in the opposite direction. How should these be modelled? Morwen 21:58, 17 March 2007 (UTC)

I can think of at least one in downtown Seattle (5th Ave between Cherry St and S. Jackson) --Cohort 02:00, 2 July 2007 (BST)
I suppose that in such cases you should draw two ways and tag them accordingly. Neither cars nor buses can make a U-turn in such a way. FedericoCozzi 15:47, 12 February 2009 (UTC)
oneway=yes+access:bus:oneway=no, using the proposed Proposed features/access: name space proposal. --Hawke 21:12, 12 February 2009 (UTC)
oneway=yes + oneway:bus=no using the Proposed features/Scope_for_access_tags proposal. It's even shorter! ;-) --Tordanik 04:23, 13 February 2009 (UTC)
Or simply oneway=yes + bus:oneway=no which is slightly more logical IMHO :-) --Eimai 13:35, 13 February 2009 (UTC)
oneway=yes + bus=opposite_lane is another nice option --Skyper 13:59, 17 November 2009 (UTC)

Routing restriction

The following does not seem to be the state for the art any longer (quote from the article):

For the street:

  • highway=unclassified
  • oneway=1 (or =yes or =true)

For the cycle lane:

  • highway=cycleway
  • oneway=-1

Instead the Map Features probably want us to use just one way:

  • highway=unclassified
  • oneway=1 (or =yes or =true)
  • cycleway=opposite_lane

--Keichwa 18:59, 7 July 2007 (BST)

Why has oneway the values: yes, true and 1 with the same meaning? I propose to remove true, as yes is more common for other tags. I agree 1 is good to be consistent with -1.

--Steven te Brinke 08:28, 31 January 2008 (UTC)

I guess we'd better stop using anything else than "yes"/"no" for all tags (there as been a discussion somewhere I don't remember, where it was said that it'd be better if we stay consistent )

And no, I don't thing in this particular case "1" is consistent to "-1", because "1" means yes there is one way allowed, while the opposite of 1 is -1 and should mean the opposite ( both way are allowed ). Well in fact this "-1" looks like a hack I'am still not in favor of because we should turn the way around and/or split the way in 2 if there really are two ways with different direction. Sletuffe 08:10, 30 May 2008 (UTC)

Technical instead of legal access restrictions

It has been pointed out that there is a need to mark whether a road/track can be used by a specific vehicle (i.e. whether it requires high clearance or 4WD). This is a technical rather then a legal access restriction. The original proposal was to extend the tracktype tag or introduce a smoothness tag to cover this ( see here). However, I believe that it makes more sense to use the access tag, e.g. something like access=high_clearance or access=4WD. What do you think? Ukuester 08:17, 3 July 2008 (UTC)

I think the access key series should stick to describing the legal accessibility of a way. The smoothness tag has it right, in my opinion. --Hawke 13:58, 3 July 2008 (UTC)
Please use the established keys maxheight=value,maxwidth=value etc. for technical restrictions. --Lulu-Ann 15:11, 3 July 2008 (UTC)
Thanks for the hint but maxheight and maxwidth are not related to the quality of the track/road. For many dirt roads in the US for instance it is crucial to know whether they are passable by passenger car or require high clearance or even 4WD. This is obviously not captured by maxheight and maxwidth. Ukuester 13:19, 4 July 2008 (UTC)
okay, you've already read all ;-) I agree with hawke, and I pointed out that this taging schema would raise e problem.
But you made me realise that we could also have a problem ( that we might allready have) with the access keys, by transposing my remark here :
Let's suppose an highway=unclassified is allowed to owner's cars, but also allowed to anyone's motorcycle, I suppose we'll tag it :
Suppose one year has past, now we decide to add a "moped" access key. What's going to happen to my, but also ALL roads, that have been tagged this way ?
A logical routing program would say, "no" moped not allowed because general access is private and there are no moped=yes key, but in fact they are, because we could assume the owner as allowed motorcycle, so he would do the same to moped !
I don't have the answer to this problem, but I forsee lots of time loss Sletuffe 16:30, 3 July 2008 (UTC)
As I see it, this is more of a problem with defining a moped. Some jurisdictions consider mopeds to be a type of motorcycle, some consider them to be a type of bicycle, some consider them as a separate class of vehicle altogether. So some places, motorcycle=yes would also imply moped=yes, moped_belgium_class_b=yes, and bicycle:electric=yes, while in other places it would only allow motorcycles exactly. --Hawke 18:00, 3 July 2008 (UTC)
The wiki does say access is for legal restrictions. There is also now access=discouraged, but a suggestion you could also use access:advisory=* similar to maxspeed:advisory=* which is already well accept to tag suggested but not legally enforced speed limits. --Aharvey (talk) 04:34, 8 November 2019 (UTC)

Gated Communities

Just checking for concensus. I've been marking gated community roads with access=private, and placing a gate node at the entrance to the community. Does this match up with everyone's expectations on how to treat a gated community? --OneEye 17:33, 17 July 2008 (UTC)

Sounds fine to me. Alexrudd 21:42, 15 August 2008 (UTC)
Did you place a fence around it? --Lulu-Ann 13:04, 26 September 2008 (UTC)
It's what I've been doing. Fences and walls are lower priority for me than road and sidewalk access, so I don't often add them. Recently I have seen a few instances in which streets in gated communities have been tagged with access=destination, and this is what prompted my re-checking of the access=* page of the wiki. --EdH 18:03, 20 June 1014 (UTC)
Tagging with access=private will make OSRM not route to or from these gated Communities, while access=destination will work just fine. Schrader (talk) 20:10, 16 June 2016 (UTC)
access=destination may be used only if anybody who want to reach destination in this area may enter. Mateusz Konieczny (talk) 13:45, 18 June 2016 (UTC)
Resolved: Mateusz Konieczny (talk) 09:35, 24 May 2020 (UTC)

Oneway and destination traffic

How do I tag a road that's oneway for all traffic except destination traffic, i.e. destination traffic can go both ways, but all others have to obey the one way direction? Mtcv 16:36, 15 December 2008 (UTC)

There are no way to do that for now, proposals are under construction, but it's hard to take every thing into account
You can help here : Proposed_features/access:_name_space or here : Proposed features/Access restrictions or here : Proposed features/Legal access restriction All three share the same goal with slightly different approaches Sletuffe 21:52, 15 December 2008 (UTC)

Inheritance rule

I added a table which summarizes the inheritance rule among access, vehicle, motor_vehicle and so on. While it may look superfluous, I believe such a table is needed when/if we add more transport modes and all those access tags become used by routing software. Moreover, it helps to clarify obscure transport modes (e.g. emergency: should an emergency vehicle be allowed where motor_vehicle=no?) --FedericoCozzi 14:58, 20 February 2009 (UTC)

The problem with the table is that it's country dependent: horses could for example be a vehicle in one country, but not in another one, and there are other similar issues (the rule "motorcar=no" would imply "bus=no" and "goods=no" for example here).
In case of emergency vehicles: they can go anywhere, there's no point in tagging roads with emergency vehicle access rules. The emergency services use predefined routes to get somewhere and since we have no access to that we can't put that in OSM. --Eimai 15:43, 20 February 2009 (UTC)
Your point is valid, but how can a software solve this problem if this kind of information is not known? That table is a first step in that direction: by making the inheritance table explicit, we can discuss it and provide country-specific rules. Up to now, that problem was not even acknowledged. I tried to address you point here. --FedericoCozzi 22:51, 20 February 2009 (UTC)
There are likely ways you might want to tag access=no and emergency:yes, so the format (even though it is the only one where you'd formally use emergency) is sound. Circeus 04:31, 21 February 2009 (UTC)
There may be some busways and pedestrian streets which are off-limits to emergency vehicles. Erkin Alp Güney (talk) 15:55, 25 November 2017 (UTC)
"pedestrian streets which are off-limits to emergency vehicles" - can you give an example? AFAIK emergency vehicles are free to ignore general traffic rules, including legal restrictions about banning motor vehicles on pedestrian streets Mateusz Konieczny (talk) 15:37, 7 December 2017 (UTC)
Istanbul Metrobüs busway is off-limits to ambulances and firefighters even if the situation arises in the busway itself. Erkin Alp Güney (talk) 15:45, 7 December 2017 (UTC)
I asked about pedestrian streets, I am aware that some busways are inaccessible due to technical issues (like ) Mateusz Konieczny (talk) 17:10, 7 December 2017 (UTC)
Some questions/thoughts:
  1. Is there a reason why many common transport modes (bicycle, hgv, ...) aren't included? Is is because they are considered self-explanatory?
  2. Is "horse" really a vehicle? Wikipedia defines it as "non-living means of transport", which is consistent with what I would have assumed it means. Something like that shouldn't be country-dependent either. If there are traffic rules in some countries that apply to vehicles and horses, this doesn't mean that "horses are vehicles there". It means that they have a (vehicle+horse) category of transport which should get its own key then.
--Tordanik 18:44, 23 February 2009 (UTC)
Quick answers:
  1. The tree is not complete because I just wanted to show the general idea of an explicit tree of transport modes, which leads to...
  2. This is the most important feature: a tree makes people aware of problems they don't even know exist. Horse are vehicles in one country and aren't in another: however, if the tree wasn't drawn, nobody would have noticed the problem. --FedericoCozzi 22:30, 23 February 2009 (UTC)
For example in Finland most of the traffic rules read "the driver [of a vehicle] must ..." and then there's a clause "anyone riding or reining a horse must obey the applicable rules as applicable to a driver of a vehicle". Alv 19:08, 23 February 2009 (UTC)
This is definitely something that should be addressed in the form of country dependent definitions. The system must be so that it can easily be maintained, logical, and include a wide enough range of definitions. Whether or not a horse is defined as a vehicle should be down to law, not to wikipedia definitions, and it should also be possible to put some definitions in more than one category (for example I would put a taxi in both motorcar and psv, while a bus is only psv). The question is what would have the higher priority when a tag such as motorcar=no is put together with psv=yes, does that mean a taxi can go? Beside, the access tag should be used ONLY for law and regulation imposed access, while physical access (such as a bus trap) must be tagged in a different way. --Skippern 18:55, 23 February 2009 (UTC)

"multiple inheritance"

(I continue this aspect of the discussion in a separate section to prevent chaos...)

I agree with Skippern's statement there can be multiple "anchestors" for a category, and that a solution has be found to deal with that. There are similar problems with my recent Conditions for access tags proposal, which I tried to solve by stating that

  1. More specific information overrides more general information.
  2. If there are conflicting tags without a "specificness" hierarchy, the most restrictive rule does apply

In the context of our problem here this would mean: If I add access information for vehicle and motor_vehicle, then that access information would apply to all motor_vehicles, including its descendants (e.g. taxi). If I add x=yes and y=no, where neither x is an anchestor of y nor the other way round, then for all descendants of both x and y the "no" information applies. --Tordanik 19:27, 23 February 2009 (UTC)

I refer you to Computing access restrictions and its talk page, where I discussed this topic. Basically I am against multiple inheritance because it make things much more complex. The only way to solve it would be to impose a complete order on the access mode restrictions (e.g. no < private < permissive < yes < designated) and then decide that, in multiple inheritance cases, one should use the most (or least?) restrictive. This would quickly lead to a mess for two reasons: we still haven't decided on a tree hierarchy for transport modes, we will never agree on such an order on restrictions (is agricultural more specific than delivery?); we will never agree on whether we should use the least or the most restrictive restriction (and someone will advocate for a country-specific rule). FedericoCozzi 21:47, 23 February 2009 (UTC)
The vehicle tree you are suggesting HAVE to be country specific. On the other hand, what type of restriction is higher or lower can be a generic rule. Your example of no < private etc. is a good one. But what type of vehicle to group with what must be possible to make country specific as national laws can make grouping different from other. See also the list of Access-Restrictions, as you see the default rule of various countries are different, so where access restrictions are not signed, there are different ways of handle the default. If we do not get software to handle country specific rules, than we might end up banning vehicles that are allowed by law on certain type of road because the software doesn't know, and same, we might send a vehicle down a road where it is prohibited, because the software didn't know. The only solution for this is country-specific rules. --Skippern 11:44, 24 February 2009 (UTC)

Could we move that discussion over Computing access restrictions

Since this is an alpha work in progress, that discussion should go to there preferably non ? Sletuffe 11:28, 24 February 2009 (UTC)


Please write down some good examples on the wiki site. The code field there isn't one. Since I do not really understand how the access-key should be used I will just wait for that... Malenki 17:28, 28 March 2009 (UTC)

I don't think it's very clear either! Seventy7 14:32, 21 February 2010 (UTC)
@Malenki, @Seventy7 I finally added some examples and improved existing one! If you are still active, review would be welcomed. Sorry for so long wait. Mateusz Konieczny (talk) 10:09, 24 May 2020 (UTC)
Resolved: Mateusz Konieczny (talk) 12:26, 25 May 2020 (UTC)

Ski Types

So is "nordic" skis supposed to mean just cross-country or all types of nordic skiing (except telemark) such as ski jumping. For access, I've never seen telemark have different rules to alpine whereas I have seen plenty of snowboard only or snowboard banned runs. I'd have thought cross-country and downhill would be better categories with snowboards, telemark, skibobs, monoskis, alpine etc as subcategories of downhill skis. --Opk 11:26, 10 July 2009 (UTC)

There are areas that have prohibitted off-pist and telemark, though I do not know of restrictions in prepped pists. It is more like a restriction of a larger geographic area. ski=no + nordic=yes is a easy way of saying that only cross-country-skiing is allowed AFAIKT --Skippern 23:18, 25 August 2009 (UTC)

4wd only?

Is this a legal access restriction, physical restriction or a recomendation? I really do not get this tag. I have never seen a restriction sign saying 4wd only, seeing one I would guess that the road is illegal for 4wd to use. If it is a physical restriction, maybe I can take a chance to drive there with my high-clearance non-4wd offroader, and if it is only an recomendation, than it have nothing to do on access. --Skippern 23:14, 25 August 2009 (UTC)

Apparently it's an Australian-specific legal access restriction (with corresponding sign). If you don't have a car registered as a 4wd (which actually means something like 'off-road', but has to be specifically registered as well) then you're not allowed to use those roads. --Hawke 11:49, 26 August 2009 (UTC)
Data users in other countries would appreciate it if these are also tagged as motorcar=no; no other access mode tag is of the type "_only". Alv 11:59, 26 August 2009 (UTC)
I agree, but the proposal passed. I guess this is therefore a Australia-specific tag, and not an access=* tag. --Hawke
Many of the objection stated *_only syntax as reason, some of the objections approved the need but not the tag, so changing it to 4wd would have gained more support. For me *_only sounds more like a recomendation than a restriction (i.e. the road is only recomendable for 4wd vehicles). Can anybody make a thorough documentation of this tag, and how it should be used (for example together with motorcar=no) before letting it into the tree structure? --Skippern 01:03, 27 August 2009 (UTC)

Keyed access?

I'm missing a tag for access requiring an explicit permission or a key (card)? Here, I'm not talking about access to private property but access to public areas like mostly pedestrian areas of a city center. The area is closed off to general motorized traffic by rising bollards and can only be accessed by holders of a key card to lower the bollards. The key card is only issued to some residents and other groups having a special need to access the streets in question. It is definity not "private" (it is the center of a major city), neither is it destination which would allow general access to the area if your destination is there. I would suggest a tag like "access=keyed" or "access=permit_holders" (not to be confused with "permissive"). Any better solutions? polderrunner 22:19, 20 November 2009 (UTC)

  • Hi, in this case, no "Access-Tag" is necessary. Because some other combination is enough. For your case take: "barrier:bollard" "bicycle:yes" "foot:yes" "goods:destination" "motorcar:destination" Smarties 21:12, 23 November 2009 (UTC)
  • I think an extra tag *is* necessary. There is a difference between a legal restriction and a physical restriction. For instance, I can drive to a shop to load something into the car in a "No vehicles except for access" zone as I do need to access the shop. But if there were a rising bollard in the way then I physically couldn't. Seventy7 14:36, 21 February 2010 (UTC)
  • IMHO, such a tag could be useful. For instance, there are some streets in Toledo (Spain) like Calle Santo Tomé ( where only delivery **and** residents can enter. Right now, these streets are tagged as "highway:pedestrian", which is only partially accurate. Something like "highway:residential", "access=residents", "delivery=yes", could be better.

No Parking/No Stopping/No Overtaking

How to tag these? parking=no stopping=no and overtaking=no seems like good solutions, I've seen some recomendations for stopping=no but no documentation....--Skippern 23:30, 19 December 2009 (UTC)

I've sometimes added halting=no for that. Guess only time will tell which one gets used more often, since there isn't anything that could make use of the information. Alv 11:03, 20 December 2009 (UTC)
When routing can find addresses by houses, it would be more interesting for a taxi to avoid the side with no stopping, while other visitors would prefare the side with the public parking space. Just to mention one usage... --Skippern 14:19, 20 December 2009 (UTC)
Yeah, I have some ideas for the information, too; I meant that no software implements such features, yet. ("Find an optimal route for finding a free parking spot, staying as close as possible to the original destination".) Alv 14:32, 20 December 2009 (UTC)
"Stop infront of entrance B to drop off passengers as the street infront of main entrance is a no stopping zone." --Skippern 15:31, 20 December 2009 (UTC)
From taginfo it seems there's no competition to Proposed_features/parking:lane. overtaking=* is documented and in use. Alv 18:05, 15 May 2011 (BST)


I found another access sign in Germany. Like forestry and agricultural it says: free for watermanagement. Maybe we can indroduce this. --Skyper 14:12, 19 January 2010 (UTC)

can you provide a picture of the sign and maybe a link to some legal sources describing the sign? then we can check if other countries have a similar restriction in order to find a most suitable solution (e.g. naming). --Marc 17:58, 19 January 2010 (UTC)
Hi, this is not a offizial sign of the [German Law (StVO)]. It is a Sign made by the local Goverment. Are you sure we need to make a key for that? Smarties 16:25, 29 March 2010 (UTC)
I would tag it simply access=private Mateusz Konieczny (talk) 09:36, 24 May 2020 (UTC)
Resolved: as a dead inactive discussion (remove this if anyone wants to continue it)Mateusz Konieczny (talk) 12:27, 25 May 2020 (UTC)

Access restriction in one direction only?

Is there a way to tag a single-carriageway road that allows all traffic in one direction but only buses in the other direction? --NE2 17:11, 19 January 2010 (UTC)

maybe I've misunderstood your problem, but why not use the postfixes backword/forward like for example psv:backward=yes (or psv:forward depending on way direction) in combination with one-way=yes (or -1 depending on way direction)? --Marc 18:04, 19 January 2010 (UTC)
Way 48551493 is a two-way service road, tagged access=permissive. But the only way to go westbound is from the bus lane. Tagging it one-way seems misleading, given that the bus-only ways are also tagged one-way (in particular, a pedestrian crossing the road needs to watch for westbound traffic). --NE2 18:39, 19 January 2010 (UTC)
Using extended conditions, oneway=yes+oneway:psv=no should work. --Hawke 20:31, 19 January 2010 (UTC)
See above; tagging it one-way is misleading. --NE2 22:35, 19 January 2010 (UTC)
That’s not tagging it one-way; that’s tagging it “one-way, except buses” which is correct. --Hawke 04:11, 20 January 2010 (UTC)

Disabled parking access for blue badge holders only

How should I tag a highway=service that is intended only for disabled badge holder drivers? access=no for the general case and <something>=yes to indicate the holder of the rights. disabled_badge_holder=yes is a possibility, but perhaps there's a more generic way of stating that. Perhaps disabled_only=yes. Any ideas? --Pink Duck 20:13, 9th February 2010 (UTC)

As you wrote, it is about parking. --Lulu-Ann 22:47, 9th February 2010 (UTC)
I have already created a node in the middle of the way for the amenity parking with equal numbers for the total and disabled spaces. However, for a routing system there needs to be information that the way is only accessible if someone has a disabled badge parking identity. --Pink Duck 18:32, 10 February 2010 (UTC)

I have changed blue_badge_holders=* to disabled=*, because it is internationally better understood. [[User:Lulu-Ann|Lulu-Ann}}

the disabled tag is absolutely misplaced under the vehicle tag. as the name indicates the badge is something assigned to a person, not a vehicle. according to the current scheme "disabled" is a value" not a property. -- Flaimo 16:09, 15 March 2011 (UTC)

Funicular (inclined railway)

For an incline that carries private vehicles (like a ferry across water), would access=yes be correct, or should motor_vehicle=yes also be used? --NE2 16:33, 19 April 2010 (UTC)

If you include the motor_vehicle tag, than autorouters/GPS navigation systems could be able to take that ferry/railway trip as part of the route to the destination. Sounds useful to me. Arnotixe 13:37, 12 August 2010 (BST)

Private roads that look like public roads?

In Walt Disney World there are a lot of roads that are open to the public. Some of the major ones are actually public roads, maintained by the Disney-controlled but governmental Reedy Creek Improvement District. Others are privately owned by Disney. On the ground, there's literally no difference between the two classes, except that the public roads have "no parking on right of way" signs. Here's an example; Bonnet Creek is public but Vista is private. Should the private roads be tagged access=permissive, or should they just be mapped as if they were public roads? --NE2 16:39, 21 April 2010 (UTC)

It is OK to use access=permissive but I think that such differences are not important and nothing is lost by not mapping such differences Mateusz Konieczny (talk) 09:37, 24 May 2020 (UTC)

Golf cart

I propose to add golf_cart=* to the access=* hierarchy. Aside from its obvious use in golf courses, there are some planned communities (such as Peachtree City, Georgia (USA)) that allow golf carts on normal roads, but also have a secondary set of roads just for the golf carts.

In that context (and also in golf courses) it makes sense to tag those roads with highway=path and golf_cart=designated. BigPeteB 04:44, 22 June 2010 (UTC)

Seems in use and reasonable. Do they have traffic signs to single out the ones where they are or aren't allowed? Should probably be included in the appropriate place in the hierarchy.Alv 18:01, 15 May 2011 (BST)

Gender/sex restrictions

Where does that idea come from? It's inconsistent with the rest of access tagging. bicycle=yes doesn't mean that only bicycles are allowed. Therefore, female=yes should not mean that only females are allowed! I'm sure there are better solutions, but I would prefer to have an example of that kind of situation before starting to discuss it. --Tordanik 11:23, 23 December 2010 (UTC)

Came up in the discussion of amenity=toilets and after consideration of the taginfo pages for it and what would be most elegant for tagging. In that context the restriction really is exclusionary almost all of the time. So too institutions like gentlemen's clubs or women's shelters. "male" and "female" (and "unisex") are the most common tags out there as far as I can make out using taginfo. If you'd prefer to park the descriptions from the main page here for discussion and consensus, go ahead. IMO making "male" and "female" exclude others and "unisex" include all by implication is the neatest way to do it because then one can use fewer tags. I concede that there's a high degree of co-tagging as of now (238 "male" total of which 199 are co-tagged "female"; 234 "female" total), but since the version with implications is backwards-compatible with a fully-enumerated (male=no|female=yes|unisex=no|...) version I think it's still permissible. --achadwick 16:37, 23 December 2010 (UTC)
Actually, I believe that the toilet example has different semantics than "access rights". It means that there are dedicated facilities for that gender. Thinking of this as "access" rights is of course possible, but neither necessary nor beneficial. It's closer to tagging a node as amenity=recycling + recycling:glass_bottles=yes. It can be thought of as "bottles are allowed in here, and everything else is implicitly forbidden", i.e. a kind of access right. But that's not how I would look at it. You see, if someone places a container for cans next to the bottles container, you would add recycling:cans=yes. That's not the same as adding a "free for bicycles" traffic sign to a road, as it doesn't really change the rights to use a given object. It means that there can be (and likely are) two separate objects in that place, one container dedicated to bottles and one to cans, tagged as a single node for the sake of abstraction. In my mind, that's the same situation as with male/female/unisex toilets.
So I agree that the male/female/unisex=yes solution makes sense for toilets and similar gender-segregated facilities, especially if you want to avoid semicolons that would occur with gender=* tags. I still believe that all access tags should have the same semantics - however, that's not a problem, because these suggested tags aren't access tags. :-) In fact, I think that's what my original irritation boils down to: They express a different concept, and shouldn't be documented on Key:access. --Tordanik 22:10, 28 December 2010 (UTC)
Is link in "see also" enough to resolve this? I think that it is good solution Mateusz Konieczny (talk) 09:49, 24 May 2020 (UTC)

Seasonal roads

In the Alps, there are roads that are not ploughed during the winter. There are no fixed dates for closure - it's basically from when there's too much snow until the snow has sufficiently melted. There does not seem to be tags for that. Submarine 00:59, 19 January 2011 (UTC)

We've used seasonal:winter=no here in Finland for (pedestrian) routes with a signpost saying they're not maintained during the winter. Noting that your restriction is only a part of winter, that doesn't help that much, though.Alv 17:58, 15 May 2011 (BST)

access structure is confusing and often limited

the current structure is confusing. there is no clear list of values for the access tag, sometimes values are also made to tags (for example "agricultural").

i would suggest:

  • for clarity all access tags should have an "access:" in front of them (just like the fuel tags do). otherwise, as the list grows bigger and bigger, people will find it hard to find out what certain tags are for. also the risk of double usage of tags becomes more likely.
  • there should be only one supernode "access" and all other access types should be grouped under that node. the three main levels should be "kind of transportation" (access:foot, access:vehicle, access:boat,…), the second group should be "special interest group" which has all the roles the affected driver/person holds (access:emergency, access:disabled, access:customer, access:delivery,…). the third group is the "target" (road, parking space, tunnel…)
  • in contrast to transportation modes, access tags for special interest groups are not exclusionary. so a "access:vehicle=permissive" + "access:disabled=permissive" + access:customer=permissive" means only disabled customers driving a vehicle can access a certain element (for example parking space).
  • separated from the tree should be a list with possible values which can be assigned to any of the attributes in the access tree, no matter if it is a kind of transportation or a role a person holds. a vlaue can not be a property (like it is now)
  • access time restrictions should be replaced with the opening_hours syntax. example: access:vehicle=permissive + access:vehicle:time=Mo-Fr 08:00-22:00
  • other conditions like "left, right, backwards, oneway can be appended like it is done now -- Flaimo 16:35, 15 March 2011 (UTC)

I have written down my suggestions for a modified version of the current tagging scheme. you can find it here: -- Flaimo 12:11, 17 March 2011 (UTC)
Resolved: this page documents actually used scheme, if someone wants to deprecate all existing access tags - feel free to make a proposal but I would not expect success Mateusz Konieczny (talk) 09:50, 24 May 2020 (UTC)


To mark that it's prohibited to swim in certain reservoirs.

Should this be moved to the page? In Norway at least there is a clear need for a tag like this. Many natural lakes are used as drinking water sources and are prohibited from swimming in. --Olejorgenb 21:47, 8 May 2011 (BST)

This was also discussed on the tagging list at, and based on the outcome I've just added it to the list. Aharvey (talk) 11:55, 7 November 2019 (UTC)

Specific Permits

It would be good to have some way to allow users of routing applications and the like to know whether they have the necessary permission to use some restricted resource. For instance, a visitor/residents/employee/parking pass to a gated community, military base, or parking lot. The routing application could have a list of permits and check against them whenever it comes across a restricted resource. If a route exists but can't be followed without permission, it might even be possible for the application to then tell the user what permission is needed, rather than just saying 'No Route'. As a simple example of such a scheme, we could just use the URI of a relevant page for an access value. --Hai-Etlik 11:07, 23 April 2011 (BST)

at least for my proposal for parking_spaces i have incorporated the idea of user roles: . there shouldn't be a problem to also use it in a more general way --Flaimo 18:59, 23 April 2011 (BST)

Unwieldy talk page

This talk page is getting too long. Can we make some use of Template:Resolved and friends and maybe archive old conversations? --achadwick 16:37, 25 April 2011 (BST)

Halfway there. Alv 17:32, 15 May 2011 (BST)
Resolved: :) Mateusz Konieczny (talk) 09:51, 24 May 2020 (UTC)

Access time restrictions: hour_on and hour_off logic

There needs to be a better explanation of how to apply hour_on and hour_off (and their associated date, and day fields). Presumably one uses hour_on to describe when all access restrictions on the current object start applying, and hour_off to describe when all restrictions stop applying, and the object falls back to a completely unrestricted default state. Examples would be a very good idea. --achadwick 16:53, 25 April 2011 (BST)

As an aside, this seems very limiting. There are a lot of mode-based, time-based restrictions around here for which the "unrestricted" default state also carries restrictions! If we were to revise this, it would be useful to adopt the schema behind opening_hours=*, calling it access_hours perhaps. I'd appreciate a standardised way of representing mode-based restrictions too: modal suffixes like access_hours:hgv, anyone? --achadwick 16:53, 25 April 2011 (BST)

Resolved: seems to be resolved by deprecating this tagging scheme Mateusz Konieczny (talk) 12:28, 25 May 2020 (UTC)

Maximum vehicle occupancy

UK no buses sign.jpg

How should I represent the restriction to the left? The meaning from "Know your Road Signs" is "No vehicles designed to carry more than 8 passengers (excluding driver) or local buses". There doesn't seem to be a maximum occupants tag that quite matches this in the current schema (hov is normally too small a number), and there really should be. Can I suggest maxoccupants=<integer>, defined to include the driver? That way I can fiddle something together using bus=* and maxoccupants=9 to represent this restriction. --achadwick 00:12, 26 April 2011 (BST)

Restricted access

In the historic centre of Rome we have roads in restricted access areas (calls ZTL "Zona a Traffico Limitato" - "Limited Traffic Zone" in English) without an appropriate tag to describe these restrictions. The restrictions are on only in some days and/or hours and is not valid for all kind of motor transport. Every restricted area have passages controlled by enforcement cameras for control who can access or not when the restriction is on. I think we need new tags for describe these situations and similar.--Madeco 12:43, 30 April 2011 (BST)

could you add detailed description of this ruleset to the discussion page of my proposal? i would like to see if it might can be represented by the access syntax i have in mind. --Flaimo 19:53, 30 April 2011 (BST)

Value "customers"

Discussion moved to Talk:Proposed features/customer

Exceptions to access=no

I have been tagging streets that only allow particular modes of transportation, such as those in transit centers, as access=no, *=yes, with the latter tags being used to indicate exceptions. So in the case of the transit center the tags are access=no, bus=yes to indicate that only buses are allowed on these roads. This method is much more efficient that explicitly stating whether each mode of travel is allowed on a road (bus=yes, foot=no, bicycle=no, motor_vehicle=no, etc.). Is tagging a way as access=no and then stating exceptions as *=yes tags an acceptable use of the access tagging scheme? And if so can we add this methodology to the main wiki page?

I am just a real beginner with OSM, but I think it would not be a good idea to use a key with several values instead of multiple keys. I suspect that because, as stated in the Semi-colon value separator article, this method is usually harder to parse and not often accepted by search engines (eg on a smartphone). It may be a bit less efficient this way, but you could specify such a bus route once, then copy all tags to the other object and then edit if needed. [ This was added by an unknown user ]
I don't think that is what the OP described. While I am not such a great mapper myself, I agree that the scheme of adding access=no and bus=yes as two separate tags is an OK and efficient way to indicate a bus only only area, this seems consistent with the semantics described on the access=* page. User:Jbohmdk 18:36, 17 June 2013 (UTC)

Time restrictions

If I'm reading the descriptions correctly, the logic of access-*-on is the reverse of what I would expect. If access is "on", I expect to able to access something. Compare restirction-*-on; restriction is the opposite of access. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:05, 4 October 2011 (BST)

@Pigsonthewing Is it still a problem? Which tags are problematic? Mateusz Konieczny (talk) 09:52, 24 May 2020 (UTC)

Seasonal access

A nature reserve I'm mapping has a path which is accessible "in Summer", with no specific dates defined. How would folk tag this? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:15, 4 October 2011 (BST)

Conditional restrictions should cover this, if unclear and specific example is needed - please comment on a talk page there Mateusz Konieczny (talk) 09:54, 24 May 2020 (UTC)
Resolved: Conditional restrictions are now described on the page Mateusz Konieczny (talk) 09:54, 24 May 2020 (UTC)


caravan=* is currently defined by the pictogram Sinnbild PKW mit Anhänger.svg which shows a car with a goods trailer. This does not match any of the meanings listed on [1]. Therefore, a tag trailer=* has been suggested for trailers of any kind. If we go for this, a few questions arise:

1) Shall a bot convert the existing caravan=* to trailer=* ?

taginfo caravan=* taginfo trailer=*

2) Shall caravan=* be deprecated? If not, what is it actually supposed to mean?

BTW: In Austria, there are 2 kinds of traffic signs forbidding trailers: one forbidding them generally, and one forbidding hgvs with trailers. How can we represent the latter case in OSM? --Fkv 22:34, 22 November 2011 (UTC)

with this current scheme probably not at all, but this way could work. --Flaimo 17:05, 3 January 2012 (UTC)

New 'Access' Feature page?

Should we split the content and discussion that doesn't relate specifically to 'key:access' to a new article called Access or similar? This will allow this 'key' page to simply tell people how to use the tag which is what is normal within the wiki. PeterIto 05:27, 3 January 2012 (UTC)

Wide Loads

Some places (usually laybys or other service roads) are marked as only for use by wide or abnormal load vehicles. For example the lane inside this motorway roundabout is only for wide loads. I've tagged it as access=no;wide_load=yes - is this something we might want to formalise? Spark 21:01, 19 March 2012 (UTC)

Perhaps minwidth=*? --NE2 01:15, 20 March 2012 (UTC)
There are no need to tag for abnormal loads as they need special permission to drive anyway. I have taken part in approving an abnormal load (32m long, 5.5m wide and 6.1m high weighing 280T including carrier) for road transportation in which included passing under a viaduct marked maxheight:physical=5.20m and a long bridge. There was several weeks of preparations for the 190km trip, including applying special transport permits from road transport authorities and police. --Skippern 23:39, 22 April 2012 (BST)

Access time restrictions: get rid of them

Can we please move the hour_on/hour_off/… stuff away from the page? The fact that those tags are completely broken is documented in quite a lot of discussions and wiki pages for several years now, yet this page makes it look like those tags are recommended. -- Eckhart 23:38, 6 June 2012 (BST)

Resolved: no longer described as recommended Mateusz Konieczny (talk) 09:54, 24 May 2020 (UTC)

Distinction between vehicle class and by use not always clear/right

Goods is depicted as a class of vehicle like a motorcar, but instead it looks as if it was a kind of insurance/legal thing how the car is registered, so it is not really a class but more a use case, or do I get this wrong? Similarly one might argue that taxi is not a class of it's own but a use case. --Dieterdreist 11:49, 26 June 2012 (BST)

Legally it is a class of vehicle; in most countries you can't take any random car and register it as a goods vehicle/van, or the other way round. Likewise, a motorcar only becomes a taxi when vehicle inspection has checked that it complies with the requirements for a taxi (including the meter, and the sign on the roof), and made the necessary registry changes. I think, though, now that the distinction is this: all two-tracked motor vehicles Zeichen 251 - Verbot für Kraftwagen und sonstige mehrspurige Kraftfahrzeuge, StVO 1992.svg vs. "passenger cars" Zusatzzeichen 1024-10 - Personenkraftwagen frei, StVO 1992.svg vs. Finland road sign 834.svg (Finnish sign, afaict Germany doesn't have an equivalent sign) vs. Finland road sign 313.svg (which, contrary to Germany forbids also vehicles registered as vans). Alv 12:08, 21 October 2012 (BST)

Bus has multiple meanings

You can now find this section/discussion at Talk:Key:psv#Bus_has_multiple_meanings, because of a more recent discussion about the psv=*, which references buses. There's a nice table about the differences between "bus as used in public service" and "bus as vehicle category", traffic signs etc. Alv (talk) 17:20, 16 January 2014 (UTC)

Emergency vehicles have fallen between the cracks?

It appears that amongst different people editing different pages, there is no longer an appropriate tagging for special access restrictions for emergency vehicles

  • [Proposed features/emergency vehicle access] is abandoned
  • This page points to the emergency=* page
  • emergency=* page has never talked about emergency vehicle access but points back to this page

So somewhere between the abandoning of the proposal, editing of this page and creation of the emergency=* page, emergency access was lost and all the GPS-managed ambulances and fire engines end up doing detours while people may die waiting. Not good, not good at all. (As for people dying, see for example the very last point on Proposed features/emergency vehicle access, this is not hyperbole).

(Note I was actually just looking for how to tag a road that is being consistently kept clear for use by ambulances and police cars, just in case, but is 100% banned for any other kind of car. In fact the use by police and ambulances is not signposted and is known only to a few locals and maybe some emergency drivers, for now I just have to leave this aspect untagged). Jbohmdk 01:00, 10 June 2013 (UTC)

Though I agree that such a tag is necessary - not only for roads, but also to tag parking restrictions e. g. in front of police stations - the example you gave is a tricky one. IMO only such roads and other entities should be tagged as access=emergency or similar that are officially designated as such. If there is no sign, I would argue against tagging it. Remember: Emergency vehicles on a call are already exempt from virtually any access restrictions (in Germany as a result of § 35 StVO), but this is a legal feature of the vehicles, not the roads. So the emergency vehicles' GPS devices should take this into consideration and choose routes along any physically accessible way regardless of legal restrictions. Ergo the tag should only be used where there is an official restriction. --Silanea (talk) 20:53, 10 June 2013 (UTC)
Yes, this key has been messed up. 30,000 uses of emergency=yes [which looks 'access'-page related] vs. 130,000 of emergency=fire_hydrant [which is tagged according to the emergency-key page], plus many other values.
Option 1) Since the emergency=yes is somehow just a shortcut (from the early OSM days) for access:emergency (similar to maxspeed:emergency or maxweight:emergency), access:emergency could be used for making the meaning more obvious (I don't prefer this approach, see below).
If we want to keep things consistent with the agricultural tagging, access:emergency=yes would relate to the *vehicle type*: An ambulance car can access a highway tagged with access:emergency=yes, no matter if there is actually an emergency situation or just a launch break! Further following the agricultural approach, access=emergency would allow everybody in an emergency situation access, no matter if this person is in a emergency vehicle (e.g. private car). This type of tagging (access=emergency) is not very useful (and BTW not defined in the access key!), since in emergency situations many restrictions either do not apply or are not enforced. Thus access=emergency can be assumed everywhere and does not require explicit tagging.
Option 2) I personally prefer to don't follow the agricultural approach, since this is very misleading and confusing (I believe that people mix it up anyway, even I tagged it wrong in the past and used agricultural=yes for agricultural traffic allowance). Because we have to fix things anyway, a modified tag emergency_vehicle (or long access:emergency_vehicle) is in my opinion preferable over start using access:emergency.--Martinq (talk) 22:23, 10 June 2013 (UTC)
Yes more option 2, IMO. For the reasons you state. I'd prefer the token emergency_service in there somewhere rather than _vehicle for a smidgin more flexibility. More below --achadwick (talk) 15:34, 11 June 2013 (UTC)

I agree that there's almost certainly no need for a tag expressing the concept that an object can be used by emergency responders who are responding to an emergency. Quickly duckduckgoing around, emergency response is a defence for regular citizens to the tort or offence of trespass in the US and in the UK[2][3][4][5]. Where that's not the case, there's good reason to assume that recognised emergency services will have the privilege needed to enter land when responding.

There is probably a need for a tag expressing the concept that an object may only be used by emergency responders (including their vehicles) regardless of whether or not they are currently responding. By the argument above, it's not always needed for privately-owned roads; those can be tagged with access=private but should be made available in a routing engine use by ambulances and police. It probably is needed for parking spaces and other facilities which the emergency services would seek out (particularly traffic-free routes, for example). This can already be done as a by-user-group conditional restriction, as suggested by access:conditional=*, though it's probably wise to tidy up that wiki page to precisely define what the @-condition needed means. Something like:

access:conditional=yes @ emergency    ← or maybe @ emergency_services ?

The OP's concerns as expressed can be addressed by ensuring as a community that we get out and map all the things, and by routing software or map renderings for emergency users simply ignoring all legalistic access[:*]=* prohibitions but paying attention to widths, surface and other relevant properties.

Somebody should probably tidy up Key:emergency too, and remove the somewhat pointless suggestion that it can be used to indicate that emergency vehicles have access.

--achadwick (talk) 15:34, 11 June 2013 (UTC)

First off, that the page only documents the "emergency facilities" like hydrants, is easily solved. The key was used as emergency=yes and emergency=designated before somebody wanted to unify all of the emergency stuff away from key "amenity". A hydrant never is routable, the different uses should never clash? Just add the two other use variants to the Key:emergency page Very few seem to have taken on the idea that the access keys are "shortcuts" to longer access:*=* tags, so I don't think there's any value documenting any new keys as such longer form being the "real" key.
Then a comment on the usage: at least here in Finland (just about) all new (from the last 20 years) apartment building lots have signposted "rescue roads", where the emergency services then know immediately that the route is wide enough for the ladder unit, and that the service road will not fail under the significant weight of their vehicles - not all "internal" footways are built to such standards. Many older buildings have them, too. The sign they installed for several years looks like this. A side effect is that no parking is allowed on any such ways, and the building owner must make sure it's not otherwise blocked, either. These routes get emergency=designated (+ parking:lane:* tags). (No, they won't ram through parked cars - they did before, but one time that broke the hydraulic pump, so a girl died falling when they couldn't get the ladder up.)
The uses of emergency=yes around here seem to be either emergency exit doors, and on health facilities offering emergency services, and tiny shortcuts between dual carriage road carriageways, which normally have a gate they can open manually (it's still faster) - only the snowplows and emergency vehicles may use them. From a quick read it seems one could claim "necessity" in other countries, were they to be prosecuted for using a road only for official emergency vehicles - if their own emergency was urgent enough to justify such, and the official vehicles weren't available fast enough. Alv (talk) 17:04, 11 June 2013 (UTC)
Thanks for this response. I agree that dreaming up new hard to enter tags like "access:emergency" would be worse, and if emergency=yes is already being used like this, it is merely a matter of bringing the wiki back into sync with practice. And yes, I agree with achadwick that emergency vehicles are generally allowed to go absolutely anywhere if they have to, so tagging this would be for two other things: A) Shortcuts where they can physically get through, and which should be included in their GPS routing (my original case was an unusually dimensioned sidewalk at a strategically chosen location, but a resurvey today showed that the feature was now gone). B. Specially signposted driveways etc. which are reinforced and/or kept clear just in case a heavy fire engine is ever needed at that very location, the Danish signposts for those often say "Brandvej" along with some variant of "Keep clear at all times" . Jbohmdk 19:14, 17 June 2013 (UTC)

Redefining default designation of road

Was there some discussion about redefining default designation of road by access tag (namely access, not specific tag of type of vehicle)? For example, highway=footway is a road, designated for pedestrians - legal access for vehicles is closed and such roads usually can't be used for driving by physical reasons (such roads don't have sufficient surface and width). The practice is that for distinguishing footways with open access from footways with closed access some people use tag access (highway=footway + access=yes, highway=footway + access=permissive, highway=footway + access=private and highway=footway + access=no). Of course, tag foot=yes/permissive/private/no, perhaps, can be better in such case, but it is not the best solution, when there are some special rules for footways. It is easier to use tag access instead of several tags foot, bicycle and so on. Does highway=footway + access=yes mean, that road is legally and physically open for all, including drivers? There are different opinions. I think, there is a sense to mark, that access tag should not redefine the default designation of road. To mark that we have some footway with open access for vehicles we should use highway=footway + vehicle=yes, highway=footway + access=yes should mean, that road is open for all pedestrians, because it is highway=footway. Dinamik (talk) 07:07, 18 July 2013 (UTC)

"Use the access=* key to describe a general access restriction that applies to all transport modes." is fairly clear, and people who use access=yes wrongly (e.g. on a footway where vehicles aren't allowed) are the cause of routing problems that need fixing by correcting the access tagging to the correct vehicle type(s). --EdLoach (talk) 07:19, 18 July 2013 (UTC)
Most access=destination [100 000+] tags should be motor_vehicle=destination [20 000+] (probably even in the UK), but my educated guess is that that's not going to happen until the default stylesheets are updated. However, taginfo shows that only 3300 highway=footway's have access=destination. The current use seems to be that mappers have added access=* to all these "not-for-motorcars-roads" to denote what applies to the by default allowed users, not to all transport modes. Alv (talk) 11:41, 18 July 2013 (UTC)
motor_vehicle is a fairly new blanket category compared to access. That could account for some it. --achadwick (talk) 12:39, 18 July 2013 (UTC)
Special cases are nasty. We need to allow 'horse=*' or 'motor_vehicle=*' to widen the range of users for something like a highway=path. IMO access=* should operate in the same way because it is at the root of the hierarchy. Here's the way it works in my head:
  1. It's helpful to think of a "set of users under consideration", which may be grown or shrunk (technically we're building a non-injective, non-surjective mapping function that returns how a user may use the way, but I'm keeping it simple).
  2. It's the highway, railway, and waterway keys that create this set initially, expressing via their union the things which could physically use some unspecified way of this general type.
  3. Consider the values of those keys next: waterway=streams cannot be used by ocean-going container vessels. Apply to the working set a mask consisting of the union of the users who may by default (legally and physically) use any of the specified kinds of highway, waterway etc.
  4. Next apply access tagging in order according to the hierarchy, from most general to most specific. Here values such as "yes", "private" etc. may extend the set of users under consideration, but only to the limits of the physical mask worked out in 2. If you use "access", then you just extended it to "everyone who could physically use some way of this general type", so don't do that.
  5. Then apply conditional access tags (exercise for the reader).
I think (hope) that that's just a restatement of Computing access restrictions#Algorithm taking waterways and railways into account. We should probably make that page more high-profile. --achadwick (talk) 12:48, 18 July 2013 (UTC)
--achadwick (talk) 12:39, 18 July 2013 (UTC)
Any kind of mixing legal/designation and physical properties of ways is quite bad manner. Substitution of properties is also a bad idea.

What does "physically accessible" mean? Pedestrian street could be, physically, passed by the motor vehicle or muscle-driven vehicle. Footway (narrower way built for pedestrians) sometimes, also could be passed, if it's wide enough. Even path could be passed by wheeled vehicle (say, Segway or motorcycle). What properties affecting it? Surface, obstacles (barriers), width, maximum height, depending on specific vehicle. Why should we do some assumptions and use generalized tag to describe physical accessibility? And why should we even think about it, if specific way is not accessible for specific types of traffic (vehicles, pedestrians, etc) legally?--BushmanK (talk) 08:09, 22 July 2013 (UTC)

Are there some mistakes in phrase "Use the access=* key to describe a general access restriction that applies to all transport modes. Note, that, for example, adding access=yes to highway=footway changes default restrictions (which usually are foot=yes and vehicle=no for highway=footway) to yes, highway=footway + access=yes means "road, which is open for all pedestrians and vehicles". Be very careful when adding general permitting tags access=yes and access=permissive, think about adding precise correct tags with concrete transport modes. If you want, for example, distingush footway with open access from footway with closed access, use tags like foot=yes and foot=private instead of access=yes and access=private"? Dinamik (talk) 13:47, 13 August 2013 (UTC)

Resolved: seems to not require any changes to the wiki page Mateusz Konieczny (talk) 12:30, 25 May 2020 (UTC)

Tag for describing the physical access

In description of key access we see "Access values are used to describe the legal access for highway=*s and other facilities including building entrances". Many times I met situations, when people asked about tag for describing physical access to road for different type of vehicles. I think, that there is a sense to create such tag. If you don't see sense in existing such tag, this topic is not for you. If you see sense, please, answer a question "how does such should look like?". For example, we have highway=unclassified road, which is legally available for all vehicles, physically available for "normal" cars, but isn't available for heavy goods vehicles and bicycles. How can we tag it? Dinamik (talk) 07:16, 22 July 2013 (UTC)

Which heavy goods vehicles? Which bicycles? Why? That's the problem, that's why it's hard to tag. Alv (talk) 07:42, 22 July 2013 (UTC)
I agree, that is tag with not the most definable values. But practice shows, that in the most cases it is possible to decide what to do. Sometimes we can use highway=unclassified or highway=track, highway=foothway or highway=path, there are tags smoothness=* and tracktype=*, which values are not always clearly determined. I think, that it better to have scheme, which allows to mark a physical accessibility and a few cases with questionable values, than not have such scheme at all. For example, I see 3 unclassified roads with the same length, but one is good for bicycles, second is almost unserviceable for them and third is something middle. Tag like physical_access passability can solve this task. The first road will get highway=unclassified + access=yes + physical_access:vehicle=yes passability:vehicle=yes passability:vehicle=excellent, the second - highway=unclassified + access=yes + physical_access:vehicle=yes passability:vehicle=yes passability:vehicle=intermediate + physical_access:bicycle=no passability:bicycle=no passability:bicycle=impassable, the third - highway=unclassified + access=yes + physical_access:vehicle=yes passability:vehicle=yes passability:vehicle=intermediate + physical_access:bicycle=medium passability:bicycle=medium passability:bicycle=intermediate. To distinguish two roads with <s>physical_access:bicycle=medium</s> passability:bicycle=medium tag we can use, for example, additional tag <s>physical_access:bicycle:medium=40%</s> passability:bicycle:medium=40% and <s>physical_access:bicycle:medium=60%</s> passability:bicycle:medium=60% (0% means, that road is unserviceable for some type of vehicles, 100% means, that road is excellent). In that way possible values are yes, no and medium with possibility to make the value more exact. I am not sure, that such scheme and such tags are the best, but it is only the first preliminary draft of proposed scheme. I don't like tag physical_access much, because it is rather long. Can you propose the better scheme with better tags? The answers to questions "Which heavy goods vehicles? Which bicycles?" are "normal / average statistical heavy goods vehicle" and "normal / average statistical bicycles" (see specific types of bicycles). Dinamik (talk) 10:24, 22 July 2013 (UTC)
Each road has only limited number of actual physical properties: surface, width, topology. Ability to pass it by some vehicle is just an abstract and derivative property, that depends on assumptions and averaging. Mentioning the particular vehicles in tagging scheme could quite easily lead to confusion and misunderstanding, causing the conflict with legal access. Situations like highway=footway physical_access:motorhome=yes sounds ridiculous, while highway=footway surface=asphalt width=4m max-height=3m perfectly describing the situation.--BushmanK (talk) 11:45, 22 July 2013 (UTC)
I agree, that actual physical properties are good parameters for tagging, but there are many different factors, which can affected to passability - so it is too hard (impossible?) to take them all into account. I think, that we should give a possibility to mark physical parameters for editors, who want mark them, and a possiblity to mark final characterization of road for editors, who want mark it. There is no irreconcilable contradiction between tags for physical properties and tags for final characterization. Dinamik (talk) 05:40, 23 July 2013 (UTC)
I believe the "category vagueness" (for the lack of a better word) is more obvious at the other end of the physical road properties scale. Take a random little maintained road in a remote part of just about any country, and ask, which bus out of these two would get farther along it: (these are just the first suitable examples I found from commons) Neoplan Doppelstockbus Viernheim 100 3625.jpg vs. TATA BUS AT FEWA LAKE POKHARA NEPAL FEB 2013 (8561417995).jpg. It does not only concern mountain roads in poorer countries, but rather just the common reasons for not being passable change from country to country, and they vary from model to model. Sometimes it's too narrow or trees too low, sometimes the road edge/soil will crumble under the weight, sometimes there are too big rocks, bumps and potholes to cross, or even too deep fords. HGV's come in all lengths from maybe 7 meters to 12 meters (+ longer with trailer), and even their width varies. Not only that, but the wheelbase affect their manouverability significantly within the "hgv" category. The only sure way is to test drive each road, and tag (for example) "passable:Volvo_B9R"=yes. Otherwise, we can only claim that where the smallest of all hgv's does not fit, that road is impassable to all hgv's (or the most "terrain-able", where the surface or the required ground clearance is the limiting attribute).
As to unserviceable for bicycles, I believe only narrow tube racing bikes and 3+ wheel cargo bikes will find any roads that can be driven with other vehicles, as impassable - sure, it's sometimes difficult or there's inconvenient heavy traffic, but not physically totally inaccessible. Alv (talk) 22:41, 22 July 2013 (UTC)
Yes, vehicles are different. But the gradation for one class of vehicle is exactly common. For example, we have 3 roads. The first is motorway, the second is impassable path, the third is unpaved way in village. If you ask the drivers of both buses in your example, both of them will say you, that if they have choice, they in the first place they will drive along motorway, in the second place - unpaved way, in the third place - impassable road. This is because first road is the best, second road is the worst and third is intermediate. The aim of tag is give relative ration between roads. We can try to use values excellent, good, intermediate, bad, very_bad, horrible, very_horrible, impassable for such purposes. Dinamik (talk) 05:48, 23 July 2013 (UTC)

Draft of hierarchy for land-based transportation mode

(editing is in progress, you are welcome to add strings)

      • motor_vehicle=* (category: any motorized vehicle)
        • Single-tracked
          • Sinnbild Kraftrad.svg motorcycle=* (a two-wheeled motor vehicle, allowed to drive on motorways)
          • moped=* (motorized bicycles with a speed restriction; e.g., at most a 50 cc engine or max. speed of about 45 km/h)
          • Sinnbild Mofa.svg mofa=* ("low performance moped", usually with a maximum design speed of 25 km/h)
        • Sinnbild Kfz.svg Double-tracked (category: motor vehicles with more than 2 wheels/more than 1 track)
          • Sinnbild PKW.svg motorcar=* automobiles/cars
          • psv=* (public service vehicle)
            • Sinnbild Kraftomnibus.svg bus=* (a bus acting as a public service vehicle)
          • goods=* (light commercial vehicles; e.g., goods vehicles with a maximum allowed mass of up to 3.5 tonnes)
          • Sinnbild LKW.svg hgv=* (heavy goods vehicle; e.g., goods vehicles with a maximum allowed mass over 3.5 tonnes)
          • Sinnbild Traktor.svg agricultural=* (agricultural motor vehicles (e.g., tractors) that have additional restrictions (e.g., a 25 km/h speed limit))
          • ATV=* a.k.a. Quad (bike) (Restricted to or permissive for vehicles 50 in (1.27 m) or less in width) still in proposal stage. You may want to use maxwidth=1.27 instead.
          • snowmobile=*

Rendering Private Features, particularly Ways.

I think a sub-section on rendering would be in order. In particular, I'm noticing that some areas are getting over-mapped with private car parks and footpaths, which can make the map difficult to use when one is looking for public features. Whilst one problemk is that most of these are entered with no access restrictions at all, even when you add restrictions, you end up with a sea of yellow patches, for car parks, and the dominant colour becomes pink because of footpaths and private driveways (typically to flats).

Could I suggest, as a rendering guide, that private footpaths not be rendered at magnifications less than 18, private vehicles ways not below 16 or 17, and private parking lots be restricted to similar zoom levels.

I don't know if it is possible to automatically over-ride these restrictions for exceptionally large private features, but if so, that might be considered. Hadw (talk) 07:58, 5 September 2013 (UTC)

mapping private paths and parkings is not overmaping. Contact authors of map render of you want them to change something. As rendering goals of different map makers will be wildly different it makes no sense to create such guide. Mateusz Konieczny (talk) 09:57, 24 May 2020 (UTC)

Access in common practice, but not in law?

How should something be tagged when there is de facto public access, but no official public access. For a UK (countryside primarily) point of view two examples would be:

  • There is a small woodland which is superficially divided in two, with one half owned by the Woodland Trust and open to the public, but the other half in private ownership. However the public use the private half all the time, and there is not attempt, or crucially willingness, by the owner to stop this.
  • There is a public footpath crossing over the middle of the field, but this is ploughed every year. However, say 30 yards away, along the side of the field is a path where people tend to walk instead. The farmer is happy for this to continue as it has done for years.

In both cases I would say that "access=yes" would be wrong as there is no legal right of way. Access could also be stopped at any point.

"access=permissive" seems a logical answer, but there is indeed no official permission, nor is there likely to be, and any attempts to get official permissive access would most likely result in the landowner clamping down on public access for fear of more permanent legal access being enshrined. What's more 'permissive access' in UK legal terms is something else which basically entails creating a public footpath but only for a set number of years after which is becomes private again - usually simply for the purpose of outdoor recreation.

What access should the tags be? --Abc26324 17:21, 21 January 2014 (UTC)

access=permissive is OK. The value "permissive" is more generic than only for cases where permission is given "in writing", it also applies to cases where the owner implicitely "tolerates" it ("tacit permission"). If you really want to provide more detail about the type of "permission", I suggest to add the key permissive=* for the details, for example something like permissive=toleration in this case.--Martinq (talk) 19:12, 21 January 2014 (UTC)
Resolved: seems to not require any changes to the wiki page Mateusz Konieczny (talk) 12:31, 25 May 2020 (UTC)

Compulsory and non-compulsory cycleways

In France as well as in Germany roadside cycleways and cycle lanes can be compulsory or not. In France, the roadsign for the compulsory ones is round, the sign for the non-compulsory ones rectangular. In Germany the compulsory ones are marked like in France, the non-compulsory ones generally are not marked with signs.

The terms used for tagging are not self-explaning. Therefore the very busy and advanced Lübeck Group prefers the tag "bicyle=yes" for the non-compulsory ones, and the tag "bicyle=designated" for the compulsory ones (They have also listed "bicyle=official", but they do not use it practically), which differs from the international scheme. See

Up to now, no renderer shows these specifications. Before any does, a new tag can be introduced, still.

I suggest the tag "bicycle=compulsory" for the compulsory cycleways and cyclelanes. That is self-explaining to all mappers. For the non-compulsory ones, the use of "bicycle=yes" may be kept.--Ulamm (talk) 15:00, 16 June 2014 (UTC)

Being comulsory is more an attribute of the referring street than of the cycleway, if the cycleway is mapped as a separate way (see bicycle=use_sidepath). Infrastructure like a cycleway lane or track is per se designated (this is very common usage and was documented as described until YOU changed the description of the tag at this page). --U715371 (talk) 14:28, 26 November 2014 (UTC)
Telling that the tag is used in different meanings, my change is descriptive. The ambiguity of the usage is a problem that mustn't be denied. Reality is worth to be recorded, because it is real, and not only to feed some routers. Therefore bicycle=use_sidepath is insufficient, too, if PeeWee's restriction of its usage is accepted.--Ulamm (talk) 11:22, 27 November 2014 (UTC)
Since June, I have changed the terms of my suggestion: cycleway=obligatory on road-tagged cycleways and bicycle=obligatory on separately drawn ones has the advantage that "obligatory/obligatoire/obligatorio/obligatorisch" is common to many languages. The opposition can be =facultative or =free. "free" is the shorter, simpler and more positive term, but sometimes the word is used as a synonyme of "gratis".--Ulamm (talk) 11:36, 27 November 2014 (UTC)

What should the tag be for when a permit is required for access/use?

For example - in many Forestry Commission owned woodland in the UK you have to have a permit from the Commission to ride horses, with no such permit is needed for walking or cycling. I would have though the best tag would be 'horse=permit'+'foot=yes' etc etc.

I've had look around and found nothing similar or useful - does anyone know how to tag?

In the current scheme the best solution IMO:
'horse=private' + 'foot=yes' + ...
with private: Only with permission of the owner on an individual basis. Althio (talk) 11:39, 4 December 2014 (UTC)
I use "horse=permit" for this. Whilst "horse=private" correctly describes the access permissions it fails to convey the fact that the landowner is amenable to horse riding (albeit in a controlled manner).
AndyS (talk)
In my opinion, how exactly you obtain permission from the owner to use a feature (renting, verbal agreement, obtaining a permit) is too much detail for access tagging. --Tordanik 22:55, 10 December 2014 (UTC)
I think, AndyS' solution is convincing.--Ulamm (talk) 07:59, 12 December 2014 (UTC)
From my point of view it seems like another tag-combination that doesn't add useful information; it's still access given by owner (and here you can define owner either very specifically, or simply look at it from a broad point of view) and thusly it seems rather redundant and unhelpful to use a permit value. I agree with Tordanik. Messy Unicorn (talk) 02:45, 1 January 2015 (UTC)
I also agree, uncontrolled growth of values is a nightmare during data processing. Mateusz Konieczny (talk) 20:18, 3 January 2015 (UTC)
access=private implies that it is the landowner, owners association, or other non-governmental group that regulates the access, whether by signing, verbal agreement or written permit, I am not sure how to treat this if it is done by the government, but that will be on an exception basis and not a general rule. i.e. if the government give access to horses on a footway, than there will be a sign allowing horse=yes, if Average Joe have been given this permission than no tag should be added as this is an individual exception to the rule. --Skippern (talk) 10:29, 4 January 2015 (UTC)
Although I'll agree that's reasonable based on the access=* page, I disagree that it's necessarily a non-governmental group that regulates the access where access=private is used. An example would be the entrance to a military camp: access is granted on an individual basis, from a governmental organization -- although usually from a set person/group.
While I agree that access=private doesn't have the same sense of belonging to the situation, I find that the tag rather well defines the legal use-case and right-of-use. In a Venn diagram, I would visualize access=permit as only being slightly off access=private. Does it seem like they're much more similar if you look at another potential tag that overlaps both of these, such as access=permission? Messy Unicorn (talk) 12:50, 4 January 2015 (UTC)
Well, a military base would most likely be access=no anyway, and if access to the base is done on a per-case individual evaluation of the base management, than it would not alter the fact that access=no. access=no doesn't necessarily mean that there is absolutely no access, it means that there are no public access. Authorised personnel will still have access in one form or another, such as soldiers and officers belonging to that particular base. On another such note, many ports could be tagged with access=ISPS instead of access=no, ISPS have a specific meaning which might change with political threats or particular threats of terrorism etc, including requesting access to area in advance, access for documented cargo, etc. We could probably add thousands of different values to cover all possible aspect of access, resulting in a cumbersome task for dataconsumers to interpret the data as well as mappers to understand what to add and when. (Most ISPS port facilities have a large visible sign which states it is an ISPS facility and the current threat level). --Skippern (talk) 13:18, 4 January 2015 (UTC)
Please don't use ISPS: they have a general access permission from national laws for situations of emergencies, including for entering any private or military area or any dangerous area or any ship or port facility in their maritime or land area of competence. They can use any highway, field, cross any building, enter any vehicle, they can walk, use vehicles including helicopters and otrher ships, climb, break doors/windows/walls/barriers... The state will offer compensation later to landowners/ship owners/harbour operators, in case of damages caused by their access! Their emergency mission prevails, notably when life of persons is involved (this includes the police, armies, and official civil security services; however they'll coordinate with local security teams and their respective higher authorities will negociate in case of conflicts; or the government or a juge may grant special rights by designating a competent team to lead the operations and coordinate the work made by multiple teams and to report progresses to high autorities). In such case, we cannot decide anything, the situation will evolve in unpredictable ways. The ISPS rules only apply in practice to inside foreign ships navigating in territorial waters, or inside any ship on international waters, it does not apply on lands except authorized personnel that you can find in any private place. The rule in normal time remains access=private or access=no. The ISPS standard only gives basic rules for qualifying personnels and equipments so that a ISPS-compliant certification made and asserted in one country is valid in another one. Similar standard also exist for international air traffic, customs/duty controls, fight against piracy and terrorism, fight against money laundry (see the ratification of UN treaties and UN Security Council decisions). — Verdy_p (talk) 20:29, 8 March 2017 (UTC)

Access only by toll?

There are a number of roads that I know about (in Switzerland, but there are probably equivalents everywhere) that have the restrictions:

  • Unrestricted use by residents, public service and agricultural vehicles
  • Motor vehicle access to the general public on payment of a toll
  • Foot and cycle access unrestricted

This is enforced by an automatic barrier at the point of access, to which those in the first category have some sort of key while other vehicles have to make a cash payment.

What sort of tag should be used for these? The first would imply access=private, but the definition of that is "Only with permission of the owner on an individual basis", which does not strictly apply - there is no individual negotiation with the owner or any formal permission given, but it is available to anyone after payment of the toll. It can't be access=designated because that says "for a specific vehicle type or types", and I'm not sure whether a vehicle falls into a "certain type" just by paying a toll. It can't be access=permissive either because it is not "Open to general traffic...".

At the moment I'm guessing access=destination (because these are not through routes) combined with a toll barrier at the access point. Just wondering, though, if this would affect routing (OSRM seems to not comment on the restriction). Threefoursixninefour (talk) 11:16, 28 March 2015 (UTC)

access=private;toll or access=residents;toll ? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:00, 28 March 2015 (UTC)

highway=path and bicycle=* in Austria

Currently this table lists Austria as the only of 22 countries where highway=path implies bicycle=no. Why is it so? I don't think many mappers are aware and respect this.

Also the table thinks that designated forest roads are tagged highway=track + vehicle=forestry - imho highway=* + access=forestry would be better. RicoZ (talk) 13:10, 7 June 2015 (UTC)


It was added with description "Alternate form of the above". Given that it is outnumbered 423 to 2 975 035 - can it be considered as anything more than rare misstagging? Is there any proposal, reasoning or idea supporting this tagging? Mateusz Konieczny (talk) 09:32, 23 August 2015 (UTC)

There were some proposals like Proposed_features/access_restrictions_1.5#Namespace and there is serious need to further develop current access mechanisms (Talk:Proposed_features/access_restrictions_1.5#Any_life_here.3F). Having an "access:" prefix with a chain of roles and other subkey specifiers seems like one of the more workable ways to go. RicoZ (talk) 12:14, 23 August 2015 (UTC)
Maybe it would be better to link proposal in see also? I think that this tags are rather in proposal phase Mateusz Konieczny (talk) 17:36, 23 August 2015 (UTC)
There is rendering support for this variant (see Andy Allen's messages on the topic). Brycenesbitt (talk) 03:36, 24 August 2015 (UTC)
Tags like access:bicycle=yes are valid syntax in the context of the (approved) Conditional restrictions framework. The proposals mentioned above are not needed for this. --Tordanik 13:24, 24 August 2015 (UTC)

Resolved: gone from the page Mateusz Konieczny (talk) 09:38, 24 May 2020 (UTC)

Personal transporters, alias Segway : access tags for "mofas" (low powered) or "mopeds"?

"Ride on Personal Transporters prohibited" (IZ 8a) signal used in the Czech Republic.
Access restriction signal in Prague, Czech Republic.
See also Other images on Commons.

This road [6] is now prohibited to the segway motorized scooters (see image: [7]); since the city is planning a wider rollout of such bans, is there way to tag this? I don't see a segway=* tag, and there doesn't seem to be a relevant category in the Land-based hierarchy either. Is a special tag overkill here? Piskvor (talk) 14:24, 11 September 2015 (UTC)

  • Given that only segways are banned (and vehicles and pedestrians are allowed) new tag may be required Mateusz Konieczny (talk) 14:52, 11 September 2015 (UTC)
  • It seems strange than some official traffic sign uses the term "Segway" which is a recently invented, registered (and still protected) trademark. May be the Czech authority did not officialize the traffic sign really, but it is just a local initiative, currently experimented. Many people will just wonder what is a "segway" (even if Segway is still the main manufacturer, and many users of these two-wheeled motorized slow vehicles would know it; however given its price, other areas would know it under diffrent name. The term adopted in France is "gyropode", with "gyro" refering to rotating wheels, and "pode" for the feet as users are standing with their feet on the platform. In France their status is still not clear, but given the speed (20 km/h) they are not suitable for use on footways.
    For now they are considered mostly like bikes with electric assistance in France (but bicycles with motorized assistance are still not permitted on restricted footways, they must also use a cycleway or the carriage lanes of the street).
    The same engines may be used by people with walking disabilities, in such case they can use footways, just like motorized chairs, but the vehicle must be signaled by a special sticker, so they have to use cycleways or the carriage ways of streets.
    Some of these "Segway" vehicles are really too fast, theyt've been modified to run as fast as motorcycles and could reach 40 km/h or more (when footways should be limited to less than 15km/h and most users on their feet don't walk faster than 7 km/h.)
    Probably the problem here in this Czech city is already the excessive speed (possibly also the noise of the engine in what should be a pure pedestrian area with only unmotorized bicyles admitted) and risks of collisions with pedestrians.
    It looks like this should adopt the same regulation as rollers or skateboarders, frequently forbidden as well (notably where there's a steep incline or steps, like in your example image). And wearing a bicycle helmet is also mandatory in various countries, like with any bikes.
    For the sign itself (beside the non conforming term "segway"), it should be replaced by a symbol. The French adopted generic term "gyropode" starts being used as well in English (even Segway describes sells its vehiles under this name). The term "segway" is almost unknown in France. I doubt that the term would fit very well on restriction traffic signs. But it's easy to design a symbol from it, just like there are symbols for rollers and skateboards.
    Note all "segways" have a handle for hands. See for example this collection of images on Google [8], or in French with the term "gyropode" [9]. You'll see immediately that there arez other manufacturers and trademarks than "Segway". You'll also see that these vehicles are also used by the police within cities.
    In all cases, please avoid using the trademark "segway" for naming tags in OSM (I suggest "gyropode=no", to be used like "bike=no"): this tag will not be needed in France because all gyropodes are considered to be motorcycles (using "motorcycle=no" is enough in your example, or possibly "moped=no": no need for a new traffic sign in France; may be this is similar as well in the Czech republic, that legally considers these gyropodes also as motorcycles with the same rules, including the required helmet for driving them, and the fact that they don't have priority against walkers on footways where they could be tolerated, and the requirement to use the carriage way and not the sidewalks, or the requirements to register and display the registration number of the vehicle and to have an assurance for damages caused to tiers, unless this is just a toy for children and its manufacturer respects and certify severe limitations on power, speed (less than 7km/h) and total weight, and they pass the mandatory security tests required for these "toys" being suitable for children, including securing the electric engine and batteries). — Verdy_p (talk) 19:04, 8 March 2017 (UTC)
  • Note: I find useful this statement in English Wikipedia about mopeds in the European Union (applicable to the Czech Republic):
    The drivers license category for mopeds across the E.U. now is the AM driver's license. This license is for scooters and mopeds with no more than 50 cc (3.1 cu in), and a maximum speed of 45 km/h (28 mph). E.U. member countries that had not fully implemented the E.U. directive that refers to the moped and other drivers license categories had to do so by 2013 at the latest. The "E.U. moped" is a scooter, moped (or similar) with two, three or four wheels, a maximum speed of 45 km/h (28 mph) and an obligatory license plate as proof of insurance. Many E.U. countries only require special insurer issued plates, not state issued plates.
    So moped=no (this includes scooters, and models of fast segways used by policemen) or mofa=no (low power mopeds, below 25 km/h, no passenger except the driver, no "AM" driving license required, not applicable to scooters) is probably the best response to your problem (ignore the informal term "segway" shown, the Czech city should use the normative signal applicable to mopeds, the term "segway" used has no legal value, it is just informative, but then the rest of the plate is a general interdiction: this signal is clearly invalid and most probably has no legal value). — Verdy_p (talk) 19:46, 8 March 2017 (UTC)
The term gyropode is apparently not English but French. Why cannot we use segway=*? Because of some legal consequences? I do not think you can register the word itself. Anyway segway=* was used in database already. What is the English generic term for this vehicle? Hoverboard? Can some native English speaker weigh in? Chrabros (talk) 06:38, 9 March 2017 (UTC)
See the website of the Segway company: it uses "gyropode" in its English pages ! I oppose "segway" because it is still a protected trademark, that other manufacturers don't use (they also use "gyropode") — Verdy_p (talk) 12:56, 11 March 2017 (UTC)
Note also that English has the terms "personal transporters", and France is about to pass laws applicable to a larger category of "transporteurs personnels", with the same meaning (but that will also include rollers or skateboards, as well as electric chairs but with some exemptions for people with officially recognized walking disabilities...)
The European Union also uses "personal transporter". The Czech Republic uses "Osobní přepravník" with the same meaning. So "Segway" is the wrong term (used informally, but still a trademark not applicable to all manufacturers and all types of similar vehicles for single persons and running at speed lower than 25 km/h, including electric chairs and "mofas").
Below 25 km/h, they are not considered as motorized vehicles, but users of engines limited to 6 km/h (required to be suitable as toys for children) are considered as pedestrians and can legally use all footways. But personal transporters must not use the carriage ways for motor vehicles and are only "tolerated" on cycleways (cycles can go above 25 km/h) only if protection helmets are worn (just like bike users). On footways, these engines must not be used above 6 km/h.
The signs used in the Czech Republic would soon become simply illegal as this is an unfair access restriction between pedestrians: if a footway/path is marked for pedestrians, all personal transporters can use them provided they run at foot speed below 7km/h (manufacturers will soon have to include speed limiters on their engines, because they run too fast up to 24km/h, between 7km/h and 25km/h without these limiters, they are considered like "mofas" so these restriction should be mapped as "mofas=no"). Faster engines (such as those used by policemen) are considered like motorcycles and more generally as motorized vehicles (so motor=no will prohibit their access, but these models can run on ways for motorized vehicles, and will require a driver's licence, an official registration plate, an insurance, and wearing the same protection helmets and clothings applicable to motorcycles). — Verdy_p (talk) 13:34, 11 March 2017 (UTC)

Gated Communities

I read a previous discussion here about the access tag, and 2 years later I found an issue.

OSRM will not route to our from a gated community with access=private. Tagging it with Schrader (talk) 20:10, 16 June 2016 (UTC)

Is anybody permitted to entry this area to reach houses? If not then access=destination should not be used. In general it sounds like OSRM bug that should be reported to them Mateusz Konieczny (talk) 13:45, 18 June 2016 (UTC)
Resolved: Mateusz Konieczny (talk) 09:35, 24 May 2020 (UTC)

access tag for people living there?

It does not look like there is a tag that says "people who live there/own something in the area are allowed to access it" (in german "Ausgenommen Anrainer"). Any ideas for that?
--TBKMrt (talk) 08:57, 8 April 2017 (UTC)

This is access=destination. Not really "private" because it's shared (and publicly owned), but access is still limited for vehicles, but allowed for delivery and visitors, or public service vehicles. And pedestrian hikers or bikes are also allowed; vehicles entering there should consider it like a living street (speed generally limited to 30 km/h, or lower with an additional trafic signal to tax with maxspeed=*). Cannot be used for parking or camping (except possibly within private areas connected by this access driveway, under specific permission of local residents and land owners). — Verdy_p (talk) 13:32, 8 April 2017 (UTC)
If you had read the page, "Ausgenommen Anrainer" in German is explicitly given in the description ! — Verdy_p (talk) 13:41, 8 April 2017 (UTC)
Thank you for your fast answer - I'm not used to an answer that fast on this site. I read that part, but was confused by the part that there is no distinction between people who live there and people who drive into the area (so like no passthrough, but not delivery) as "destination" sounds as if it would represent both at the same time. --TBKMrt (talk) 17:49, 16 April 2017 (UTC)
People living there have also a need to jet visitors come in (destination) and products delivered to them (delivery). If there are other restrictions (such as vehicle weights, or bicycles/pededstrian only, or no parking here, or private parkings reserved for some residents only) there will be additonal restriction tags.
so access=destination is still the correct answer. It perfectly matches what you asked for including with the common translated messages visible on the ground in street signs for several languages. But it cannot cover more local details where there will be additional restrictions with additional street signs. — Verdy_p (talk) 10:51, 20 April 2017 (UTC)
The description on the wiki page is actually a bit more liberal than the legal definition of Anrainer/Anlieger in AT/DE but access=destination is the accepted way of tagging those streets in AT and DE. -- TZorn (talk)
access=private, if really only "people living there" may enter Mateusz Konieczny (talk) 05:17, 3 October 2017 (UTC)

Access=no for hgv with EURO 0-2

Is there any standard how this should be tagged? --TBKMrt (talk) 13:42, 1 October 2017 (UTC)

The EURO emission standard. It is not allowed to access this was with cars that emission standard is EURO 0, 1 or 2. --TBKMrt (talk) 17:12, 9 October 2017 (UTC)
soooo? --TBKMrt (talk) 01:08, 10 December 2017 (UTC)
If you're looking for more input, it would probably be best to ask this question again on the tagging mailing list. The forum might be an option, too, although its English language section is not as active as the lists. --Tordanik 16:53, 12 December 2017 (UTC)
Resolved: it seems there is no obvious answer and noone appears to be interested in making in a proposal Mateusz Konieczny (talk) 12:34, 25 May 2020 (UTC)


Does anyone think we need a new access key for electric vehicles, e. g. electric cars? This could maybe be a sub-gruop of motor vehicles. Lukas458 12:34, 25 Oct 2017

Yes, a separate tag for electric cars is needed. There are different restrictions in many places for them. They aso have different/reduced fees in toll points many places in Norway
Maybe electric_car=* can be an alternative? Gazer75 (talk) 15:52, 16 June 2019 (UTC)
I don't think electric_car=* would be the right choice. Even it's already used today by 280 nodes. But it would be better to use vehicle:electric=* as verhicle could be anything like motorcar, hgv or bicycle. Just replace vehicle by required category. Additional, electric could be replaced by diesel and German restrictions on Diesel vehicles could be targeted by same key as well. Anyhow, a new access key combination is required. --Vanagaudi (talk) 15:41, 9 January 2020 (UTC)

is *=delivery correct for any case?

*=delivery seems generally suspicious - "Only when delivering to the element."?

So (1) owner of the road/area may not use if (s)he is not delivering anything and (2) whoever wants to deliver anything may use it? I would expect that all (nearly all) of *=delivery are better described as *=private ("Only with permission of the owner on an individual basis." - so authorized deliveries may use it) Mateusz Konieczny (talk) 17:46, 11 November 2017 (UTC)

The delivery value isn't limited to private roads. Around here, it is commonly found in pedestrian streets: There's often a special signed exception for vehicles delivering wares to the local shops. --Tordanik 17:53, 13 November 2017 (UTC)
Yes, highway=pedestrian, motor_vehicle=delivery may make sense Mateusz Konieczny (talk) 23:03, 21 November 2017 (UTC)
Resolved: added Mateusz Konieczny (talk) 12:37, 25 May 2020 (UTC)

value "designated"

The present text for the definition of the value "designated" reads:

"A preferred or designated route for the class of traffic specified by the tag key, such as foot=designated."

"preferred" means non-exclusive, which would mean tags like "bicycle=designated" do not exclude other highway uses, like foot, horse, tank, elephant, you name it. But, in practice, "bicycle=designated" is normally used to mean exclusive use, unless you add a second means of transport, like adding "foot=designated" which would make this highway exclusive to cyclists and pedestrians, but excludes everything else.

I am not aware of any use in the sense of "preferred".

I suggest to drop the meaning "preferred" from the description of the value "designated".

My interpretation of "preferred" in this context is that "designated" modes of traffic have some kind of priority over those that are merely "yes". For example, a path tagged foot=designated and bicycle=yes would require cyclists to make a particular effort to not get into pedestrians' way, by driving more slowly and so on. That is, pedestrians would be "preferred" in that situation. --Tordanik 19:06, 17 January 2018 (UTC)

access on non-navigational objects

The page currently focuses on the road network. Indeed the access tag is used to 75% in combination with the highway tag. However about 10% each are on leisure and on amenity (most popular probably on amenity=parking and leisure=playground). I'd like to reflect that on the page. --Polarbear w (talk) 17:23, 7 February 2018 (UTC)

Sounds like a good idea Mateusz Konieczny (talk) 12:01, 8 February 2018 (UTC)
Done, open for refinements. --Polarbear w (talk) 11:09, 9 February 2018 (UTC)

Resolved: Thanks for improving the page! Mateusz Konieczny (talk) 09:39, 24 May 2020 (UTC)

Let us reword the definition for "private"

Currently the definition for private reads: "Only with permission of the owner on an individual basis." I propose to change this, in accordance with the general mapping practise, to the more concise and more accurate wording "only with individual permission" or "Only with permission on an individual basis". Asking about permission from the "owner" seems to complicate unnecessarily the question, and in case of public roads with "private" access (i.e. special permit required), the "owner" might be another entity than the one issuing permits. This would make it also clearer that "private" is not meant only for "private roads". --Dieterdreist (talk) 09:14, 14 May 2018 (UTC)

I agree. I made change, if anybody disagrees please revert it and comment here Mateusz Konieczny (talk) 09:21, 14 May 2018 (UTC)
Thank you! --Dieterdreist (talk) 09:39, 14 May 2018 (UTC)
Hi, I think this is a rather (perhaps unintentional?) substantial change from the wat that no/private are used in tagging and described on the wiki as far as I have seen. In this case all the examples where a traffic sign forbids entrance for a specific transport mode (bicycles, motorcycles, ..) instead of "no" you would have to change it into "private", because under the different traffic coedes there often s a possibility to get a dispensation on individual basis either regularly (if you have to use a cycleway to get to your home) or for a day or so (special occasions such as maintenance, festivals, emergencies).

This would lead to a massive retagging which would not be positive but negative in my opinion, because you would lose sight of which roads are private instead of being accessible for the general public. "Private" seems like an excellent tag for private roads. Multimodaal (talk) 17:03, 14 May 2018 (UTC)

what is diffference between =private and =no

For example "residents only" - is it =private or =no? Or private driveway used by property owner and his/her quests - is it =private or =no? In practise it seems that there is nearly no difference between these two values. Mateusz Konieczny (talk) 09:33, 14 May 2018 (UTC)

"no" is IMHO for situations where nobody may access the place, e.g. because it is dangerous (think nuclear radiation or something like this), or because by accessing you might create a dangerous situation for others (e.g. cause a landslide). In all other cases (including military areas), where there is someone who has the permission to access, you should use "private". In other words, true "no" are extremely rare and private is usually the better value. --Dieterdreist (talk) 09:43, 14 May 2018 (UTC)
I agree generally but would go for less extreme examples. =private is where there is regularly access for a limited range of users, i.e. the teacher's car park. I would use =no e.g. for a gate that is regularly locked, i.e. not typically used, but can be opened to leave a large vehicle in for construction. --Polarbear w (talk) 16:22, 14 May 2018 (UTC)
For a gate which is locked but occassionally might be opened, e.g. for large vehicles, I would use private. Maybe for a locked access to an old mine where access is dangerous I would put no (less extreme). --Dieterdreist (talk) 16:36, 14 May 2018 (UTC)
I think this is not is different from how it is used in tagging and in the wiki untiul now; if there is a traffic sign that prohibits a certain transport mode, it is indicated that this is ..=no and not "private". And "bicycle=no" seems far more logical to me on say a motorway then "bicycle=private" (even though there have been examples that a motorway in the Netherlands has been blocked for speed cycling by the road authority ;-) Multimodaal (talk) 18:59, 14 May 2018 (UTC)
Yes of course, I was writing about the generic access=no, for specific modes of transport "no" is much more frequent. "residents only" (wrt vehicles (like it is meant in Italy) would be private, "Anlieger Frei" like it is in Germany is "destination". In case there are exceptions, there is never "no". --Dieterdreist (talk) 17:29, 14 May 2018 (UTC)
OK, thanks for clarifying that, for the generic access=no I agree that that should be reserved only situations whit no -taggable- exeptions. Personally I would tag a closed military areas wih "no"instedad of "private", since they are not privately owned but government owned.Multimodaal (talk) 19:00, 14 May 2018 (UTC)

Missing access value

I'd like to draw your attention to a problem:
There are many special roads in Hungary only used for prior authorization / permission. The total length of these roads are hundreds of kilometers. The type of permit applies to pedestrian / bike access or only motor vehicle depending on the roads. These roads are currently not properly tagged. There is a significant difference compared to existing values (private, permissive), because mostly anyone can ask permission for these roads (what you get), but without it, entry is forbidden. That's why I've thought needs a new tag.
These roads can be classified into three main categories:

  • Roads found in Waterworks area (These roads go in untouched nature, perfect for biking, running. Entry without permission is strictly forbidden, a photo ID is required, but anyone can get it. It had to pay for it, but it's free now): The access tags would be sg like this: access=no/private?, foot=license/authorization, horse=no, motor_vehicle / vehicle? =no, bicycle=license
  • Roads on the embankments (The longest ones in category. Driving by car without permission is forbidden, other access is free. Some roads on the embankments are free access): The access tags are: access= private, foot=yes, horse=yes, motor_vehicle / vehicle? =private, bicycle=yes, motorcar=license, motorcycle=license
  • Roads managed by Hunting Association (wildlife reserves) (These roads go in huge forests. Crossing by vehicle without permission is forbidden): The access tags are: access=private, foot=yes, horse=license, motor_vehicle / vehicle? =license, bicycle=license

(I know the "license or authorization?", maybe not the best choice, but these are different from permissive and private. I'm waiting for your proposal.)

Why is maxspeed an access tag?

Looking at the examples.. and wondering.RicoZ (talk) 11:41, 4 September 2018 (UTC)

It's a bit weird, I agree. You could maybe think in this way: "If you want to drive faster than 70 km/h you cannot use this road". -- TZorn (talk) 16:43, 13 September 2018 (UTC)

Event access?

I tagged a parking lot as access=event. Access to this parking lot is blocked by a chain expect during specific events when additional parking capacity is needed. There are many amenities, roads and barriers which are typically accessible only during special events. The schedule of these events may vary. Comments? T99 (talk) 06:40, 14 January 2019 (UTC)

Maybe introduce a Key:access=restricted ?

Possibility to 'introduce' a Key:access=restricted ... with description ; traffic only open for mentioned*=yes . Could be a simple 'replacement' for several others, like i.e. ; access=restricted + agricultural=yes (because ;"Only for agricultural traffic") and access=restricted + forestry=yes (because; "Only for forestry traffic.") and access=restricted + delivery=yes (because; "Only when delivering to the element") and so on ... Because there is some 'confusing' for several 'cases' -> --Henke54 (talk) 10:48, 23 February 2019 (UTC)

I redirected on of your pages to avoid confusion [10]. I guess you refer to a tag (key means left side only). What do you mean by mentioned*=yes? mentioned:agriculture=yes? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:16, 27 February 2019 (UTC)
  • Sorry for my fault, you are right, i only meant, if it could be, to add 'restricted' as a value on Access tag values, because some roads (in Belgium for example Buurtweg) are not 'compatible' with 'permissive' or 'private' or 'permit' or any other value on Access tag values ... even the Belgium 'prof'-mappers are sometimes 'confused' about how to tag some of those roads -> --Henke54 (talk) 09:17, 28 February 2019 (UTC)
    • Can you try describing the problematic situation? Unfortunately I am unable to speak in language in linked thread. I am pretty sure that existing tagging will be able to cover it. You may also try asking on tagging mailing list Mateusz Konieczny (talk) 09:38, 28 February 2019 (UTC)
I see no reason whatsoever to create duplicate of access=private. Mateusz Konieczny (talk) 17:24, 27 February 2019 (UTC)
"Could be a simple 'replacement' for several others," - I see nothing simpler in this replacement and this proposal would effectively create duplicate tagging scheme. JOSM already complains about access=restricted. I also modified Tag:access=restricted to explain standard tagging. Feel free to modify it if I misunderstood this new proposed tagging scheme. Mateusz Konieczny (talk) 17:26, 27 February 2019 (UTC)
It is even worse, access=restricted was present for a long time, so this proposal manages not only to duplicate existing tagging scheme but also to conflict with old meaning of access=restricted Mateusz Konieczny (talk) 19:20, 27 February 2019 (UTC)

Why not access=employees

A lot of Tag:amenity=parking are reserved for employees of the structure : employees of an hospital, employees of a factory, employees of an administration, employees of a university, and so on... There is no way for somebody not working there to park at this place... this is reserved for employees !
Therefore a very simple proposal: why not introducing a new key for the Access tag values to denote this usage?
The new value would be Tag:access=employees.
This key is already used:

Barnes38 (talk) 19:59, 24 June 2019 (UTC)

access for hgv with trailer

Is there any access key for ways that restrict hgv that tow a trailer? So motor_vehicle=yes, hgv=yes, motor_vehicle+trailer=yes, hgv+trailer=no. I didn't see any. Did I miss it? The access restriction also has a dedicated street sign in Austria --TBKMrt (talk) 13:34, 24 August 2019 (UTC)

I would go more with what seems to be the standard pattern with a collon. So like access:hgv I would either go with hgv:trailer or trailer:hgv. I would choose the second one since it follows the same logic of access:hgv. You can figure out what is meant by asking The access for what. Answer: The access for hgv. So the question would here be The trailer of what? -> The trailer of the hgv.
hgv_articulated does exist, but it's just proposed and it's used only 136 times accoring to taginfo. So I wouldn't use this as explicit example even we can use it as guideline. --TBKMrt (talk) 00:38, 20 September 2019 (UTC)

Proposal: reorder sections

This article is very long - and for a new mapper, I think too complex. I propose as a first step moving 'Transport based restrictions' up to just below 'Access tag values', as this is the most frequent use of the tag. Time-based and other tricky cases should go below, so that the article moves from simple cases to more complex. Eteb3 (talk) 07:31, 9 October 2019 (UTC)

  • Seems a good idea. Note that in general such edits can be also done without proposing/discussing them. And start discussion in case where someone disagrees and reverts such edit. Mateusz Konieczny (talk) 19:53, 9 October 2019 (UTC)
    • Thanks. If I try to move 'Transport based restrictions' I get the message 'This section is anchor linked from above'. What does that mean, and can I override it? eteb3 (talk)

potential change of subtitle order

Could it make sense to change the current order of:
? --MalgiK (talk) 17:32, 29 January 2020 (UTC)

Or even
3 Access time and other conditional restrictions
4 Size and statutory restrictions
5 Routing restrictions
6 Transport mode restrictions
3 Transport mode restrictions
4 Routing restrictions
5 Access time and other conditional restrictions
6 Size and statutory restrictions
--MalgiK (talk) 17:38, 29 January 2020 (UTC)
Or even we start with chapter key which seems current 6. "Transport_mode_restrictions" ( followed by value which seems currently 2. "List_of_possible_values" ( and so on... --MalgiK (talk) 17:50, 29 January 2020 (UTC)
Did an edit for changing the order of the sections, please double check, if it will not work this way, please undo it. --MalgiK (talk) 11:41, 31 January 2020 (UTC)

Direction dependent access tags do not overrule oneway restriction

The current text under the header "Exceptions to 'one-way' and related special cases" is misleading. It seems to suggest that bicycle:backward=yes can be used to overrule oneway=yes while that is not the case. Oneway is not the same as general access in one direction.

AndriesWijma (talk) 13:58, 14 May 2020 (UTC)

Yes, to override oneway for bicycles we have oneway:bicycle=* Mateusz Konieczny (talk) 14:26, 14 May 2020 (UTC)
No, I disagree. oneway=yes can be interprated as vehicle:backward:no. From that it logically follows that bicycle:backward=yes overrides vehicle:backward:no and therefor oneway=yes Phicoh
We've already had this discussion on the Dutch forum where I've explained why your conclusion is wrong and I've demonstrated that OSRM and GraphHopper disagree with you. AndriesWijma (talk) 16:06, 14 May 2020 (UTC)
If your main argument is how two routers handle a corner case, then I don't find that very convincing. In any case, we already had this discussion doesn't imply any kind of conclusion. Just that we disagree on this Phicoh
My main arguments are that the tagging hierarchy does not work the way you imply, that you interpret the meaning of the text starting with "The oneway tag can be translated (for routing purposes) to this generic system [...]" wrong and that it does not logically follow that a surrogate tag interacts the same way with other tags as the original tag." Please resume the discussion on the Dutch forum. AndriesWijma (talk) 22:16, 14 May 2020 (UTC)
I agree that bicycle:backward=yes can be interpreted as equivalent to oneway:bicycle=*. But oneway:bicycle=* is much more clear, readable and established, so I would strongly recommend using oneway:bicycle=*. oneway:foot=* was different because it is less established and some claimed that "oneway" applies only to vehicles even in case of oneway:foot=*. Mateusz Konieczny (talk) 23:18, 14 May 2020 (UTC)
Yes, a router can go with that simplification. The problematic claim though is that it means that bicycle:backward=yes overrules oneway=yes because bicycle:backward=yes is more specific than vehicle:backward=no. But you can't use the already interpreted tag to weigh against other tags, no it still is oneway=yes. And oneway is an access restriction tag not an access tag. It restricts traffic that has gained access through access tags. Bicycle:backward=yes is an access tag and does not overrule the access restriction oneway=yes. AndriesWijma (talk) 23:43, 14 May 2020 (UTC)

Why does dog=* still missing at this page?

Here is proposal but it is for some reason not yet accepted: Proposed_features/Key:Dog. We have 3000 dog=* tags in database already... Xxzme (talk) 23:19, 20 July 2014 (UTC)

No one responded in six years, but I too wondered why it was missing. It is used often enough. It looks like an oversight in documentation to me. I have added dog=* in below horse=*. JeroenHoek (talk) 07:10, 24 May 2020 (UTC)
The problem is that horse=* is about transport using horse - is dog=* about dog riding? I would put it into related tags if it is about walking with a dog (or about transporting dog in some other way) Mateusz Konieczny (talk) 09:23, 24 May 2020 (UTC)
Is that a correct line of reasoning though? While most people won't literally ride dogs, you do take them along. The dog may not (usually) propel you along, but you are still responsible for conducting it and adhering to any restrictions placed on the route. I think we can think of dog=* in a similar vein as trailer=*; a passive addition to the class of vehicle. If trailers should be in the list, dogs seem valid too, don't you think? Come to think of it, dog=* should probably reside under foot=* as a sub-category of that. JeroenHoek (talk) 10:14, 24 May 2020 (UTC)
And caravan=* (This reminds me of dog sleigh, for the oppsoite case of riding on the trailer, as in carriage=*)) -- Kovposch (talk) 10:32, 24 May 2020 (UTC)
"addition to the class of vehicle" makes sense, though it would be necessary to clarify difference between dog and horse in case of adding it. Personally, it seems weird to have it it there and I am not supporting placing it there, but I also would not revert adding it back there. Mateusz Konieczny (talk) 10:36, 24 May 2020 (UTC)
I've added dog=* with some clarification. Feel free to reword it if it doesn't sound right. By placing it beneath foot=* it shouldn't be confused with horse riders either. JeroenHoek (talk) 15:54, 29 May 2020 (UTC)