Proposal talk:Divided road

Bad approach

I don't like this proposal. If we go to that level of details, we shouldn't figure out dividers but rather lanes. Then we could fix many other issues (e.g. restricted access) instead of just tagging for the renderers. --Pieren 13:28, 12 February 2010 (UTC)

+1 from me --Lulu-Ann 15:32, 12 February 2010 (UTC)

The just added section "routing cases explained" IMO is only great for convincing others that the proposed method is far more cumbersome for both editors and data consumers, than the style we've used from the very beginning: physical barrier means separate ways. None of those extra rules are needed when current practice is followed. Alv 22:36, 12 February 2010 (UTC)

This method is much less cumbersome than that are used for ways with non physical (legal) divider: lots of restrictions. This is why rule "two ways if they're physically separated" simply does NOT WORK. Often people use two ways just to avoid restrictions. --Vovanium 15:09, 20 February 2010 (UTC)

Well they shouldn't use two ways, then, and the road is full of restrictions so the restriction relations just need to be entered. Alv 08:50, 22 February 2010 (UTC)

That's why routing section of proposal is added. Proposal gives ability to replace lots of restrictions (or oneways) with one relation. --Vovanium 13:32, 1 March 2010 (UTC)

Why do you judge what should and what should not be mapped? Dividers are just objects to map as all ather features. And... Tagging_for_the_renderer? Automatic rendering task is difficult one and helping it done is good. Or you already have a brilliant algorithm? --Vovanium 15:09, 20 February 2010 (UTC)

No, it's not always objects. It can be a piece of grassland. Divider is a space between lanes and the whole proposal and comments are refering to "nice rendering". Again, the question is to know if this proposal is the best modeling for divided lanes and I think it is not because it's not solving many issues. A similar example would be to tag the amount of painted white lines to represent the amount of lanes. --Pieren 15:50, 18 March 2010 (UTC)

I wonder if grass strip is not an object like white lines or barrier. If there are problems which are unsolved, there is a time to look on them while in draft/RFC to edit proposal or make better one. But i do not realise about which you are. Also there's another proposal which i like: Proposed features/lane and lane group and which may incorporate features of this proposal. --Vovanium 22:37, 8 April 2010 (UTC)

Comments

I like this a lot. It would render much better than the current pairs of ways, for minor roads. I don't really like the "legal" and "physical" tags, though, would "marked" and "barrier" be better?

Yes, it would be rendered really better, and this was one of main reasons to propose it. I'm not native english speaker, so feel free to change these values to more suiable ones. But keep in mind that look of "physical" barriers may be different: it may be metal or concrete constrution, grass island, or just gap in asphalt with gravel or bare soil. And "legal" divider may lack ground marking (there may be restrictive road signs, or some implicit traffic rule). - Vovanium 18:01, 3 December 2009 (UTC)

Now, how do we get more eyes to this? Stevage 09:08, 3 December 2009 (UTC)

Hmm. Forums/mailinglists? - Vovanium 18:01, 3 December 2009 (UTC)

The u-turn tags should use the same scheme as access tags, ie. divider:forward and divider:backward if it only applies from one direction. Daeron 17:31, 3 December 2009 (UTC)

I have no objections on this. So divider:forward=u_turn+divider:backward=u_turn will act like divider=u_turn. And divider:forward=legal is divider, that can be passed only in one direction (— — — — line). - Vovanium 18:01, 3 December 2009 (UTC)

This proposal makes a lot of sense and would solve a problem I've been struggling with this evening. See this for the issue: a dual carriageway with a section of 4-lane single carriageway in the middle. The resulting junctions are an inaccurate mess. Having a single way to represent the dual carriageway would solve this problem. BigRedDesign 22:33, 21 February 2010 (UTC)

Better draw the smaller roads as ending at separate points on the trunk road; at the northern end the junction nodes some 10 to 20 meters apart. In the south you could even see that there might be a divider just north of the intersection; if so, then you may split the trunk road to separate carriageways already just before the intersection (it's correct if it's correct, and the rendering looks nicer, too). If there isn't, the carriageways merge at the intersection, so they'd end in the same intersection node; even if that makes a small kink into their path the ways drawn stay well inside the road surface and path taken. Alv 08:09, 22 February 2010 (UTC)

