Proposal talk:Access restrictions

Using tags with colons

I've recently started to mark restrictions imposed on long and heavy vehicles. Or wanted to, but can't find a common scheme so I'll drive forward the process for finding one. First up is the method of combining several factors with colons:

As Proposed_features/Access_restrictions lists, there are several types of factors affecting restrictions:

1. The restriction itself (no/destination/overtaking/maxspeed)
2. direction
3. Vehicle group (motorcar/goods/hgv/has-trailer...)
4. Vehicle properties (either the minimum weight or other for the restriction to apply (minweight=3.5) (4a=4b) or a maximum weight allowed to enter (maxweight=3.5))
5. times
   1. Several for each restriction - could be multiple tags
   2. (say 7-18 on weekdays, 9-15 on saturday or with several intervals each day)

Ordering of different factors

I believe that combining these factors in a defined order could be usable, until given a case that can't be represented.

First tries suggest that using the following order might be most suitable, referencing the numbers above:

 2:3:4a:4b:5 = 1   or
 2:3:1:4a:4b = 5   when a time interval is needed

Some known strings would be defined, i.e. dof aka. day of week, could be 0-7 (both Sunday) or the usual Mon, Tue, ...), weekend, workdays. Since time is mostly an interval, if time_yes or time_no is present in the tag, it's value will be in the tag value. Other values can be included in the key, as follows.

The tags might look tedious or cumbersome to come up with, but few example cases should clear the situation. Most restrictions are of the simple type, anyway.

No entry for motorcars on any night between 23:00 - 07:00, except service traffic and with parking permit.

motorcar:time:no=23:00 - 07:00 + 
motorcar:parking_permit=yes + 
motorcar:service=yes

No entry for motorcars on any working day night between 23:00 - 07:00, except service traffic and with parking permit. Absolutely no traffic on Saturday and Sunday 22:00 to 08:00

motorcar:day:workdays:time:no=23:00 - 07:00 + 
motorcar:day:workdays:parking_permit=yes + 
motorcar:day:workdays:service=yes +
motorcar:day:weekend=no

No entry for vehicles of 12 meters or longer, except psv allowed

maxlength=12 + psv=yes or psv:maxlength=none

No entry for vehicles of 12 meters or longer, except psv allowed and destination on saturdays

maxlength=12 + psv=yes + access:dof:sat:maxlength:12=destination

Free access in way direction, only destination traffic from the other direction for vehicles of weight 12t except psv allowed always and heavy traffic allowed on tuesdays

access:forward=yes + 
access:backward:maxweight=12 + 
access:backward:psv=yes + 
access:backward:dof:2:maxweight=none

No overtaking for heavy vehicles with a maximum mass of 30t, except every night 20:00 - 05:00

access:overtaking:maxweight=30 + 
access:time_yes:overtaking:minweight:30=20:00 - 05:00

No access for mass of 30t or over, except destination allowed for vehicles of 30t to 40t on tuesdays 18:00 - 21:00

access:maxweight=30 + 
access:time_yes:dof:2:destination:maxweight:40=18:00 - 21:00

Call for complex signs

Let's try to find suitable ways. Add a picture. I've tried to use the relation model specified on the main page of this proposal for the first column and for the other column the model I started to sketch on this talk page. The best way for different scenarios should soon be evident - which might well be a mixture of the models.

I'm leaving parking restrictions on the street side untagged for now, even if visible in the sign poles.

