Osmand occasionally routes on and off freeways at the same exit

[Mark Waterbury]

http://imgur.com/IFkts1f

[Paul Johnson]

I've noticed this as well, seems to be more problematic at places where maxspeed=* is tagged on the highway but the ramp does not have a speed limit (it feels like Osmand is assuming that the lack of speed limit makes up for the surface intersection somehow, even though bombing a ramp, even if you make the green, at 55-85 MPH the main motorway allows would be somewhere between foolish and impossible).

On Mon, Mar 23, 2015 at 1:10 AM, Mark Waterbury <mwat...@gmail.com> wrote:

http://imgur.com/IFkts1f

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Harry van der Wolf]

Yes, this is most likely the case. You can't blame OsmAnd for this. You also have situations where you go from one motorway onto another via a long ramp. Sometimes those ramps have speed limits and some don't, whereas the main road does have a speed limit. It is inconsistent road tagging.

I know a few situations in my "neighborhood" (60 km diameter) as well where the ramps are officially(!) not tagged (or road management simply forgot). 

There are two streams in the OSM world: those who wish to correct those "errors" for navigation purposes, and those who want to tag the "real world" situation. In other words: don't touch it (even if everyone knows it should be tagged).

Harry

[Maarten Deen]

IMHO there is not enough penalty in the route calculation on taking a motorway exit.

[Paul Johnson]

On Mon, Mar 23, 2015 at 3:23 AM, Harry van der Wolf <hvd...@gmail.com> wrote:

Yes, this is most likely the case. You can't blame OsmAnd for this. You also have situations where you go from one motorway onto another via a long ramp. Sometimes those ramps have speed limits and some don't, whereas the main road does have a speed limit. It is inconsistent road tagging.

Inconsistent reality, more like it, as these ramps often don't have a speed limit in reality (or if they do, it's an unenforced technicality because it falls under a default speed rule for an entire county by not having it's own speed limit sign, but honestly, who's gonna drive 35 MPH on an expressway on-ramp to meet 85 MPH traffic?).  This is even occurring when the data does reflect that there's no rational reason to expect it to be faster (it's a _link, it runs into a stop sign or traffic light on a surface intersection, the return ramp has a yield sign, meanwhile the through motorway bypasses all of that very obviously).

[stf]

This has been an issue for a while and has had several threads here.

My take is that most *_link roads are unposted and so will never have a maxspeed=* tag in OSM so osmand will nearly always use its default speed assumption.

Thinking about the *_line roads in general and the motorway_link roads in particular, the vast majority of them are either on ramps or off ramps.

For nearly all off ramps there is a traffic control device (stop sign, yield sign, traffic light) at the far end which will usually result in the motorist either having to stop or come to a pretty slow speed. For on ramps there may be a traffic control device but even if not there is often a sharp turn getting onto the link which requires a slow speed.

Assuming uniform acceleration/deceleration then your speed on a *_link will on average be 1/2 the speed of the *. Setting the default routing.xml link speeds to 1/2 what they currently are should help.

The real "fix" would be to have the traffic control devices on all *_link ways tagged. And to have them recognized by osmand. I've tagged a number of those in my area and my impression is that osmand does not adequately penalize a route because a stop sign or traffic light is on it. There is a simple penalty value in routing.xml that I assume is in seconds but changing that to ridiculously long value seemed to make no difference.

And the general case for penalizing a stop sign is actually quite complicated as you should allow for deceleration, dwell time at the stop sign and then acceleration. The time/distance for acceleration/deceleration is dependent on the speed you are going and so the penalty for a stop sign should depend on the maxspeed of the way the sign in on.

Given the difficulty of doing the time penalty for a traffic control device correctly, it seems easiest to simply set the *_link speed assumptions to something more realistic.

[Harry van der Wolf]

I would vote for a much simpler approach:

- Use the max speed for the ramp

- If there is no max speed for the ramp, take 90% of the max.speed of the road section immediately before the ramp (like motorway speed * 0.9). OsmAnd "knows" that speed and also uses it in its calculations.

I think that would be more effective and relatively easy to implement.

Harry

--

[Paul Johnson]

Based on general US ramp advisory speeds, I'd go with 60%, not 90%, and that'd still be extremely generous if not a half or fill diamond or X interchange (like cloverleafs, dogbones, roundabouts, trumpets...)

[Max]

Hi all,

it is a routing engine bug.
It is not a maxspeed, priority or penalty issue.

