James Mast <rickmastfa...@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.
pgp_mw2zOhuoI.pgp
Description: PGP signature
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk