On Fri, Aug 14, 2009 at 8:26 AM, Martin Koppenhoefer<dieterdre...@gmail.com> wrote: > 2009/8/14 Roy Wallace <waldo000...@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. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk