Estimated Arrival Time Calculation - Driving Speed

[Helmut Leininger]

Hi,

is there a possibilty to adapt the speeds used for time calculation to the personal driving habits? For me, the calculated driving times are always too short (i.e. speeds used for the calculation are too high).

Regards

[Luke Bryan]

Yes. Under http://www.openstreetmap.org/ log in, select edit. Select the street you think has the wrong speed limit. If no maxspeed tag is set on it, you may add it in the advanced tab. (maxspeed = "25 mph" or similar).

I'm not sure what speed limits Osmand is guessing when the maxspeed is not set? Anyone know if there is a way to set the default somewhere? for example, are all residential streets calculated as 25 mph?

[Nelson A. de Oliveira]

From what I understand, Helmut is saying that osmand calculates the
ETA based on the maxspeed while it should use the average speed of the
driver.

[Onkar Shinde]

I agree with original topic. The values taken for average speed are too high. It should either be calculated (and saved) based on previous driving behaviour OR it should be possible to set it for different road types.

In my home country an average speed of 70 km/h is not at all realistic for city routes. It is more like 40-45 km/h.

[pl]

This is the situation with the most of the navigation softwares.
There are mountain roads where you can drive with no more than 40 km/h for example, but the software always calculate arrival time based on the max permissive speed (in EU countries around 90 km/h, non-urban areas).
Expensive routing applications fetch live data abt. road traffic, congestions, etc. This is nice feature, but expensive.
There were many discussions in OSM Wiki about 'normal' and max speeds - see here
Prediction is a difficult job, as found years ago by Nostradamus.

[DLichti]

Regarding ETA, OsmAnd is very precise for me here in south western Germany. As long as i don't get stuck in traffic jams or things like that, my actual arrival time is almost always within 1 minute of the predicted arrival time for up to 50km.
I didn't use OsmAnd on longer voyages so much yet.

But I agree that it would be nice to be able to fine tune the ETA algorithm. Two things come to my mind:
1. A general speed multiplicator x which would tell OsmAnd to compute ETA using x*maxspeed instead of maxspeed. It should be discussed wether penaltys like traffic lights and left turns should also be modified (multiplied by 1/x) or not.
This would be very useful for people who generally drive slower or for regions with a lot of small and curved roads.
2. A general speed limit x which would tell OsmAnd to not go faster than x, even if the official speed limit allows it. I imagine this could be a little bit harder to implement since this means that all roads with speed limit greater than x should not be regarded as advantageous for navigation compared to roads with speed limit equal to x as long as they have no other advantages.
This would be useful for vehicles like cars with a trailer, trucks, tractors, buses.

David

[Helmut Leininger]

I used Osmand for a distance of 440 km in Austria, about 350 km of Autobahn, the remaining 90 km mainly Bundesstraße. The ETA was about 45 minutes to early compared with a cheap dedicated navigation device (which estimated nearly exact the time I needed).
Estimating driving times in larger cities is always difficult, it is more easy in rural areas.

Maybe the speed used for calculation could be:
Autobahn: max speed - 10 % (except where there is no speed limit as in Germany, could use 130 km/h)
rural roads: max speed - 15 %
cities: 35 - 40 km/h

[Nelson A. de Oliveira]

On Mon, Jul 8, 2013 at 3:15 AM, Helmut Leininger <hl...@gmx.at> wrote:
> Maybe the speed used for calculation could be:
> Autobahn: max speed - 10 % (except where there is no speed limit as in
> Germany, could use 130 km/h)
> rural roads: max speed - 15 %
> cities: 35 - 40 km/h

Around 5% to 10% less seems to be more ideal/real.
At least here in Brazil, it's just not possible to always travel at
the highway maxspeed (traffic, tolls, etc)

[HarveyHase]

Hi,

driving speed is influenced by roads (bad surface, bad weather, ...), by car (roadster, minivan, ...), traffic (emplty streets, jam, ...), individual driving experience (profi racer, learner, ...)
So I guess all static calculations based on speed from the maps are somehow broken.

what about:
- first guess: max-speed weighted by use of different roads (e.g. 30% max 50Km/h, 70% 120 Km/h => 99 Km/h) minus xx% (10~15%) * facter for car/bike/(pedestrian=fixed_speed 3Km/h?)
- calculate percentage of real driving speed so far to the weighted speed of the roads so far. This giving a factor like "Im driving at 74% of the first-guess-speed"
- use this factor for calculation of the still to go distance. This means, I will more or less drive with the same relative speed to the first-guess-speed in the ongoing navigation. This might proove wrong, but will be adapted automatically
- update this factor from time to time, but not too often. This will update the calculation of the estimated arrival time based on the real situation of the already driven part of the navigation.

By this calculation you dont need information of the road, traffic etc as everything ist calculated by this automatic factor from the latest navigation.
Even keeping this factor for a new calculations seems to me better than static/maximum legal speed from the map.

just my idea ...

[Harry van der Wolf]

I'm currently on holidays in England and I've driven some 120 kilometres with about 70 on "motorway" where I was allowed to drive 70 mph. After about 12-18 roundabouts I can tell you that the average speed minus 10-15% is still way too high. But maybe this road was an exception.
So a user adjustable set of settings (min/max %) for motorways, trunks, primary and secondary roads might be fine.

Harry

[David Levy]

I'm a new user in Boston, Mass., and the estimated travel times are between 35% and 50% of actual times. The program seems to assume 30mph through city streets - doesn't take account of traffic or junctions+lights.
But bigger issue is that this is causing major routing errors, as it pushes the routing preference to side streets.

There must be relatively easy ways to improve the algorithm for journey time and routing, even without real time traffic, e.g. use average, not max speeds in urban areas, by class of road; and/or number of junctions.

[Sabra Sharaya]

By default, the app also considers streets with stop signs to be faster than streets with traffic lights.

[David Levy]

from what I can see checking several routes, the program seems to allow a bit under 2 minutes per mile in the urban area, with little regard to the number of lights or intersections. Actual journey times are at least twice the estimate without traffic. And it systematically routes over roads that are more direct but much slower due to many intersections. I have not done systematic tests, just some local routes so far.

[David Lichti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Did you check the fastest route/shortest route setting in the
navigation settings?

David

> -- You received this message because you are subscribed to a topic
> in the Google Groups "Osmand" group. To unsubscribe from this
> topic, visit
> https://groups.google.com/d/topic/osmand/wbAimqGTRyU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email
> to osmand+un...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJR8N1CAAoJEJmIEsQzdXsqSFMH/jGaN+mtbaRupcOarbuPIyoI
WoRjhI/xWWIKuIJzYDIzWTssDN1caooaly7pgfx7txGG8HbZX7siatqYbZuvcXkB
Rht+7IF8Zm9IEvwYYOmyHJYnl6eodVafkWSDia2YmPrxRsHEZ0O8JxdbHQu8tsjH
5IDlraXCjxGK9bTxj0goBOtPpxFdIJYyk/4dZspSYQ31riS4x02n0Wq87wZLXZUC
HpLySNAaL4VcRLGml4LNicm0jUfpZJDUShwpvH8rDIQZ+XKAGltIAraFbEa6KRbn
rU92ZNKXC8C6zow3ilxWL20xbQarIXV0kcwlZBkP1wiXNnzQgJfEG9Pzu1XnuuM=
=JE7O
-----END PGP SIGNATURE-----

[David Levy]

yes, I'm on fastest route, thanks for suggestion.