Talk:Key:access

From OpenStreetMap Wiki
Jump to: navigation, search

Some older, resolved discussions were moved to Talk:Key:access/Archive.

Contents

Resolved discussions

  • Access Time Restrictions: Date and time values should be specified using ISO date/time format YYYY-MM-DDzHH:MM:SS.}}
  • Scooter: moped=* is popular. Alv 17:32, 15 May 2011 (BST)
  • Taxi: taxi=* is popular. Alv 17:32, 15 May 2011 (BST)
  • A new core value: Virtually no uses of =only in 3 years. Alv 17:32, 15 May 2011 (BST)
  • Accessibility": Page changed to "legal accessibility".
  • Imperial Units: Relatively very few uses of maxspeed converted mph to kmh. Most use what's on the sign, but remember the unit, if not kmh. Alv 17:32, 15 May 2011 (BST)
  • Local traffic only: access=destination, motor_vehicle=destination, hgv=destination.
  • Hazmat: hazmat=*
  • Access=yes and access=no not consistent wording: Wording for no was changed some years back.Alv 17:32, 15 May 2011 (BST)
  • Military base roads: Private they are. access=military hasn't gained popularity (431 at the moment).Alv 17:32, 15 May 2011 (BST)
  • access=occasional: In this case, a gate open on special events: private.
  • Water-based transport/ships/boats: resolved|Was included on the page.Alv 17:32, 15 May 2011 (BST)
  • Garbage truck: goods=private tells the relevant properties.
  • Access restrictions for dangerous areas: Hazards are not an access restrictions. Tagging them systematically should be discussed. Alv 17:32, 15 May 2011 (BST)
  • Bars, Nightclubs: Members only equals private.
  • ISPS: Unresolved. Private seems to convey the important part; no uses of isps in the database.

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)

bikes / one way

hi, i've edited some maps and I've taged streets which are oneway=true and have a permission for bikes in the opposite direction as cycleway=opposite. Is that the correct way to do it? Then I will continue to correct maps which do not have this tagged properly... Bike junkie 16:55, 15 March 2009 (UTC)

yes, correct --Extremecarver 23:01, 15 March 2009 (UTC)
But be careful with "corrections". If information is missing, then, of course, add it. Some alternative solutions (such as bicycle:backward=yes) aren't necessarily "wrong", though. Still, cycleway=opposite is by far the most widely used tagging. --Tordanik 17:58, 16 March 2009 (UTC)
  • Roadside cycleways (compulsory ones as well as non-compulsory ones) in Germany are oneway-cycleways whenever bidirectional is not allowed by special signs. Nowadays most renderers do not show this fact. The "German style"-renderer shows it, if the cycleway is drawn as a separate "highway=cycleway" with the additional tag "oneway=yes". If it is only marked by additional tags of the road OR if it is drawn separately but tagged "highway=path" OR if it is tagged as "highway=cycleway" and "oneway:bicycle=yes", the real one-way-specification is neighther show by the international mapnik, nor by the "German style" nor by openstreetmap-cyclemap.
  • Oneway streets with allowed counterflow cycling on the road: This very frequent regulation nowadays is shown by opentreetmap-cyclemap only, if "cycleway=opposite" is tagged – though there is no cycleway in those streets. I think, it should be shown by all renderers, also if only "oneway:bicycle=no" is tagged.--Ulamm (talk) 14:41, 16 June 2014 (UTC)

why is horse no vehicle?

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

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

Miscellaneous topics

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

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

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

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

There is an international standard called GDF ("Geographical Data Files", see Wikipedia) that otherwise probably is irrelevant for OSM, but it includes a textual specification syntax for what they call "Time Domains". As far as I can see this is exactly what we would need here, instead of trying to come up with an own way of tagging using day_on, day_off, hour_on etc tags. The actual ISO GDF standard is not freely available and is quite expensive, but 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)

Transport Mode Restrictions

I'm curious as to how these are supposed to be used in practice. I sort of understand the theory behind it. However in the examples it shows: "<tag k="horse" v="public"/> The public has a right-of-way by horse (eg a designated bridleway)".

Does this mean that for a particular way which is a bridleway then it should be tagged as follows: <tag highway="bridleway" horse="yes" foot="yes">, even though, by its' very nature, a bridleway is suitable for horses and foot traffic?

Following on from the above would mean that a road would be tagged for instance as: <tag highway="secondary" horse="yes" foot="yes" bicycle="yes" car="yes" motorcycle="yes" goods="yes" hgv="yes" psv="yes">

This has implications in that:

  • this is going to increase the amount of data held in the database;
  • I don't see this tagging scheme being used much at present.

Other than wanting to know what I am supposed to be doing for all the ways I have so far created, the reason I am interested is that I was wondering how to mark a defined cycleway. There seem two options:

  • A new core value of highway is needed such as highway=cycleway This would be consistent with the structure for bridleways and footpaths;
  • I tag it as <highway="minor" foot="yes" bicycle="yes"> and hope this is OK.

