Proposal talk:Lane group

Comments made during Draft phase

A number of comment were made to this proposal while in the Draft phase. As a lot of things have changed since these comments were made they are no longer reflecting the current proposal. It concerns the comments from "Does not help routing software" to "Separating forward and backward lanes" which are therefore now partly irrelevant (but did influence the development of the proposal). --polderrunner 20:11, 3 February 2012 (UTC)

Does not help routing software

While this proposal may seem more readable than Proposed features/Turn Lanes, it is just a different notation, and does not solve real problems of that proposal. For example, software still has no means of determining, which ways at a crossing are "right turn", which are "through" and so on. I'd like to see that addressed as well. --Zverik 05:43, 20 January 2012 (UTC)

I don't understand what you mean by "no means of understanding ..". Each lane is precisely described. If the third lane value is 'sr' this means that the third lane from the left is a 'straight-through and right-turn' lane. Absolutely unambiguous. The software then knows to draw (at least) three lanes and paint a corresponding arrow symbol (up and right arrows) on the third lane. You don't need any complex logic to compute that result (unlike in your proposal). --polderrunner 22:00, 20 January 2012 (UTC)

To paint lanes, you don't need any logic, you're right. But imagine youself a routing software. You need to get to way B from way A, and tell a driver which lane he should take. So, you know arrangement of lanes, but how you determine, whether way B is "right turn" from lane A, or is it "through"? This may be trivial on regular 2-by-2 crossings, but on T-like intersections and something like this it is not obvious at all, you cannot derive it from angles or highway status. --Zverik 07:22, 21 January 2012 (UTC)

Maybe in such rare cases each letter of line direction could be accompanied by an additional number. This way we could differentiate between two different left turns. Your example could be tagged s,s,l1,l2. Another example - s,s,L1,L1L2.--Arturek 14:59, 21 January 2012 (UTC)

First of all such situations are actually quite rare and we should probably not invest too much effort in caring for these odd cases. Using relations is in my opinion overkill (response to Zwerik). Your solution using l1,l2 or r1,r2 would be usable. I have been thinking of a similar solution distinguishing between a hard right-turn and a soft right-turn (coded as 'zr'). The tagging could then look something like s,s,zr,r (not perfect but usable to guide a driver). Another situation that may be more common is having two right turns in quick succession where the driver must select the right-turn lane before the first crossing even if he is only going to take the second right turn. This could be indicated by a double 'rr' representing a double right-arrow symbol. --polderrunner 21:43, 21 January 2012 (UTC)

I don't consider your second 'comment' as appropriate and I may delete it. Please stay serious when posting! --polderrunner 22:00, 20 January 2012 (UTC)

The second comment is exactly on point, because it points out the major flaw in the proposal: the value notation is so complex, only german mappers and programmers will understand it. Even after reading the wiki page. Also, this is the first time I encounter tags inside values. --Zverik 07:22, 21 January 2012 (UTC)

Very good idea

I support your proposal as it allows lane mapping in an intuitive way. Some ideas/remarks:

• For now, parsing/validating may be a bit tricky as every part may be omitted. I suggest, to prefix them: flow:aaa, type:bbb, dir:ccc, restr:ddd. Also for humans, this makes reading+understanding easier.
• For aaa, + and - are probably easier to understand: - could represent backward, +- two-way driving, …
• Instead of using , as fixed separator, separators could be used to denote the lettering on bottom between the two lanes: , for a broken line, | for a unbroken line, … -- Simon04 13:29, 20 January 2012 (UTC)

