Talk:Key:access/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Access Time Restrictions

Resolved: Date and time values should be specified using ISO date/time format YYYY-MM-DDzHH:MM:SS.

I think the date and time values should be specified using ISO date/time format YYYY-MM-DDzHH:MM:SS. Using dd/mm/yyyy is not very friendly for North Americans and easy to misinterprete by them (and vice versa). 80n 13:46, 17 Mar 2006 (UTC)

Change made Blackadder 14:46, 17 Mar 2006 (UTC)

Scooter

Resolved: moped=* is popular. Alv 17:32, 15 May 2011 (BST)

I wonder how I am able to distinguish between motorcycles, scooters and bicycles. In the Netherlands these types of transportation have their own status and regulations. Kind regards Dryke 12:41, 27 June 2007 (BST)

Vehicle category for scooters "below motorcycles" is moped. Alv 17:32, 15 May 2011 (BST)

Taxi

Resolved: taxi=* is popular. Alv 17:32, 15 May 2011 (BST)

Is there any way to tag that a road is accessible to taxis? (I presume that they don't count as a psv) Many thanks --Ndm 22:20, 1 May 2008 (UTC)

Some definitions indeed say psv includes both public service buses and taxis, in others they don't. Many use taxi=* anyway. Alv 17:32, 15 May 2011 (BST)

A new core value "=only" ?

Resolved: Virtually no uses of =only in 3 years. Alv 17:32, 15 May 2011 (BST)

If a way is exclusively reserved for one type of vehicule, I would like to use a core value like:

  • psv=only or taxi=only

Instead of

  • psv=yes, hgv=no, motorcar=no, foot=no, etc...

or

  • access=no, psv=yes
A bad idea IMO. What does it mean if a way is tagged psv=only+motorcar=yes? IMO access=no+psv=yes is best way to tag a route which is exclusively for PSVs. --Hawke 17:48, 3 July 2008 (UTC)

"Accessibility"

Resolved: Page changed.

I've remove the word accessibility from the description in the box. accessibility sounds like whether you can physically use the way, while the access key describes whether you can legally use it. If you have a better alternative, go ahead and edit it. How does "legal accessibility" sound? Robx 14:00, 9 July 2008 (UTC)

Sounds great. I've updated the page with that term. --Hawke 05:53, 10 July 2008 (UTC)

Imperial Units

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

Do the database/renders support unit conversions? I'm in the US, and we use those other weird units for height and width. Sure, I could convert to meters, but nobody ever sees a sign with "4.2672m." Can I just start tagging with an explicit unit? I realize it may not be practical to use ' and ", but would "ft" and "in" work?

maxwidth = 12ft
maxheight 9ft 4in

Alexrudd 21:42, 15 August 2008 (UTC)

I hope JOSM, Potlatch and Merkartor will soon offer automatic conversion, so that only metric values are stored and the users can view whatever they want. --Lulu-Ann 10:12, 18 February 2009 (UTC)

From previous discussions on IRC and the mailing lists, it appears that the general consensus is that the units on the signs and in the documentation are used, regardless of what they are. For the UK, with speed limits in miles per hour, and dimensions in feet-and-inches, they should be tagged maxspeed=30mph and maxwidth=7'0" (or whatever notation people agree on). In the UK there are specific rules on designating height limits, and where both metric and imperial units are used it's entirely feasible to find one sign saying 13'9"/4.2m and another saying 14'0"/4.2m. Chriscf 14:47, 12 January 2009 (UTC)

While it is clear that OSM has to use SI-units, it is ok if people from Liberia, Myanmar and the United States use the imperial-units. We can use scripts to fix those values... --Phobie 02:37, 13 January 2009 (UTC)
"While it is clear that OSM has to use SI-units ..." No, it isn't. In fact, that's the exact opposite of what I said. If the sign on the ground gives a height limit in hands or a weight limit in bags of cement, then that's what goes in the database. Chriscf 17:31, 14 January 2009 (UTC)
Scripts are not the best solution. The editors need to implement the transformation! --Lulu-Ann 14:06, 15 January 2009 (UTC)

Local traffic only

Resolved: access=destination, motor_vehicle=destination, hgv=destination.

Is there a way to tag a road as no through traffic / no through hgv? Random832 15:53, 16 September 2008 (UTC)

I would tag it as access=destination. --Gypakk 23:57, 16 September 2008 (UTC)
Or more likely motorcar=destination - "no through traffic" doesn't usually apply to pedestrians or cyclists. Alv 06:39, 17 September 2008 (UTC)
I agree. But it schould be motorcar=destination, motorcycle=destination, bicycle=destination and the proposed tag moped=destination. Easier maybe: access=destination, foot=yes.
Why don't we have a vehicle tag? I'd like to suggest vehicle=destination. --Gypakk 10:43, 17 September 2008 (UTC)
This was introduced: we now have vehicle=* and motor_vehicle=*. --Skyper 12:03, 1 April 2010 (UTC)
Stick with access=destination. It's up to each country to define what it exactly means (and remember that the exact meaning of those signs in each country can change in future, at which time it'll be very hard to change all those access tag lists, and 99% of all mappers will forget at least one of the vehicle types if you're going to define it by which vehicles are allowed and which aren't). --Eimai 11:42, 17 September 2008 (UTC)