image	Translation	With relations	"Colon strings"
	Speed limit 30 (zone) Maximum vehicle length 12 meters, but all buses allowed and other longer vehicles allowed with special permission. Samma på svenska/Same in Swedish. No hazardous materials of class A between 7 to 9 and 15 to 18 hours on workdays. No hazardous materials of class B at all other times.	<way id="-100"> highway=residential maxspeed=30 </way> <relation id="-1"> // can be used for multiple ways, say // all similar in one city type=access + (vehicles=all) + minlength=12 + except=bus;permit + access=no <member role="" id="-100"> ... </relation> <relation id="-2"> //can be used for multiple ways type=access + vehicles=hazmat:A + access=no + time=Mo-Fr 7:00-9:00,15:00-18:00 <member role="" id="-100"> </relation> <relation id="-3"> // can be used for multiple ways type=access + vehicles=hazmat:B + access=no + time=Mo-Fr 7:00-9:00,15:00-18:00 off <member role="" id="-100"> </relation>	highway=residential maxspeed=30 + maxlength=12 + maxlength:bus=none + maxlength:permit=none + hazmat:A:no:day:workdays:time=7-9;15-18 + hazmat:B=no + hazmat:B:yes:day:workdays:time=7-9;15:18 +
	No motored vehicles between 22-06 every day, except: driving to premises (destination), service traffic and with residential parking permit 'F' Same in Swedish No parking between 9 to 17 on workdays unless paid for or with residential parking permit 'F'	<way id="-100"> highway=residential maxspeed=30 </way> <relation id="-1"> type=access + vehicles=motorcar + time=22:00-06:00 access=destination <member role="" id="-100"> ... </relation> <relation id="-2"> type=access + vehicles=motorcar + time=22:00-06:00 // this is partly overlapping with // destination but not the same: access=service <member role="" id="-100"> ... </relation> <relation id="-3"> type=access + vehicles=motorcar:parkinglicence:F + time=22:00-06:00 access=yes <member role="" id="-100"> ... </relation>	highway=residential maxspeed=30 + access:motorcar:destination:time=22:00-06:00 + (*1) access:motorcar:service=yes + (always allowed) access:motorcar:parkinglicense:F=yes (always allowed) motorcar=yes is implied so a time restricted destination limits only that? (*1) is theoretically misleading, because the word "tontille" means "onto property" so the destination can't be on the road. This sign was actually erected because 20 years ago some illegal street races were organized on the straight beginning from this sign.
	Maximum vehicle length 10 meters but no maximum length applies to buses on a route, to destination traffic, nor to agricultural or forest maintenance traffic.	<way id="-100"> highway=* maxspeed=50 </way> <relation id="-1"> type=access + (vehicles=all) + length=+10 + except=bus;agricultural + access=destination + <member role="" id="-100"> ... </relation> Access is unlimited, onto which the relation adds that vehicles over 10 meters have only destination access.	highway=* maxspeed=50 maxlength=10 maxlength:bus=none maxlength:agricultural=none access:destination:maxlength=none
	Pedestrian zone, no motor vehicles at any time. Unless you're a disabled person displaying a "blue badge" in your vehicle, or someone loading or unloading (between 06:00 and 10:00). Also, no cycling between 10:00 and 18:00. We're ignoring the no-waiting sign and the rising bollard times for the purposes of this exercise...	Let's not use relations for this. Let's just not, OK?	highway=pedestrian foot=yes motor_vehicle=no motor_vehicle:disabled=yes ¹ motor_vehicle:loading=yes motor_vehicle:loading:yes:times=06:00-10:00 ² bicycle=no bicycle:no:times=10:00-18:00 ² ¹ We probably don't need to specify which disabled badge scheme. The "disabled" condition should be read as "any scheme or none" for OSM purposes. ² Note the sense shift between the time-based loading and bicycle restrictions. We definitely need the ":yes:" or ":no:" or whatever in the key in order to specify what the ":times" are applying to.

One note before we start this: I've also mentioned several times I'm in favour of tags like bus:maxlength=none, so I wouldn't do the maxlength rule with a relation. It's for the more difficult rules like the hazardous materials that relations make it more readable -- to me at least. The relation method is also needed for zonal restrictions, because they have extra metadata that can be valuable for maintaining OSM, like official reference numbers and names.

Basically, I want to give a choice here to let the user decide what method to use. There are places where the tag:tag:tag:tag=value method is better and places where relations are. But, I was mostly interested in defining a "formal access rule scheme" based on relations, and have a method to map tag=value and tag:tag:tag=value to those relations to have a method that computers can easily check whether vehicle X is allowed somewhere without any ambiguities.

So, I'm not arguing if tag:tag:tag=value is better than access relations or not. Sometimes it is, sometimes not. --Eimai 17:29, 5 November 2008 (UTC)

I've modified the table introduction to support this notion. Alv 19:20, 5 November 2008 (UTC)

In the relations examples above, Is see :

• vehicles=motorcar
• access=destination

any reasons not to use :

• motorcar=destination ? ( *or motorcar:oneway=yes if we want to talk about oneway) Sletuffe 23:46, 22 November 2008 (UTC)

I think the main reason for now is to have a clear distinction between the access rule on one side and the vehicle types on the other. But all syntax you see here is preliminary (and also comes from different people), and will likely change. --Eimai 12:36, 23 November 2008 (UTC)

I have some remarks:

1. In "time=24/7;* off" the "24/7" is not needed. If only "off"-values are used in "time" it defaults to be "24/7 on"...

That's reasonable, I've modified it now. Alv 19:49, 30 November 2008 (UTC)

2. In "except" the "permit"-value should be replaced by "permissive"! See access=*!
Same problem in the third relation of the second example. You should use access=permissive instead of access=yes there.

More likely by "private" - there's no general access, the owner (city) doesn't give access to unspecified long vehicles but the local police may issue a permit for some individual transport. Without the sign not even the ... evil intergalactic emperor could give permission. Around here permissive is only applicable to shopping center indoor footways which they may close at will - otherwise it's always private (someones home or fenced and closed), open to public or forbidden to all. Alv 19:49, 30 November 2008 (UTC)

