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

[Christiaan Welvaart]

hi,

I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - 
only to document current (best) practices.


* Transportation modes

The transportation mode hierarchy picture is replaced by a simple outline, 
because the picture was not integrated in the text and too small to read 
on the page itself (could both be fixed), and having to figure out how to 
modify the picture complicates editing of this wiki page. The hierarchy is 
however the only definition of several transportation mode categories so 
quite important. IMHO the picture can be re-added but not replace the 
outline.

Some transportation modes were listed in two unrelated categories. This 
needlessly complicates determining the correct tags for a real-world 
situation. Specifically, the meaning of access tags becomes very unclear 
if they belong to unrelated categories. There was apparently a good reason 
for doing this but I have not found a clear explanation. (Note that 
*=agricultural is not necessarily defined by this hierarchy, only tags 
like agricultural=no.)

Added a separate tag for cars, because AFAICT any routing app computing 
routes for cars uses this transportation mode. If routing would be done 
for 'motorcar', ways tagged as hazmat=no, for example, could not be used 
because the motorcar *could* be a hazmat vehicle. Maybe the actual tag is 
not needed, in which case the description can stay but the tag removed. 
BTW what is a hov?

Added a tag for low performance mopeds, because in some countries they are 
by law neither a bicycle nor a true moped.

Separated land (road), water, and rail based transportation because they 
can be treated separately(?).


* Direction specific restrictions

I listed :backward and :forward postfixes for access keys but apparently 
forgot explicit descriptions. The examples should be enough for now. Some 
roads (around here at least) have complicated oneway restrictions that 
cannot be modeled with oneway= and cycleway=opposite*. The postfixes allow 
specifying any restriction (yes/no/destination/etc.) for any 
transportation mode in either direction.

I'd like to deprecate cycleway=opposite because it is used for roads that 
have neither a cyclelane nor a cycleway in that direction, so using a 
cycleway tag does not make much sense.


* Evaluating access tags

In order to know the meaning of a set of access tags on a way with some 
highway tag (in case of roads), it is necessary to define how access for 
each transportation mode can be computed from these tags. I added a 
section about this which hopefully matches current tagging practice. It 
does not include time-based, height, width, or weight restrictions so it 
is certainly not yet complete. Many of the values listed at the top of the 
page are also missing. The idea is that this model links tagging to 
routing so if it used, while currently AFAIK one needs to find out how a 
router computes access and tag accordingly or accept broken routing in one 
or more routing engines.


     Christiaan