[OSM-talk] How to tag lanes, not ways, was: Deprecating the use of Tag:highway=stop in favour of Key:stop

[Anthony]

On Mon, Aug 31, 2009 at 12:14 AM, John Smith <deltafoxtrot256 at gmail.com>wrote:

> 2009/8/31 Roy Wallace <waldo000000 at gmail.com>: > [should join] multiple
> lanes." From the wiki: "relations are basically
> > groups of objects in which each object may take on a specific role."
>
> http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories


Which says "We also use them to group fragments of a road, as in: These
fifteen parts together make up so-and-so road."

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.

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.

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".

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.

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.

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090831/0dab96b5/attachment.html>