"Local traffic only" seems to have two meanings (for cars; laws are more restrictive towards trucks). Either it's a warning that the road doesn't go anywhere (usually "no outlet" would be used, but "local traffic only" might be used, for instance, if a temporary situation such as a bridge out or construction closure blocks the road), or it's a regulatory sign that aims to prevent through traffic from using the road. The former use has no real legal meaning; it's the actual closure that prevents through traffic. The latter is probably unenforceable on public roads, since local traffic is ill-defined; does driving down the street for OSM mapping purposes make you local traffic? Google certainly sees their street view vans as local traffic. Maybe the best way is to tag each place such a sign appears, and let the end user decide whether he is local traffic. --NE2 13:41, 1 April 2010 (UTC)

There are places around here where a short way is signposted (to the effect of) "no motor vehicles - driving to premises allowed". It's then quite possible to park an unmarked patrol car so that one officer can monitor all the traffic and stop all that just drive through. They do occasionally have time for such, mostly after enough people complain that people drive through daily. Longer (suburb wide) destination only limits are also enforceable, even if the ticket can be contested (if you have evidence). They keep record of times cars pass the end points of such restriction (they won't even notice driving through if one really stops there, given they most likely do it manually and compare to cars with reasonable through times only). There used to be more such limits around here, and they did enforce them more often, but it's easier/cheaper to build barriers and have the short type somewhere for emergency traffic. Alv 16:56, 1 April 2010 (UTC)

Hazmat

Resolved: hazmat=*

Is there a tag for restrictions on hazardous material traffic? Random832 15:53, 16 September 2008 (UTC)

hazmat=* is widely in use. Alv 15:48, 15 May 2011 (BST)

Access=yes and access=no not consistent wording

Resolved: Wording for no was changed some years back.Alv 17:32, 15 May 2011 (BST)

The description says :

  • access=yes The public have official, legally-enshrined right of access, i.e. it's a right of way

and

  • access=no Access by this transport mode not permitted or unsuitable

I allways thought for access that "yes" was the exact opposite of "no", but the wording for the "no" add the word or unsuitable while the "yes" doesn't have or suitable This might be a possible cause of misunderstanding. I know someone might think I am playing on words, but it's not the case. Those 2 words or unsuitable are not coherent to yes and the access being a legal property, therefor, because it is not so obvious, I'm not removing it without comment. Please give your point here. Sletuffe 16:09, 30 November 2008 (UTC)

