Proposal talk:Access: name space

access=private vs access=no

I prefer access tags highway/provided/permissive/suggested/private (Ben) over yes/permissive/private/no (present). 'no' is IMHO no difference with 'private' and 'provided' and 'suggested' I encounter very much in real word. 'provided' is for instance a sidewalk next to a road and 'suggested' a trail in a park with general way of right.--rvanderh 14:05, 5 August 2007 (BST)

"No" is very different from private. It would indicate something like a sign saying "no bicycles" on otherwise public land. "private" means land where the landowner may allow one person access and forbid another, or arbitrarily change the restrictions without notifying anyone. --Hawke 22:00, 24 September 2007 (BST)

Vehicle types

How about putting the "types" of access on Vehicle types page, so that the definitions (foot, horse, hgv, car, etc) can be re-used in other tags (e.g. maxspeed) Ojw 22:17, 24 September 2007 (BST)

Units

• I'd really like to see units on the key side of the tags, like "access:*:maxspeed:kph = 123", with units being globally unique and clear in OSM scope (a "ton" could be a short ton, a long ton, a metric ton...). But I guess this isn't the right page to discuss this, just wanted to comment when I saw the examples. Tsok 05:29, 25 September 2007 (BST)

• I think the more general way this is done (has been discussed elsewhere, but I don't remember exactly where) is to document a "default" unit if units are unspecified, and then put other units in the value if necessary (e.g. 65mph). I really don't want to see, nor do I see a need for "access:*:maxspeed:kph" and "access:*:maxspeed:mph" on the same way. (What would that mean? "if you measure your speed in this unit, you can go this fast, but if you measure it in that unit, you can go that fast" It doesnt make sense. --Hawke 19:52, 4 January 2008 (UTC)

• Common units should be used. Weight should be with implicit tons, symbol t, but neither clear text "tons" or "tonnes" - and the meaning should be as given by SI units ( 1 t = 1000 kg ). I guess that countries which use feet or miles per hour would not declare them, but would use every number within this country according to the local units on the roads. Is there any official standard for km/hr? I know km/h only (and no KM/h, Km/h etc.) --Traut 15:16, 3 January 2008 (UTC)

• I think we should just keep everything metric and have those who want to render maps with funny units do the calculation themselves. ;-) 3247 23:18, 6 January 2008 (UTC)
• Ireland switched to metric speeds in 2005 and the speed signs where thus changed. They contain "km/h" on the signs, to ensure, that people know it's km/h, while signs without that still are mph. I've seen kph, kp/h, and all kind of other funny variations being used, but i reckon km/h can be considered the official unit in metric countries. As for the discussion of added maxspeed in metric or imperial, the speeds really should be added in the default of the country, but the problem, that arises is, when a country changes, all of these speeds have to be updated, so i'd recommend to put a unit on there. Marlow 13:34, 18 November 2008 (UTC)

Nested namespacing

• I like the access namespace idea in general, but I think the nested namespacing could start to explode out of control. What's wrong with access:hgv=yes hgv:maxweight=7.5 ? I have reservations about using access for the oneway tag, too. I'd rather see it namespaced itself (i.e., oneway:motorcar=yes or just a oneway=yes on the way, then oneway:bicycle=no for an exception). --SiliconFiend 19:18, 4 January 2008 (UTC)

• Yeah, I've tried to keep it down to minimal nesting; however, most (all?) of the last section of the proposed tags really feel like they go together, and fit in with the general access restrictions. I am loathe to have that whole set of access restrictions under separate tags (oneway, noexit, date_on,date_off, max_mass,max_height, max_width, max_length, dow_on, dow_off, max_speed, min_speed). I'm definitely open to suggestions, but I think the only real ugliness with it is the current "wild card" *. Would a different wild card (e.g. "all") be acceptable? --Hawke 19:42, 4 January 2008 (UTC)

• I agree with changing the wildcard value from '*' to 'all' - it would make things easier on coders. --Cohort 20:39, 4 January 2008 (UTC)

• Done. --Hawke 21:10, 4 January 2008 (UTC)

Why everything in "access" namespace?

• I might be missing something, but why do all the tags have to be in the same namespace? What are the advantages of this? Gyrbo 22:26, 4 January 2008 (UTC)

• It groups all these closely-related tags together logically, and gives the tag itself more meaning. A tag of "bicycle" or "horse" doesn't really describe how the way relates to bicycles or horses. We are mapping/tagging access restrictions (in this context), we're not mapping a bicycle or a horse. --Hawke 23:15, 4 January 2008 (UTC)

• Has everybody moved either to potlatch or josm presets? sticking access: in front of all the tags means you have to type a lot more before josm auto complete kicks in. Bridleways for example require three tags so the extra typing would be a pain. --Thewinch 00:03, 5 January 2008 (UTC)

• This is a valid objection to namespaces; however, it could be mitigated with minimal changes to JOSM's autocompletion (that is, add a method for partial autocompletion) --Hawke 07:51, 6 January 2008 (UTC)

• Speaking as a programmer, it would be fairly trivial to break on a ':'. That is, you type 'a', and amongst the list, 'access:' appears .. you select it and continue typing to get the next set of completions. --Cohort 13:55, 6 January 2008 (UTC)

• As a new mapper this feature is what immeadately came to my mind, just to find it's already proposed. I have same arguments as Hawke. Japa-fi 06:17, 24 October 2008 (UTC)

Namespaces are difficult

• Using namespaces like this makes it much harder to tag things - without a real benefit. -- Ulfl 00:46, 6 January 2008 (UTC)

• In my opinion, being able to understand a tag without having to look at other tags or guess at the meaning is a real benefit. --Hawke 07:51, 6 January 2008 (UTC)

• I agree. --Cohort 13:55, 6 January 2008 (UTC)

The problem of using a name space here, is that we would break compatibility, or need to have two systems, or need to convert every thing. By just removing access: to every where will solve this issue to a little cost of being harder to understand. I'm in favor of removing it, and don't see it's real benefit Sletuffe 18:02, 22 November 2008 (UTC)

Distinction between different tags could be unclear

It might be very difficult to find out whether a way is access=higway or access=provided. Furthermore, the distinction may not be present in other legislations, e.g. in Germany. I'd prefer to replace highway and provided with a simple yes. Maybe we should also have access=restricted for ways that may be used by some types of vehicles where the exact restriction can't be modelled with usual tags. I don't think access=suggested makes sense; instead, the land should be marked as area=yes, access=*, priority=low (or everything else that's lower than the highway). 3247 23:18, 6 January 2008 (UTC)

