User:Santiago1504/MultiLane

This is a draft that is planned to be an official proposal someday.

Scope

Concerning the mapping of roads with multiple lanes several concepts have been mentioned so far. One of these concepts is to describe all lanes by extra tags on one way. As of march 2012 a couple of proposals are under way that try to establish this idea making use of comma(or some other character)-seperated lists (such as Proposed_features/Lane_group and Proposed_features/lanes_General_Extension).

As I don't like the idea of putting that much information into comma-seperated, ugly-to-read and unstable lists I decided to resurrect this old draft I made (and forgot to maintain) some time ago in order to point out some thoughts on the idea of "seperate namespaces for seperate lanes".

I'd like to make clear that the idea behind this proposal has already been mentioned on German wiki pages (WikiProject_Germany/Workshops/Linienbündel), but I could not find an English version yet. In this proposal I'm slightly modifying the syntax that is used on the linked wiki page, as I find my own syntax more intuitive.

What do you mean when you speak of a "lane"?

"Lane" in the context of this proposal has a wide scope that includes not exclusively the following:

• driving lane for cars
• turn lane
• cycleway
• footway
• a line of grass/trees that typically separates the cycleway/footway from the main road (i.e. an avenue)
• parking lane
• a second/third/fourth lane for cars
• ...

How does it work

• The geometry of the complete road including all lanes is described by only one way. The road itself is tagged as we do it right now (highway=whatever) making this scheme compatible to what we have right now.
• Every extra lane gets it's own namespace that is tagged by right:<n>:xxx and left:<n>:xxx where <n> is the lane's number counting from the middle of the road to the right or left side beginning from 1 (the middle of the road might be denoted by 0) and xxx are any tags that are needed to describe this lane. These tags can be some new tags described below as well as more or less any present and future tags that are suitable for highways (e.g. highway=cycleway) including access restrictions, width, surface, speed limits, ...
• Extra tags: to denote any non-trivial nature of any given lane I propose to use the tag lanetype which may have the values: standard, througth, rightturn, leftturn, cycleway, footway, greenlane, parking, ...

Simple example

Let us regard a secondary road with one lane for cars for each direction that on the right side has a parking lane, a line of grass and a combined foot- and cycleway. You would add the following tags:

• highway=secondary
• left:1:lanetype=standard
• right:1:lanetype=standard
• right:2:lanetype=parking_lane
• right:3:lanetype=greenlane
• right:4:lanetype=footway
• right:4:bicycle=designated

Sophisticated examples

up to come (I don't have time to do that, so please feel free to help --Santiago1504 22:51, 5 March 2012 (UTC))

Benefits of this concept compared to comma-seperated lists

• far easier to read
• probably easier to edit
• more stable because the lane order is explicitly defined by the parameter <n>, not just implied

"You will need to change numbers again and again to add just one lane"

I propose to use some smart kind of alphanumeric ordering of the parameter <n> in order to be able to add lanes without having to change the numbers of outside lanes. So if lanes right:1, right:2, right:3 and right:4 are already present and a lane is to be added between right:1 and right:2 it could just get the number right:1a. This works because in alphanumeric ordering it is: 1 < 1a < 2 < 3 < 4. (This will not cause subsequent troubles for huge roads with more than 9 lanes because due to alphanumeric ordering you can tag an arbitrary number of lanes.)

Additionally one could only use e.g. odd numbers for lanes when roughly editing a street in first place. If one later wants to add an extra lane somewhere in between one can still use the free even numbers and usually won't have to change the other ones.

"Your scheme depends on the direction of way; I'm afraid this will cause trouble when switching directions"

JOSM (tested with 1607 long ago) can already correctly switch the direction of a way AND update the tags needed for this scheme. So this scheme is already compatible with JOSM. Anyway the rules are more than simple: you only need to replace 'right' by 'left' and 'left' by 'right'.

As I don't use any of them I have no idea how Potlatch and other editors behave on this.

Merkaartor does not reverse tags automatically, as of December 2009. Potlatch doesn't either, as of November.

any news regarding this? --Santiago1504 22:50, 5 March 2012 (UTC)

ToDo

• add more examples
• make this an official proposal

I won't have time to do so in the next year or so. If anybody likes my ideas please feel free to occupy them and bring them to vote! --Santiago1504 22:58, 5 March 2012 (UTC)