search

osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.67k stars 1.02k forks source link

ETA Routing timing - 100% off (Traffic signals penalty) #10251

Open KlavsKlavsen opened 3 years ago

KlavsKlavsen commented 3 years ago

Description

I ask for a route from https://www.openstreetmap.org/way/10636079 to https://www.openstreetmap.org/way/2796 - and osmand estimates the time to 31 minutes.

In fact it takes me 17 minutes.

How is the routing time calculated.. do all the "red/green light"-intersections cost a "certain time" or something, that throws these off so much?

I see the same miscalculation if I take the route via the freeway to https://www.openstreetmap.org/way/4782615 - where osmand likes it to take ~45 minutes - but in fact, it takes ~22 minutes.

Your Environment

OsmAnd Version: 3.8.5 Android/iOS version: 8.1.0 Device model: Google Nexus X

Maps used (online or offline):
Denmark offline map.

Spielmops commented 3 years ago

I don't know, if you have seen this configuration item: Configure profile/e.g.Driving/Navigation Settings/Vehicle parameters/Default speed

Spielmops

KlavsKlavsen commented 3 years ago

@Spielmops But WHY would it use "default speed" for anything? Shouldn't it use the allowed driving speed for each "stretch of road" the route passes - to calculate time it'll take? otherwise highway will be slower as its a longer route (but you drive a lot faster on it - so often its quicker)

Spielmops commented 3 years ago
  1. the allowed speed-entrys are often wrong
  2. the app can not predict traffic jam or construction sites
  3. the app can not know your driving style
  4. there are various other obstacles ... I found per track-recording, that my normal average speed aside motorways is 48km/h. When I inserted this value into the mentioned settings, my predicted time of arrival was way better. Without jams and construction it was within a range of +-2 minutes per hour. Try it ..

Spielmops

KlavsKlavsen commented 3 years ago

@Spielmops I tried setting default speed to 45 km/h.. and to 60 km/h - the estimate of 30 min. to https://www.openstreetmap.org/way/2796 (nr. 1) - still didn't change. It seems it HAS "speed indicators" for all stretches on that route - so it has no effect? Can I somehow see what it estimates "each part" to take - to better debug where its calculations is so hugely off on such a short route?

Spielmops commented 3 years ago

I tried it just with exact your route: 41 seconds. Settings: min.speed:20, average:45, max:130

Spielmops

PS: it's just that one road, isn't it?

KlavsKlavsen commented 3 years ago

41 seconds what?

Spielmops commented 3 years ago

Estimated time of arrival

KlavsKlavsen commented 3 years ago

How do you get en ETA of 41 seconds, when mine says 30 minutes (and the actual time it takes me is ~17minutes) ?

Spielmops commented 3 years ago

You sent a link which calls Opensteetmap and that is showing a track in Kopenhagen that meets the street "Fruebjergvej" ...

KlavsKlavsen commented 3 years ago

yes.. and driving from https://www.openstreetmap.org/way/10636079 - that is estimated to 30min in my osmand (and takes 17min in reality)

Spielmops commented 3 years ago

30 minutes. The reason for this longer time must lay in the traffic-ligjhts. How long would it take, if all traffic-lights stop you? Does it take 17 minutes while rush-hour? My routes are most times outside town, that would explain, why I have better ETAs. If I would drive through such a big town and I would arrive earlyer than ETA, I would be happy. Other way round I would always be as frustrated as TomTom-users. (I had to use those devices with the cars of my ex-company).

Spielmops

KlavsKlavsen commented 3 years ago

Thats why I'm asking about where I can see what osmand calculates each part of the route.. I also see the same for other routes (not going through central copenhagen - and mainly freeway - see the other route I mentioned in first post).. does it add a "set amount of time" for each traffic-light or ?

Spielmops commented 3 years ago

does it add a "set amount of time" for each traffic-light or ?

I do not know, I'm not a developer. You seem to have a problem with this behavior? If yes, why?

Spielmops

KlavsKlavsen commented 3 years ago

You seem to have a problem with this behavior

No - not necessarily.. I'm merely trying to figure out HOW it calculates the 30 minutes - so I can see if I can figure out where it goes so wrong, as calculating double the time it actually takes - on such a short route.. I want to help my favorite Open Source route app improve :)

Spielmops commented 3 years ago