Bus and High Occupancy Vehicle

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

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

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

Bus contraflow

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

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

Routing restriction

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

For the street:

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

For the cycle lane:

  • highway=cycleway
  • oneway=-1

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

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

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

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

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

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

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

Vehicle-type-specific one way streets

How do you tag a one way street where bycicles are allowed to use the street in both directions (i.e. the one-way applies only to motorized vehicles)? Ukuester 14:06, 20 June 2008 (UTC)

There's a proposal, Proposed features/access: name space which would deal with this. --Hawke 18:46, 20 June 2008 (UTC)
Thank you! However, I'm pretty new to this thing. What is proposed there is
<tag k="access:motorcar:oneway=yes" />
<tag k="access:bicycle=yes" />
<tag k="access:foot=yes" />
Current standard is
<tag k="oneway=yes">
What is good style to use now? All four tags together? Or just the three proposed ones? Ukuester 20:16, 20 June 2008 (UTC)
Probably all four. I doubt it makes much difference at this point, as no special rendering would be done. for the access:* ones. --Hawke 07:15, 23 June 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)

Gated Communities

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

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

Routing with oneway restrictions

Regarding routing, is it save to assume the following?

  • The oneway=yes applies to motorcar, motorcycle and bicycle but not to foot.
  • If cycleway=opposite_lane is set, oneway applies to motorcar and motorcycle only.
  • If the way is tagged as highway=footway, oneway does apply to pedestrians.       --Gypakk 23:16, 31 August 2008 (UTC)
Unfortunately there is no clear semantics so far on the access tag, and you should check with your routing software. Gosmore, for instance, ignores oneway=yes even for bicycles (which I think is wrong). Ideally, the routing software itself should have a checkbox like "Ignore oneway: Yes/No" FedericoCozzi 15:51, 12 February 2009 (UTC)

Adding modes of transport i.e. mtb=yes/no/unknown...

Resolved: Tags relevant specifically to mountainbiking are not legal access restrictions. More at Mountainbike. Alv 17:32, 15 May 2011 (BST)

I have added mtb as a mode of transort. Is this o.k.? Or do I need to make a proposal for append for this? There are many ways that can be used by a mountainbiker but not by a normal cyclist on a road/trekking-bike. Further information/proposals about Moutainbike acces restrictions are here: Mountainbike I know that for things like mtb_oneway or mtb_difficulty that concern access of mtb a seperate proposal is needed, the append should only concern mtb=yes/no... like any other of the transport modes featured in the list.

