<div class="gmail_quote">On Mon, Aug 31, 2009 at 12:14 AM, John Smith <span dir="ltr"><<a href="mailto:deltafoxtrot256@gmail.com">deltafoxtrot256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/8/31 Roy Wallace <<a href="mailto:waldo000000@gmail.com">waldo000000@gmail.com</a>>:<div class="im">
> [should join] multiple lanes." From the wiki: "relations are basically<br>
> groups of objects in which each object may take on a specific role."<br>
<br>
</div><a href="http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories" target="_blank">http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories</a></blockquote><div><br></div><div>Which says "<span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-style: italic; line-height: 19px; ">We also use them to group fragments of a road, as in: These fifteen parts together make up so-and-so road."</span></div>
<div><br></div><div>Honestly, I think we have to do both.  Ways should be determined logically - they are a "way" to get somewhere.  When multiple ways form one road, they should be grouped together somehow (relation seems the best), not for the purpose of presenting routing information, but in order to provide information to those drawing maps.  One example which I think is pretty much indisputable is the dual carriageway.  We don't want a dual carriageway represented as a single way, because doing so would make the routing information inaccurate.  But it'd be nice if we could group together two ways in a dual carriageway representing a four lane bi-directional road with a Jersey barrier in the middle (same thing with multiple ways going over a bridge, but I don't want to suggest a solution geared solely toward bridges).  I'm not talking about specific implementation, but map-makers could use that kind of information to make better maps.  Whether this grouping is done by a relation or a new table isn't something I'm going to comment on beyond the fact that it obviously could be done by a relation.  The implementation details I'll leave to those familiar with the inner workings of the system from a performance perspective.</div>
<div><br></div><div>That said, it'd be nice to have lane-specific information without breaking apart the way.  Speed restrictions, height restrictions, truck restrictions, are often lane-specific, but those who aren't affected by the restrictions are free to change lanes as they wish.  Lane specific truck/height restrictions are especially nasty, because they represent routing information for some users, and not for others.  We want to be able to tell trucks to stay in the right lane, but we don't want to tell cars to stay in the left one.  So in addition to grouping ways together, we need a method of dividing them up.</div>
<div><br></div><div>I have a great fear of the solution proposed by John, though, specifically because it allows nodes (and even more specifically, nodes which represent junctions with other ways) to be attached to individual lanes.  I can't come up with a single example of the use of that feature that isn't destructive, especially when combined with the notion John expressed that painted medians should not be treated the same as physical gore areas.  Taking the most beneficial situation I can think of, when the right lane of a three lane road becomes an "exit only" lane, John would seemingly have us connect the exit ramp with the rest of the road at the point of the physical gore.  That is completely incorrect.  It is at the point where one must choose to use or not use the exit that the split should take place, and the two ways should remain parallel for a while until finally reaching the physical gore point.  This may be hundreds of meters apart on some roads, so it is not at all a trivial concern.  The routing information we need to convey is "at point X get into (or out of) the right lane" *then*, possibly hundreds of meters later, "take the exit".</div>
<div><br></div><div>If people are interested in micromapping normal intersections with turning lanes, the same logic applies, just at a smaller scale.  When the turning lane appears, you split the way to add the turning lane, run the roads parallel for a bit, and then make the junction with the other road.  That's far too detailed for my taste, when there are plenty of major routing errors sitting in the database.  For these micro situations I'd just as well draw the two roads at a 90 degree angle and stick a single junction at the cross point.  But if you're going to map individual lanes, do it right.</div>
<div><br></div><div>So what is the solution for providing information about individual lanes?  I'm not 100% sure.  Maybe something like John's idea is fine if you eliminate the ability to attach nodes to lanes, or at least the ability to attach junctions to them.  I'm still not convinced there's a need to attach nodes to lanes, though.  If you have a stop sign for a particular lane of a single-direction road, there's almost certainly going to be no lane changing allowed at the point of the stop sign (otherwise people would just drive around it), so if you want to micromap this situation you need to split the way, so you know the point at which you are able to get in the other lane to avoid the stop sign (or speed bump or whatever).  It's only if the restriction applies to some traffic but not others that you have to go to lane-specific detail.  If there's a maximum height restriction on the right lane of a three lane single direction road passing under a bridge, you split the way at decision point before the bridge and the "all's clear" point after the bridge, and put a single three lane way in between the two points with lane specific information.  You can't split the way up into a single lane and a double lane, because regular vehicles are free to change lanes between all three.</div>
<div><br></div><div>John, can your idea work without allowing nodes to be attached to individual lanes?  If not, what specifically would you need this for?  (I'm not convinced tables are the best way to do it technically, from a performance standpoint, but the logical structure minus the nodes seems sound.)</div>
</div>