Talk:Key:access

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... 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 http://www.ertico.com/download/misc/GDF/Annexes.pdf 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)

+1

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)

I use oneway=yes + oneway:bus=no + :lanes tagging, now a days. --Skyper (talk) 11:50, 25 April 2023 (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 :

access=private,motorcyle=yes.

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)

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)

Mean-while, we have the post-fix :forward and :backward but I always hesitate to use them as you might be able to turn around somewhere in between and what happens if you exit a driveway? Are there signs. Usually, these restrictions are better tagged with turn-restriction relations, see type=restriction. --Skyper (talk) 18:43, 14 February 2022 (UTC)

It seems these days this can also be expressed with oneway=yes + oneway:conditional=no @ destination. Aceman444 (talk) 15:38, 10 July 2023 (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 http://www.constructionenquirer.com/wp-content/uploads/Screen-Shot-2012-05-01-at-15.31.14-600x414.png ) 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)

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é (http://www.openstreetmap.org/way/113971030) 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.

I second the view that a specific key would be useful. I hvae an example where bicycle lockers are accessible if you have a smartphone with an OS from one of the two giants (apple, google), have installed the appropriate app, and regsitered your creditcard in the app. access=via_app  ? MortenLange (talk) 14:34, 28 July 2020 (UTC)

Usually you can use one of vehicle=private or motor_vehicle=private together with *:conditional=yes @ delivery.
What do you need more? --Skyper 19:09, 28 July 2020 (UTC)

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)

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)

Resolved: answered, though unlikely that anyone has seen the answer Mateusz Konieczny (talk) 09:10, 14 March 2022 (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)

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)

conditional restriction may help Mateusz Konieczny (talk) 14:24, 21 July 2020 (UTC)

swimming=*

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 https://lists.openstreetmap.org/pipermail/tagging/2019-October/048860.html, 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: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#General_tags . there shouldn't be a problem to also use it in a more general way --Flaimo 18:59, 23 April 2011 (BST)

Maximum vehicle occupancy

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)

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)

+1 for two or more keys and not using multiple values for access=*. I even try to avoid access=* as you often miss some transportation modes, especially pedestrian access on the sidewalk. I would use vehicle=no or motor_vehicle=no together with bus=designated, I guess. --Skyper (talk) 18:51, 14 February 2022 (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)

Resolved: stale Mateusz Konieczny (talk) 09:11, 14 March 2022 (UTC)

caravans/trailers

caravan=* is currently defined by the pictogram 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)

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)

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 vs. "passenger cars" vs. (Finnish sign, afaict Germany doesn't have an equivalent sign) vs. (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=private
amenity=parking
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)

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) vs. . 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)

• • Moving without a vehicle
    • foot=* (pedestrians)
    • ski=*
      • ski:nordic=* (cross-county skiing)
      • ski:alpine=* (downhill skiing)
      • ski:telemark=* (telemark (free-heel) skiing)
    • inline_skates=*
    • ice_skates=*
  • horse=* (horse riders)
  • vehicle=* (category: any vehicle)
    • Non-motorized vehicle
      • Single-tracked
        • bicycle=* (cyclists)
          • road_bicycle=*
          • mountain_bicycle=*
          • racing bicycles=*
          • track_bicycles=*
          • see  list

• • • • Double-tracked
        • carriage=* (horse(s) + carriage)
        • off-road_vehicle=*
        • trailer=* (needs to be towed by another vehicle which has its own restrictions)
          • caravan=* (a travel trailer, also known as caravan)
    • motor_vehicle=* (category: any motorized vehicle)
      • Single-tracked
        • motorcycle=* (a two-wheeled motor vehicle, allowed to drive on motorways)
          • off-road_motorcycle=*
        • moped=* (motorized bicycles with a speed restriction; e.g., at most a 50 cc engine or max. speed of about 45 km/h)
        • mofa=* ("low performance moped", usually with a maximum design speed of 25 km/h)
      • Double-tracked (category: motor vehicles with more than 2 wheels/more than 1 track)
        • motorcar=* automobiles/cars
          • motorhome=* (a motorhome)
        • psv=* (public service vehicle)
          • 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)
        • hgv=* (heavy goods vehicle; e.g., goods vehicles with a maximum allowed mass over 3.5 tonnes)
        • 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=*

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 https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode.

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 [[Key:|]]=facultative or [[Key:|]]=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)

I agree with U715371. This is really a feature of the associated street and if one wants to be clear that an associated street can't be accessed with a certain means of transportation, it should be tagged foot=no/bicycle=no/…. That you can't access that other, associated street with a certain means of travel is what that sign means, isn't it? This will be much clearer for routers as they won't have to make any inferences as to which street is associated and, in my opinion, should also be clear to human readers. --Tschoerbi (talk) 18:58, 25 August 2022 (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)

What about toll=yes + toll:bicycle=no + toll:foot=no + toll:agricultural=no + toll:conditional=no @ private ? You haven't specified what non-motor vehicles other than bicycle need to do, so it could be refined even more then (maybe like toll:vehicle=no + toll:motor_vehicle=yes). Aceman444 (talk) 16:39, 10 July 2023 (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)

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)

electric_vehicles

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 vehicle 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)

Another thought, something like maxemissions= ? In the same way that there are maxheight, maxweight etc. values? -- Chuq (talk) 09:57, 15 September 2020 (UTC)

Think maxemission=* is too general and we need recognizable values. For emission, I would expect numerical values with a unit. We would need subkeys for each gas. I'll go with traffic_mode post-fixes per engine power source type. One question is how to handle a situation where electric vehicles are not allowed but only human and animal power. Do we need something like bicycle:human=designated or vehicle:mammal=yes together with vehicle=no or is vehicle:electric=no enough. --Skyper (talk) 12:36, 15 September 2020 (UTC)

You're right, I posted my comment about 10 seconds after thinking of it and thought there would be an issue. Just trying to think of a way to fit it into existing structures instead of coming up with another key! -- Chuq (talk) 10:05, 17 September 2020 (UTC)

