Wouldn't this discussion benefit from a summary of the use cases we are
trying to address? I see multiple semantics being suggested for the
lanes tag, and at the end of the day we will have to choose one.
* Renderers such as mapnik might want to reflect the number of lanes in
the width of the line
* Routers might use the lane count (along with many other attributes) in
heuristics for the road capacity and travel time
* Other renderers might try to derive a "picture" of the road or junction
Sometimes it's about "what is painted on the road"; sometimes it's "how
many vehicles fit across the road"; sometimes it's something else.
If we choose one definition for the lanes tag, and allow the other
definition to be derived by combining lanes=* with something else, then
everyone could be happy. To choose one definition above the other
options we should look at which is likely to be the most useful to the
most users (in the broadest sense). The minority use cases will then be
able to derive what they need by combining tags.
As a simple example, on a motorway with 3 normal lanes plus a hard
shoulder, we could have lanes=3 and shoulder=yes in one model, or
lanes=4 shoulder=yes in another model. In either case, provided the
semantics of the tags are applied consistently, one can satisfy all the
use cases I listed above. If there are narrower lane
This is a classic case of a discussion dragging on for hundreds of posts
discussing different points of view (and there's nothing wrong with that
of course) without a common cause to allow the discussion to converge.
If we only discuss how to put things INTO the data without a view of how
we (and others) might want to USE that data, we will end up with nobody
being happy. If this situation arose on my project I would be having
SERIOUS discussions with the customer - maybe the project should never
have been started.
Colin
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