I think what would be useful is some kind of hierarchy for ways. We could have one object with no location at all, that just defines the name, maybe the country, alternative names etc. of a highway. We could then assign one child to this object, that represents only the path of the highway (or several children that represent certain bits of the highway). These bits can then define lanes as tags, or in the form of additional children. In many cases those children would just be the two sides of a divided highway, but they could represent lanes as well. Or both sides could have children of their own to represent lanes. Each child can override the tags of their parent (we may set a general speed limit, with exceptions in some areas). So as an example, the object defining the highway path may be tagged with something like footpath|motorway|motorway|divider:barrier|motorway|motorway|child1, where child one represents an off-ramp. Or we'd just have child2|divider:barrier|child3, with child2 being tagged as footpath|motorway|motorway and child3 tagged as |motorway|motorway|child1.

Images for discussion

• 

  Example 1

• 

  Example 2

• 

  Example 3

• 

  Example 4

• 

  Example 5

• 

  Example 6

• 

  Example 7

• 

  Example 8

• 

  Example 9

• 

  Example 10

For each example, let's discuss how to apply the tags: whether to map it as two ways, one way tagged with divided=*, or one way untagged.

Example 1

SB: A residential street, clearly best marked as divided=median, imho.

This divider is not trivial one. If one wants to map every tree, separated ways may be drawn. --Vovanium 20:26, 4 December 2009 (UTC)

Example 2

SB: Another residential street, marked divided=median. The triangles off the roundabout could be marked, optional.

Example 3

SB: A section of a busier road. Mark divided=line.

Example 4

SB: These are really traffic islands. Could mark divided=median, with a divided=gap node.

Example 5

SB: A good example of something you want to map, but for which two lanes would be overkill. divided=median, width=3 ?

Mok0 This can also be viewed as a "flattened" roundabout with only 2 roads connected to it, in which case you'd map it as such.

They are not parallel ways. I'd prefer to map them separate to display their form. --Vovanium 20:27, 4 December 2009 (UTC)

Example 6

SB: Intersection of major road with minor road. Map the major road as two ways, mark the centre of the other with divided=median?

divided=median for way, junction=yes (+ divided:gap = n) for junction, also divided = u_turn, if u-turns are allowed. --Vovanium 20:27, 4 December 2009 (UTC)

Example 7

SB: Grey area. Could go either way, depending on what else is going on. Divided=median might be sufficient.

Example 8

SB: Clearly divided=median on the minor street. Either a divided=gap node on the intersection, or mark the big road as two ways.

Example 9

SB: Due to the complexities, such as the two bridges, two ways is a must here, right?

Yes, i see here two individual ways too. One bridge is the reason to draw single way. --Vovanium 20:33, 4 December 2009 (UTC)

Example 10

SB: Straightforward example of divided=median, and the impact it has on routing.

Please add your own thoughts, and find other difficult examples to show any problems in this proposal. Stevage 13:25, 4 December 2009 (UTC)

I'd draw all of them, except for example 3, as separate ways. Once you start adding hedges, trees, minor power lines, sloped and lowered curbs, grass vs. paving_stones and manholes or similar, possibly within the median, the locations of the road and the other features wouldn't anymore be representative relative to each other. Alv 14:25, 4 December 2009 (UTC)

Interesting images. I mainly see very short segments, on which we cannot see full power of proposed tags. :) In my opinion does not matter how they will be tagged. Use separate ways if you think that this is approptiate. For example ex. 4, 5, 8, 10 may be treated just as junctions, where links are explicitly drawn. --Vovanium 20:26, 4 December 2009 (UTC)

Melways approach

For an example of how another site handles this, check out the Melways:

File:Melways median example.jpg

This approach is interesting - it looks at first glance like they're mapping out both directions individually. But they're not: there's actually no representation of median width at all, it's just symbolic. Stevage 13:25, 4 December 2009 (UTC)

