Proposal talk:Lane and lane group

You could simply use bus=designated, bicycle=designated and so on, as it is already being used for cycle- and footways. This already means that they are the only ones allowed there. --Driver2 22:28, 31 December 2008 (UTC)

Your suggestion is to tag a lane way with e.g. bicycle=designated and nothing else – correct? Access tags would contain all relevant information, you've got a point there. The lane key does allow for values that have a more complex definition, though, even if that is not the case for the current rudimentary set of values. This could, however, be solved with some kind of presets, too. I mainly thought of the lane value as something renderers can handle more easily, considering that =designated can be used for more than one type of traffic. "lane=cycleway => draw as cycleway" is easier than "bicycle=designated and not (vehicle=designated or hgv=designated or horse=designated or ... ...) => draw as cycleway". --Tordanik 13:26, 1 January 2009 (UTC)

No, actually I just meant instead of the implied access=no, bicycle=yes. --Driver2 15:55, 1 January 2009 (UTC)

Ah, of course. Well, I've changed the implications from yes to designated, but I didn't find any definition stating that a designated value excludes other types of traffic. Is this stated somewhere? --Tordanik 17:05, 1 January 2009 (UTC)

Well, it is used for footways and cycleways and those don't allow any other traffic, if not stated otherwise. It may be different in other countries. It's like with many other tags, not defined very well, but from the actual usage you can derive a definition. I guess there are also many ways tagged as footway or cycleway that aren't really footways or cycleway, however that comes from the rather loose definition "mainly/exclusively for ..". It allows for variations in different countries, but also encourages people to use it for just about anything that is not a road and that pedestrians/bicycles can use. The further description of cycleway "If pedestrians are allowed as well.." indicates that pedestrians (and probably other traffic as well) are not allowed by default, but it is not stated clearly. It would be nice to resolve these kinds of ambiguities by defining it properly, however I don't know how, since there is no instance of some kind that does something like that. --Driver2 17:28, 1 January 2009 (UTC)

example

This proposal could do with an example-image. I have trouble understanding how this is supposed to look like together with the ways of type "highway=xyz". --MarcusWolschon 12:34, 7 January 2009 (UTC)

I'll try to add an example soon. --Tordanik 20:45, 7 January 2009 (UTC)

Maybe add how this was tagged to the example-image. --MarcusWolschon 09:11, 13 January 2009 (UTC)

Have you tried opening the .osm file in a text editor? I think it's rather human-readable. If you still prefer it to be included, tell me, but I thought it would just make the page unnecessarily long. --Tordanik 20:14, 13 January 2009 (UTC)

No I have not yet have the time or opportunity to. I cannot run JOSM here while browsing the wiki and...why should you need an external editor to understand a feature-proposal? If one can't understand it in a few minutes by reading the proposal, why should anyone vote in favor of it? --MarcusWolschon 07:20, 14 January 2009 (UTC)

What do you need more, than watching the 2 screenshots to understand the huge benefit? --Cbm 08:52, 15 January 2009 (UTC)

Proposed_features/lane_and_lane_group/Example_01. Let me know whether this helped to improve your understanding of the proposal. --Tordanik 18:55, 15 January 2009 (UTC)

Degree of Generalization

The ongoing discussion about tagging cycle lanes as separate ways or assigning them to an existing (master) highway, has one central reason:

OSM data is tagged for any scale - its rendering is not its main target.

Usually the degree of generalisation depends on the scale: At scales of 1 inch to a mile, single lanes would make a rendered map unreadable; but at scale of 10 inches to a mile, single lanes would be desirable (like shapes of buildings etc.).

In the end, everything must stay maintainable - especially where highways need to be moved or run in curves, it is quite dreary to make parallel lanes stay parallel (not mentioning crossing roads, traffic lights etc.).

Your proposal does not make things easier as there will be separate line segments for each lane. Only if editors keep those "in shape" (grouping?), it could be useful.

My personal opinion at this state is:

* use separate tracks, lanes whatsoever if there is a significant
  deviation from the main track.
* if possible at all, use side sensitive tags (like left:cycleway or sim.).

Regards --RalfG 19:41, 7 January 2009 (UTC)

The proposal doesn't require you to use separate line for each lane if lanes are parallel --Jttt 20:40, 7 January 2009 (UTC)

Crossings