• It is not necessary to use all access levels in all jurisdictions. Just use whichever one is more applicable to the relevant jurisdiction. It is meaningless to have a "access=restricted" without saying what the restriction is (and those types of vehicles would need to be added to the vehicle classes or types, if they can't be modelled otherwise). There are still routes (paths) through areas where you can legally go anywhere (the scottish highlands were mentioned), and these routes deserve to be mapped as much as other routes. I agree that those areas would be mapped as you suggest, with the exception of "priority=low", since as far as I know "priority" is meaningless. --Hawke 16:40, 7 January 2008 (UTC)

Relations for access restrictions

To provide details on access restrictions, relations should be used. This makes it easier to add multiple restrictions for the same class of vehicles, e.g. "Mo-Fr 06-09, 16-19; Sa 06-09":

 <relation id="1234" visible="true">
   <member type="way" ref="123" />
   <tag k="type" v="access"/>
   <tag k="mode" v="motorcar; motorcycle" />
   <tag k="access" v="no" />
   <tag k="dow_on" v="1" />
   <tag k="dow_off" v="6" />
   <tag k="hour_on" v="06:00"
   <tag k="hour_off" v="09:00"
 </relation>
 
 <relation id="1235" visible="true">
   <member type="way" ref="123" />
   <tag k="type" v="access"/>
   <tag k="mode" v="motorcar; motorcycle" />
   <tag k="access" v="no" />
   <tag k="dow_on" v="1" />
   <tag k="dow_off" v="5" />
   <tag k="hour_on" v="16:00"
   <tag k="hour_off" v="19:00"
 </relation>

3247 23:18, 6 January 2008 (UTC)

• It seems to me that this means that the relation would have only one member. That seems ... weird, at best. What is the relation between? How is putting the access restrictions on a relationship attached to the way any better than putting the access directly on the way? --Hawke 16:34, 7 January 2008 (UTC)

• How would you tag the above access restrictions without using relations? Seriously, just try to make up a scheme and you'll see how relations can be better for complex restrictions. However, relations should only be used for more complex sets of restrictions. If a simple access:motorcar=yes on the way suffices, it should be used instead. I don't care whether it's strange to call that "relation"; "relation" is just an arbitrary name for a data model provided by the API. You could argue that it's a relation between the way and a set of key-value pairs, though. 3247 00:16, 8 January 2008 (UTC)

• I misread your examples. (my brain interpreted them as one set being for motorcar and the other to motorcycle). Either way, applying multiple date/time restrictions to a single way is outside the scope of this proposal. Feel free to propose the method you describe in a different proposal. --Hawke 19:15, 8 January 2008 (UTC)

Access priorities

Access restrictions could be supplemented with access priorities, e.g. whether a way is a primary, secondary,... route for a type of transportation:

1. primary - The way is part of the primary network of a country or continent. For motorcars, that's currently implied by one of highway=motorway|trunk|primary. Very good speed.
2. secondary - The way is part of the secondary network of a country or continent. Good speed.
3. tertiary - The way is part of the tertiary network of a country or continent. Fair speed.
4. high - Not part of a network but generally preferred for a given type of transportation. Fair speed.
5. medium - Use if no better way is available. Low speed.
6. low - Use of this way should be avoided if possible. Very low speed, maybe taxing.

3247 23:18, 6 January 2008 (UTC)

• I don't see a need for this; these priorities are completely arbitrary and unrelated to access restrictions, i.e. what kinds of vehicles are legally allowed to use a way. --Hawke 16:34, 7 January 2008 (UTC)

• Yes, that's the point: Knowing whether you may use a way is not enough to determine which way you should prefer over others. Sometimes, this can be determined from speed limits, surface material, width, etc. However, this requires that that information is present and complete. 3247 00:16, 8 January 2008 (UTC)

• Usage recommendations are completely off-topic for this proposal. Feel free to make a new proposal to cover them. --Hawke 19:15, 8 January 2008 (UTC)

Taxis

I love this proposal. I don't see taxis mentioned though. Can they be added? Polyglot 19:47, 8 January 2008 (UTC)

Done. --Hawke 22:25, 8 January 2008 (UTC)

are taxis not a part of psv? --Cbm 00:30, 9 January 2008 (UTC)

Are they? I'd been led to understand that psv is bus. "psv" is very much an anglicism, so I'm not totally clear on its meaning. --Hawke 16:41, 9 January 2008 (UTC)

Maximum maxweight

We're going to need another kind of maxweight for Belgium, something like "maxmaxweight": if there's a speed limit sign with "+5t" under it, it applies to the maximum allowed weight of the vehicle, and not the current weight when it passes the the sign. We need a different tag, since a sign like this with a weight limit under it applies to the current weight of the vehicle. But I'm still looking for a better key than "maxmaxweight"... --Eimai 15:59, 17 April 2008 (UTC)

Hmm, I would think that maxweight would be whatever definition is used within the jurisdiction where the tagged item is used. For the US, this appears to be the GVWR, though there seems to be some debate on this. For belgium I think it is similar. Unless Belgium uses two different weight determination methods in the same place, I think a single tag will suffice. --Hawke 20:16, 18 April 2008 (UTC)

Yeah, my "maxmaxweight" would be the same as GVWR (although no-one would understand a tag like that :-) ). Maybe you're correct, the two different weights can't appear with the same signs. A maximum speed or parking restriction with weight limit is always GVWR, an access restriction for road is always the actual weight. But then you need to properly understand the traffic rules of the country of course, and perhaps it's different in other countries, so different tags for the two doesn't look too bad... --Eimai 11:36, 19 April 2008 (UTC)