3. The "+*" in "length" could be irritating. Better stick to min and max! I.e. length=min:12 or minlength=12 for your example

I think the "colon strings" should be identical to the relations! So we could convert them with scripts.

First example:

 highway=residential
 maxspeed=30
 access=(no;vehicles:all;length:max:12;except:bus,permissive),(no;vehicles:hazmat:A;time:Mo-Fr 7:00-9:00,15:00-18:00),(no;vehicles:hazmat:B;time:Mo-Fr 7:00-9:00,15:00-18:00 off)

Second example:

 highway=residential
 maxspeed=30
 access=(destination;vehicles=motorcar;time=22:00-06:00),(service;vehicles=motorcar;time=22:00-06:00),(permissive;vehicles=motorcar;parking_license:F=*;time=22:00-06:00)

--Phobie 14:33, 30 November 2008 (UTC)

What we want is complex logic (A OR B OR C) AND D OR E or F

Many "basic" case which can be handled with only the word AND or only the word OR is quite possible to be hosted in one way or node without needs of relations. That solves many cases without relations.

But we need something when we have both OR and AND. What we need here is a language called SQL, but we haven't so we need a way to mimic it. And the simple answers by use "relations" does not, in the end solves the fundamental problems.

Relations will probably help, but if badly used they won't

Has I'm sure I might not be understood, let's have an example :

I want to tag a way that is forbidden to car over 1 ton OR car over 4m long Now, we would solve this by :

• max_weight=1
• max_length=4

Suppose I want now to tag a way that is forbidden to car over 1 ton AND car over 4m long (With words, that means that a car of 2 tons with a length of 3.5m is allowed ) There is no way to tag this with current solution.

Putting this in a relation won't solve the problem either, unless we say that between a way and a relation there is an AND, in which case we could do : my way :

• max_weight=1

in the relation :

• max_length=4

But that might well not be what we need

This might also be very unusual, in that case, we could just "let go". We need more problem case to see if we can deal with it Sletuffe 17:49, 22 November 2008 (UTC)

You don't understand the relations correctly I think :-) The AND problem is solved with a relation -- to stay a bit with the syntax of the examples on the page:

The rule applies to: vehicles that have max weight over 1 and have max length over 4. So that's something in the relation as: "weight=+1", "length=+4", "access=no". The idea is that the access rule in the relation (in this case simply access=no) applies to vehicles that conform to all properties in that relation (weight over 1, length over 4).

The OR rule is just applied by two relations on the same road. --Eimai 20:21, 22 November 2008 (UTC)

Ok, I got it. The end formula is (tag1_relation1 AND tag2_relation1) OR (tag1_relation2) OR tag1 OR tag2

( tag1 and tag2 being the tags in the way itself ) Looks like we can do much with that. Sletuffe 23:36, 22 November 2008 (UTC)

Putting it simply, this proposal suggests a disjunctive normal form: each relation is a conjunct. It is a well-known fact that every boolean formula can be converted into disjunctive normal form, so theoretically this proposal covers all restrictions which are expressible by boolean formulas. FedericoCozzi 14:56, 21 February 2009 (UTC)

How about leaving "brainstorming mode"?

While this proposal has its merits, it won't have a chance of adoption or even proper evaluation until someone creates clean, concise documentation for it. Does anyone intend to do this? If yes, I'd suggest that we compile a table with all relevant "conditions" to be used by both Proposed features/Conditions for access tags and this proposal first to increase consistency (for example, it doesn't make sense to call the same thing weight_per_axle here and axleload over there). --Tordanik 12:54, 26 April 2009 (UTC)

Suggestion for a new scheme

Of course you will never be able to handle all the access restrictions in the world. The goal should be to bring some structure and naming conventions to the current access tags and values and handle special cases a bit better than right now. I did some brainstorming about that subject too, here is how I would handle it …

Edit of 2011-04-26: Since my suggestions became rather lengthy, i have moved them to a separate page: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5

--Flaimo 11:27, 26 April 2011 (BST)

Any life here?

Current system needs some improvement:

1. refactoring : imho lots of the difficulties we currently have arise from the fact that signs on roads/highways mean different things in different countries. So there needs to be a "translation mechanism" to translate "road signs" into OSM restrictions
2. implicit/default restrictions and interpretation are highly complex and may depend on country, landuse, ownership etc
3. some type of highways like path/track (formal/informal) vs unpaved roads are vaguely defined

Please see Talk:Proposed_features/access_restrictions_1.5#Any_life_here.3F for discussion. RicoZ (talk) 11:51, 23 August 2015 (UTC)