Hi,
I have configured my India map for motorcycle profile with fastest strategy. While testing with GH version 5.0, I can see that it is snapping to internal routes as opposed to Google and even GH version 0.13 which is snapping to the main road. Is there any restriction or optimization done in the later version that is giving this incorrect snapping?
Kindly help me with this.
Thanks in advance for the help!
It is not clear to me which snapping do you expect?
Hi, as depicted in the image specified by Google Maps, we can see that the snapping goes directly to the Ring Road while graphhopper 5.0 snaps through an internal route although the ring road is quite nearby and clearly the expected snapping.
Ok, you mean from the start location you expect the route to go North towards big road shown in red, instead of going South and then East before going North?
I got confused because you were talking about ‘incorrect snapping’. ‘Snapping’ is usually what we call the process of figuring out the exact point where a route starts in the road network when we are given the coordinates.
I can confirm that using recent OSM data the motorcycle profile does this detour (going South, East, then North), while the car profile goes straight North towards the motorway.
Thanks for the confirmation. That was exactly my concern.
It does seem that for motorcycle profile, this is the case. However, I would like to understand why this is the case for the version 5.0 (and even for 4.0 ) but for graphhopper version 0.13, the detour happens as google suggests which is basically the route that goes North towards the big road.
Please find the example below for version 0.13:
This is for the same motorcycle profile using fastest strategy
I’m investigating and apparently this changed between the 3.0 and 4.0 releases. The route we get for 4.0+ is both longer and takes more time, but we probably still choose it because we are trying to avoid motorways with motorcycles? @boldtrn maybe?
Oh I see.
Yes I could see that in MotorCycleFlagEncoder, we do add motorways in the avoidset for motorcycles. However, since we have major roads passing through many cities, is there any specific reason why we would want to avoid such roads for this profile?
It was this PR that changed the route: Include priority EncodedValue in CustomWeighting by karussell · Pull Request #2333 · graphhopper/graphhopper · GitHub
It seems like the change was not intentional, or at least the PR was not meant to directly change the motorcycle profile. @karussell?
Thanks for finding the work that caused this change. Indeed there was no change intended but at the same time small changes are expected as we moved this “0.5” from the Weighting into the FlagEncoder and so rounding could lead to different values.
However, since we have major roads passing through many cities, is there any specific reason why we would want to avoid such roads for this profile?
Yes, probably it is a good idea to only avoid them outside of the city. Related to: Urban encoded value · Issue #2395 · graphhopper/graphhopper · GitHub
The intention is to create a more beautiful driving experience if I correctly remember the discussion.
Is this your example rather an exception or do you experience many routes that got worse between 0.13 and 5.0? As @karussell explained there was a small change that might be only relevant in case two route options had very similar weights before. Whether or not motorways should be avoided probably depends on the exact use case. Note that you can modify the motorcycle profile using custom models if the default does not fit your needs.
Thanks a lot for your callouts @easbar and @karussell. This helps a lot.
@easbar This is one example that I had identified between the 2 versions (0.13 and 5.0). Probably there could be more since I can see that in the avoidset for motorcycles we have the following tags - motorway, trunk, motorroad and residential.
I am currently doing an analysis specifically for motorcycles and since it uses PriorityWeighting, I can see that it does return distances which are larger as opposed to the FastestWeighting class. By making use of custom models, is there a simple way to overcome this behaviour for specific vehicle types?
To summarize my concern, how would it be possible to mitigate this distance difference between versions by making use of custom models?
Yes, exactly. When the priority for some roads are high it can happen that a route is chosen even though it is longer and/or takes more time. You can try to adjust the priority calculation in MotorcycleFlagEncoder and PriorityWeighting. Using custom model you can setup detailed rules to set the priority depending on the road class etc. without changing the code, see here: graphhopper/custom-models.md at 5.x · graphhopper/graphhopper · GitHub
Got it. Thanks @easbar
It was this PR that changed the route: Include priority EncodedValue in CustomWeighting by karussell · Pull Request #2333 · graphhopper/graphhopper · GitHub
It seems like the change was not intentional, or at least the PR was not meant to directly change the motorcycle profile.
One last question. Since you mentioned that there was no change intended with the above PR, would you be picking up a fix or revert for this?
I did not look into it in detail, but sure if you manage to find out the exact reason the priority changed in this PR and this can be fixed that would be appreciated. As @karussell said there was a factor 0.5 moved from the weighting into the flag encoder and some rounding takes place, which is probably the reason for the changed priority.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
