I've not participated in this discussion for a while due to distractions
such as FOSSGIS and the Garching 3D Workshop.
Nevertheless, I'd like to take this opportunity to do two things before
the voting period ends: Clarify what I was talking about in the first
place, and then explain why I no longer think that it is necessarily a
better idea than what has been defined as part of this proposal.
On 07.03.2012 09:22, Martin Vonwald wrote:
So you want all legal restrictions depending on driving direction
using forward/backward, but not legal restriction, that applies to a
physical part? It's getting a little tricky here ;-)
My suggestion was to use left/right suffixes for everything - physical
and legal attributes - referring to placement relative to the road
centre line.
As I consider lanes physical entities placed at an offset to the left or
right of the road centre line, this would have meant tagging lanes with
:lanes:left/right, rather than :lanes:forward/backward.
I also suggested that everything - physical and legal attributes - that
depends on driving direction should use forward/backward. My explanation
probably ended up somewhat confusing because it's hard to find an
example of a physical attribute that changes depending on the observer's
driving direction, so I put more weight on the legal-physical
distinction than I intended.
Anyway, both the forward/backward and left/right modelling have their
respective drawbacks. Two weeks ago, while working on some lane-related
features for 3D rendering[1], I focused on the suitability for either
routing or rendering applications. A left/right distinction lets
renderers ignore local traffic rules when determining the physical lane
layout, and this - along with philosophical considerations - is still
something I see as strong point in favour of this approach.
However, this shortcut for determining the physical layout only works if
the lanes are ordered from innermost to outermost lane, rather than
left-to-right. I realized that for mappers in some countries this would
be inconsistent with the writing order of the lane strings in the tag
value. And, of course, some "lane preview"-style implementations in
navigation apps may be able to benefit from the forward/backward
approach. So I'm no longer really certain which approach is best, and
think that the proposal's choice might have some merit after all.
To sum this up, it's worthwhile to give this proposal a try.
We still need a good way of handling two-way lanes, some kind of tagging
for lane categories and a definition of lane connectivity, but as I
understand these issues are to be addressed in future extension proposals.
Tobias
[1] http://tobias-knerr.de/upload/FOSSGIS12_lanes.png
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