That are some very interesting ideas you are suggesting. I don't think parsing should be difficult, the chosen symbols are unique and actually not position dependent. But see below for a more parser-friendly variant. The thing I like the least are the prefixes. They make the tag rather long and may actually detract from readability (especially if only half of the tag is visible in your favourite editor). However, I admit the system of sub-fields may not be ideal either. Below is a modified idea for the lane value using some of your ideas addressing this problem avoiding using hyphens as field separator. I have incorporated the idea of using '-' and '+-' for flow direction (replacing the 'aaa' field. Concerning using , and | for lane crossing restrictions is also good. However it needs a bit of modification to allow for lane crossing in only one direction (lanes separated by a solid line and a broken line). The commas serve as separator as before. A '|' before the comma means that crossing towards the lane to the right is forbidden, a '|' after the comma that crossing to the left is forbidden. A concern is that the '|' character next to lowercase 'l' is not very readable in some fonts. Maybe another symbol like '#' could be used? I also added an alternative to the 'bbb' field using the ':' as a qualifier. The main disadvantage of this variant is that it cannot cover lane specific restrictions except for the lane to lane crossing restrictions. Not sure if that is good or bad. Such lane specific restrictions are not very common anyway.

Example:

lane_group=-s|,|l,ls,s,s:bus

which would describe a highway having one backward lane and 4 forward lanes, the right-most one being a bus-lane. Overtaking is not allowed. What do you think? (simon04, please don't forget to sign your post). --polderrunner 20:07, 20 January 2012 (UTC)

Use separate keys with a list of normal values

It's fine to use single letters like l,s,s,r for the basic lane layout. But instead of making up mini-tags like "maxs:70" for additional information, I suggest that you put them into additional tags like this:

• lanes:width=4,3,3,4
• lanes:maxheight=3.2,4.0,3.0

Then mappers can use any tag they like for their lanes - maxspeed, surface, width, whatever. --Tordanik 19:25, 21 January 2012 (UTC)

I'm also not that happy about those minitags for restrictions, it is a bit of a hack. Your solution is more elegant (those lane specific attributes are relatively uncommon, so the extra tags won't be a burden). I would probably propose using lane_group:* instead of lanes:* in order not to interfere with the existing lanes tag. --polderrunner 21:57, 21 January 2012 (UTC)

What Tordanik is looking for is here: Proposal lanes General Extension

Separating forward and backward lanes

I think that forward and backward lines should be stored in separate tags. This would make this feature consistent with others and would help editors to correctly reverse the direction of the way without being forced to understand the lane_group tag's internal syntax. For example:

lane_group=b-cl-s,b-tram-s,tram-s,r

should be replaced by:

lane_group:forward=tram-s,r
lane_group:backward=tram-s,cl-s

':forward' is the default for one-way highways and can be omitted.

Center lane could be described using its own tag center_lane=reversible or center_lane=turn (plus already used center_turn_lane=yes). I don't know whether these kinds of lanes needs turn attributes (or a default 'straight' is enough). --Arturek 20:43, 21 January 2012 (UTC)

That would solve the way direcion reversal problem for editors. But it will be a bit more cumbersome to mappers as there are now two tags and the lane order is no longer left to right for the backward lanes (could lead to mistakes). I would find it more elegant to include center turn lanes in this proposal. Center turn lanes are normally used for making left turns, often to private properties, so they should be coded 'l' (or 'r' in GB and other left-hand driving countries). Long time ago Denmark had three-lane highways where the center lane could be used for overtaking in both directions. For good reason they became known as suicide lanes and have luckily been abolished. At the moment I'm more inclined to stick to the single tag solution but using the 'sign' notation suggested by simon04. --polderrunner 22:23, 21 January 2012 (UTC)

I do not think that one-tag-for-everything is always a better solution. When lanes are taken from an aerial image then yes - one tag is easier. But when lanes are mapped from the point of view of a driver then two tags are better because the user is not forced to reverse both lanes order and lanes turn directions (and I think we should support more real-word mapping then aerial-image-based one). One tag also suggest that both sides of the road should be described at the same time, but frequently I do not know how opposite-direction lanes look like. In such cases I could just add one (forward or backward) tag and someone else could add another. When only one tag is used then it is less clear whether its value is complete or partial. --Arturek 09:37, 22 January 2012 (UTC)

Abbreviation is bad

Packing of abbreviated status is usually to lanes proposals. Yet it will be hard to 'casual' mapper. It is too much "database style". While there is no rendering plugin for JOSM or something else like this, every user must count lanes when he needs to set width or maxspeed (or when he wants to read this). There must be another way. --Scondo 20:50, 3 February 2012 (UTC)

