Talk:Computing access restrictions

Let the discussion begin!

Restrictions on multiple conditions

What about a method like used on Proposed_features/Access_restrictions: the idea is to make a relation syntax for access rules, and to have a proper way of translating the tags we now have like bicycle=yes into this relation syntax -- as we need to look for a relation solution anyway to get more complex restrictions.

The idea is than that the access algorithm works like:

• translate tags to relations and add those to the access relations of which the way is a member
• get input from the user (if known) (vehicle type, vehicle size and weight, time of day and date, weather...)
• work out in which country that way is, and use that to load the set of access translation rules (implied restrictions, the vehicle types that have meaning in that country, etc) that are valid in that country.
• answer the question whether you can enter a road with "yes" or "no". If we have insufficient data (we don't know the time for example): present both to the user.
• also give the extra conditions (maximum speed, allowed to overtake other cars, ...) that you have to obey on the way (again, when it varies and we have insufficient info, present all options to the user)

Of course, this needs a lot of work to be defined, and can be quite hard in practice:

• what's a moped in country X could be classified as motorcycle in country Y. This is not straight forward to solve.
• if a road can't be driven on when there's snow, how could a router know if it can route over it or not when it's not clear if there's snow or not when calculating the route.
• and much more of these...

-- Eimai 12:54, 21 February 2009 (UTC)

Frankly, I do think that it is very complex and yet won't be enough. I come from a mathematical logic background, so I always use that language. That page proposes a sort of boolean logic for restrictions, where access restrictions are expressed as formulas in disjunctive normal form: each relation is a conjunct, i.e. it applies only if all its conditions are satisfied. If a restriction relation applies, then some properties hold (e.g. it's oneway, or private). What I would propose is even more complex but ultimately simpler: let's define a special logic whose connectives are AND, OR, etc. and whose predicates are access mode attributes (e.g. vehicle, car, etc.), properties (e.g. length, occupancy) and time (monday, night, etc.): the result of the formula should be an access restrictions, e.g. private, yes, designated. We should then define a semantics for that logic, that is an algorithm for evaluating such a formula in a concrete setting (a specific vehicle at a specific date/time) which yields the corresponding access restriction. That is, a "generic restriction" must be a logical proposition of the form R(vehicle, time) such that, if I evaluate it with a specific vehicle V and a specific time T, R(V,T) = yes (or no or designated or whatever) FedericoCozzi 15:08, 21 February 2009 (UTC)

What do you mean with "present both to the user."? In a map you could have hovering notes but in a router there is no way to ask the user for any significant number of the millions of ways searched for a usual route. --MarcusWolschon 09:45, 23 February 2009 (UTC)

You have to give all the possible options to whatever program wants to know the access restrictions. This can be the gps in someone's car displaying both options when getting to such a road, or a router that could ask the user additional information when required (or let it just do a "safe assumption"). But if you can't tell from the parameters given (e.g. vehicle type, date) whether you can enter a road or not, or what its maxspeed is, you just have to give all the options that are left back to the program that requests it. --Eimai 12:49, 23 February 2009 (UTC)

The existing solution I've tried have hidden all the options in the device settings (with safe or sane assumptions), except for the permission to use toll roads, for which some devices present a question when the optimal route does include toll roads. Even the toll road avoidance is accessible only through the settings menu in some devices. Sane assumptions are left to implementers, for now, but a reference page could be created for them, if anyone wants to do so. Alv 16:11, 23 February 2009 (UTC)

Pyramide Structure

Isn't this more readable than the example on the front page?

access=*
vehicle							foot
motor vehicle						unmotorized vehicle	foot	bicycle	horse
motorcar	psv		goods	| motorcycle	moped	horse
	taxi	bus

This is only a suggested structure. --Skippern 15:40, 21 February 2009 (UTC)

This is definitely more readable but it has a drawback: the tree structure is not enforced. In your example above, horse inherits both from vehicle and from foot. While this may be a mistake, the problem remains: such layout does not enforce the tree condition, i.e. that every node as at most one parent. See below for another layout which however has the same problem. FedericoCozzi 17:56, 21 February 2009 (UTC)