I made a calculation of the travel time on the assumption, that each traffic light takes one minute. The actual journey takes 13 minutes at 50 km / h. And I counted 17 traffic lights. How much driving time is it?

KlavsKlavsen commented 3 years ago

How much driving time is it?

its 17 minutes, pretty much every time. One minute waiting time for a traffic light is very rare in Denmark atleast. Perhaps "stop-light average time" - needs to be configurable per-country or something? In general they time lights so they fit - along the well-used routes - so if you drive too fast - you hit red, if you follow speed limits - you hit green on every stop light. Often works very well.

Spielmops commented 3 years ago

No, that was not a real question. :-) Osmand showed an estimated time of 30 minutes. And I found to numbers: 13 minutes real travel-time and 17 minutes waiting time. Sums up to 30 minutes!

I believe you that it is very rare for one minute waiting time, but Osmand was not made for navigation in Danmark. You just hit a wish for every developer of navigation-apps and navigation-users: learn from previous travels and calculate better each day.

That is the advantage of using online-navigation with Google: Google knows about traffic and speed of every main road and puts this into every time-calculation.

I stay on offline-navigation and therefor Osmand, but I often have a look into Google-Maps and it's traffic-situation and i guess how much time i really need.

KlavsKlavsen commented 3 years ago

solving this with online-navigation and snooping into everyone's data is ofcourse an option. I really enjoy osmand working offline AND not snooping into where I am and reporting that to Google constantly :)

I do believe the calculations COULD be much better, with some adjustments - like showing what time "individual parts" are set to take.. so if route calculation "overview" - would have shown me, that drive-time is estimated to 13 minutes, and 17xtraffic light is estimated to 17 minutes - then I would have landed at the conclusion that it would be nice if one could adjust the "expected delay" - by a traffic light.. This would probably fit entire Denmark with a more realistic setting (1 minute is very high - especially since 50% will atleast statisticly be green when I reach them :) - and in Denmark that is more often the case, due to good traffic planning :)

Can I somehow adjust the time/cost osmand sets on traffic lights?

Spielmops commented 3 years ago

You can change many things related to routing by editing the file "routing.xml". If traffic-light-wait-time is within that file I don't know ...

lunkhub commented 3 years ago

I've seen similar for a long time, but my differences are less, about +50%. A 15 mile trip taking about 30 minutes is estimated at about 43 minutes for example. It is much more accurate for taking highways.

I've adjusted Default speeds to significantly higher than my real: Min: 34, Default: 50, Max: 75; versus real: 25, 45, 70. This does not help much, probably because of traffic lights.

I second the request for an option to adjust average traffic light delays.

Alternative: and option to apply a multiplier to total time estimates.

Note see also #2625.

aceman444 commented 3 years ago

Yes you can find the penalty from traffic_signals in the routing file at https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml and you can change it for your needs and then drop in the OsmAnd data folder/routing.

Zero3 commented 3 years ago

@KlavsKlavsen I am currently working on a Denmark-specific routing.xml file, because I ran into a number of issues with OsmAnd routing and time estimation as well, including this problem. I checked Hædersdalvej -> Fruebjergvej, which OsmAnd currently calculates as taking 32 minutes by default, and interestingly enough, it takes exactly 17 minutes with my config :). So it seems like I am doing something right.

For your information: Traffic light penalties are set to 30 seconds by default, which I suspect is too high for Denmark, so I set it to 15 seconds in my config instead. You mention there being 17 traffic lights on the route, so that explains ~4,5 minutes of the difference. Crosswalks also cost 15 seconds, which is problematic as well, seeing that most of these on your route likely are placed in the exact same traffic light controlled junctions that we already added traffic lights penalties for. Assuming 34 of those (one on the way into the junction, and one of the way out) would explain another ~9 minutes. The rest of the difference can most likely be explained by other stuff from the routing.xml config file.

Also see this related comment I just made: https://github.com/osmandapp/OsmAnd-resources/pull/675#issuecomment-904124667

Zero3 commented 3 years ago

@KlavsKlavsen after some more adjustments related to other routes, my current routing.xml calculates Hædersdalvej 42 -> Fruebjergvej 4 (the house numbers are just some arbitrary ones that I picked) as taking 21 minutes.