Lane specific properties

You used a comma as separator, which is already used in some keys and therefore would lead to some collisions. (Imagic forgot to sign here)

Well, my proposal is not using the comma in the key, only as separator between values. I am aware of Key:opening_hours which does use the comma in the value. The solution is simply to require such a value to be put within round brackets (see Proposed_features/Extended_conditions_for_access_tags which uses the syntax of opening_hours within the key where the colon causes collisions). I should probably specify the use of brackets in those (rare) circumstances. --polderrunner 13:21, 9 February 2012 (UTC)

Separate ways for the lanes would be better, if you want these as features

I wrote this already in the German forum, where this topic will be also discussed.

I find it easier to map a way for every lane and add tags for the four directions a vehicle can go on it. Then add the lanes to a highway=*-relation and then add this highway-relaion and the sidewalks in a super-relation for the street. I find something like

lane=yes
foot:all=yes
bicycle:all=yes
motor_vehicle:forward=yes
motor_vehicle:backward=no
motor_vehicle:left=yes
motor_vehicle:right=no

much easier to understand as the tag soup you can see in this proposal, even if relations are hard for new mapper, but these tags are much harder to understand. At least I will not edit/update these tags, if I have to edit the way and please blame me then, if I mess things up. --Fabi2 00:38, 23 February 2012 (UTC)

Well, I don't think that mapping every lane (a big intersection may have 20-30 individual lanes), adding 7 tags to each lane (that would be 140-210 tags in total for one intersection!), then creating a relation for each direction and finally adding one or more super-relations (which Potlatch AFAIK can't handle) would exactly be "easier" to map. My proposal would typically require one tag on each of the 4 approaching highways (the lane_group:match tag may be added in ambiguous cases but is normally not needed for 'well-behaved' intersections). Furthermore your proposal is not backward compatible, mine is. If you map lanes separately you cannot specify where you can change lanes as they are not connected (your relation could help here but again how do you specify whether it is allowed to cross the lane separator?). If a newby mapper doesn't understand the lane_group tags he should just ignore them (not delete them of course). The lane_group tagging only affects lane guidance functions of navigation devices and possibly rendering of very detailed maps. Something that requires 200+ tags just to support detailed lane guidance is doomed to fail! In my case standard map renders and route planners can ignore the lane_group tags. Your proposal would require support for a new highway type relation in all major applications, routeplanners would have to consider all lanes during route planning making the task much more complex etc.

Most lane tagging proposals that I have seen avoid the requirement of mapping each lane separately exactly to prevent the whole mapping ending up in a big "spaghetti-soup". Some require relation support (and usually fail for that reason), some follow similar ideas as my proposal. --polderrunner 08:30, 23 February 2012 (UTC)

This kind of tagging is just an idea I got while the lane mapping discussion and so it is a fast draft. It solves the lane serator problem (you can drive e.g. to the left or you can not) and I think it can also be made easy backward compatible, by including the old highway=* as a menber with proper role in the relations. For now I do not think about lanes, until I would see the sidewalks mapped beside each street. Your proposal will fail on the not "well-behaved" intersections, which sooner or later will appear, just because they exist in reality. I don't ned a car driver and routing application centric bullsh*t proposal, for which i need a parser to understand it and if you write out the keys, they would exceed the 255 character limit. --Fabi2 16:15, 23 February 2012 (UTC)

May I ask you who do you think should use lane tagging information if not car drivers? They will be the primary consumers of such information. For general map rendering and for route planning you don't need it (and therefore the proposal should not interfere with established tagging). To your other points: Sidewalks can be mapped using the existing sidewalk=* tag and it may not be an advantage to include them in detailed lane tagging (again a question of being backward compatible). I would be pleased to see intersections that cannot be handled by my proposal (there may be some but they may be so unusual that it is not worthwhile to adapt the tagging scheme for such rare cases). And why would you write out the keys? The syntax is not difficult to learn and mostly requires less than 20 characters in total. --polderrunner 18:13, 23 February 2012 (UTC)

Tagging each lane, and also the sidewalk, which is also just another lane, solves the problem, that e.g. you can drive easily with a bike from the cycleway to the street, but not with a car from the street to the sidewalk or an other lane wich is separated by a line. With tagging each lane in such a way as above, you also in most times need no turn restriction relations anymore, as this information can be dererived from the special "access"-tags of the lane in most cases. If you want to map each lane, you should do it like they are in reality, and not limit the usefulness of the information to a special use case such as car routing. Car drivers should look out of the windows of there car, and so need no navigation to "see" the lanes they can use, so if you think they are not needed for the renderers, they will also not needed for car navigation. --Fabi2 21:42, 5 March 2012 (UTC)

Don't like the idea of putting all that information into comma-seperated lists

Sorry to come up with this after voting has started. I like the idea of mapping lanes with tags on one way, but I really don't like those ugly-to-read and probably hard-to-maintain comma-seperated lists. I'd prefer some more explicit lane ordering that one could obtain with seperate namespaces for seperate lanes. Some time ago I made up a quick and dirty proposal thereon that I just updated slightly (User:Santiago1504/MultiLane). As you've linked to that page you seem to have noticed those ideas. It would be great if you could briefly comment on why you prefer your concept of comma-seperated lists with imlied ordering. --Santiago1504 23:06, 5 March 2012 (UTC)

Well, that is a question of taste. My proposal is a good compromise between ease of mapping (I consider it easy and efficient as soon as you have learned the basic syntax) and readability (not that difficult either). One requirement for any lane tagging proposal to have a chance of success is that it is easy to use. A scheme that requires 50+ tags and 2 hours of work to map a single intersection will never fly. My scheme may look a bit complex on a first look but most of it is about odd cases mappers will rarely encounter. I cannot see the problem with comma separated lists, they provide a direct description of all lanes ordered from left to right. No need to name/number the lanes (at which lane do you start the numbering, are cycle lanes counted or not etc). Another thing. My proposal uses just a single name space (lane_group). If you don't need lane information just can ignore the lane_group tag(s). The established tagging isn't affected in any way. As a mapper you don't need to understand the lane_group tag if you are just doing unrelated tagging. --polderrunner 21:29, 6 March 2012 (UTC)

Concurrent voting

Unfortunately we have ended up with two rather similar proposals trying to solve a similar problem -- drafted in parallel and also open for voting in parallel:

• Proposed_features/lanes_General_Extension
• Proposed_features/Lane_group (this one)

I sadly lost a little bit track of this one and mainly discussed on the :lanes extension (which is - by the way - also included here, just with a slighly different syntax). I am personally very irratated that we seem to have one group of people discussing here -- and another (rather distinct) group discussing the other proposal, but no real exchange, no effort to join our forces. I do not exclude myself here.

The rush in starting the voting process (both proposals!) makes no sense -- and parallel voting even less (what if both proposals get approved?!).