It was meant as an example, if you tilt it 90degrees, than it can be read similarly as your tree, I don't know how to merge rows in wiki tables, but you can play around with it. The most important is to have an easy readable illustration of what you are thinking, that can easily exported and edited to fit various countries. I don't like that bullet list when we are going to illustrate various systems though. I see very well what you are thinking, I am only trying to find a better way to illustrate it. --Skippern 18:02, 21 February 2009 (UTC)

Thank you very much for your comment, I am glad that someone understood what I wrote and wanted to improve on it! I think that I should completely remove the table and instead draw a real tree with a graphic program. Stay tuned for an improvement. Thanks for your advice. --FedericoCozzi 21:55, 22 February 2009 (UTC)

Another lay out with same goal

I made a related proposal here. Basically my point of view is that any grouping system must be computable by software, otherwise it's useless. Moreover, a routing software is not really interested in the grouping system per se, but only in its effects on access restrictions: if I write a routing software, my only question is this: "can a taxi drive on a Belgian highway=tertiary which is tagged as psv=no?" I provided a generic algorithm which could work in any country and which needs, as parameters, a grouping system and a set of default access restrictions. However the algorithm can work only if the grouping system is a tree, not a directed acyclic graph. FedericoCozzi 14:31, 21 February 2009 (UTC)

The grouping system we created here is also (mainly?) intended for access restrictions. As of now, if you look closer, it is a tree. But the representation look more like a star for cosmetics reasons. As of computable, I don't see why it wouldn't be. But showing it as a picture is much more easy for people to understand what "vehicule=yes" will mean if they find "vehicule" in a tree. Use of this tree will of course need a more computable form, just like the table you created. The goal here is to define keywords which define a precise "moving thing". When well defined, it would be easier to apply restrictions. Sletuffe 11:07, 24 February 2009 (UTC)

I'm moving to Talk:Computing access restrictions in order to gather the discussion in one place, I'm copying this part there as well Sletuffe 11:31, 24 February 2009 (UTC)

From Proposed_features/Any_moving_thing_grouping_system :

Please keep the discussion here so we don't monitor 3 pages Sletuffe 11:26, 24 February 2009 (UTC)

Nice that you put boats into the equation, though you should differ between large ships, fishing vessels, and private vessels, as they might have different restrictions (specially in ports, not so much on waterways). Taxi might be put under psv, or as motorcar. Agricultural might be further divided, would rather rename it to special purpose to include forestry, mining, etc. Do not see much point in dividing man and woman though. Isn't Wheelchair the same as handicapped? I disagree that a skier is under a vehicle group, he should rather be classified as pedestrian, specially when talking about cross country. Also, bicycle can be both a veicle or a pedestrian, depending on national definitions. --Skippern 14:08, 2 March 2009 (UTC)