This is slightly above the 17 minutes you mentioned, which I am curious about. Is there any chance you could you provide a .gpx trace of the trip? There is an OsmAnd plugin for recording such a trace that can be enabled in the menu, and is quite easy to use. That would be a big help for me in understanding where the differences between your trip and my routing.xml are.

KlavsKlavsen commented 3 years ago

@Zero3 yesterday I drove via that exact route - and due to the light timing (which is something that works well in Denmark) - I could drive right through without ever stopping for a red light.. and since its a straight drive - there isn't anything taking the time in those situations. I choose "trip recording" in osmand - but I can't find the file it should have saved somewhere on the phone :(

pebogufi commented 3 years ago

Go to base folder of osmand, from there to track/rec or a subfolder from here. Have also a look with the used profile in Trip Recording / Track Storage folder

KlavsKlavsen commented 3 years ago

2021-09-19_13-06_Sun.gpx.txt

Added recording (starting a bit before point where this issue starts - but exact same route).

Zero3 commented 3 years ago

@KlavsKlavsen thanks. I had a good look at your trace. It is from slightly different origin and destination than previously discussed, but has most of the route in common. I will base my findings on this common part:

Origin: https://www.openstreetmap.org/node/125437 Destination: https://www.openstreetmap.org/node/32359993

My thoughts and findings related to total travel time:

My thoughts and findings related to traffic signals:

KlavsKlavsen commented 3 years ago

@Zero3 Great work. I often only have to lower the speed - and can then continue for green light at most stops - since Denmark in general times the stoplights to ensure "green" flow - when you're following the speed limits (and hence hit red if you speed). This ofcourse IS directed towards the "usual routes" - but those will typicly be the ones you take for the largest part of your route - only at the end/start of a route do you diverge from what is usually the best route (and thus the one osmand will propose).

danepowell commented 2 years ago

so if route calculation "overview" - would have shown me, that drive-time is estimated to 13 minutes, and 17xtraffic light is estimated to 17 minutes - then I would have landed at the conclusion that it would be nice if one could adjust the "expected delay"

I just want to call out this great point so it doesn't get missed. Right now, the ETA calculations are a black box. When they're wrong, it's almost impossible for a new user/contributor (speaking as a new contributor here 😄 ) to determine why. Visibility into the algorithm would be quite helpful. I know it's documented in routing.xml and elsewhere, but that's not the same as seeing a calculation for an actual route.

vshcherb commented 2 years ago

They are actually printed and result is displayed in Popul with development plugin. OsmAnd finds the fastest route using routing_time, rtime for each segment. ETA is calculated by adjusted rules using complete_time and time.

This issue is related to country-specific penalties and I can confirm that I observed in some countries traffic penalties ETA should be halved at least because there are many repetitions or button-regulated traffic signals which are 90% green. 

<test vehicle="car" native="true"  start_lat="52.33993" start_lon="4.81338" target_lat="52.34832" target_lon="4.89852" 
  routing_time="791.21" complete_distance="9280.03" complete_time="766.49"  calc_timems="1.78" loaded_tiles="1336" visited_segments="17919" segments_1sec="10088"  >
    <segment id="58698915" oid="3756730573" start="1" end="7" time = "15.0" rtime = "17.0" name = "Anderlechtlaan" maxspeed = "50" distance = "215.0" tertiary turn = "Go ahead" turn_angle = "0.0" start_bearing = "-18.617128" end_bearing = "-10.007979" height = "[0.0, 0.0, 72.51129, 0.0, 58.226917, 0.0, 27.591993, 0.0, 20.738598, 0.0, 19.631685, 0.0, 3.1464224, 0.0]" description = "Go ahead and go 215.68 meters" />
    <segment id="326403224" oid="20889806355" start="0" end="2" time = "0.0" rtime = "5.0" name = "" maxspeed = "50" distance = "7.0" tertiary turn = "Take 4 exit" turn_angle = "-98.746155" start_bearing = "45.0" end_bearing = "32.735226" height = "[0.0, 0.0, 4.639766, 0.0, 3.0335295, 0.0]" description = "Take 4 exit and go 367.4 meters" />
    <segment id="325880072" oid="20856324633" start="0" end="4" time = "1.0" rtime = "1.0" name = "" maxspeed = "50" distance = "14.0" tertiary start_bearing = "18.434948" end_bearing = "-17.525568" height = "[0.0, 0.0, 3.4582734, 0.0, 3.482204, 0.0, 3.4822016, 0.0, 3.6316369, 0.0]" description = "" />
    <segment id="325880026" oid="20856321673" start="0" end="3" time = "0.0" rtime = "0.0" name = "" maxspeed = "50" distance = "10.0" tertiary start_bearing = "-34.508522" end_bearing = "-57.994617" height = "[0.0, 0.0, 3.5389755, 0.0, 3.482195, 0.0, 3.4389944, 0.0]" description = "" />
    <segment id="326403231" oid="20889806845" start="0" end="4" time = "1.0" rtime = "1.0" name = "" maxspeed = "50" distance = "14.0" tertiary start_bearing = "-73.30076" end_bearing = "-113.96249" height = "[0.0, 0.0, 3.8058317, 0.0, 3.6635065, 0.0, 3.8964076, 0.0, 3.5902297, 0.0]" description = "" />
    <segment id="326403225" oid="20889806459" start="0" end="2" time = "0.0" rtime = "0.0" name = "" maxspeed = "50" distance = "9.0" tertiary start_bearing = "-130.36453" end_bearing = "-146.30994" height = "[0.0, 0.0, 4.7842755, 0.0, 4.6001987, 0.0]" description = "" />
    <segment id="325880064" oid="20856324159" start="0" end="3" time = "0.0" rtime = "1.0" name = "" maxspeed = "50" distance = "13.0" tertiary start_bearing = "-163.73979" end_bearing = "161.56505" height = "[0.0, 0.0, 4.556667, 0.0, 4.5603147, 0.0, 4.611031, 0.0]" description = "" />
    <segment id="7385603" oid="472678601" start="0" end="3" time = "0.0" rtime = "0.0" name = "" maxspeed = "50" distance = "9.0" tertiary start_bearing = "151.69925" end_bearing = "126.25384" height = "[0.0, 0.0, 2.6911418, 0.0, 3.350942, 0.0, 3.3903677, 0.0]" description = "" />
    <segment id="7385153" oid="472649829" start="0" end="6" time = "16.0" rtime = "18.0" name = "Anderlechtlaan" maxspeed = "50" distance = "226.0" tertiary start_bearing = "165.25644" end_bearing = "160.78732" height = "[0.0, 0.0, 3.580986, 0.0, 18.30408, 0.0, 26.041454, 0.0, 95.497345, 0.0, 70.442116, 0.0, 12.739715, 0.0]" description = "" />
    <segment id="707013381" oid="45248856437" start="0" end="1" time = "4.0" rtime = "4.0" name = "Anderlechtlaan" maxspeed = "50" distance = "61.0" tertiary start_bearing = "162.10556" end_bearing = "162.10556" height = "[0.0, 0.0, 61.10204, 0.0]" description = "" />
Zero3 commented 2 years ago

@vshcherb Cool! This is the first time I head about this feature, and it would be useful for me too. I know how to enable the development module in OsmAnd, but what is this "Popul" you mention?

vshcherb commented 2 years ago

In popup (toast message) Android but that only displays total and not individual segments

Breizhux commented 1 year ago

Hello, I raise exactly the same problem for France, whose time estimates almost double... However, many cities do the opposite of Denmark: "red" flows...

I realize that it is difficult from one country to another to predict the estimated time for each intersection. Yet this calculation is important, and many people uninstall OSMAnd just because of this completely wrong calculation. However, I think it is not very complicated to create as many "routing.xml" files as there are countries, and the route calculation algorithm automatically selects the file according to the country. This way, users from all countries would be satisfied. I also wonder about the relevance of taking into account all obstacles in the ETA calculation...

Otherwise, ideally, it would be interesting that OSMAnd integrates in time the probability that the user has to be stopped at the traffic lights (idem for the other obstables of this same type: crosswalk, level crossing). This could be done locally. It would be enough to start from a default value, and by observing the driving behavior during the trips, to retain the time spent at each traffic light. If this were to happen, the values obtained could very well be sent back to OSMAnd thanks to the "Analysis" option allowing to bring back some information about the use of the application.

I admit I don't have the technical skills to contribute to OSMAnd, yet it is my favorite navigation application. But in front of such mistakes I don't always know how to defend it. And many people prefer to go back to Waze, GgMaps... Or MagicEarth which is more and more preferred even by free software advocates...