I agree with your edit. The meaning needs to be consistent, and the other texts on the page generally focus on legal restrictions (see e.g. definition as "For describing the legal accessibility of an element."). --Tordanik 17:07, 30 November 2008 (UTC)
I agree with your edit as well, and for the same reasons as above. --Hawke 19:27, 30 November 2008 (UTC)
Yet any way that is unsuitable can't be used, no matter if legal or not. Thus it must be tagged with, for example, foot=no, unless someone prososes a better value; either *=impossible or *=forbidden. Alv 12:32, 27 May 2009 (UTC)
the wording unsuitable doesn't seams equivalent to impossible to me. (Adj.1. unsuitable - not meant or adapted for a particular purpose) People reading might be abused and tag *=no ways that are "not comfortable" or "risky" while other tagging it because of legal restriction. A key/value pair indicating two possible meaning doesn't looks good to me. (even if, in the end, result is close).
The idea behind *=impossible seams a good idea to me. However I would prefere to make separated keys than those here used for legal restrictions.
(isn't foot=no the same as foot=forbidden ?) Sletuffe 15:51, 27 May 2009 (UTC)
foot=no was the worst example; say bicycle=no on a track (or path) that's filled with sharp rocks or infested with roots... Alv 16:06, 27 May 2009 (UTC)
Right now, if I see a path with bicycle=no, I will consider that I haven't the right to go there and will risk a fine (or one of the land owner's shotgun's bullet), but If I like to live dangerously, I'll probably try it ! But if someone tagged it to no because it ends in a cliff, that might be extremely unpleasant. Therefore I prefere to make distinction between both.
On your example, a path infested with roots might well be unsuitable or impossible to a racing bike while still beeing perfectly interesting and usable with a mountain bike. (thus, bicyle=yes and racing_bike=impossible looks possible to me) But here we are joining the smoothness=* and mtb:scale=* tags. Sletuffe 16:18, 27 May 2009 (UTC)

Usage for parking?

Resolved

What would you say of tagging a parking reserved for a commerce/residential building, but relevant for mapping purposes as access=destination(commercial)? Circeus 19:23, 19 December 2008 (UTC)

Yes, just access=destination - or motorcar=destination if one could roam freely on foot in the parking area. If appropriate, combine with a operator=company name. Alv 19:30, 19 December 2008 (UTC)

Military base roads

Resolved: Private they are. access=military hasn't gained popularity (431 at the moment).Alv 17:32, 15 May 2011 (BST)

Is it possible to specify a tag for roads on military bases, wherein the military effectively controls, limits, or restricts access via a gate? I'm thinking of proposing a tag like access = military for this purpose. Dufekin 20:35, 31 December 2008 (UTC)

Doesn't access=private cover that? It seems similar to other private roads – the owner (in this case the military) controls access to it. --Tordanik 13:37, 1 January 2009 (UTC)
Wouldn't the barrier=gate (or whatever) on the road combined with the landuse be enough? As far as a map is concerned, people are bright enough as to not try to route through a military base. Circeus 05:20, 2 January 2009 (UTC)
The subject ist not wether people are bright enough not to route through a military base. The goal is that the OSM data provides valuable information to routing software not to calculate a routh through! I would also prever to have military / private / industrial roads behind a gate in a different color, so an information at the highway is needed. --Lulu-Ann 10:17, 18 February 2009 (UTC)
The road to Fortaleza de Santa Cruz da Barra is behind a gate and on military property (landuse=military) but the access restriction is ONLY based on time (0900-1900 open for everybody to visit the fort, at night closed, only for military use). That is an example where gate + landuse wouldn't cover it, though most roads on military property would probably be access=military. --Skippern 15:27, 19 February 2009 (UTC)
I'm fairly sure there is currently no widely agreed system re: time for access, so tag however you feel. Circeus 20:15, 19 February 2009 (UTC)
I have actually not tagged access on the mentioned feature, I used it merely to illustrate that landuse=military combined with gate is not enough to say access is military. There is use for such tag access=military --Skippern 20:31, 19 February 2009 (UTC)
Might this be a good case for using Proposed_features/Scope_for_access_tags, with "military" as one of its conditions? --Hawke 20:45, 19 February 2009 (UTC)
I see "military" and "isps" as two specific types of restriction that needs to be tagged, and that doesn't quite fit the values yes/no/restricted/permissive/private and, a access:military=yes will suggest that military personnel have access to the area, without saying anything about private persons, cars, bicycles, etc. while access=military would give a range of various restriction valid for a military area (such as civil vehicles are subject for search, no entrance without valid pass, goods to be delivered at the gate and handled by base personnel from there, etc.). Similarly with access=isps, as this is governed by a similar set of rules. --Skippern 11:50, 20 February 2009 (UTC)
Is the military or isps tag really needed? Usually those roads are tagged as plain highway=service, optionally with some access rules, like access=private. And that's what they really are as well: private roads, as they aren't belonging to public space. A better place to put the military/isps information would be the service=* key IMHO. --Eimai 12:21, 20 February 2009 (UTC)
Military roads I guess are generally maintained by the military and can therefor be interpreted as private, but many ISPS port areas are maintained by the city, and are therefor NOT private, but public areas with restrictions. Besides, ISPS restrictions might temporarily be lifted when for instance no foreign flag vessels are in the port. Besides, many places, port operator is only a relay instance, and access is granted by some other instances, such as vessel operator, vessel agent, charterer and so on. International regulations from IMO and ILO (UN organizations for Maritime industry and Labor) give right of access by law to mariners on vessels inside such port. ISPS is a very complex regulation. Besides access=isps would also apply for man_made=pier and other non-highway facilities in the port. --Skippern 16:33, 20 February 2009 (UTC)
OK, those places often are public property, but that doesn't mean anyone is allowed to access it. Don't know the laws in your country, but an area with restrictions like ISPS to enter is no longer a public place (likewise, private property can be a public place, airport entrance halls for example). I just don't think the ISPS rules are special enough to come up with a new access rule. I could likewise propose tags like access=travelers for the airport terminals for example (only allowed to enter if you have a ticket to get on an airplane). I remember something like a access=licence being proposed some time ago which may cover that, but I don't think that's needed. You're always allowed to enter if you have a licence or permission to enter. You can drive on footways if you have the necessary licence (road work vehicles for example) or permission (emergency vehicles) for that.
And if ISPS rules are just temporary it would just be the same as temporary access=no/private.
If you want to map ISPS access somehow, I'm not stopping you. It just doesn't belong in the access tag, but it needs to be in something separate from it. --Eimai 18:42, 20 February 2009 (UTC)
I have noticed that there are a separate approval for access=agricultural and access=forestry, doesn't that open for ISPS? Doesn't see that agricultural and forestry traffic is protected by any laws, but there is a large set of international laws governing ISPS, which covers anything from who can enter a port and when from the shore side, from the sea side, how control of vehicles and cargo is to be done, who is responsible for what and so on. The international ISPS regulation is a book of more than 200 pages. --Skippern 11:45, 21 February 2009 (UTC)

ISPS

Stale: Private seems to convey the important part; no uses of isps in the database.

How to tag access in ISPS ports? For those not familiar with the term, ISPS is the international security regulation regarding ships and port facilities. The requirements to enter a ISPS port is that you are pre-announced, and can show the necessary documentation (such as ID, cargo documents, work permits). To tag this as private isn't quite right, same goes for permissive, restricted is close but doesn't quite cover it. What about access=isps? --Skippern 18:20, 15 February 2009 (UTC)

I'd go for access=private and, say, access:isps=yes - or even permissive for the latter. The former being private tells passerby's that they're not allowed. Those with reasons to go there either know to search for "isps" (regular port visitors) or to contact the port operator beforehand as with any place "private". But there can be valid reasons to tag it otherwise... Alv 09:25, 16 February 2009 (UTC)
For a port town such as Kristiansund, there are areas regulated as ISPS port, areas regulated as non-ISPS port, and some areas where measures can be temporarily put in place to allow it to be classified as ISPS facility. This applies for most port cities in western Europe, and I would guess in most ports with international trade in various degree. This would indicate that access=privat or access=permissive could be tagged together with for instance isps=yes/no/temporary, or as I would suggest access=isps with maybe temporary=yes if needed. --Skippern 19:06, 17 February 2009 (UTC)

access=occasional

Resolved

I propose the value "occasional" to be used where access is only on occasions, not on predefined times. E.g. An assembly hall with parking lot is fenced. The gate is open for access only when there is an event in the hall. Willi2006 07:11, 17 April 2009 (UTC)

IMO it should be enough to mark the gate. There is no need for a new value. access=private would say the same. --Cbm 12:07, 17 April 2009 (UTC)

Water-based transport/ships/boats

Resolved: Was included on the page.Alv 17:32, 15 May 2011 (BST)

How should we specify various forms of water-based tranport, we have now boat=* and motorboat=*, doesn't that automatically qualify sailingboat=*? What about fishing vessels, passenger ships, vessels carrying dangerous cargo, vessels covered by ISPS, exempted from ISPS, not covered by ISPS? How for example to tag a dedicated berth of a single hull crude oil tanker? I suggest ammending the following tags to water-based tranport:

Please amend as needed. --Skippern 02:08, 23 August 2009 (UTC)

Maybe pleasurecraft=* maybe useful as a generic term which includes sailing yachts as well as motor yachts. --HeikoE 08:37, 23 August 2009 (UTC)
I think they belong under boat=*, let me include them in the list above so that it is complete. To divide with one more class is meaningless, as I feel yachts belongs under boat=*. If we make a different for pleasurecrafts, what then are boats? --Skippern 09:38, 23 August 2009 (UTC)
Changed tanker subtags to tanker:*=*, because gas, oil will be used for other things.--Vsandre 21:28, 24 August 2009 (UTC)
Good spotted, good suggestion, looks better --Skippern 00:48, 25 August 2009 (UTC)
One way to interpret a tree structure like this is to inherit the master keys in the names, such as passenger=* really is short for ship:passenger=*. I like to use the shorter versions, but where they conflict, adding the master key to the key is a logical solition. In worst case, the full name access:ship:cargo:tanker:singlehull=* is bloody long to write, and are logically shortened (I used first singlehull=* but tanker:singlehull=* also works fine) --Skippern 00:53, 25 August 2009 (UTC)
What makes more sense, upper or lower case of imdg=* and isps=*, or does it really matter? Will parsing software surch as renderers and routing be able to treat them as same, or might they be wrongly interpretted as different tags? --Skippern 00:56, 25 August 2009 (UTC)
  • I need a tag for canoe (or non-motorboats). canoe=* Becauce: small rivers are allowed for non-motorboats (canoe) but not for motorboat and sailboat. Some lakes are allowed for canoe and sailboats but no motorboats. Some harbours are allowed for motor and sailboats but no canoes. Smarties 18:51, 21 September 2009 (UTC)
Good example, adding --Skippern 01:01, 22 September 2009 (UTC)

oneway=*, backward=*, forward=*

Resolved: Included on the page.Alv 17:32, 15 May 2011 (BST)

There were two sections discussing routing restrictions and the oneway=* tag. I have combined them. Please look it over.

It is unclear to me why the forward=* and backward=* tags are needed since the oneway=* tag can be prefixed. Perhaps they are simply competing practices. TomashPilshchik

I don't think that your edits correctly represent current tagging. Most importantly, there are no forward/backward=* tags. These are suffixes for other tags, but cannot be used on their own. The idea of "prefixing" keys also isn't really used consistently, so I don't think it can be formalized in this way.
Also, this page generally separates larger examples from definitions, and I don't see a reason not to do so for oneway/directions. Therefore, I've mostly restored the example section, but removed some information from it that was indeed a duplicate from the definition section. Please check whether you think that some other changes need to be restored, too. --Tordanik 15:56, 4 December 2009 (UTC)

Garbage truck

Resolved

I find use for one additional tag type for land based transportation "by use". The type is "garbage truck" or "waste collection vehicle". In my neighborhood there exist service roads with gates meant for garbage trucks, but not allowed by car. The entry row would look like: "garbage=* (a vehicle meant for collecting garbage)" Anyone else find such tag useful?

Is it really necessary to have an access token specific for garbage trucks? Can this not be covered in some other way, such as goods=*, or accept this as a general exception? In my experience there is no special use of restrictions for garbage trucks, and if the roads have limits such as goods=no or access=no, garbage trucks enters on their routes nevertheless. Besides, the routes of garbage trucks are often fixed, making certain routes at pre-defined times, and they are either operated by, or contracted by, the same bodies deciding the restrictions. --Skippern 21:57, 5 March 2010 (UTC)
goods=private IMO. Those who know that they can enter can enter, and it can tell others (pedestrians mainly) that a truck might be encountered. Heck, add a goods:private=garbage truck to addr if someone has interest in it. Alv 22:20, 5 March 2010 (UTC)
OK, goods=private seems like best suitable. --Kslotte 02:32, 6 March 2010 (UTC)

Access restrictions for dangerous areas?

Resolved: Hazards are not an access restrictions.Alv 17:32, 15 May 2011 (BST)

I just had a discussion on german OSM Forum about tagging dangerous streets or areas in OSM. As here in Brazil much places can be kind a dangerous that not even the police will go ever inside i think it will be wrong to use the map data in GPS and point the user in this areas... I think a new tag access = dangerous should do the job. What do you think? Let me know. --Deltabrasil 19:24, 28 March 2010 (UTC)

You completly misunderstood access restrictions. Make a new key for that (like tracktype, smoothness or other subjective keys describing access conditions), but don't abuse access (which is for "signed" access rights)--Extremecarver 19:42, 28 March 2010 (UTC)
tracktype, smoothness? This can't tag if it's better to leave out of an area. Surely you can tag them wrong "very_horrible" as smoothness, but that doesn't fit cause it's completely wrong. Other suggestions? --Deltabrasil 19:58, 28 March 2010 (UTC)
There was a proposal some time back for hazards, since entering in a favela is not physically or legally prohibited, I would rather call it a hazard. You inform about it, but doesn't do any actions to prevent people from actually entering. --Skippern 22:20, 28 March 2010 (UTC)
Surely it isn't prohibited at all, if u tag opening_hours from 10 am till 8 pm doesn't mean you can go over there at 9 pm anyway... There was a discussion in the ML without a concrete solution for this type of tag. I wil lwait how this discussion will proceed but i suggest a hazard_level tag from 1 till 5 (like the us terror flag) could be great; Anyway: it will just help anyway just if the software on a navigation system will ask you like "i dont want to use ferry" so should ask anyway "dont go dangerous places".
A danger is not an access restriction. At least not unless the government declares it as an officially restricted area. Dangers like this should be tagged, but access= is the wrong tag. There should be a separate tagging scheme, something like hazard=crime_area might be a good start, or define a new tag. --Nop 13:51, 29 March 2010 (UTC)
I have a forest that is officially designated by the government as a restricted area [1]. Explosive and Toxic Weapons from the war have been found there. For that I have chosen = no access, is that right? Smarties 16:51, 29 March 2010 (UTC)
Yes, if there is a sign, then it's access=no. Lulu-Ann

Bars, Nightclubs

Resolved: Members only equals private.

Hi! I'd like to use this key along with amenity=bar and amenity=nightclub to show that there is no public access. E.g.: access=private. In my opinion, an additional value would be necessary: access=members. --Gypakk 12:48, 28 June 2010 (UTC)

access=private means that only people who are authorized to use it can do so. This would include employees of a company using a parking lot or members of a nightclub using said nightclub. --NE2 14:35, 28 June 2010 (UTC)
I know a parking lot at a bureau complex where employees are not allowed to park their cars, because it is only for customers. A little more differentiation would not harm. Lulu-Ann
If it's for customers it's probably access=destination. Employees should know where they can park :) --NE2 12:47, 29 June 2010 (UTC)

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.


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)


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.


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)

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)