• The boat was just an example, I'd hoped that if the idea is good, much aware people (like your name or user page suggest ;-) ) might contribute the leafs bellow the "boat" category.
• For the taxi case, I would first put it in the common denominator of countries (ie : in it's own leaf) but that can be discussed. In france we have roads where taxis are allowed and Buses aren't and vice-versa. I don't mind tagging taxi=yes and bus=no instead of psv=yes if France is a special case.
• For man and woman, I went far ! To show the tree idea might even be extended to toilets. In a general pedestrian area, I would tag foot=yes, but a men's toilets or a mosque would be tagged as access=no + man=yes
• handicapped I didn't add this one, I don't know what Phobie meant by that
• skier, no problem, might me moved to another branch. But not pedestrians, as for example ski slopes are forbidden to pedestrians so I would tag them access=no + ski=yes (well that case is tough as it's season variating then access=no + ski:winter=yes + byclycle:simmer=yes or something like that )
• For country dependancy, my point is still to give, in one way or another, the database a hint about country specific values. Since countries with different juridiction about bycycle exists, I would put them appart and tag bicycle=yes+foot=yes for those cases. (Either directly in the database, or as interpretation defaults by routing software or as per-country post-processing of the osm database) Sletuffe 16:24, 2 March 2009 (UTC)

Just to continue on the skier, most cross country ski tracks in Norway are footways, paths, or roads of less significance and access restrictions in the summer time, thus the skier should be allowed where foot=yes is tagged unless a ski=no is present, I am not saying that ski=yes should imply foot=yes either. In Brazil where I live, snow is non-existent so the problem about the skier is not valid here.

Boat access should be divided as follows: ships, fishing vessels, yachts, sailing vessels, with the values yes, no or isps. Yachts would mean private boats such as small cabin cruisers, open dingies, or yachts. ISPS refers to the International Ship and Port Facility Security regulation, which all international shipping have to adhere to, at least in most of the world. --Skippern 17:45, 2 March 2009 (UTC)

Alternative evaluation model

I put an alternative model on the Key:access page before someone pointed me to this page - I'll remove it from there, the text is included below. AFAICT the difference is that with this model, access=no + some other tags gives the same results independent of the highway type i.e. highway default access is more easily overridden. This was a bit how I expect access tags to work, but maybe it has drawbacks, I'm not sure yet. The algorithm can be simplified because the strict separation between transportation modes and transportation mode categories is likely not needed. It is very limited in access values because I wrote it for gosmore which AFAIK only supports these 3 values when routing, other values are mapped to those 3. --Cjw 23:18, 27 August 2009 (UTC)

The result of evaluating access tags for ways following this method is:

• for each transportation mode (so not for categories), two values:
  • forward: yes/no/destination
  • backward: yes/no/destination

1. initialize the result such that it allows any tranportation mode (yes for all)
2. look up country specific defaults for this highway type, and apply them in the order of explicit tags, see below
3. evaluate oneway tag, if present:
   1. if oneway=yes, apply vehicle:backward=no, see below
   2. if oneway=-1, apply vehicle:forward=no, see below
4. for each category: access, vehicle, etc. from generic to specific:
   1. if <category>=x, apply x to all modes in <category> for both forward and backward
   2. if <category>:forward=x, apply x to all modes in <category> for forward only
   3. if <category>:backward=x, apply x to all modes in <category> for backward only
5. for each transportation mode, in any order:
   1. if <transportation mode>=x, apply x to that mode for both forward and backward
   2. if <transportation mode>:forward=x, apply x to that mode for forward only
   3. if <transportation mode>:backward=x, apply x to that mode for backward only

example

A highway=path is tagged access=no, bicycle=designated, foot=designated. Did the tagger mean:

• horse=yes or
• horse=no  ?

With the above model, the result is horse=no.

Access inheritance given existence of Lanes

This is a topic area I haven't really seen explored. It took some digging to find this page, which essentially is the how to hierarchically compute the access for mode of travel X, given tags on object Y. As this topic has matured, however, so has a fairly locked down proposal to determine additional access characteristics per lane on a way, as seen in Lanes.

Consider a typical motorway in the United States, with an HOV restricted left lane, and additional (freely traversable lanes).

Bayshore freeway, Sunnyvale, California, USA Oh, and for the purposes of this discussion, let's NOT worry about the time restrictions.

So, we will assume this is a four lane freeway whose leftmost lane is restricted to hov and bus at all times.

What we really want here is for ONLY buses and hov vehicles to be able to use the left lane. So, now we get to the heart of the matter, and the reason for this question. What happens, then, if we're explicit in other logical ways with respect to 'lanes' - which 'wins'?

 highway=motorway
 oneway=yes
 lanes=4
 motor_vehicle:lanes=no|yes|yes|yes
 hov:lanes=designated|yes|yes|yes
 bus:lanes=designated|yes|yes|yes

(I might expect: regular motor vehicles and all children are not allowed to use the left lane, except for busses, and HOV, which are. Everything in the access lists is explicit.)

 highway=motorway
 oneway=yes
 lanes=4
 motor_vehicle:lanes=no|||
 hov:lanes=designated|||
 bus:lanes=designated|||

(I might expect: equivalent to the first example, because way access defaults on a United States motorway happen to work out that way, and because motor_vehicle:lanes would be evaluated before hov:lanes and bus:lanes, because it's higher in the tree.)

 highway=motorway
 oneway=yes
 lanes=4
 motor_vehicle=no
 motor_vehicle:lanes=no|yes|yes|yes
 hov:lanes=designated|yes|yes|yes
 bus:lanes=designated|yes|yes|yes

(I might expect: this should ALSO be equivalent in results, but only because the way-access 'motor_vehicle=no' would be executed before lane specific access for motor_vehicle, which in turn would be executed before hov:lanes and bus:lanes.)

Has a prescriptive statement (for navigation engine purposes, etc.) been made yet about evaluation order for lanes: specific access?

Skybunny (talk) 07:12, 27 September 2014 (UTC)