Talk:Key:access

From OpenStreetMap Wiki
Jump to: navigation, search

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

Contents

Resolved discussions

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)

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)

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:

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:

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:

For the cycle lane:

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

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

Routing with oneway restrictions

Regarding routing, is it save to assume the following?

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)

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:


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"

The access=customers was added only recently in April 2011, as a copy from the Parking page. Its propagation needs to be stopped. For a parking lot the value for customer access has been permissive or destination from the start; the meaning of access=customers would be a more specific case of access=permissive - the owner generally gives access, but can choose to remove access at any time, for any reason. The access=customers is not yet used too much, only 1600 times, to have users convert them to permissive or destination. With those 1600 uses it can be documented somewhere, but the list of accepted main values on this access=* page should list only the established core values. Alv 13:12, 23 May 2011 (BST)

for this current scheme, i agree, that user roles shouldn't be added left and right. permissive for customer parking is enough. --Flaimo 16:22, 23 May 2011 (BST)
access=permissive isn't really accurate, though, in the case where a sign says "customers only". In that case, barring a new tag, I'd use access=private rather than access=permissive. In my opinion the "general permission" in access=permissive means anyone can use the [whatever] unless the owner specifically says they can't, whereas access=private means no one can use the [whatever] unless the owner specifically says they can. "Customers only" would be an instance of the latter. Anthony 02:21, 4 June 2011 (BST)
I wholeheartedly agree. "Customers only" is not permissive, one glance at its definition makes this unambiguously clear. destination appears to be the best choice if we want to stick with the existing tags. Though I could certainly see the point be made that semantically customers is the sounder option, but that distinction is of lesser importance. What is much more important is the matter of how to tag the associated business or, even more complicated, businesses! Tagging such a restriction is pretty much useless if we do not at the same time give the permitted uses. Is there an established schema? --Silanea 12:19, 22 July 2011 (BST)
for associating a parking lot with a business, you can use the operator tag on the parking lot which could be the name of the business. while "permissive" might not be ideal, it still the best match under this access scheme. for a new scheme you could take a look at this proposal i wrote: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/access_restrictions_1.5
operator is not always appropriate. A parking lot may be run by one company on behalf of the shop owners in the vicinity (think: big shopping centre). So we have an operator, company X, and a slew of businesses for whose customers the parking lot is a valid destination. This case is not hypothetical: Many bigger shopping centres require parking tickets but will refund some or all of the ticket cost to people who actually shop at one of the associated businesses. How do we tag this? --Silanea 22:42, 16 August 2011 (BST)
that is why i wrote the proposal mentioned above. together with the already approved parking proposal from may 2011 this would solve most user role problems including "customer". --Flaimo 11:43, 17 August 2011 (BST)
Still figuring out whether all the restrictions I have come across so far map onto this scheme. :-) This may indeed be the Big Thing. --Silanea 14:24, 18 August 2011 (BST)
If the shop is inside a shopping center, that is evident from the data, and the operator for parking can then be the shopping center. Alv 16:53, 18 August 2011 (BST)
Firstly in many cases the shopping centre is not the operator. Someone else is, on their behalf. Secondly I can think of two major cases along my daily commute where the related shops that share one parking area are not organised in a unified shopping centre. Thirdly forget shopping centres and look at the general case of one parking facility being shared amongst a group of entities, be that in a residential area, a business park with offices or a bunch of shops. I hope I do not come across as rude, that is not my intention. I am banging my head against the wall trying to understand the implications of tagging such properties and I am currently looking at some examples of Flaimo's proposal applied to parking facilities in my mapping "home zone" to see if it works. In my mapping work so far access has been the second most problematic tag, topped only by the subtypes of building. I really hope for a tagging scheme that enables us to answer the question "Can and may I go there?" for anyone and for anything that is on the map. Call me a dreamer, heh? :-) --Silanea 23:03, 21 August 2011 (BST)
In the end it's irrelevant if it's tagged operator= or destination= or for_customers_of= - it's a parking lot that just happens to be nearby, and any of the nearby lots with =yes, or =permissive, or =destination with a suitable additional criteria, is as good as the others if the trip destination is known to the software at that time. Alv 14:03, 22 August 2011 (BST)
I'd rather see access=restricted (access is given by the owner under certain conditions), as something in between access=permissive and access=private. Then access:restriction=customers_only could specify the restriction. I think this would be easier on the routers when people decide to add new types of conditional access, rather than having lots and lots of things all under different access=* tags. Anthony 02:17, 4 June 2011 (BST)
On the parking page, the access tag's possible values are listed as "yes/customers/private". Perhaps "permissive" or whatever tags are preferred should be added there? This will prevent users from assuming that one of the three above values is best. --Douglas P Perkins 01:15, 14 June 2011 (BST)
I think the customer tag is really needed, because "access=permissive" is a parking lot that is "Open to general traffic" as stated in the wiki, while "access=customers" says that the parking lot is open for a special group of people, the ones who are customers of a shop, etc. Its also a matter of usage. When I want to go to a restaurant and look at the map where to find a parking lot and I find a parking lot directly beside the restaurant I need all three tags to know if I can use it. If "access=Private" I have to search for another. If "access=permissive" I'm generally allowed to use it. With "access=customers" I know that I may use it, BUT ... Now what is missing in my opinion. There is no relation to what that says whose customers are allowed. Are the customers of the restaurant I want to got to are allowed to park there or the customers of the shopping centre on the other side of the parking lot. So I would suggest to keep the "access=customers" tag and add a relation what it belongs to. --Maptin 11:05, 7 August 2011 (BST)
Permissive inherently implies that the lot owner has the right to disallow access, even if it's generally open to traffic. You'll never now for certain if anything tagged as permissive is open at any given time, not until you reach said object. "Customers" is still a role and roles don't make good values - you'll soon have a slew of different values (say, access=jury, as was mentioned on the talk mailing list) and cases with concatenated values, i.e. access=customers;employees Alv 16:53, 18 August 2011 (BST)
It depends on what you want to do. If I ask a navi for the nearest parking lots, I assume that it just shows me those available for general use. A public Parking lot is a parking lot with no or few restrictions, but a parking lot of a shop center is a parking lot where Parking is not allowed, except for customers. "access=customers" might not be the best way to specify the restrictions, but it's better than "access=permissive", because such parking lots are not for general use. --Ancpru 15:06, 19 March 2012 (UTC)


I agree, access=destination is the right way to tag that. Lulu-Ann
I wonder why a discussion was started here when there was already a proposal on this. Please note that the proposed tag value is in singular case (access=customer) because singular is generally preferred for tag values (eg. shop=car instead of shop=cars), and key names in the access scheme are singular too (eg. horse=*, bicycle=*). --Fkv 19:32, 28 September 2011 (BST)

Exceptions to access=no

I have been tagging streets that only allow particular modes of transportation, such as those in transit centers, as access=no, *=yes, with the ladder 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?

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)
Retrieved from "http://wiki.openstreetmap.org/wiki/Talk:Key:access"
Personal tools
Namespaces
Variants
Actions
site
Toolbox