Hi, I take a look on lanegroups in the moment. How do you think, we will handle crossings? Because in crossingsituations there are sometimes additional lanes for left/right turn. --Marco.horstmann 06:21, 21 January 2009 (UTC)

• for crossing-action we can use the "turnrestriction"-relation. e.g. FROM "lane[2] from start-way" VIA "crossing node" TO "lane[6] from target-ways" --Cbm 19:05, 21 January 2009 (UTC)

Feture Request for the lane-Plugin

it would be very useful if the lanegroup-Positionnumber woudl be visible in the lanebox-animation. --Cbm 19:21, 21 January 2009 (UTC)

Could you specify for what purpose this would be useful? --Tordanik 12:40, 22 January 2009 (UTC)

it could be nessecary for connecting ways with lanes. e.g.

(F= footway, B= cycleway, C= carlane, D= divider)

pos-no: -3 -2 -1  0  1  2  3
way1:    F  B  C  D  C  B  F
way2:       F  C     C  F
pos-no:    -2 -1     1  2

how do a routing-program know on which lane i can continue routing?

For that situation the position-no. could be essential. e.g. a type-equal way with the same pos-no. plus +/-1 lane you can be continue traveling. --Cbm 13:36, 23 January 2009 (UTC)

Well, that's a meaning you just made up. ;-) Originally, the lane number was just meant to specify a relative ordering, i.e. it wouldn't have mattered whether you use a=-1 and b=1 or a=-1002566 and b=-126721, as long as a < b. That's because it would likely be assumed that you can go from each lane to every other lane in a lane_group unless there is something (e.g. a lane for other types of traffic) between them that you can not or are not allowed to access.

I do have to admit that I have no perfect idea to specify which lane goes into which other lane, but I don't particularly like a number-based approach, and I expect it'd be quite an effort to properly program routing software for that. Of course we could also use a "succesor" member to specify successors, but it would be painful to edit that manually.

Showing the number in lanetool is probably not enough, because there is also the problem that lanetool's role number shifting (when inserting a lane) currently assumes that it doesn't matter which of the existing lanes it shifts and where it shifts them, and it is designed to hide the whole numbering from you. As described on the proposal page, the numbering was supposed to be eliminated with API 0.6 anyway...

--Tordanik 14:03, 23 January 2009 (UTC)

path a new (generell) lane-type

the same we use path for multidesigneted ways normally we should be able to use it here as well e.g. lane1 with type=path; value= {foot=designated; bicycle=designated; segregated=yes}. --Cbm 16:10, 26 January 2009 (UTC)

sloped curb / curbstones

For wheelchair-routing (See DE:Rollstuhlfahrer-Routing)and for routing for the blind it is necessary to have an information if there is a curb and if it is sloped. --Lulu-Ann 11:11, 20 March 2009 (UTC)

Shouldn't it be more generic relation?

It seems to be very useful relation, and I think that relation may describe not only lanes but whole road. What we may add:

• Road boundary roles: it would be very usable for micromapping in cities.
• Roles for forward and backward directed parts for dual carriage ways.

And resultant relation may be named: type=road. Also type=lane group may be used for ierarchical lane grouping.

Also there is one unsolved problem: no way map divider types between lanes, as they may be crossable, non crossable or crossable only in one direction. --Vovanium 16:50, 1 March 2010 (UTC)

Why not use the associatedstreet relation, and set the members as "lane"? That way, routing software knows that you can cross the street to another house by crossing all the lanes with the exception if there is a barrier between the lanes. --Sanderd17 10:05, 7 December 2010 (UTC)

lane values

Why invent a new scheme for access tagging here? There could be 2 options:

1. inherit the access restrictions from the highway in the lane group (and optionally refine it)

   way #0:

   highway=motorway

   maxspeed:wet=100

   way #1:

   lane=highway

   hgv=no

   way #2:

   lane=divider

   divider=<divider_type>

   way #3:

   lane=highway

   relation #0:

   type=lane_group

   members: way #0 ("highway"), way #1, way #2, way #3

2. completely define/override the access in the lane way/relation

   way #0:

   highway=cycleway

   relation #1:

   type=lane

   lane=highway

   highway=path

   bicycle=designated

   relation #2:

   type=lane

   lane=highway

   highway=path

   foot=designated

   relation #3:

   type=lane_group

   members: way #0 ("highway"), relation #1, relation #2

--Bk 08:58, 21 July 2010 (UTC)