GIScience / openrouteservice

🌍 The open source route planner api with plenty of features.
https://openrouteservice.org
GNU General Public License v3.0
1.33k stars 379 forks source link

Unexpected durations when using quiet or green routing #632

Closed sfendrich closed 4 years ago

sfendrich commented 4 years ago

Here's what I did

Send this request:

{"coordinates":[[8.404056381665544,49.00957154757667],["8.47001","48.99956"]],"elevation":true,"language":"de","maneuvers":true,"options":{"avoid_features":[],"profile_params":{"weightings":{"green":0,"quiet":0}}},"profile":"foot-walking"}

Here's what I got

Duration of about 3h (Distance 5.1km).


Here's what I was expecting

Duration of about 1h.


Here's what I think could be improved

When the green and quiet routing factors a set to 0, the duration should match the duration of a regular routing request not using green/quiet routing at all.

MichaelsJP commented 4 years ago

Seems as the actual routing is not affected, only the time calculation is wrong and seems to be doubled at some point. As soon as one weighting is used, the time increases for one hour and together it makes up +2h in time travel.

MichaelsJP commented 4 years ago

@sfendrich I dug into the weighting extensions for a bit and I think I solved the mysterious duration thing.

Setting one of the two weightings to zero, doesn't mean they're not going to be applied. The weighting values just work as a weighting factor.

For e.g. quiet routing: https://github.com/GIScience/openrouteservice/blob/735f98744811be2426988e324177349fabbaa295/openrouteservice/src/main/java/org/heigit/ors/routing/graphhopper/extensions/weighting/QuietWeighting.java#L37 that means there is still a natural factor applied to the route calculation and the speed reduced by it's half. It's obvious in the above example where the speed of 5kph was just reduced to 2.5kph and therefore doubling the needed travel time even though the weighting itselfs was 0.0.

Imo this is not a bug but something that just needs to be communicated mroe clear in the api documentation @TheGreatRefrigerator .

TheGreatRefrigerator commented 4 years ago

If you decide this needs more documentation: That's not my job anymore 😛 The documentation is autogenerated using swagger anotations in the backend. https://github.com/GIScience/openrouteservice/blob/d1e158a96f1f8053c16f5d60c49772d8c4ccf784/openrouteservice/src/main/java/org/heigit/ors/api/requests/routing/RequestProfileParamsWeightings.java#L38-L46

Anyways: why does the speed get reduced by half, when requesting green or quiet routes?

aoles commented 4 years ago

I still don't get it: if the same route is returned, it should also take the same amount of time to traverse it. AFAIU quiet/green routing is about prioritizing certain edges in route calculation by modifying their weights while keeping the travel speed (or duration) assigned to the edges unchanged. Am I missing something here @sfendrich ?

aoles commented 4 years ago

BTW: when I query for the provided example on maps.openrouteservice.com with both green an quiet routing enabled I get the expected travel time of 3675s. Where do the higher numbers reported by @sfendrich and @MichaelsJP come from?

TheGreatRefrigerator commented 4 years ago

BTW: when I query for the provided example on maps.openrouteservice.com with both green an quiet routing enabled I get the expected travel time of 3675s. Where do the higher numbers reported by @sfendrich and @MichaelsJP come from?

that's a bug. Probably introduced when i switched to v2 endpoint. It doesn't pass the green or quiet options.

MichaelsJP commented 4 years ago

BTW: when I query for the provided example on maps.openrouteservice.com with both green an quiet routing enabled I get the expected travel time of 3675s. Where do the higher numbers reported by @sfendrich and @MichaelsJP come from?

@aoles The results are coming from the interactive docs.

MichaelsJP commented 4 years ago

@aoles When I request it on maps.openrouteservice.com the payload looks like this: {"preference":"fastest","language":"en-US","instructions":true,"geometry":true,"units":"m","attributes":["detourfactor","percentage"],"instructions_format":"html","elevation":true,"coordinates":[[8.404056,49.009572],[8.469944,48.999592]],"extra_info":["steepness","waytype","surface"]}

So no sign of the weightings. Seems to be another bug. Just try it out on the playground.

sfendrich commented 4 years ago

I still don't get it: if the same route is returned, it should also take the same amount of time to traverse it. AFAIU quiet/green routing is about prioritizing certain edges in route calculation by modifying their weights while keeping the travel speed (or duration) assigned to the edges unchanged. Am I missing something here @sfendrich ?

At least, this is what I would expect. IMO it makes no sense to travel at lower speed just because we prefer quiet routes. If the same route is returned it should have the same travel time and the same distance. In addition, we might report a "quietness" or "greenness" of the route.

Anyway, looking through the code, it looks rather experimental.

aoles commented 4 years ago

Thank you, now I can confirm your findings @MichaelsJP.

If I understand it correctly the idea of the route weightings is to modify edge weights for routing in order to change the resulting route rather than make any changes to the travel mode itself (here: average walking speed). If this is true then if the green/quite route has the same geometry as the original one no changes in travel time should be observed.

MichaelsJP commented 4 years ago

Thank you, now I can confirm your findings @MichaelsJP.

If I understand it correctly the idea of the route weightings is to modify edge weights for routing in order to change the resulting route rather than make any changes to the travel mode itself (here: average walking speed). If this is true then if the green/quite route has the same geometry as the original one no changes in travel time should be observed.

In fact the routes are not the same. If you apply the weights with 0.0 there is a slight difference. That results from the fixed internal weight, that is still applied, just without the factor. So setting the weights activates the whole thing, even with values being zeroed.

MichaelsJP commented 4 years ago

So, I guess I'll just clarify the weight descriptions more, so it's clear that they're just factors.

Regarding the actual green or quiet implementation we should open a new issue and discuss eventual changes in there.