[OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?

[Greg Troxel]

James Mast <rickmastfan67 at hotmail.com> writes:

> I've been normally mapping slip lanes as '_link' highways at
> intersections since the beginning.  However, as most fellow US mappers
> know, they almost never have 'speed limits' posted for them, and that
> seems to help cause problems in some routing programs when they give
> those slip lanes a speed limit higher than the main highway.
>
> Anyways, I've been using OSMAnd recently for occasional offline
> routing on my tablet and have come across weird routing (I'd like to
> call them 'bugs') at some intersections that have 3+ traffic lights
> nodes at them because of the roads being divided.  Here, OSMAnd routes
> me onto a slip lane, makes a U-Turn on the side road, and then
> continues the across the main road to accomplish what a simple 'left
> turn' could have done [1], all to avoid '1' traffic light node.  So, I
> go report the 'bug' on the OSMAnd Google group [2], and then somebody
> forwards it to the GitHub site [3].

[This is a little US centric in details, but I think broadly applies.
For context, white speed limit signs are legal limits, and yellow signs
are advisory.  You can probably be cited for exceeding a yellow limit by
a lot, but it will be for having an unsafe speed, not for exceeding a
specified limit.]

I've been on the osmand list for over a year, and the issue of routing
choices similar to yours have come up multiple times.  It seems that the
views of the osmand developers (who are not very active on the list) are
different from the consensus on the list.

The issue of on-ramps/off-ramps tagged as *_link has been a particular
discussion focus.  The notion you expressed that these don't have actual
posted limits, just sometimes yellow signs is indeed shared by most in
the discussions.  And we generally agree that the right speed to use for
them is more or less half the speed of the larger road from which the
links go to/from.  Perhaps half the speed of the actual road, perhaps
half the speed of a nominal road of that class, and perhaps slower.
But these are fine details, and the consensus is pretty strong.

I do not understand why the osmand devleopers don't just implement this
notion; it seems relatively obviously correct, and people who have
modified their routing.xml files report reasonable results.

A few further thoughts:

While it's important to tag actual speed limits (posted, or
unambiguously determined from local law, such as 30 mph in thickly
settled areas in Massachusetts), routers should actually function on
typical speeds, not limits.  I think osm should have this data, but it
gets a bit complicated.  Still, a simple take on it would help a lot.
One could just put in the yellow-sign value as typical.  Or perhaps
there should be a warning-sign tag, and a typical determined from a
number of tracks.  (Around me, there's a highway with limit 65 mph, and
I'd say typical is 75 mph.  Ramps are often yellow-signed at 30 mph and
typical is 40mph on some of them.)

Routing is clearly tricky.  There are multiple steps:

  1) modeling the real world in the database

  2) computing how long and how far a path will take based on the database

  3) choosing a function to minimize.   Shortest distance and shortest
  time are both not right, as dangerous maneuvers are avoided by many
  people even if they save a few seconds.  And then there's avoiding
  highly bumpy roads.

In your case arguably you have done 1 right within the current rules,
and adding typical speeds or yellow-sign speeds would help.

osmand is doing 2 wrong.  It is completely wrong to assume that exit
ramps can be traversed at highway speeds (100 km/hr or so).  Yes, there
are a few like that joining Interstates, but in the normal case
something like 30 mph (50 km/h) is rational.

In 2, there should be a time penalty for u-turns.  Really it's not a
penalty: it's an estimate of how much time it actually takes, and
ideally these times would be extracted from actual tracks so the actual
time and the predicted time match in some zero-mean sense.

3 is much harder, but the basis for getting it right is to have 1 and 2
correct.

If there were to be a penalty (distinct from a time/distance estimate),
it should perhaps be for getting off a major road and getting back on.
But, one could argue that this would be kludgy, and if one wanted that,
the real issue would be that the underlying cost functions are wrong.
Perhaps in addition to the time spent at stop signs, lights, etc. there
should be a cost associated with the cognitive effort and accident risk,
to be minimized, so that staying on the highway is treated as the
rational choice (that it probably actually is).

So my advice is to use a custom routing.xml with osmand that has
sensible speeds for links.  And perhaps to work towards typical speed
tagging, and encourage osmand to use typical speed if present, and limit
if not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150730/27f202f9/attachment.sig>