[OSM-talk] [Fwd: Re: Proliferation of path vs. footway]

Roy Wallace waldo000000 at gmail.com
Fri Aug 14 00:46:24 BST 2009


On Fri, Aug 14, 2009 at 8:26 AM, Martin
Koppenhoefer<dieterdreist at gmail.com> wrote:
> 2009/8/14 Roy Wallace <waldo000000 at gmail.com>:
>
> but this is not real "map"-information but it is legal information you
> could also get from different sources. If a way is legally a cycleway,
> all the laws and implications in that county apply automatically.

highway=cycleway (and footway) has inconsistent implications. This is
the problem, and this occurs even within areas with the same law. I
think this makes cycleway an inherently bad tag (as currently used).

You suggest we use the wiki to supplement the database - that's fine,
BUT within the database highway=cycleway must mean the same thing as
highway=cycleway. That's called consistency. Putting extra stuff in
the wiki *cannot* give the database consistency.

So I should probably now propose a solution rather than just criticise others':

You make the point that we should be entering "real map-information"
in the database. I agree, and interpret this as meaning the database
should represent the situation "on the ground" (and not necessarily
aim to capture also the situation "in the law books" - unless this can
be done in a separate namespace, e.g. law:*=*, as others have
suggested).

So, how about the following consistent scheme?:

1) A yes/no tag that indicates signage
2) A yes/no tag that indicates legality (independent of signage) -
feel free to not put this in the database if you don't want
3) A yes/no tag that indicates a subjective recommendation/suitability
judgement (should be discouraged in favour of width=* and surface=*,
but will often still be useful)

As others have requested, this would separate the "legal information"
from "what's on the ground". These tags could be called:

1) "*=designated/designated_no" (would require slight change to wiki
definition and introduction of designated_no)
2) "*=yes/no" (seems to reflect current wiki definition)
3) "*=suitable/unsuitable" (don't think there's currently a tag for
this, probably because it's not verifiable - but people probably often
mistakenly use *=yes/no for this)

These could be used as values, with the mode of transport as the key,
i.e. *=designated/designated_no, *=yes/no, *=suitable/unsuitable (this
should look familiar). But then you can only use *one of these values
per mode of transport*, which is problematic.

To avoid this, I would prefer a nicer structure (suggested recently in
relation to the school_zone proposal), with keys as keys and values as
values, as in:
1) designated:vehicle=*;yes/no
2) access:vehicle=*;yes/no
3) suitable:vehicle=*;yes/no

The general format, which could be extended to all kinds of access
restrictions, is:
<X>:<K> = <L>;<V>, where
X = the standard tag (maxspeed, or access, or bicycle, etc.)
K = the kind of condition
L = the value of the condition (in an appropriate format according to K)
V = the value for <X> (e.g. yes/no, speed in kmph, etc.)

I realise this would involve a big change in syntax - but as soon as
people start asking for the ability to tag more than 1 aspect of a way
(say, legal vs suitability vs signage) in relation to, say, bicycles,
you need to put "bicycle" in the value field. Let me know if anyone's
interested in a proposal in this format. Conversely, let me know if
I'm wasting my time.

Anyway, if you want to know if you can ride your llama down the
street, you need to refer to *:vehicle=llama;* or infer it from the
values of the other tags. IMHO, this is the best we can do, and is
better than requiring software to look up the default value for
llama=* on a cycleway in Peru from the wiki.

Using the above scheme in combination with highway=path,
cycleway/footway would become unnecessary, but could still co-exist
with their current definitions (which is something along the lines of
"who knows?").

Apologies for bashing everyone over the head with another scheme, but
I couldn't help myself.




More information about the talk mailing list