More realistic time estimates for routes

[jansoe]

In general GraphHopper underestimates travel times (even without any traffic slow downs).
This also might lead to suboptimal routes, as the underestimation is not consistent.

Examples:

1. Routing through Madrid estimated time 13min, realistic time (without traffic!!) ~26min-> better Routing around Madrid estimated 14min, realistic ~22min
2. Routing through Mettmann estimated time 9min, realistic time ~14min
   -> better Routing around Mettmann estimated 9min, realistic ~12min
3. Berlin City estimated 19min, realistic ~28min
   (remark: 19min corresponds to continously driving 0.9*50kmh all 14.55km (maxspeed=50 is tagged all along the way))
4. way in Bayreuth has three parts with motorway the second part: 2 + 9 + 7 = 18min, but more realistic would be 4 +8 +8 = 20min
5. through the country estimated 46min, realistic 58 -> better motorway estimated and realistic 52
6. mainly through city estimated 7min, realistic 9min
   -> better motorway estimated and realistic 8min

But there are also cases of overestimation

1. munich to heilbronn estimate of 3h6min is OK, but travel time for motorway route is 3h43min but should be rather 3h0min!!!

[jansoe]

This issue also relates to #334

Possible causes are

• Not taking traffic lights, zebras or general stops at junctions into account, see Interpret traffic lights #75
• Missing maxspeed tags (but general speed default values are a bad guess as 50kmh applies as default within citys), see Car: Different max speed for inner and outer city #230 (but seems to be rather a minor problem see tags )
• incomplete parsing of maxspeed tags "maxspeed=none" and more missing #381
• Also see http://taginfo.openstreetmap.org/keys/traffic => intermediate etc and https://wiki.openstreetmap.org/wiki/Key:traffic:hourly

[kschrab]

• Taking turn costs into account would help a lot as well (time to decelerate + accelerate for a turn). For a given path it should not be that expensive to calculate. See https://algo2.iti.kit.edu/download/turn_ch.pdf (chapter 3.2)

[beeing]

Hi guys, I just found an interesting project - http://opentraffic.io

Perhaps we can simplify the calculation based on average time for each path, which then may improve accuracy of the estimates.

[karussell]

If it would be an 'open' project it would have an open forum, a public issue tracker, a public documentation site etc, I fear there is zero content on this site for us. But would love to hear your experience if you contact them :)

[beeing]

Have not contacted them. Believe it is quite new, went in to their repos and look like v2 is coming soon. Impressed with some docs and images that they have that is from v1.

[karussell]

Believe it is quite new, went in to their repos and look like v2 is coming soon.

It is at leas 1 year old

went in to their repos and look like v2 is coming soon

Which repos? Or do you mean the source code? We need data here, not code :)

[boldtrn]

Do you need traffic data for your application?
Historical and real-time travel speeds will enable accurate routing, estimated time of arrival and other transport analysis and planning applications. Follow the development of the OpenTraffic platform, and we'll let you know as APIs and data extracts become available.

I signed up for the newsletter, let's see if there are news :).

[akadeev]

When I check route examples mentioned in the first post I see online maps became much better in predicting time. For my case it does good as well, giving reasonable 12 minutes: https://graphhopper.com/maps/?point=-33.533348%2C151.304847&point=-33.485782%2C151.323629
The issue is with my local GH server (0.10.1). It returns 8 minutes for same start and end points and same length.
Do you have any idea why this could happen?
Maps downloaded from: http://download.geofabrik.de/australia-oceania.html
I do requests this way:

        graphHopper = new GraphHopperOSM().forServer();
        graphHopper.setDataReaderFile(OSM_PATH);
        graphHopper.setGraphHopperLocation(GRAPHHOPPER_PATH);
        graphHopper.setEncodingManager(new EncodingManager("car"));
        graphHopper.importOrLoad();

        GHPoint p1 = new GHPoint(-33.533348,151.304847);
        GHPoint p2 = new GHPoint(-33.485782,151.323629);
        List<GHPoint> points = new ArrayList<>();
        points.add(p1);
        points.add(p2);

        GHRequest req = new GHRequest(points)
                .setWeighting("fastest")
                .setVehicle("car")
                .setLocale(Locale.US);

        GHResponse response = graphHopper.route(req);
        response.getBest().getTime(); // Returns 496 seconds instead of about 60*12=720

[boldtrn]

Do you have any idea why this could happen?

The Directions API uses improved ETAs that are not part of the open source project. Also see this SO answer.