[OSM-talk] Changes to Key:access wiki page

[Tobias Knerr]

Christiaan Welvaart wrote:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags
> 
> This proposal does not seem specific enough. Shouldn't it list exactly
> which simple keys can be modified this way, especially for the
> :<transport mode> extension?

There is no need to list keys because it can be used for every
access-related key. Nevertheless, I'll probably create a more detailed
page about conditional tagging in the future which can include base keys.

> For example, with this proposal it is
> possible to create both bicycle:backward and oneway:bicycle, while I
> would really prefer to only have the former.

If we don't try to abolish oneway completely, I would prefer the latter
in most situations.

My opinion is that a base key should not be able to remove a restriction
introduced by another base key. For example, hgv=yes should not be able
to remove a maxweight=3.5 restriction. Similarly, an access tag (such as
access:bicycle:*=* or short bicycle:*=*) should not be able to remove an
oneway tag.

This principle makes understanding and evaluating the tags much easier,
imo. To get a value for maxheight, you check all maxheight:* keys and
nothing else. The same goes for oneway and all other base keys.

One example why I think oneway and access (including the transport mode
and category tags) should not affect each other:

In front of a station, there is a road that must not be used by motor
vehicles except busses. This road also is an oneway road, with no
exceptions. Therefore, I consider it natural to tag this
- oneway = yes
- (access:)motor_vehicle = no
- (access:)bus = yes
This can easily be understood if oneway isn't influenced by the other tags.

If, however, we consider oneway=yes just another way of saying
(access:)vehicle:backward=no, then we suddenly have a problem: Neither
of the two conditional expressions "vehicle:backward" and "bus" is more
specific than the other one, so we cannot determine whether the yes from
"bus" or the no from "vehicle:backward" is relevant here.

To sum up: Yes, both bicycle:backward and oneway:bicycle are
direction-dependent restrictions for bicycles. However, they are still
different because only oneway:* keys should be able to overwrite other,
less specific oneway keys.

In practice, this means that :backward will rarely be useful for
bicycle, it makes more sense in combination with maxspeed and sometimes
other base keys.

>> As evaluation is the aspect that needs to be documented (routing graph
>> creation is up to the application), I believe forward/backward shouldn't
>> be introduced or documented separately but instead as a part of
>> conditional tagging.
> 
> Is it really a problem if work is one in this respect as long as it does
> not contradict the conditional tagging proposal?

There were some suggestions to use brackets instead of colons for this
(such as bicycle[backward]=no or hgv[06:00-10:00]=delivery) because
conditions are not what colons have been used for before - for example,
they don not have a defined order.

Probably, though, colons are better anyway because using different
syntax for different postfix semantics would only lead to confusion and
inconsistent uses...

> A (transport mode) category is simply a group of transport modes and/or
> other categories that are sometimes treated similarly regarding road
> access (by law).

Ok, thanks, I now understand what you mean. I thought it had something
to do with the access values (forestry, delivery and so on), because
except for destination, they are not mentioned by your description at all.

Tobias Knerr