highway=motorway_link:
https://www.openstreetmap.org/way/5570541

highway=motorway:
https://www.openstreetmap.org/way/119371474
https://www.openstreetmap.org/way/5667921

There is no maxspeed in OSM data, highway=motorway_link has a lower priority and a transition penalty in routing.xml.
Also the way over the motorway_link is much longer.
Thus the routing engine already has 3 reasons (lower priority, penalty, longer way) not to choose the motorway_link.

Also if I calculate a route which goes over this motorway junction, it depends on the distance to the motorway junction if OsmAnd calculates a route over the motorway_link or not!

Tested with current nightly build:

Same destination:
https://www.openstreetmap.org/?mlat=33.66210&mlon=-112.12339#map=15/33.66210/-112.12339

If I start the calculation here, the motorway_link is used:
https://www.openstreetmap.org/?mlat=33.83049&mlon=-112.14481#map=15/33.83049/-112.14481

If I start the calculation here at the same motorway (but bigger distance to the junction), the motorway_link is not used:
https://www.openstreetmap.org/?mlat=33.90480&mlon=-112.14653#map=15/33.90480/-112.14653

@Victor:
It is not a bidirectional "meeting" problem, I also tested it with unidirectional search.

Thus it is clearly a routing engine bug, not a routing.xml or obf file problem.

Regards,
Max

On Monday, March 23, 2015 at 7:10:42 AM UTC+1, Mark Waterbury wrote:

http://imgur.com/IFkts1f

[Greg Troxel]

Paul Johnson <ba...@ursamundi.org> writes:

> Based on general US ramp advisory speeds, I'd go with 60%, not 90%, and
> that'd still be extremely generous if not a half or fill diamond or X
> interchange (like cloverleafs, dogbones, roundabouts, trumpets...)

I was going to say 50% before rading Paul's mail, so we agree.

I really do not understand why people seem to want to assign high speeds
to link roads. The reality of most link roads (aside from a few at big
junctions) is that you have to or should slow down. And I really do not
expect to get bad routing because of a 30s extra penalty is using a link
road when the route is still going to be shorter from using the
motorway.

The other issue is this focus on "max speed". That's too tied to the
law, vs what typically happens. I think OSM really needs a "typical
speed" tag.

This is messy because (in the US) most motorways have explicit speed
liimts (white signs, which really are a limit). Ramps ("links" in OSM)
rarely have white signs. They almost always have black on yellow signs,
which are technically advisory.

However, pretty much everywhere it is unlawful to drive faster than a
reasonable and prudent speed, regardless of signs (you can be properly
cited for speeding when going *below* the posted speed if it's snowing
hard). So driving far above the yellow speed is likely to be an
infraction, and so it's not really so advisory.

I do not know if this white/yellow concept applies in other countries.
I do know that in Ireland the actual limit is crazy high outside towns
on country roads, but I suspect if you're going unreasonably fast but
less than 100 km/hr you may still get a ticket.

That's a long way of saying that until there's some tagging scheme that
distinguishes actual limits (from white signs in the US) and advisory
limits (yellow signs in the US), it seems best to tag the yellow signs
as limits. And to assume ~half the motorway speed, or 50 km/hr, for
link roads in the absence of tagged speeds.

Plus, 4-way junctions should have penalties unless the other two ways
have stop signs tagged. That's stronger than giving a penalty if
there's an explicit stop sign.



So, a modest proposition:

assume a speed of 50 km/hr for any link rout without an explicit speed

Why not? Why do people want to assign a higher speed to untagged links?

[Harry van der Wolf]

2015-03-24 23:29 GMT+01:00 Greg Troxel <g...@lexort.com>:

So, a modest proposition:

  assume a speed of 50 km/hr for any link rout without an explicit speed

Why not?  Why do people want to assign a higher speed to untagged links?

As Max mentioned: the routing.xml already has a priority penalty. Maybe this one should be increased as well.

With regard to speed: Any speed is OK, be it 50 km/h or 60 km/h. It simply should be considerably lower then the average motorways speed, even when the motoway itself has a reduced speed (like from 130 km/h to 80 km/h). Not so much because of safety, as we are talking about calculating a route, but to get a correct route.

On the total travelling time it doesn't make a difference at all.

[Paul Johnson]

On Tue, Mar 24, 2015 at 5:29 PM, Greg Troxel <g...@lexort.com> wrote:

Paul Johnson <ba...@ursamundi.org> writes:

> Based on general US ramp advisory speeds, I'd go with 60%, not 90%, and
> that'd still be extremely generous if not a half or fill diamond or X
> interchange (like cloverleafs, dogbones, roundabouts, trumpets...)

I was going to say 50% before rading Paul's mail, so we agree.

50% might be a better assumption, though Oklahoma may be an extreme example having a relatively broad variety of junction types despite the relative lack of motorways and a heavy reliance on limited access expressways that typically have surface junctions rather than grade separation.  You have links here that are capable of being sailed through no problems at the speed limit safely, to cloverleafs that you have to slow down so hard for that you might have to backtrack and use a different ramp at rush hour to avoid going below the minimum speed limit outside the turn lane.  And until about 3 years ago, there were still a few motorway entrances that were basically a right turn directly into traffic with a very short scram lane, controlled by a stop sign. 

 

The other issue is this focus on "max speed".  That's too tied to the
law, vs what typically happens.  I think OSM really needs a "typical
speed" tag.

If an app really wants this information, it can pull it from the GPX uploads.  There's no real reason to make a tag for this since it's too subjective.

 

This is messy because (in the US) most motorways have explicit speed
liimts (white signs, which really are a limit).  Ramps ("links" in OSM)
rarely have white signs. They almost always have black on yellow signs,
which are technically advisory.

And rarely regarded at all except by drivers of certain high profile vehicles.

 

However, pretty much everywhere it is unlawful to drive faster than a
reasonable and prudent speed, regardless of signs (you can be properly
cited for speeding when going *below* the posted speed if it's snowing
hard). 

Heck, heavy traffic will do that, too.  Heavy traffic will also get you a ticket for going too slow on Oklahoma motorways; if traffic gets too thick to drive above the minimum posted speed, you're supposed to get off the highway and take an alternate route.  This isn't as impractice

 

I do not know if this white/yellow concept applies in other countries.

Canada, and I believe Australia and Mexico (basically, anywhere that uses US-inspired signage still maintains a high level of concept consistency to the US model, though Australia is somewhat notorious with message overload, often having multiple diamond panels on the same sign assembly).  I think the EU equivalent would be the white circle with red border and a number inside for limits in km/h (or mph in the UK) and a rectangular blue sign with white numerals for advised speeds, but I'm not 100% on this convention (I'll admit my exposure to EU signage is limited to a business trip to Paris and London almost 15 years ago and playing Euro Truck Simulator 2).

 

That's a long way of saying that until there's some tagging scheme that
distinguishes actual limits (from white signs in the US)  and advisory
limits (yellow signs in the US), it seems best to tag the yellow signs
as limits.  And to assume ~half the motorway speed, or 50 km/hr, for
link roads in the absence of tagged speeds.

I believe maxspeed:practical=* could be redrafted for this purpose, as I have a hard time believing that advised speeds for various road hazards is a strictly AU/CA/MX/US thing.  If I could get the EU equivalent for an advised speed sign, that'd be awesome.

[Greg Troxel]

Harry van der Wolf <hvd...@gmail.com> writes:

>> So, a modest proposition:
>>
>> assume a speed of 50 km/hr for any link rout without an explicit speed
>>
>> Why not? Why do people want to assign a higher speed to untagged links?
>>
> As Max mentioned: the routing.xml already has a priority penalty. Maybe
> this one should be increased as well.

I view the priority penalties based on road type and based on changing
road types as a hack. Road types don't crisply correspond to driving
situations, and a turn from secondary->secondary is not necessarily any
worse than primary->secondary. The real issues are slowing to turn,
stop signs/lights, and the expected speeds on each road.

I think it would be best to focus on getting expected times to match
actual times. That's easier said than done. If I had infinite spare
time, my plan would be

allow routes to be exported in some format that has the segments and
osmand's speed/time guesses and stop penalties annotated.

have a way to take a gpx, match up to roads, and specifically to the
above and compare, and visusalize it.

start adding in time estimates for stop signs etc., and make estimates
for those based on road geometry in the absence of tags.

Even just doing the first step should allow lots of people to spot
problems.

> With regard to speed: Any speed is OK, be it 50 km/h or 60 km/h. It simply
> should be considerably lower then the average motorways speed, even when
> the motoway itself has a reduced speed (like from 130 km/h to 80 km/h).

Sure, exact value probably doesn't matter much, and I think we basically agree.

> Not so much because of safety, as we are talking about calculating a
> route, but to get a correct route. On the total travelling time it
> doesn't make a difference at all.