My intention - and I hope that is also the intention of others - for participation in this process is to establish an alternative to the mircomapping of lanes. The micromapping looks very attractive and intuitive for mappers (casual ones), but hiding the complexity of tags in a big number of ways -- also ignoring the additional complexity they get for solving the routing problems (which mappers sadly don't see as this is hard to visualize).

To make this alternative fly, the approval process here is mostly irrelevant (many things are used but never gone through an approval process -- other things are approved but not really in use).

For success we need:

• A graphical tool (JOSM plugin), roughly based on the existing lane tool - I started with that, but I am months away from an experimental state.
• A visualization/rendering (what is not visible is not attractive for many mappers). We have limited ways to influence this. All we can do is:
• A as huge as possible amount of mappers really using the tagging concept - in the real world - on real ways.
  • Why? Once tags are in wider use, we have better chances to get a rendering for it -- and then a even broader basis of mappers

Conclusion: Dividing our forces is not useful. Thus I would propose to abort voting (both sides) and have a merge discussion first, identify undisputed parts, discuss if a step-wise approach does not make more sense, etc. --Martinq 10:59, 6 March 2012 (UTC)

Here was a micromapping-related discussion that finally resulted in the striked out text above. It has been moved to Talk:Proposed features/Lane group/Archive --Martinq 22:07, 6 March 2012 (UTC)

Martinq, I tend to agree with you on most of your points. The approval process is not working on such complex proposals (it is even questionable for simple tag proposals). You suggested some useful criteria for a proposal to succeed. I think we also need to get some feedback from the target users of lane tagging information, that would be mainly developers of navigation software. The problem seems to be that none of us really know what they need of data in order to implement lane guidance, lane rendering etc. Some hints about how the 'pros' do it would be great (of course without violating any intelletual property rights). One way of evaluating the practicality of the different proposals could be to ask some volunteer mappers to try out the proposals on some selected examples and report their opinions, eventually give a score on things like ease of understanding the scheme, ease of editing, versatility etc. These volunteers should of course not have taken part in the creation of any of the proposals in order to be unbiased. --polderrunner 20:53, 6 March 2012 (UTC)

And please stop the discussion on micromapping in this thread. None of the two proposals in question are about micromapping. That discussion belongs somewhere else, not here. --polderrunner 20:56, 6 March 2012 (UTC)

I took some time to reread this proposal. I fully agree, that we should work together on solving this "lane issue". The problem I see here it that those proposal share a common idea, but in the detail are completely diametrical:

* Use of abbreviations: this proposal uses abbreviations for the lane description. This has the advantage of shorter tags and maybe easier processing, but is IMO very hard to read and extremely error-prone. Imagine you wanted to write lane_group=s but instead you wrote lane_group=w (simple typo). This is a valid code and so very hard to spot and correct. Also mappers need to know all the abbreviations and all future additions to them. In my proposal the same typo would result e.g. in turn=wharp_right instead of turn=sharp_right. Even if you are a Star Trek fan you should be able to spot and correct the error.

* Using of comma as separator: was already discussed. The problem here is, that some values contain one or more commas and therefore the comma is a bad choice as separator.

* Prefix vs. Suffix: this was also discussed. Prefix as in this proposal has at least two disadvantages: 1) the lane-specific properties are separated from the generic properties in the editors, e.g. maxspeed=xx is not sorted right after/before lane_group:maxspeed=xx,xx and 2) it is placed differently (therefore inconsistent) than the existing extensions like :forward/:backward/:right/:left, which all tell us, that the key/value is only valid for a specific part of the way, as does the lane_group extension.

* Lane matching tag: this was also something considered in my proposal but dropped for obvious reasons: as soon as someone splits a way, one of the two resulting ways contain incorrect information about lane matching.

So three of four differences were discussed in my proposal and dropped. The fourth difference (abbreviations) is some kind of philosophical difference. How would you merge the proposals in this case?

I don't want to end my statement without also showing one advantage: lane crossing restrictions are already included in the lane_group proposal. Although again with abbreviations it seems to work. This is something I intend to add later on to the :lanes-scheme, preferable using some kind of standard key like divider.

So I'm unsure what a stop of the voting could achieve. It clearly doesn't make any sense to vote on two proposals on the same problem at the same time. I'm also not sure, why voting on this proposal had to start immediately after the voting on the :lanes proposal started, even with the reason "(noting that the "competition" has also entered voting status)".

