fix: Implicit vehicle access handling for ferries

[koebi]

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.
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 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.

Not sure if there are any cases that would be covered by the or-part of the original if-statement that are not caught by the new statement…

One would probably have to change hgv as well, I think?

Information about the changes

• Key functionality added: Use ferries that do not have any general or vehicle-specific access tag (such as foot, motorcar, access, …), but only the route=ferry tag.
• Reason for change: According to the tag filtering logic we accept these ways, which I think makes sense.
  Whether it makes sense to only do that if foot or bike are absent, I don't know…

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

This route using such a ferry in norway will now be available.

[aoles]

FYI: The logic to allow access only in the absence of foot or bike tags has been adopted from graphhopper and has been originally introduced in graphhopper/graphhopper@f87fba4.

[aoles]

Many thanks for the prompt fix! 🚀

Looks aready quite good. Would you mind adding:

• corresponding changes to the HGV flag encoder/tests
• an entry in the CHANGELOG file?

Cheers! ❤️

[aoles]

Hi @koebi,
thanks for implementing the suggested changes! Unfortunately, a few API tests started failing, some with quite big deviations from the expected values 💀 I'm a bit puzzled by this, especially as this PR effectively restores the original behavior that got broken in #1291. There the influence on API tests was negligible.

[aoles]

Some of the proposed changes seem to break the routing 💀 This is evident e.g. when looking at the route from testHGVHazmatRestriction api test for hazmat = true (blue is the reference as on main, and red the results calculated with this branch)

Apparently some sort of secret tram routing option got activated, see below 😂

Not sure what the following is about though 🙈

[aoles]

LGTM! 🚀

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
45.5% Coverage on New Code
6.9% Duplication on New Code

See analysis details on SonarQube Cloud