This is what i want to see in OSM. --Vovanium 20:29, 4 December 2009 (UTC)

Introductiory provisions

I've decided to write this, because in my opinion the idea of proposal is not completely understood.

Main goal of such scheme is to completely remove any reasons to draw roads twice. So if we need to apply any property to one single direction, we should be able to set them without splitting.

As a programmer i am keeping in mind automatic data processing issues. Thus i state:

• Scheme must be unambigous. Any possibly ambigous combination of tags should be avoided in any case
• Scheme must not use any information that is hard to gather. This includes way geometry and state rules (like driving side).
• Tagging must be backward compatible. No tags should change meaning of other tags.
• Scheme must be extensible while staying compatible with software which doesn't know about extensions.
• Meaning of tags and relations sohould be kept easy without bunches of exceptions.
• Also no artifical restrictions on tagging should be applied. (E. g. does not matter which width, number of lanes or legal status road have).
• Highest possible level of integration should be mapped. It is trivial to split complex entity to parts (for example road to lanes), but hard to recognize one under pile of details.
• Absence of information means nothing but abscence of information. No one should assume any property if no tags set. (E. g. if neither adjoint role, nor junction is set then the status of connection is unknown and nothing else!)

At other hand this scheme must be easy to understand and use by humans using basic map editing software (i. e. no plugins needed).

And yes, I pretend to completely change current practice of road mapping as a new one is better. There's no way for trade-offs. :)

-- Vovanium 17:41, 4 December 2009 (UTC)

Opinion Poll

• I don't like this proposal. Lulu-Ann

  So, how do you think roads with non-passable line divider should be mapped? --Vovanium 22:44, 8 April 2010 (UTC)

  • Like motorways: Two ways. Lulu-Ann
• I don't like this proposal. Ewen Hill A really simple solution that reduces complexity for future editors and for the viewer. Ewen Hill (talk) 13:53, 21 August 2019 (UTC)
• I don't like this proposal. Gormur - This is just a meagre solution to the general lane problem we have. --Gorm 12:56, 27 May 2010 (UTC)
• I like this proposal. Splitting into two ways for short sections makes a mess for a major category of data user: either there needs to be a good way of putting the two back together (could be difficult; it's a computational nightmare), or a method for encoding the information on a single way. Or both, so you can choose: nobody is obliged to use it. I'd settle for leaving the restriction relations in place, rather than force routers to "understand" this tag, and stopping the divider any time there's a gap, rather than identifying "u-turn" locations. No sensible router advises people to do u-turns anyway. Keep it simple.--RichardMann 11:47, 25 May 2011 (BST)
• I like this proposal. But only for small scale maps where a symbolic rendering as in the example above would aid clarity; also for routing. However I don't like this proposal for large scale maps where detail and physical layout is of the primary concern. Would it be possible to map in both ways somehow, both having our cake and eating it? Basically if this proposal allows lane concerns, sidewalk concerns, and road area concerns to be split out out to separate objects as necessary, then I'm all for it as a representation of the centreline route of the logical road (plus some tags about the kind of road that might be used in smaller-scale symbolic maps)! --achadwick 16:32, 15 July 2011 (BST)
• I like this proposal. Splitting the highway into several ways makes a tag mess. Either I haven't figured out how to properly change tags on split highways, or this is a real problem. I have also had the problem of a U-turn-restriction on a split road. Consider driving on a two lane highway with left-hand traffic. At an intersection, traffic coming from the left would be allowed to turn right (then driving in the opposite direction as you), you may also turn right, but you may not do a U-turn. How do I map this? I do agree with the previous comments, that this approach should possibly treat lanes in general (what about several barriers on a highway? Or barriers between lanes of the same direction? It should be possible to keep only one way for the highway itself and then either define each lane or draw seperate ways for one or more lanes and associate them with the highway. The lanes themselves should inherit tags such as speed limit, name, surface from the parent, unless redefined in the child. And we need a proper way to define barriers (possibly in the parent?). Workoft