My biggest concern (and when I look into the already existing votes I'm maybe not wrong): While the opposers will vote on both, the parallel voting may result in less approvers for both proposals (even if assuming that people supporting tag solutions in general are at least clever enough not to vote 'no' for the "competitor", because this will kill both proposals). The people in favour of "lane_group" are missing in the ":lanes" voting - and vice versa.--Martinq 18:50, 8 March 2012 (UTC)

As was written: even if a proposal was approved or rejected, it doesn't really matter. The reason why I wanted a vote on the :lanes-proposal is simple. If it will be approved, it can be documented in the wiki without too much resistance. And this is very important for the usage of any scheme. The more people are using the scheme, the more feedback we will get. And if we see after a year or two, that it completely sucks, we deprecate it. But at least we tried.

The :lanes proposal was discussed for some time. The voting is only on a part that needn't to be adapted for some while. I'm tagging the local motorways with it for some weeks and didn't spot a problem. But we need more people using it to see the problems. So lets approve the idea, use the scheme and see how/if it works.

So once more: what would be the benefit of stopping the voting? --Imagic 09:51, 7 March 2012 (UTC)

See concerns above. Summarized: One discussion, one acceptable proposal for all - with good rationale for decisions, one proposal to vote, more approvers - success in voting. --Martinq 18:50, 8 March 2012 (UTC)

Correct, correct, correct, correct. Everything you write is correct. But there is one flaw in your argument: when reading through various mailing lists the discussions are more like "I rule - you suck". Especially on the lane-issue. What I am really afraid of is that if we stop the voting, the discussion - which was surprisingly fruitful - will lead in the same direction. And we might also lose the people who already have voted on each of the proposals. This is why I really don't think this is a good idea.

Yes, the emotions and the human factor... But that's the reason I have made the request to take a deep breath, make a step back and "cool" down. I have tried to mediate between these proposals by pointing out common objectives and similarities.--Martinq 10:52, 9 March 2012 (UTC)

Also I still do not see how we can merge the proposals, as they are so diametrical. I think the votes on both of the proposals are more like a decision of the community between human- and processing-friendly. So let them vote! If the community decides, that OSM should turn away from descriptive tags then it is their decision. OSM is community based and there will always be different opinions.

If there had been already a discussion about the use of abbreviations, the integration of access modes in the "type" code, etc -- then I would agree. But for me it looks like that such items (that are diametral) haven't been really discussed here - and the creator(s) of the proposal where not enforced to justify these decisions. I saw a chance to sort these differences out and learn about the (good) reasons for the diametral approach. Thus my request that we should try to do that (but I may have missed non-referenced discussion threads in mailing lists). That's all. As I already emphasized: The whole voting process is somehow questionable and - here is agreement - the least important factor for success.--Martinq 10:52, 9 March 2012 (UTC)

Don't get me wrong: polderrunners proposal is good. I personally could even live with the abbreviations and the somehow programmatic approach. But that's just me and is mostly because of my background. In my(*) proposal I tried to consider all the people without technical background and define the keys/values in such a way that you simply can "read" them without further knowledge. This was also why I liked zverdiks proposal: you could simply "read" the keys and understand, what's going on. Polderrunners proposal is in any way a step in the right direction, even if it just forces people to think and discuss about this issue.

* footnote: I always write "my" proposal. That's not true. The main idea and many details came from different persons. I simply collected ideas and put them together. Thanks to all of you!

--Imagic 08:59, 9 March 2012 (UTC)

Justification for the use of abbreviations

I start a new section because voting has started.

There was no dicussion on a valid comment above: Talk:Proposed_features/Lane_group#Abbreviation_is_bad. I don't see any justification for the decision to use abbreviations. There was no response on the comment.

Those mapping routinely ("the lane experts") may see the abbreviation as advantage, because the tag values remain short. But we should not forget that OSM is a crowd sourcing project where maintenance of data - keeping it up-to-date - is also relying on casual mappers. We lose a lot of potential for such quality assurance and data 'hygiene' activities, because those mappers cannot spot errors in a tag like lane_group=l,l#,bus:s,#s,r,r without lookup in the wiki. For good reasons the use of abbreviations is exceptional in OSM, self-explanatory meanings are documented as good practice in the OSM wiki.

Additionally and already mentioned: Single-letters are prone to errors (because they are less robust against typos) - at least as long as humans are entering the data.--Martinq 19:27, 8 March 2012 (UTC)

Voting cancelled

I have decided to stop the voting on this proposal in order to avoid the concurrent voting issue and maybe also to adapt the proposal. --polderrunner 22:02, 12 March 2012 (UTC)