Quite the opposite, maxemission=* is good enough to me. You can further specify pollutant (or fuel?) and mode with this format. The quantity could be non-numeral, viz Euro standard (this should be considered together with boundary=low_emission_zone). Cf maxstay=* has maxstay=load-unload and maxstay=unlimited values; maxspeed=walk is raised by some. ---- Kovposch (talk) 07:13, 7 August 2021 (UTC)

I'm having the problem of restricted parking space for electric vehicles car only. I thought perhaps a propulsion=electric or perhaps even better: powerplant=electric might be a good idea? This could probably be also expanded for vehicles unbound to hard surfaces, like boats, etc. Perhaps not right now, but it is reasonable to think, that access restrictions might be expanded to boats, trains, etc. The problem with this is, that it's not bound to emissions, as all non-emission vehicles (for instance pedal power) aren't allowed to park there **except** cars that can be charged with electricity. The Access restriction on the sign when entering the parking lot, is "electric cars only". Which excludes hydrogen vehicles, as far as I know, except if they can be also charged, like a plug-in hybrid hydrogen vehicle. For now I tagged vehicle=electric which should be easy to correct with a bot at some later stage, but I regard this as very much temporary. Polemon (talk) 19:34, 13 January 2022 (UTC)

1. That won't be extensible enough for access:*=*. I only thought about it in Proposed features/Unconvetional railway details and Proposed features/Transit energy source details where it is fixed info.
2. You can already try eg motor_vehicle=no + motor_vehicle:conditional|yes @ ("Electric"). While *:conditional|* @ (fuel=electric) is "in use", but ambigious on battery only (usual meaning of "electric") or all-electric (including fuel cell). Including plug-in hybrid would be troublesome.

--- Kovposch (talk) 06:19, 10 October 2022 (UTC)

Yes, we need a way to diffentiate. For example here in CPH on parking spaces with chargers, electric motorcars, hybrid motor cars and electric motorcycles are allowed to park. But only the hybrid motor cars have to pay for the parking. Elgaard (talk) 15:43, 1 December 2022 (UTC)

The U.S. has a standard sign for exempting "inherently low-emission vehicles" (ILEVs) from high-occupancy vehicle (HOV) lanes. This sign is for any zero-emissions vehicle, not only electric cars but also hydrogen fuel cell cars and solar cars. Enumerating the different kinds of zero-emissions vehicles would be inconvenient and error-prone, so I think we should have a low_emission_vehicle=* access key that serves as an umbrella for more specific keys like electric_vehicle=* and hydrogen_vehicle=*, just as psv=* and motor_vehicle=* serve as generic groupings. [10] – Minh Nguyễn ^💬 00:00, 18 November 2020 (UTC)

Think technically and consistently, you need it to be low_emission_motor_vehicle=* or motor_vehicle:low_emission=* to avoid including some motorized vehicle=* that are legally not considered motorized. But anyway, I like maxemission=* more.

A personal note is "electric vehicle" is unclear. It should refer to battery electric vehicle (let's not consider plug-in hybrids vs all-electric vehicle yet), but inclusion of ranger extender (usually a diesel engine APU) is unspecified. "hydrogen vehicle" is also ambiguous, when there are hydrogen combustion engines, and potentially non-hydrogen fuel cells. ---- Kovposch (talk) 07:26, 7 August 2021 (UTC)

---- Kovposch (talk) 07:26, 7 August 2021 (UTC)

We really need to figure out a tag for this. More and more EVs are entering the roads and many places have special restrictions or fees for them. Here in Norway we had 80% of new cars sold being electric in January 2022. Gazer75 (talk) 14:53, 4 February 2022 (UTC)

There are somewhat more attention in Proposed features/amenity=small vehicle parking and Proposed features/ElectricScooters, which is fine (I guess) with almost all being battery. Didn't participate much in Proposed features/ElectricBicycles because I'm not familiar with them. However, differing terminology when tagging vehicles other than bikes may be a shame. --- Kovposch (talk) 18:35, 4 February 2022 (UTC)

I drafted Proposed features/Vehicle emission and energy source in response to a recent question for my own reference. Not going RFC soon. --- Kovposch (talk) 06:14, 10 October 2022 (UTC)

My two cents is that there should be two separate options depending on the use case.

1. Where authorities use coloured language like "low-emission vehicle" or standards signs like the ILEV sign mentioned by Minh Nguyễn, the correct approach is probably to introduce a new standalone transportation mode (I vote for just "lev") whose meaning is "whatever the authorities define to be a low-emission vehicle in this jurisdiction". Then you can have lev=yes or lev=designated for the workhorse cases and standard variants like lanes:lev=*, toll:lev=*, charge:lev=*, maxweight:lev=*, and so on. This is similar to "hov", which is the transportation mode signifying "whatever the authorities define to be an high-occupancy vehicle in this jurisdiction".
2. Where the specific type of powerplant matters (as in the pay-for-parking case raised by Elgaard), then usually the powerplant will be a condition influencing the value of some other variable, success as access or fee. In this case, I suggest going with the :conditional suffix and using a powerplant=* condition where the possible powerplants are ice, ice_hybrid, battery_electric, hydrogen_cell and hydrogen_combustion. Then for Elgaard's case you end up with tags like charge:conditional=17 DKK @ (powerplant=ice_hybrid) and access:conditional=yes @ (powerplant=battery_electric); yes @ (powerplant=ice_hybrid).

I would also tend to agree with Skyper and Chuq that maxemission=* likely does not work well. It isn't the way authorities want us to view electric vehicles, the only values it would ever have are "0" and "low", and conceptually it needs an emitted substance, a value, and a unit. The maxemission tag could be added later if and when authorities start specifying things at that granularity. In the mean time, a transportation mode (lev) is simple and consistent for the majority of cases, and a powerplant condition should help with tricky edge cases. -- Vcs (talk) 05:22, 18 April 2023 (UTC)

1. The case of ILEV already shows *:lev=* as a suffix won't work. There are many different classifications, eg PZEV, ULEV, etc; not to mention local (not even national) differences. Between states, California has its own system.
2. Battery is the (secondary) energy source (carrier). Motor is the powerplant. Conditions are difficult, and too long when combined.
3. Maximum emission is already specified in the form of Euro standards, and some (eg Islington ULEV shown in Proposed_features/Vehicle_emission_and_energy_source#London inside London LEZ and ULEZ) use 50g/km or 75g/km CO2 explicitly to define classes. For the concern of updating and maintainability, not every local jurisdiction may use the same definition, and there can be transition periods for each zone. Therefore an explicit emission level is needed, and at least complements the class definition.

--- Kovposch (talk) 03:50, 19 April 2023 (UTC)

The same problem exists for LPG (liquid natural gas) powered vehicles, which are forbidden e.g. some in underground parking lots/garages. Luckily the standard sign for it (at least in our country) does not mention any type of vehicle, it just forbids the propulsion system. Thus motor_vehicle:lpg=no or jut lpg=no would work (not needing subkeys for all the different vehicle types). Similar may be for future hydrogen powered cars. Aceman444 (talk) 14:35, 17 July 2023 (UTC)

It's not always necessary in the first place. There are already a few motor_vehicle:conditional = no @ (fuel=lpg) . The need arises due to examples viz charge:conditional=22 NOK/hour @ (weight >3.5); 28 NOK/hour @ ((Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off);); 26 NOK/hour @ (fuel=diesel); 31 NOK/hour @ (fuel=diesel AND (Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off)); 6 NOK/hour @ (fuel=electric ); 11 NOK/hour @ (fuel=electric AND (Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off)); 88 NOK/hour @ (weight>3.5); 49 NOK/hour @ (weight>3.5 AND emissions=euro_6); 104 NOK/hour @ (weight>3.5 AND (Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off)); 49 NOK/hour @ (weight>3.5 AND emissions=euro_6; weight>3.5 AND "Rechargeable hybrid"); 66 NOK/hour @ (weight>3.5 AND emissions=euro_6 AND (Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off); weight>3.5 AND "Rechargeable hybrid" AND (Mo-Fr 06:30-09:00, 15:00-17:00; PH off; Jul, Dec 24,31, easter -4 days off) that have to be split. I personally won't input all the tolls, but this has been asked and partially added.
lpg=no is confusing as to whether such fueled vehicle is not allowed, or this fuel is not provided as a mistake of fuel:lpg=no in a amenity=fuel . —— Kovposch (talk) 06:54, 18 July 2023 (UTC)

I don't care much about how exactly the lpg information will be input, into which tag, just that there is a possibility. Conditional restrictions so far contain no mention of any fuel= condition and many more of the conditions you posted in the example are also some free-form undocumented values so no app will be able to parse this stuff. But once all of this gets sorted out (proposed/documented), I will be happy :) Aceman444 (talk) 09:02, 18 July 2023 (UTC)

A couple years ago, I already went ahead and documented nev=* based on the neighborhood electric vehicle (NEV) standard in the U.S. Infrastructure and restrictions relevant to routing were beginning to crop up in some places, with a strong analogy to bicycle infrastructure. At the time, I didn't realize the connection between this standard and others like ILEV, but I'm starting to think we've been overthinking things in the name of avoiding key proliferation. The fact is that these standards are proliferating; the keys should reflect that fact, rather than attempting an artificial harmonization across legal systems. – Minh Nguyễn ^💬 21:51, 13 October 2024 (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)

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 ;-) http://www.omroepbrabant.nl/?news/2682561073/Fiets+rijdt+met+83+kilometer+per+uur+over+de+snelweg.aspx 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.)

• You may be interested in discussing it on tagging mailing list or starting Proposal process Mateusz Konieczny (talk) 08:36, 24 July 2018 (UTC)

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)