Agreed; this is not about safety; it's about estimating what's likely
in a way that produces good routes.

[Tod Fitch]

> On Mar 25, 2015, at 5:07 AM, Greg Troxel <g...@lexort.com> wrote:
>
> I view the priority penalties based on road type and based on changing
> road types as a hack. Road types don't crisply correspond to driving
> situations, and a turn from secondary->secondary is not necessarily any
> worse than primary->secondary. The real issues are slowing to turn,
> stop signs/lights, and the expected speeds on each road.

+1 on this. I really think road change penalties is a hack.

Near as I can tell OsmAnd is not recognizing time penalties for traffic control (stop, yield, traffic signals) which might make a difference.

>
>> With regard to speed: Any speed is OK, be it 50 km/h or 60 km/h. It simply
>> should be considerably lower then the average motorways speed, even when
>> the motoway itself has a reduced speed (like from 130 km/h to 80 km/h).
>
> Sure, exact value probably doesn't matter much, and I think we basically agree.

FWIW, I’ve set up a routing.xml file with the heuristic set to 1.0 and the assumed link speeds set to 1/2 that of the corresponding way assumed speeds. For motorway_link that is 55km/h. I will shortly be leaving on a 900 mile drive home and will be seeing how it behaves. I’ll know more in about 16 hours but might not be back here to relate that experience until I’ve slept some. :)

It does calculate a route that looks reasonable when zoomed out but I don’t know if there are exit/re-enter freeway bits in it yet. It would be nice to be able to export and visualize the route as mentioned too.

>
>> Not so much because of safety, as we are talking about calculating a
>> route, but to get a correct route. On the total travelling time it
>> doesn't make a difference at all.
>
> Agreed; this is not about safety; it's about estimating what's likely
> in a way that produces good routes.

+1 This is definitely not for safety or even accurate travel time estimates but for generating good routes.

[stf]

Interesting, if partial, results from my routing.xml change on my drive yesterday.

Conditions:

Distance: >830 miles (>1345 km) with about 700mi (>1100km) of freeway/motorway

Osmand version: 1.9.5

Map edition: 20Mar2015

Routing.xml changes:

$ diff routing.xml.stock routing.xml

55a56

>         <attribute name="heuristicCoefficient" value="1.0" />

185c186

<             <select value="110" t="highway" v="motorway_link"/>

---

>             <select value="55" t="highway" v="motorway_link"/>

187c188

<             <select value="75" t="highway" v="trunk_link"/>

---

>             <select value="50" t="highway" v="trunk_link"/>

190c191

<             <select value="50" t="highway" v="primary_link"/>

---

>             <select value="32" t="highway" v="primary_link"/>

193c194

<             <select value="50" t="highway" v="secondary_link"/>

---

>             <select value="30" t="highway" v="secondary_link"/>

196c197

<             <select value="40" t="highway" v="tertiary_link"/>

---

>             <select value="22" t="highway" v="tertiary_link"/>

201a203

>             <select value="17" t="highway" v="residential_link"/>

I specifically set heuristicCoefficient to 1.0 because it was not obvious to me what it would assume if the value was commented out and I wanted to assure it was using a A* algorthm.

On my Galaxy Nexus (Maguro) phone, Osmand was able to calculate a route this long even after warning of possible issues. It did take a minute or two but wasn't a horribly long time for the calculation.

There was not a single instance of directing me off the freeway and then immediately back on. Not a definitive test, but certainly a good thing. I know of a place where with the old routing.xml this regularly occurs and I'll be going that way next week and see what happens.

There were some routing issues, but most were explained by missing or bad data in OSM, some of which I have now corrected. There is one area where Osmand consistently choses a bad route and I don't see the problem in the OSM data and where other routing engines that use OSM route correctly.

In general, my opinion is that with a pure A* algorithm (heuristicCoefficient=1.0), reasonable assumptions on default motorway_link speeds and good data from OSM, automobile routing is reasonable and usable.

See http://en.wikipedia.org/wiki/A*_search_algorithm#Bounded_relaxation

Reading about the A* algorithm and using a heuristic value to select routes (I think the heuristicCoefficient is supposed to be (1 + ε)), it seems to me that the only reason to select a value other than 1 is to reduce memory and processing resources.

For devices that have slow processors and/or small amounts of RAM, perhaps one could start the routing computation with ε=0 (heuristicCoefficient=1.0) and when some time limit is exceeded or memory drops below some threshold, increase the heurestic to find a non-optimum route before RAM is depleted.