access=exclusion_zone?

Hi, I do not like that access=exclusion_zone was added to the table Access tag values.
This tag is not used in the database, so it is just a proposal. And a very bad proposal IMHO. It seems do define an area and not an access value, though it could be used as such when properly defined.
I would like to remove it. What do you think? Chrabros (talk) 02:15, 9 March 2017 (UTC)

I agree that this value should be removed. I would also prefer if the tag page was moved into the proposal namespace. --Tordanik 11:36, 11 March 2017 (UTC)
I'm not opposed to this. I only made edits to make clear this was just a proposal after someone added it to the table. In my opinion that proposal is broken, but the alternative for now only covers military zones, but not all exclusion zones (e.g. permanently and severely polluted and dangerous areas, around exploded nuclear sites in Tchernobyl or Fukushima, which are not really military zones, or other dangerous areas such as large uncleaned mine fields, which has some military control around but no real military activities, but that could be also closed and controled by civil authorities, or all exclusion zones around strategic civil facilties including large dams and water facilities, antennas, international areas around airports, radiotelescopes, or industrial sites producing or using explosives or dangerous chemical products, or handling/storing agricultural products such as seeds). In my opinion it's best to draw the barriers/walls/gates around the area, and just set access=no on nodes for their access points, plus access=private for ways inside the delimited area. — Verdy_p (talk) 12:51, 11 March 2017 (UTC)
I must be dreaming! Verdy_p: "after someone added it to the table" Come on! It was YOU who added this: [2] three dasy ago! What are you trying to achieve, Mr. Hyde? Chrabros (talk) 15:46, 11 March 2017 (UTC)
I'm not clear anough: the proposal was created as a normal page instead of a proposal, and was given no status, as if it was de facto. I've only listed it as is, but clearly as a proposal (what it is), and placed it at bottom of the list in still unsupported values with the appropriate warning and status.
Look also at its own talk page, there were others giving their opinion about this before I did it too there. Then you've just changed its status to a draft (and as far as I see, this draft was not changed since 2013, so there was no one to suppoort it, but it was not formally disapproved/rejected).
This wiki has a more formal procedure for proposals (including drafts) using a naming scheme which was not respected (but in 2013, that procedure was still not very functional). It is not me that wrote that draft! — Verdy_p (talk) 23:30, 11 March 2017 (UTC)

