graphhopper: average_speed was infinite error in PathDetail calculation

I am running into this error:

https://github.com/graphhopper/graphhopper/blob/e72c67d7fdad39c5cd1b3ecaeb91ec65ae5d9eb2/core/src/main/java/com/graphhopper/util/details/AverageSpeedDetails.java#L37-L41

I think the error is thrown whenever the edge distance is below a certain threshold (because then calcMillis will return zero). What mechanism is supposed to prevent this error ? We’d have to exclude edges below a certain distance or something (which as far as I know we do not) ?.

And another question: Why are we calculating speed=distance/time here ? Can we not just use the averageSpeedEnc to obtain the speed directly from the edge ?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 33 (33 by maintainers)

Commits related to this issue

AverageSpeedDetails: avoid exception for short edges, fixes #1848 — committed to graphhopper/graphhopper by karussell 4 years ago
AverageSpeedDetails: avoid exception for short edges (#1871) * AverageSpeedDetails: avoid exception for short edges, fixes #1848 * add comment for this limitation Co-authored-by: Andi <easbar.m... — committed to graphhopper/graphhopper by karussell 4 years ago

Most upvoted comments

Do you have a unit test for recreating the scenario?

No, not yet. But I ran measurement on bayern-140101.osm.pbf and got the error with many different seeds (I did not even find a seed so it did not happen, and it failed for many different edges as well so really suprised this did not cause any problems so far). But sure, I’ll try to build a failing test case.

Because if distance is 0 than I would expect NaN (0/0) instead of infinity (x/0).

The distance was not zero, for example it was 0.014 in one case (so still above 0.001, the minimum tower node distance in OSMReader). Still, calcMillis can be exactly zero, because it uses a cast to long.

No longer. See #1551 and the recent fix #1798.

Ah ok this makes sense yes.

easbar on Jan 9, 2020

Can we reduce this to a normal bug status 😃

Ok, sleep well 😉

easbar on Jan 9, 2020