Restrictions on multiple criteria

Something which occurs quite often here is "no entry for vehicles over 3.5 tons except for loading and unloading". How would one tag that or similar issues?

Note btw that "loading and unloading" isn't the same as "destination", so we might need a tag for that as well... --Eimai 17:14, 21 April 2008 (UTC)

• Complex restrictions would have to done using relations. I remember reading a proposal about it. --Gyrbo 10:37, 22 April 2008 (UTC)

access:maxweight=3.5 + access:minweight:3.5=loading/destination ? Alv 17:34, 3 November 2008 (UTC)

A problem with those huge strings is that they're basically camouflaged relations: where you add all things in different keys with a relation, you just concatenate them all into one string. The latter is almost unreadable as a result. It's also much more easy to make mistakes, especially if you need the same restriction in an area with dozens of ways. --Eimai 19:58, 3 November 2008 (UTC)

I'll have to try to enter some... with current editor support I'd imagine having several relations for one road - several different restrictions - makes things, especially the precedence order, hard to manage. Alv 20:19, 3 November 2008 (UTC)

I have one that is going to be hard to deal with in current models :

• Tagging a way that is forbiden to cars (over 1 ton) AND (over 4m) Read it well, I didn't said (over 1 ton) OR (over 4m) wich is easy. Sletuffe 18:12, 22 November 2008 (UTC)

Removal of "all"

I don't like access:all:max_speed=65mph and similar. If it applies to all, just use access:max_speed=65mph. Otherwise you should also write access:all=no instead of access=no. FedericoCozzi 14:14, 21 February 2009 (UTC)

It's intended that vehicle type always be present. However, I'm going to withdraw this proposal in favor of Conditions for access tags. --Hawke 18:11, 23 February 2009 (UTC)