fix(isochrones): avoid speed reduction on ways tagged with access=destination

[aoles]

Pull Request Checklist

• 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
  have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
  [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
  along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset
  (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
  importer etc.), I have generated longer distance routes for the affected profiles with different options
  (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
  points generated from the current live ORS.
  If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage
  and why the change was needed.
• 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

• Key functionality added: ignore speed penalty on roads tagged with access = destination when computing isochrones.
• Reason for change: isochrones starting around ways tagged as access = destination were smaller than expected

Examples and reasons for differences between live ORS routes, and those generated from this pull request.

Original 5-minutes isochrone (the smaller inner polygon) vs. one generated with this PR (the larger enclosing polygon).

[koebi]

Hey,

two questions:

1. Can you explain what is happening and why it is solving the issue?
2. This is another workaround for the workaround that access:destination is penalized instead of handled correctly, right? Do we have an issue for that?

[sfendrich]

LGTM!

[aoles]

Thanks @koebi !

A proper solution for handling access:destination tags via a priority-type of weighting has been already implemented in #1412. This solution uses LimitedAccessWeighting to wrap around a given weighting returned by

openrouteservice/ors-engine/src/main/java/org/heigit/ors/routing/graphhopper/extensions/ORSWeightingFactory.java

Line 55 in 20ddcbf

public Weighting createWeighting(Profile profile, PMap requestHints, boolean disableTurnCosts) {

The weighting for isochrones, however, is initialized outside of this method and was originally set to either GH's FastestWeighting or ShortestWeighting. The problem with FastestWeighting is that GH has their own, speed-based solution to penalize access:destination ways. Therefore, ORSFastestWeighting which overrides and disables this behavior should be used instead.

One could argue that for isochrone calculation LimitedAccessWeighting should be used as well. However, in the current implementation this won't work because the numbers returned by the weighting are interpreted as time counted to the isochrone limit, which effectively acts like a speed limit. A proper solution would require keeping separately track of the weighting used by Dijkstra, and the actually elapsed travel time for the stopping criterion 🤓

[koebi]

But LimitedAccessWeighting also penalizes access:destination instead of blocking access if neither start nor end nor any waypoint are inside the access:destination area, as the restriction is intended, right?