On Wed, Apr 7, 2010 at 12:37 PM, Marc Provencher <[email protected]> wrote: > I searched, but could find no tutorial on an agreed way of properly mapping > an intersection of two dual-carriage ways, ie an intersection of two > residential roads where the ways are divided by a center boulevard, along > with mini right turn ramps on all four corners (see picture link below). > > http://provencher.smugmug.com/Other/Misc/Intersection/830343527_po6Yx-X3.jpg > > In this picture, I think junction nodes B and G are not needed. Technically, > if your vehicle is at B, you are not even legally allowed to turn right > anyways. Same for G.
HI Marc, You raise interesting points. I've seen different ways of modeling this type of intersection. I've used your example often and I place connecting nodes at B and G as well. I do this because they are essentially the same carriageway, at the same level. While a turn is not normally permitted, it is certainly possible, say, if the flare is blocked by a collision. If you were to leave the two crossing roads with no node, that would raise an error in a number of OSM error detection tools, like keepright[1] because the ways cross but are not connected. This is acceptable when the ways are on different layers, as with a bridge. This suggests to me that OSM has decided it is customary to place joining nodes at B and G. I have seen models where each junction is pinched to a single carriageway, sort of like this: ===--o--=== where the "=" are dual carriageway "-" single carriageway and "o" is the junction node with the cross street. This simplifies each junction to a single node, but at the expense of taking more time to map. > Another question that arises, and for which I haven't seen a definite > answer, is what to do about the "middle" segments in the intersection. In > the picture above, if Road1 and Road2 have the same name, then they could be > drawn as a contiguous road segment, going through A-B-C-D. I do that when the road name does not change. > But what if Road1 ends at this intersection, and Road2 begins there as > well? Do you draw Road1 all the way thru junctions A-B-C, and then draw > Road2 thru junctions B-C-D? After all, if I'm heading southbound and want to > turn left onto Road2, I would want my routing directions to say "turn left > on Road2", not "turn left on Road1", which it might say if the segment > between B and C only belongs to Road1. I think I have been lazy in this regard. I'm not sure I use a consistent rule when I build these intersections. B and G seem like good places to change the name of road 1 and 2. That leaves a weird, mid-junction area where on side is road 1 and the other is road 2. Given this, from the north your nav-program would advise "turn left on Road 2" or exit right to Road 1 if you were going the other way. From the south, the nav-program instructions are okay as well. From the East and West, this seems to work as well, "continue straight to Road 2" I think this model still works if there are no flares on the intersection as well. > I have seem much more complex intersections as well, with separate left turn > lanes. I somewhat fail to see the point in modeling the intersections so > accurately, if it doesn't really add anything to a routing GPS? I agree. A routing GPS for cars should be the only application we consider when we map. But we shouldn't go out of our way to make things difficult for a common use. Others find mapping individual lanes irresistible, but I believe this is a very small proportion of OSM contributors. I'll map a left run lane if I would map it as a flare; if the flare is just dome paint and no hard curb, I'm unlikely to map it. Every mapping project faces these issues. "Where is the line between worth-mapping and not-worth-mapping". We won't all agree. There is an area with detailed micro-mapping of sidewalks, grassy medians, parking and driving lanes, and building lots. It hasn't expanded since it was added. It may be that the micro-mapper just found it too much work. It's also a horrible example of mapping for one specific renderer. It looks bad in any other renderer, and it even looks bad in the intended renderer, if you change zoom levels from the one used when the data was drawn. [1] http://keepright.ipax.at/ _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
