On 08/02/2012 13:40, Martin Koppenhoefer wrote:
6. building:levelPlan=* What each storey is used for, Examples: 0-2:
shop, 3-12: residential; 0: restaurant, 1: residential; -1: unused, 0:
lobby, 1: restuarant, 2-12: offices, 13: unused, 14-66: offices
-> missleading key (one would expect a link to a level plan IMHO). Why
should we suggest a key that is crying for multivalues? We don't use
capital letters in key names (see beginners guide, 1.4.1). This could
become:
building:level:0:use=restaurant building:level:1:use=residential
Another area crying out for this multi-value approach is the "lane
group" business, which has been going round in circles for a long time.
lane:1:access=no
lane:1:psv=yes
There you go - an instant bus lane.
lane:3:minoccupants=2
Gives you a carpool lane.
lane:3:maxwidth=2
Lane with width restriction
lane:2-3:intended_direction=turn_right
lane:2-3:destination=London
lane:2-3:dest_ref=A2
Two lanes for turning right on the A2 towards London - information only,
not affecting routing. Side-effect: lays the foundations for improved
routing instructions.
Existing tags can easily be reused, now applying at the individual lane
level, possibly explicitly overriding tags at the way level. Just needs
agreement on a system for numbering the lanes (outside-to-inside sounds
OK, starting at one for the normal lanes, then lane zero can be the hard
shoulder).
I have not got involved with the recent discussions about lane groups
because as far as I can see they are all overly complex to understand
and implement. A standardised approach to array-valued tags is the way
to go IMHO. If we are prepared to discuss changing the basic tag syntax,
we could think of "lane[2]:psv=yes" but that would have a lot more impact.
Colin
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