Unwieldy talk page

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

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

Access time restrictions: hour_on and hour_off logic

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

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

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

Seasonal access

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

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

Access time restrictions: get rid of them

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

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

Redefining default designation of road

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

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

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

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

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

Access in common practice, but not in law?

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

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

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

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

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

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

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)


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

Gated Communities

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

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

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

Access=no for hgv with EURO 0-2

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

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

access on non-navigational objects

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

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


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

Gated Communities

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

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


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)
Resolved: this page documents actually used scheme, if someone wants to deprecate all existing access tags - feel free to make a proposal but I would not expect success Mateusz Konieczny (talk) 09:50, 24 May 2020 (UTC)

Gender/sex restrictions

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

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

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)


Resolved: Nowadays syntax for such cases is documented, also no specific case is mentioned here Mateusz Konieczny (talk) 16:35, 16 June 2020 (UTC)

Value "customers"

Discussion moved to Talk:Proposed features/customer

Resolved: Mateusz Konieczny (talk) 16:36, 16 June 2020 (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)

Resolved: It is unclear what is proposed to be moved/deleted Mateusz Konieczny (talk) 16:36, 16 June 2020 (UTC)

Rendering Private Features, particularly Ways.

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

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

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

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

access tag for people living there?

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

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

Why does dog=* still missing at this page?

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

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

UK TRO/TTRO (Traffic Regulation Order)/(Temporary Traffic Regulation Order)

In the UK we have TROs which apply to 'ways' an example of this would be a byway which is closed to motorized vehicles with 3 wheels or more between October and April. Then there are TTROs which apply to 'ways' and may be used to close part of a byway for a set period of time due to errosion and needing repair.

Is there any tag which can be used to give this information?

Resolved: Please see Conditional restrictions --- Mateusz Konieczny (talk) 20:05, 3 July 2020 (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)
@Malenki:, @Seventy7: I finally added some examples and improved existing one! If you are still active, review would be welcomed. Sorry for so long wait. Mateusz Konieczny (talk) 10:09, 24 May 2020 (UTC)
Resolved: Mateusz Konieczny (talk) 12:26, 25 May 2020 (UTC)

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)
I would tag it simply access=private Mateusz Konieczny (talk) 09:36, 24 May 2020 (UTC)
Resolved: as a dead inactive discussion (remove this if anyone wants to continue it)Mateusz Konieczny (talk) 12:27, 25 May 2020 (UTC)

is *=delivery correct for any case?

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

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

The delivery value isn't limited to private roads. Around here, it is commonly found in pedestrian streets: There's often a special signed exception for vehicles delivering wares to the local shops. --Tordanik 17:53, 13 November 2017 (UTC)
Yes, highway=pedestrian, motor_vehicle=delivery may make sense Mateusz Konieczny (talk) 23:03, 21 November 2017 (UTC)
Resolved: added Mateusz Konieczny (talk) 12:37, 25 May 2020 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:access/Archive_1&oldid=2288080"