[Tagging] Feature Proposal - Voting - lanes General Extension

[Tobias Knerr]

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