I don't see a problem with you addeding that transport mode, but I do question it's usefulness. Does it gain anything over combining bicycle=* with smoothness=*? Are there any places that have legal access for mountain bikes, but not for road bikes? I can't think of any cases where there's restrictions on what type of bicycle can be used. --Hawke 00:54, 20 November 2008 (UTC)
After some thinking and discussion about it, I begin thinking too that it's not useful. mtb=yes should be a purely technical acces question, not legal. So while I know see the key/tag as itself as good because it is intuitive and easy to remember, it probabely should not be listed here. On the other hand I think on this page there should be a much clearer definition, that here the question is only from the legal side, and not to be give for ways that are unsuitable for use of a transport mode. I don't really like that standpoint. I would prefer a different tagging with say bicycle=forbidden (if it's legal) and bicycle=no (if it's technical) and for those cases where both is true but the technical part a surprise for the map viewer / or the traveler on field maybe bicycle=forbiddenandno (come up with something better than forbiddenandno however). The currennt situation is bad, because it's not clearly communicated (at least to me) that the access key is only of concern for legal, not technical restriction. I've give on the smoothness talk page examples why bicycle and smoothness is simply inadequate. You can have a look at mountainbike on some more needed keys for mtbiking. This might be interesting to hikers too, that are unsatisfied with the smoothness tag. There are indeed some restrictions on when only certain forms of bicycles are allowed, but they are rare (examples include designated mtb downhill trails (well they will pretty strictly define what kind of mtb is allowed on the trail) and of course competitions - but as they are only temporary and if outside of a bikepark mostly happening on ways usually used for other purposes the actual need for that restriction is very small. --Extremecarver

Also see Talk:Mountainbike#mtb_access_rule.3F with the same discussion. --Eimai 12:44, 20 November 2008 (UTC)

I've deleted it here again. I think it's correct that it's not an acces restriction. I do find that a discussion about this here is however well placed, and should not be deleted, but kept because maybe others can profit from it. For me it's now clear that this should be kept seperate. I've just structured the Mountainbike page a bit better. --Extremecarver 12:52, 20 November 2008 (UTC)

I can surely understand the need to tag according to suitability for certain vehicle types. I guess it needs some good discussion on finding a method to do that... My preference is to do it with tags which are as objective as possible, describing the state of a road or path, but perhaps a more subjective approach should be used with a scale for the suitability, so we don't end up needing to enter 20 parameters of a road that describe its state? --Eimai 13:25, 20 November 2008 (UTC)
Just a few thought on what has been said : Maybe this page doesn't state clearly enough the fact that access is a "legal" or "right propertie" (Yes the word legal is on the right but not in the main description)
smoothness=* is in no way usable by hikers, for tagging hiking related stuff there is the Hiking page and sac_scale=* for the difficulty
For mtb, I'll jump to the smootness's talk page to see if we can imporove things or if we need something like a mtb_scale
(unrelated, but I have an "edit war" problem about the smoothness tag, and would like a "third" party or arbiter to help resolv the issue )

Sletuffe 13:38, 20 November 2008 (UTC)

Coucou Sletuffe, please give input on names of tags to use for mtbiking. Should it be mtb_difficulty or mtb_scale? Difficulty is easier to remember, while scale is more common, being accepted already for sac_scale. If you find common factors in the smoothness page that would be great, but I think the difference ist simply to big. I will go forward and put the page Mountainbike into proposals now, as a Draft. Maybe then more input can be found. I've noticed that on the german smoothness page there is written that access to the edit function on english page is blocked for now, sorry but I can't help there either.
Coucou there, who is talking ? you forgot the ~~~~ stuff. I'll move my next discussion there, I have started draft for every tag, I think it's better than a big big page. Sletuffe 18:12, 20 November 2008 (UTC)

Oneway and destination traffic

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

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

Inheritance rule

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

The problem with the table is that it's country dependent: horses could for example be a vehicle in one country, but not in another one, and there are other similar issues (the rule "motorcar=no" would imply "bus=no" and "goods=no" for example here).
In case of emergency vehicles: they can go anywhere, there's no point in tagging roads with emergency vehicle access rules. The emergency services use predefined routes to get somewhere and since we have no access to that we can't put that in OSM. --Eimai 15:43, 20 February 2009 (UTC)
Your point is valid, but how can a software solve this problem if this kind of information is not known? That table is a first step in that direction: by making the inheritance table explicit, we can discuss it and provide country-specific rules. Up to now, that problem was not even acknowledged. I tried to address you point here. --FedericoCozzi 22:51, 20 February 2009 (UTC)
There are likely ways you might want to tag access=no and emergency:yes, so the format (even though it is the only one where you'd formally use emergency) is sound. Circeus 04:31, 21 February 2009 (UTC)
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)

Examples

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

I don't think it's very clear either! Seventy7 14:32, 21 February 2010 (UTC)

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.

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)

watermanagement

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

can you provide a picture of the sign and maybe a link to some legal sources describing the sign? then we can check if other countries have a similar restriction in order to find a most suitable solution (e.g. naming). --Marc 17:58, 19 January 2010 (UTC)
Hi, this is not a offizial sign of the [German Law (StVO)]. It is a Sign made by the local Goverment. Are you sure we need to make a key for that? Smarties 16:25, 29 March 2010 (UTC)

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)

Golf cart

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

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

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

Gender/sex restrictions

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

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

Seasonal roads

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

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

access structure is confusing and often limited

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

i would suggest:

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


I have written down my suggestions for a modified version of the current tagging scheme. you can find it here: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Access_restrictions#Suggestion_for_a_new_scheme -- Flaimo 12:11, 17 March 2011 (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)

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)

Unwieldy talk page

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

Halfway there. Alv 17:32, 15 May 2011 (BST)

Access time restrictions: hour_on and hour_off logic

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

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

Maximum vehicle occupancy

UK no buses sign.jpg

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

Restricted access

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

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

Value "customers"

Discussion moved to Talk:Proposed features/customer

Exceptions to access=no

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

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

Time restrictions

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

Seasonal access

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

caravans/trailers

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

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

taginfo caravan=* taginfo trailer=*

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

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

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

New 'Access' Feature page?

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

Wide Loads

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

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

Access time restrictions: get rid of them

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

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

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

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

Bus has multiple meanings

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

Emergency vehicles have fallen between the cracks?

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

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

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

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

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

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

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

access=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)

Redefining default designation of road

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

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

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

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

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

Draft of hierarchy for land-based transportation mode

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


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

Rendering Private Features, particularly Ways.

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

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

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

Access in common practice, but not in law?

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

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

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

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

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

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

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 =facultative or =free. "free" is the shorter, simpler and more positive term, but sometimes the word is used as a synonyme of "gratis".--Ulamm (talk) 11:36, 27 November 2014 (UTC)

Why does dog=* still missing at this page?

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

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)

Access only by toll?

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

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

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

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

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

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

highway=path and bicycle=* in Austria

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

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

access:bicycle=yes

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

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

Segways

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)

Gated Communities

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

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

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