@RicoZ: Is current state of page still problematic? Mateusz Konieczny (talk) 16:40, 16 June 2020 (UTC)

Resolved: stale, ping not answered Mateusz Konieczny (talk) 09:12, 14 March 2022 (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' -> https://forum.openstreetmap.org/viewtopic.php?id=65458 --Henke54 (talk) 10:48, 23 February 2019 (UTC)

I redirected on of your pages to avoid confusion [11]. I guess you refer to a tag (key means left side only). What do you mean by mentioned*=yes? mentioned:agriculture=yes? --Tigerfell  (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 -> https://forum.openstreetmap.org/viewtopic.php?pid=740026#p740026 --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:

• more than 600 times in Germany https://overpass-turbo.eu/s/KcL,
• more than 100 times in France https://overpass-turbo.eu/s/KcM
  

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

It makes sense to document it Mateusz Konieczny (talk) 12:05, 24 July 2020 (UTC)

How is this different to access=private? The owner/operator gave permission to access only to individual persons (employees). Aceman444 (talk) 16:47, 10 July 2023 (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)

• hgv_articulated=* is related. Maybe hgv_trailer=*? Mateusz Konieczny (talk) 08:27, 30 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:
from
5. https://wiki.openstreetmap.org/wiki/Key:access#Routing_restrictions
6. https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions
to
5. https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions
6. https://wiki.openstreetmap.org/wiki/Key:access#Routing_restrictions
? --MalgiK (talk) 17:32, 29 January 2020 (UTC)

Or even

from

3 Access time and other conditional restrictions

4 Size and statutory restrictions

5 Routing restrictions

6 Transport mode restrictions

to

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" (https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions) followed by value which seems currently 2. "List_of_possible_values" (https://wiki.openstreetmap.org/wiki/Key:access#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 interpreted as vehicle:backward=no. From that it logically follows that bicycle:backward=yes overrides vehicle:backward=no and therefore 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)

"No camping" sign

How to tag a "No camping" sign, which usually disallows overnight stay of caravans etc.? This should be an important information for camping maps (access:camping=no is not yet defined and there is no tag at tourism=camp_site either, thus I will post the same question there too). For some 150 places camping=no is used. Should this be included in the Wiki? There are also "No tent" signs. --GerdHH (talk) 14:43, 16 June 2020 (UTC)

camping=no seems perfectly fine, though I would tag it only where signed or actually adds information. Feel free to create a page for that tag and document existing use (I do it usually by copying code of a similar page, I just did it with Tag:amenity=clothes_dryer). See Any tags you like Mateusz Konieczny (talk) 16:17, 16 June 2020 (UTC)

Do not mention approval status so prominently

I think that it is not so important info that it should be mentioned on overview page, it does not matter whatever for example vehicle=* is approved or not. And this page is really complex and cluttered already. So I propose to remove "Approved" pages from listed tags @MalgiK: Mateusz Konieczny (talk) 14:27, 21 July 2020 (UTC)

Agree, I just tried to mention, that the status of some tag (keys/values) are different to the "global" 'defacto' status of entire access. Do you know a way to just remove the green background colour of the 'approved'-text? --MalgiK (talk) 14:42, 21 July 2020 (UTC)

Did a page-update, is this okay? --MalgiK (talk) 15:17, 21 July 2020 (UTC)

Looking at it again - I think that in this case it would be better to not mention it as at all private is not approved, delivery is approved, so what? Distinguishing between bogus and valid values is not needed as only valid values will be listed here Mateusz Konieczny (talk) 12:04, 24 July 2020 (UTC)

+1 - only valid values with a certain amount of numbers in use and, maybe, all approved values should be explicitly listed here. The documentation of the individual values including there development process is not needed in the table or on this page.--Skyper 14:24, 24 July 2020 (UTC)

I wouldn't delete this status information at all, maybe moving to the individual pages, but it seems they aren't exist (yet). So where readers could currently find it? --MalgiK (talk) 15:30, 24 July 2020 (UTC)

Ok, now we get to the roots. If a key or tag is mentioned on this page it should have an own page. This way more information can be provided per key or tag without blowing up this already big page. How about creating these pages? --Skyper 22:59, 24 July 2020 (UTC)

+1, I would create pages for them (maybe short stubs for start, maybe something bigger if there is something to write about) Mateusz Konieczny (talk) 22:13, 26 July 2020 (UTC)

Great, thanks in advance - let's move the status info's after that. --MalgiK (talk) 06:19, 27 July 2020 (UTC)

Removed status for vehicle=* & hazmat=*, see here (because it is already available in the info-boxes of their main key pages). --MalgiK (talk) 16:03, 24 July 2020 (UTC)

Icon for moped=*

I have added the icon for moped=* a few days and took it from the German traffic sign. But I am not happy with it as it is not easily to see the difference to mofa=*. See https://josm.openstreetmap.de/ticket/17750#comment:22 for some examples. --Skyper 09:41, 23 July 2020 (UTC)

hierarchy within hgv / consistency between language variants of the page

In the DE variant of the page, hgv=* and hgv_articulated=* and bdouble=* are on same hierarchy level.

In the EN variant of the page, hgv=* is the parent of hgv_articulated=* and bdouble=* is not in the hierachy at all.

I strongly doubt this difference is for good reasons, as I am pretty sure not only in DE but also other countries, bdouble is e.g. disallowed where hgv is disallowed, i.e. there is a hierarchy. Hence, I do not consider the difference to be a local refinement but a contradiction - which is bad for implementation of software.

Please, could anyone who knows by heart where the technical/semantic definition of the hierarchy resides tell the link / tell what is correct? --Schoschi (talk) 22:44, 9 March 2021 (UTC)

• In general en version is primary and other translations are translations + some local info. I would check whatever is it even intentional or mistake made during translation Mateusz Konieczny (talk) 23:53, 9 March 2021 (UTC)

access=unknown sounds like a joke to me

I mean, if you have no idea about the access status, then how about leaving the tag blank? --CBRS (talk) 16:39, 27 July 2021 (UTC)

• @CBRS: Because in some cases like amenity=parking lack of access tag is interpreted as public access, and when mapping from aerial in many cases it is quite likely - but not certain - that parking is private or somehow restricted. Mateusz Konieczny (talk) 07:23, 28 July 2021 (UTC)

I think in such cases one should tag it with fixme=check access, because no one would find access=unknown tag and interpret it as something to do. maro21 17:14, 28 July 2021 (UTC)

StreetComplete and JOSM are already handling it, have not checked iD Mateusz Konieczny (talk) 07:32, 29 July 2021 (UTC)

Ok, I didn't know that StreetComplete recognize it, it's good. Anyway, I don't like this tag, for me it's the default value which doesn't need to be entered. maro21 20:26, 29 July 2021 (UTC)

For amenity=parking default value appears to be access=yes judging by data and how it is used by data consumers Mateusz Konieczny (talk) 00:40, 30 July 2021 (UTC)

It seems people still explicitly add access=yes, probably via StreetComplete. If access=unknown is a useful value, how should data consumers handle it? What should a router do? How is it different from a fixme=*? Aceman444 (talk) 16:59, 10 July 2023 (UTC)

Access only for ticketed passengers?

Do we need a new access value for ways/places that are only available to passengers (ie, within a railway/public transport station, airport, etc)?

Someone recently brought up an issue on the osm reddit page ( https://old.reddit.com/r/openstreetmap/comments/pg4mxq/need_help_fixing_san_francisco_map/ ) with routing through the San Francisco Ferry Building gates. The area outside the gates is accessible to everyone while past the gates only passengers/crew have access. These have been tagged with access=customers, which is causing some routers to block through-access to/from the ferry docks beyond, and doesn't seem like the best fit for this kind of situation. I can see this being an issue in other places, like pre/post security areas in airports/stations, and waiting rooms, platforms, etc that are only accessible with a ticket.

It looks like the access=passengers tag is already in-use at Frankfurt and Santiago Airports, and a few other places.

--Oba510 (talk) 12:13, 3 September 2021 (UTC)

Just toll=yes? ---- Kovposch (talk) 09:06, 4 September 2021 (UTC)

The ferry routes already have the fee=* tag set. I was thinking more in a broader sense than just this specific situation. It would be nice to have a way to distinguish whether, for example, a restaurant is behind security or not.

There are a number of train stations, etc. (or parts of stations/terminals) that restrict access to only allow passengers. When these places are tagged with the existing access tags routers have no way to tell the difference between [access only to customers of a specific destination] (generally treated as access=destination) and [access only to people traveling across this place to reach a connected public transport route to some other distant destination]. In the example of the Ferry Building we would probably want to allow routes that have to cross the docks while blocking routes to destinations inside the dock itself (the exact opposite of how access=customers is usually treated). --Oba510 (talk) 03:54, 7 September 2021 (UTC)

@Oba510: I've previously experimented with access=permit for POIs and hallways in secure passenger areas at airports. I think the original intent of access=permit was for passes that require a bit less planning ahead than an airplane ticket, though at least this airport's flights are relatively inexpensive. ;^) access=passengers has the advantage of being more self-explanatory, but it wouldn't work for other kinds of secure areas, such as at stadiums. – Minh Nguyễn ^💬 04:54, 7 September 2021 (UTC)

So why exactly is access=customers wrong? You may need to pay something (the ticket) to access the area (inside airport or ferry terminal), so you are the customer of the facility (or transport operator). There even exist 'platform tickets', to access a train platform, when you are not traveling by any train (you have no train ticket). This limits access by random strangers inside the area. Aceman444 (talk) 17:03, 10 July 2023 (UTC)

access=customers is wrong because it is forbidden for through traffic. The appropriate tag is toll=yes, as you need to pay a toll to access the facility. If you want to route a passenger from city A to city B, needing to access the paid area for a train station to take a train, you are on a through route via the train station, the train route, and the other train station to your destination, where access=customers will prevent. --Miklcct (talk) 21:49, 29 September 2024 (UTC)

Access=no and footpaths

I have been using OsmAnd to plan walks and using its feature to highlight access=no features to avoid private roads and footpaths. But I've been noticing that people having been marking footpath networks in nature reserves as access=no, foot=yes, as suggested in the advice to keep vehicles out, and making whole networks apparently inaccessible. Surely it would make more sense for each feature, road, path, bridleway to have its own default permissions by common usage, allowing special case modifiers, and have access=no,private to wrap them as an overall qualifier.

So only dangerous routes would be access=no, otherwise it would be access=yes or access=private, and a footpath would be default vehicle=no, bridleway default horse=yes. Vicarage (talk) 09:39, 12 February 2022 (UTC)

There is a default access list here: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions Gazer75 (talk) 09:53, 12 February 2022 (UTC)

I see it quite similarly. The point is, that there is no tag for a designated footpath in the wilderness. A highway=path per default is not accessible to cars, but to two-wheeled vehicles. So mappers use access=no to make sure, no other use than pedestrians. In combination with foot=yes the access=* has no impact to pedestrians.
A slightly better tagging would probably be on paths: vehicle=no + horse=yes/no , and on tracks: vehicle=no/private/permit/forestry + bicycle=yes/no + horse=yes/no.
foot=* only is needed if not yes, in my opinion. --Chris2map (talk) 10:23, 12 February 2022 (UTC)

+1 to using vehicle=no rather access=no to denote lack of entrance for vehicles Mateusz Konieczny (talk) 10:48, 13 February 2022 (UTC)

A residential road on a private estate with a public footpath along it is vehicle=private foot=yes, using vehicle=no suggests it cannot be used by cars by anyone. I'd use yes/designated|permissive|private/permit/forestry|no in increasing levels of restriction, overriding the defaults that come with a route type of yes/no. I'm not sure access= has a useful place here as it muddies the water. But you have a pragmatic problem of getting editors to understand the subtleties of it all, as I'm not sure my thinking is correct yet. Vicarage (talk) 19:15, 14 February 2022 (UTC)

"only dangerous routes would be access=no" note that there are dangerous routes where entrance is not legally prohibited. "bridleway default horse=yes" not horse=designated? "footpath would be default vehicle=no" - defaulting to excluding bicycles from highway=path may have own problems Mateusz Konieczny (talk) 10:47, 13 February 2022 (UTC)

My fundamental problem is I want to plan walking routes in OSMAnd where foot access is allowed to the public. But while OSMAnd highlights access=private, it also treats access=no the same way even if foot=yes, and I can see why it does this, as its a general mapping program. Perhaps this is a question I need to bring up with them. Are there other map sites that allow me to specify a 'foot' mode and show me what is private in that mode alone? Vicarage (talk) 11:05, 13 February 2022 (UTC)

If you switch the OSMAnd profile to pedestrian / hiking, foot=yes will be recognized and no access restriction will be shown. --Chris2map (talk) 11:55, 13 February 2022 (UTC)

I disabled my driving profile to just have a hiking one, and with Walking Profile/Configure Map/Details/Show access restrictions I'm still having problems with Ranscombe Farm Nature Reserve, for example https://www.openstreetmap.org/way/810711597#map=15/51.3880/0.4578 which has access=no, foot=yes. But perhaps this is a thing to take up with the developers. Vicarage (talk) 12:30, 13 February 2022 (UTC)

I've just downloaded the region in OSMAnd and tested it. With profile bicycle the path is marked as restricted (rosy dotted). When I use profile walking the path is black without any marking of a restriction. The path has only one version in history from about a year ago, so you can't have outdated map data, have you? Might it be possible, that you confuse the marking with a marking of another feature of the path, such as surface or smoothness? If not, the only thing I can suggest is that you try to create a new profile for navigation by foot. May be that is jinxed. --Chris2map (talk) 13:27, 13 February 2022 (UTC)

I had installed a new OSMAnd and database 3 days ago, but imported my old settings (which must be a decade old now) from a backup. This time I reinstalled, and private shown as pink dots in default config, switched to Foot profile, no private shown anywhere. Edited the profile to show the access restrictions, and the problem returns. Compare https://www.openstreetmap.org/way/356123557 with https://www.openstreetmap.org/way/810711597 and https://www.openstreetmap.org/query?lat=51.3804&lon=0.4587

It seems that access=no, foot=yes => PUBLIC access=no foot=designated => PRIVATE, foot=designated => PUBLIC so the fault is with access=no foot=designated highway=bridleway, as for https://www.openstreetmap.org/way/356123557. When my head stops spinning I will report to OSMAnd.

Also a problem is access=no foot=designated highway=track as in https://www.openstreetmap.org/way/94933502#map=15/51.3817/0.4488. The tags in the reserve are a dog's dinner, but its more the fault of OSMand not handing it all. Vicarage (talk) 16:17, 13 February 2022 (UTC)

The way https://www.openstreetmap.org/way/356123557 has been tagged a bit extraordinary, IMHO. A bridleway with horse=permissive and foot=designated? Maybe the mapper swapped the values for horse and foot, so horse=designated and foot=permissive (like with bicycle) is meant to. --Chris2map (talk) 17:20, 13 February 2022 (UTC)

• =designated has only recently been added as equivalent to*=yes in osmand (this had me confused for ages too!) https://github.com/osmandapp/OsmAnd/issues/14294 TrekClimbing (talk) 06:30, 3 July 2022 (UTC)

Moving the destination sign text to Tag:access=destination

Resolved: Done.

Currently the table row Key:access#access-destination contains the following:

Sign text in different languages:

English: "except for access" (UK) / "no thru traffic" / "local traffic only" (USA), Dutch: "bestemmingsverkeer"/"uitgezonderd plaatselijk verkeer"/"uitgezonderd plaatselijke bediening" (Flanders/Belgium), German: "Anlieger frei"/"ausgenommen Anrainerverkehr" (Austria), French: "Interdit sauf riverains"/"excepté circulation locale" (Wallonia/Belgium), Norwegian: "Gjennomkjøring forbudt"/"ingen gjennomkjøring"/"kun kjøring til eiendommene", Danish: "Gælder kun gennemkørsel", Swedish: "Gäller genomfart".

I find this to be quite unreadable, I'd prefer it to be listed as:

• English: "except for access" (UK) / "no thru traffic" / "local traffic only" (USA)
• Dutch: "bestemmingsverkeer"/"uitgezonderd plaatselijk verkeer"/"uitgezonderd plaatselijke bediening" (Flanders/Belgium)
• German: "Anlieger frei"/"ausgenommen Anrainerverkehr" (Austria)
• French: "Interdit sauf riverains"/"excepté circulation locale" (Wallonia/Belgium)
• Norwegian: "Gjennomkjøring forbudt"/"ingen gjennomkjøring"/"kun kjøring til eiendommene"
• Danish: "Gælder kun gennemkørsel"
• Swedish: "Gäller genomfart".

but that would of course take up too much space in the table, so I suggest that we move this list to Tag:access=destination (which is currently quite empty anyway) and replace the listing in the table with something like:

This is signed for example as "except for access" in the UK or "no thru traffic" / "local traffic only" in the USA. For other countries see Tag:access=destination#Signs.

What do you think?

--Push-f (talk) 22:32, 10 June 2022 (UTC)

Makes sense, I think that this kind of edit can be just made without preemptive talk page discussion Mateusz Konieczny (talk) 06:42, 11 June 2022 (UTC)

Done ... see Tag:access=destination. --Push-f (talk) 17:41, 16 June 2022 (UTC)

No, it would be wrong. This is motor_vehicle=destination. access=destination includes foot=destination and bicycle=destination. Kovposch (talk) 12:20, 17 June 2022 (UTC)

Ah yeah, thanks for fixing that! --Push-f (talk) 09:28, 19 July 2022 (UTC)

E-ID required to enter convenience store

I just want to make sure I have used the correct key and value... If an unmanned convenience store require a smartphone and e-ID to enter (which +95% of the adult population has) do I use access=permit? Note also that any foregin visitor or tourist is unable to enter due to their lack of said national e-ID. Or am I supposed to use another key and/or value? --Christoffre (talk) 19:04, 14 August 2022 (UTC)

May not be the best. access=permit usually have to be registered for, even if always allowed. If a country mandate or expect identification documents to be carried by adults at all times, this seem more of a default law expected for everyone. A passport fits access=permit better (eg at international flight area), as it has to be renewed, and not always carried. There is authentication:app=yes.

Is the underage allowed in alone? I can think of target=* from office=diplomatic that might be reusable. Although access:conditional=* indicates the restriction more clearly, there is no "not" operator, meaning you still have to exclude by access=no + access:conditional=yes @ (country=*).

Talk:Tag:barrier=border_control#Local_/_international has a question about nationality served.

--- Kovposch (talk) 02:50, 15 August 2022 (UTC)

Thanks, I've removed access=permit and changed it to access=no, access:conditional=yes @ (country=*) and authentication:app=yes instead.

About underaged; there is nothing that say that they are not allowed to access the store alone (altough this might only show first when they try). The only requirement is that they have e-ID and a smartphone themself. E-ID itself has no hard age restrictions either, as it differ between issuers, but the two most common age limits for e-ID are 13 and 18. --Christoffre (talk) 07:19, 15 August 2022 (UTC)

Managed dynamic all lane vs hard shoulder running

https://wiki.openstreetmap.org/w/index.php?title=Key:access&type=revision&diff=2392933&oldid=2377698 Discuss recent addition of access=variable in Talk:Variable-access lanes. --- Kovposch (talk) 06:57, 16 September 2022 (UTC)

Authorised vehicles

What tag should be used on a section of road where there this sign is present: https://i.imgur.com/jg3gy5l.png

psv=yes, bicycle=yes and what tag for motor vehicles? I was thinking motor_vehicle=permit, but this sign does not necessarily mean that, as we have a separate exception sign for those with a permit in the UK (i.e. "and permit holders"). Is motor_vehicle=authorised acceptable? Nathan A RF (talk) 15:05, 10 February 2023 (UTC)

First of all before tackling that question, there is a problem causing your confusion: The definition of access=permit is different from UK's "permit" clause. The former refers to "routinely granted" ones you simply get as part of traveling there. The latter is restrictive, equivalent to access=private for residents, tenants, and legitimate users along that road.
By my understanding of your country, "authorised vehicles" is usually limited to facility service or maintenance, and emergency services or government vehicles. Therefore both should be motor_vehicle=private. From that, the least uncertain method seems to be differentiating by private=government (for "authorised vehicles") from private=resident (for "permit"). (Although I don't like the private=* part)
The issue then is determining the "authorised vehicles" there. By standard, the most common mode targeted by these is private-hire vehicles.
"The term ‘private hire vehicles’ is not used on traffic signs as this may be misconstrued as applying to rental vehicles. Instead the term “authorised vehicles” is used." https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/3218/area-wide-authorisations-special-directions.pdf
"Where certain vehicles, such as private hire vehicles (minicabs), are permitted to use a facility, this is indicated by the legend “authorised vehicles”." https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/782724/traffic-signs-manual-chapter-03.pdf
There's no specific tag for them, unlike taxi=*. Except for 2 private_hire=* in isolated cases (it may also be confused with rented vehicles, as reasoned by DfT), and some mentions in note=*. *=authorised doesn't explain much either.
However, psv=* in OSM usage may already cover them, by loose interpretation. So you don't especially need to do anything more.
You should ask the UK community. Though I'm unsure discussions will give a straightforward answer.
--- Kovposch (talk) 19:25, 10 February 2023 (UTC)

Thanks for the reply, and under some circumstances I believe the supplementary plate does indeed refer to private hire vehicles only, but this is unclear from the signage itself - specific vehicles may also be exempt, such as those of residents, hence I have applied motor_vehicle=private as well as psv=yes for these sections of road I was interested in. Nathan A RF (talk) 14:37, 14 February 2023 (UTC)

permit vs customers

Hey, we had a discussion in the forum about the difference of permit and customers. I would assume

• permit should be used, if you have to obtain the permission beforehand (like getting an access card (even if free)).
• customers should be used, if you need to intend to enter into a contract with the Operator, but the closing of the contract is no precondition for the access getting granted.

Restrooms in Restaurants is a good example: in most restaurants you can sit down, study the card, using the restroom and afterwards order your food. Free parking lots are the same. On the other hand, parking lots with an access control (you get a card and pay at the exit) would be permit. Platforms with access-control (or a "you must have a Ticket to enter this area"-sign) would be permit. --josias (talk) 20:49, 29 August 2023 (UTC)

access=construction

So many roads are under construction and therefore not usesable for public. Why not formally introduce suggested tagging access=construction? It's overdue! --Geo Dät (talk) 13:46, 9 November 2023 (UTC)

@User:Geo Dät For roads the currently expected tagging is to replace highway=-kind- with highway=construction+construction=-kind- (same can be used at least for buildings). For other features, lifecycle prefixes may be used (specifically construction:=*). What would a third competing schema improve? Ltrlg (talk) 14:57, 9 November 2023 (UTC)

I hope you have understood what I mean: it's not about a highway itself, which may still be under construction. It's about a highway that is more or less finished, but is not yet open to the public, only to construction vehicles. Therefore, in my opinion, the relevant key is access and not highway. --Geo Dät (talk) 18:15, 9 November 2023 (UTC)

Definitely not what I had understood: For me “under construction” mean precisely that it is not ready, in which case access=* is pretty pointless and can be assumed to be no. “More or less” is not ready either, hence can be represented this way. That said, even if that was not the case, I think that what you describe can already be represented by enclosing the area with landuse=construction (the whole area is not finished) and adding access=destination to the road. Ltrlg (talk) 19:31, 9 November 2023 (UTC)

More or less means that the road is passable and only the lighting, markings or something else unimportant is missing. Following your suggestion, access=no would mean that no vehicle is allowed to use the road in question at all. I would like to specify that access is only permitted for construction vehicles driving to a construction site at the end of the road. The road itself is in front, i.e. outside the construction area. Therefore, tagging the entire area as land use=construction would be incorrect. Access=construction vehicles (or access = construction) would be similar to access=forestry or access=agriculture. --Geo Dät (talk) 09:15, 10 November 2023 (UTC)

I personally don't like them either. Why not access=private ? Other construction site's vehicles can't use them.
Anyway highway=construction + access=* is error-prone. If it is completed, it may be argued it is highway=service or some highway=* , but this has the problem of needing to remember to update it, is confusing, and is more short-term that doesn't belong to OSM due to application update frequency. If this completed but not yet open status doesn't continue for more than at least a month, please don't do anything.
—— Kovposch (talk) 10:05, 10 November 2023 (UTC)

access=private implicates a private ownership of the road in question, where private includes companies and authorities. access=no does not fit at all since the road is not closed due to impassability or road construction. Is there any argument that access = construction cannot be used? I mean except of like or dislike. --Geo Dät (talk) 10:00, 11 November 2023 (UTC)

No, it does not. That's ownership=* . access=private means individually permitted, which can happen on "public" roads for vehicles. access=construction is wrong when not all vehicles for construction purposes can use it, only that construction site's vehicles. Please compare the definition for access=agricultural in Key:access#List_of_possible_values "unless the track is explicitly open to any vehicle used for agricultural purposes". (also it should be motor_vehicle=agricultural or vehicle=agricultural )
—— Kovposch (talk) 09:12, 12 November 2023 (UTC)

Let me first show you an example what I'm talking about:

access road to FAIR construction site in Darmstadt (Germany)

access road to FAIR construction site construction site This road is tagged as private - which is better than wrong but nevertehless the second choice due to be unprecise. Once again: access=construction fits very well into the logic of access=forestry and access=agriculture because any construction vehicle is permitted to use the raod in question.--Geo Dät (talk) 16:39, 12 November 2023 (UTC)

I'd tag that example as access=private and then add private=* to indicate it's for specific construction vehicles only. But I'd also agree above, if it is not going to persist for a (significantly longer) time than a month, that adding highway=construction or access=* have a problem of remembering to revert them timely (and many data consumers may only fetch new map on monthly basis, so they will not fetch new version in time for it to be useful anyway). One can try to help that issue by adding opening_date=* which can be later easily found by automated means linked on that wiki, but it still requires someone to track that and fix it timely. Other alternative would be leaving it is as an e.g. highway=primary without access=*, but adding tag like access:conditional=private @ (2024 Jun 20-2024 Jul 17). Then the issue would fix itself automatically when time comes! Disadvantage of that method is that unfortunately conditional restrictions are not supported by all software. --mnalis (talk) 14:27, 15 June 2024 (UTC)

Axle restriction?

Is there any interest in an axle count restriction? There are express lanes near me (coded as a separate link) that only allow two axle vehicles. I guess I could use some combination of goods, hgv, hgv_articulated, & bdouble. But these are described as weight classes, not axle classes. Even the picture for hgv only has two axles, but there are some non-articulated trucks which have three axles. So how would I best code this?

Three subtypes of usage

See the forum, What do access tags on barriers mean?, there was a discussion on what the "access tags" mean for barrier=bollard

Based on that discussion I think the page should be updated to clearly indicate there are three different usage scenario's:

1. access-tags in combination with roads/paths (Key:highway) for which applies it should follow ground truth; e.g., signage or legal ruling
2. for things like barriers, ford=yes, railway=crossing, entrance=yes the primary criterium is physical access (typical use), although in the exception there is a sign, something like motor_vehichle=permit also can be used
3. The third category of usage is in keys like information and amenity where these “access tags” are used to indicate the usage is designated for the given “transport mode”

Emvee (talk) 19:30, 15 February 2024 (UTC)

I agree, except that for yur first scenario, it should IMO say: ...signage AND legal ruling. There must be something verifiable to indicate the legal access. Legal rules are invoked by something.--Peter Elderson (talk) 16:27, 16 July 2024 (UTC)

relations

Unresolved

The article states in the infobox that the key can be used on relations. But no relation is mentioned in the article. maro21 23:44, 25 March 2024 (UTC)

See taginfo, Key:access is used on relations and as you can calculate only in 0.24%. Relations are mentioned, Nodes, ways and areas, area's cover relations. --- Emvee (talk) 06:32, 26 March 2024 (UTC)

access can be used on areas for example amenity=parking - these could be a multipolygon relation whereas all tags move to the relation. This is how access tags may end up on a relation Flohoff (talk) 08:16, 26 March 2024 (UTC)

Multipolygons are areas, not relations for documentation purposes.
There is a related, but still marginal, use of keys such as bicycle=* on routes, quote, "bicycle in combination with route=bus specifies if riders can bring their bicycles with them on the bus." But I'm having hard time imagining what an access=private could mean on a, say, railway route.

Now, I queried a good portion of North America ( https://overpass-turbo.eu/s/1J7n ) for "access=private" relations, of which there are 4,190. Of those, only 45 were routes, including hiking, bus and light_rail. For example, this light rail route belongs to the United States Capitol Subway System, and it makes sense to tag it as private.
Overall, I'd say this usage is quite marginal, but I agree with maro21 it should be mentioned if we intend to keep the relation icon in. Duja (talk) 09:49, 26 March 2024 (UTC)

change the world wide default for foot access on cycleway to "yes"

After taking a tour of the country specific defaults, I think the general trend is that cycleways in principle allow foot access. In several countries this is accompanied by "unless there is a better alternative" which means, if there is a footway close by. I expect routers in the foot profile to prefer the footway over the cycleway. So I move to change the default foot access for cycleways to yes, and only tag foot=no if walking there is explicitly forbidden. This equals the tagging for other road types where pedestrians can walk on the road, but only if there is no sidewalk or footway. --Peter Elderson (talk) 12:25, 16 July 2024 (UTC)

the problem is that you shouldn't tag legislation (even if at least the editor encourages you to do fill as many access as possible). and so many highway=cycleway that are forbidden to pedestrians are correctly tagged with highway=cycleway without foot=no. by changing the global value, you are secretly changing all these accesses, thereby encouraging these contributors to tag explicitly the legislation next time. so it doesn't seem to me to be a good idea to change the global value. if in one country this is the case, check with the community in that country Marc marc (talk)

@Marc marc: As far as I can tell, this isn't a matter of one country versus the rest of the world. The countries that allow pedestrians on cycleways might even be in the majority. Regardless, any change to a "default" could only happen after all the implicit foot=* usage becomes explicit, because foot=unknown (see access=unknown) is so rare by comparison. – Minh Nguyễn ^💬 21:55, 13 October 2024 (UTC)

wheelchair

Chris2map, I don't think wheelchair should be in the hierarchy because it's not a legal tag. Foot would indicate if it was public, private, etc for someone in a wheelchair. Same for stroller I think (would you use stroller=private, or get arrested for using a stroller where you can walk?). TrekClimbing (talk) 23:17, 17 October 2024 (UTC)

I didn't take this into account, thanks for notice! You're right, it would be good to have them separated and a list for those legal tags at first. Do we put legal equal to road traffic rules/regulations here, or is legal not only traffic rules but also local law and rules? E.g. strollers are sometimes forbidden by local regulations and signs. And what's about "dog" and "portage"? I think with those it's pretty much the same issue like with "stroller". --Chris2map (talk) 06:18, 18 October 2024 (UTC)

Also local rules and regulations is my understanding. Dog and portage fit here. I can see that stroller could be used that way, but its wiki page is about physical access (yes/limited/no) except a single picture of a no stroller sign at the bottom (I think I've only seen these on escalators?) TrekClimbing (talk) 15:01, 18 October 2024 (UTC)

I have partially reversed my change to give preference to a clear list of legal restrictions rather than a list of all conceivable tags. It is true that "stroller" is currently used mainly as a physical restriction and as an alternative tagging to "ramp:stroller". Therefore, I have added "stroller" together with "wheelchair" under "Not in the list" as "Physical restrictions". Does that make sense? --Chris2map (talk) 18:05, 19 October 2024 (UTC)

Works for me thanks TrekClimbing (talk) 18:36, 19 October 2024 (UTC)

Transport mode

The current section "Transport mode restrictions" is quite long, and lists pretty much every possible transport mode in the universe, regardless of frequency of use. While pages from category:Restrictions do commonly complement Key:access, I think it's an overkill to list them all here. Instead, the list could find a new home at the page Transport mode, which used to redirect here, but has been revived by User:Push-f, who has also made a convenient summary.

To make the material more accessible, I would like to:

1. Copy the complete contents of Key:access#Transport mode restrictions to Transport mode
2. Significantly trim Key:access#Transport mode restrictions, leaving only {{Main|Transport mode}}, a short summary, and a dozen most common transport mode tags (key:foot, key:vehicle etc.)
3. Link transport mode from other articles as appropriate, including Glossary.

Thoughts? Duja (talk) 11:41, 21 October 2024 (UTC)

For me the list is not long and can stay. This is the most important part of this article and cannot be separately. maro21 21:22, 21 October 2024 (UTC)

The issue is that many of those key are either exotic (Key:carriage, Key:hand_cart, Key:portage, Key:nev...) and/or not really used as a proper access qualifier (Key:swimming, Key:wheelchair, Key:cargo). While I appreciate having a complete list somewhere, I don't think this article is the best location. I don't intend to eliminate it completely, just reduce it to a set of common values and direct the reader elsewhere for a complete list. Besides, this article is currently 38 kB long, placing it well into the tl;dr territory. Duja (talk) 11:54, 22 October 2024 (UTC)