For shorter routes this would guarantee the best route. For longer routes, there could be some inefficiencies. But if one is stopping every 200mi (300km) or so for fuel, food or to use the facilities in a rest stop then you will depart the computed route. Recalculation is triggered by departure from the old route and a new route, optimal over the first 200km to 300km, over the shorter distance is determined and you may never notice that the far end of a long route was not optimal.

[JeCh]

You are right about the signs in Europe. The big difference between US and Europe is that European countries have a default speed limit. For example in Germany it is unlimited for highway, 100 km/h outside town and 50 km/h inside. Other countries have usually lower limits around 130/90/50.

The correct solution should be based on average speed. It is very common that you have a narrow road which has the same speed limit as any other - 90km/h. But you can not drive faster then 60km/h on it. Or there are parts of highway which are almost all the time blocked by heavy traffic.

Online navigations like Waze, Google or Nokia collect current and historical traffic speeds and navigate based on it. Some offline navigations (for example iGo) have information about average traffic and how it changes during day.

So if we want to navigate correctly, these information need to be known. A nice feature of OsmAnd would be to collect (optionally, if the user allows it) the speed statistics, calculate it and then upload the information to OSM. That would require a lot of data and computing power but it would be a killer feature.

Vladimir

Dne středa 25. března 2015 10:04:13 UTC+1 Paul Johnson napsal(a):

[Tod Fitch]

Many, if not all US states have default speed limits. In California it is called the "prima facie speed limit”. In addition some cities will have default speed limits.

When I first got involved with OSM I suggested on one of the tagging lists that default speed limits be put on administrative boundaries. The idea being that default speed can be deduced by looking at the enclosing town, then county, then state, then country. But there was strong opposition to that and I did not pursue it. It still seems to me that a good case for doing that can be made and would allow for data consumers like OsmAnd to do a better job in areas where maxspeed=* tags are missing either because they have not been mapped on the ground or because there are no signs for a mapper see to tag.

Yes, knowing usual speeds for a road could give better results. Usual speeds based on time of day even more. And actual speeds based on some real time reporting system would be better yet. Those are nice goals. But in the western United States just having a better set of default speed limits, on a state by state basis, would be a significant improvement.

Cheers,
Tod

[Max Erickson]

Do you go through and try to come up with a way of encoding the various rules into a small number of tags? I expect that some of the pushback you got was from people that were wary of trying to jam too much structured data into a few values

OSMAnd already indexes roads based on admin hierarchies, I guess in a way that is similar to how nominatim assigns addresses:

http://nominatim.openstreetmap.org/details.php?place_id=127749446

So there is an easy way to join external data, as long as that data is organized using the same identifiers. One way to do it would be a json file, nesting the hierarchies (so if "United States->Michigan->Calhoun County" wasn't defined yet, you could easily fall back to "United States->Michigan").

A nice side effect of this is that you can just have a separate set of rules for a given use (like trucks), rather than attaching a set of tags for each widespread use. And someone can easily inject rules that they think better reflect their driving than the official rules.

It's a chicken/egg problem, but I think if OSMAnd supported some way of pulling in the that people would quickly submit them.


Max

[Paul Johnson]

On Mar 26, 2015 5:26 PM, "JeCh" <vladimi...@gmail.com> wrote:
>
> You are right about the signs in Europe. The big difference between US and Europe is that European countries have a default speed limit. For example in Germany it is unlimited for highway, 100 km/h outside town and 50 km/h inside. Other countries have usually lower limits around 130/90/50.

Aah, good.  Not bad for an educated guess.  There are default speed limits in the US as well, but they're extremely piecemeal.  Oregon has a very structured statewide set of tiered defaults based on classification for unposted areas running from 3 MPH to 88 MPH (though most are 65 and under).  Oklahoma has County and City default speeds, but it varies from place to place.  Montana basically asks you don't drive past your ability and leaves it to driver discretion.  It's complicated enough it's easiest to explicitly tag everything for the area it applies where the limit is region based, then just update the exceptions in Oklahoma.  Oregon pretty much requires studious use of aerials and knowledge of the defaults to tag explicitly, then look up the speed limit orders one by one to tag...

> The correct solution should be based on average speed. It is very common that you have a narrow road which has the same speed limit as any other - 90km/h. But you can not drive faster then 60km/h on it. Or there are parts of highway which are almost all the time blocked by heavy traffic.

You'd still need to pull GPX to get a realistic idea...