feat: improve track grade parsing

[hwiks]

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.
• [not applicable] 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.
• [not applicable] 6. I have created API tests for any new functionality exposed to the API.
• [not applicable] 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).
• [not applicable] 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).
• [not applicable] 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).
• [not applicable] 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 applicable] 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes #1774.

Information about the changes

• Parsing of lists of track grades now work when lists are separated by '-'
• Parsing of grades between 6 and 8 are now all parsed as 6 to extract some meaningful analysis
• Parsing of lists of track grades now follow rules for single grade parsing (6,7,8 return 6, higher than 8 or not numbers return 1)
• tests are now implemented for getTrackGradeLevel, documenting the expected behaviours
• Reason for change: lists of grades using - were not parsed, and parsing of lists did not follow single parsing rules. Also, no tests were implemented yet for the function in the abstract class VehicleFlagEncoder

NOTE: This is my first PR in this project, please review with extra care and especially please double check that my tests make the correct assumptions about desired behavior!!

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

• not applicable

Required changes to ors config (if applicable)

• not applicable

[koebi]

Hey,

thanks a lot for your contribution, and especially thanks for creating tests!

I have not looked at the code explicitly, but rather at the tracktype-key itself, and I am curious:

When looking at the OSM wiki description for the tracktype key, this only lists grade1 through grade5, and according to the taginfo page for tracktype, these cover 99.95% of values.

I would love to see this aligned in the OSM a bit better, rather than complicating the tag parsing of the openrouteservice, but there might be good reason for the openrouteservice to handle this.

Could you provide an example on where the current routing fails, i.e. what caused you to add this PR?

Last, as a minor nitpick:
We do use conventional commits - see https://www.conventionalcommits.org/ - so it would be great if you had the time to re-name your commits accordingly :) If not, we will take care of it, no worries.

Best regards :)

[hwiks]

Thank you for your comment!

For your question about the grade parsing: I did none of the thinking. I executed what @aoles describes in their ticket here: #1774

It looks like the problem for them is that many mistakes could be bundled up and analyzed as a non-existent tag '6', and they provide a count.

Regardless, at the moment the lists are handled in such a way that the returned tag can be any number as long as it's the higher number in the list, and that is not, to my understanding, meaningful behavior.

I'm very happy to change the logic to whatever your group agrees on! Let me know if there is an agreement :)

As for the commit message, no problem! I'll squash all commits into one with the right format once the logic is defined :)

Thank you so much for taking the time!

[Copilot]

Pull request overview

Enhances OSM tracktype parsing in the GraphHopper flag encoder layer (ORS engine) to better handle combined/range-like values (notably --separated lists) and adds unit tests documenting expected parsing behavior.

Changes:

• Extend getTrackGradeLevel parsing to support ; and - separated grade lists via helper parsing methods.
• Normalize grades 6–8 to level 6 when encountered (including in lists).
• Add new VehicleFlagEncoderTest coverage for null input, list parsing, whitespace handling, and invalid values.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
ors-engine/src/main/java/org/heigit/ors/routing/graphhopper/extensions/flagencoders/VehicleFlagEncoder.java	Refactors and expands track grade parsing (supports -, adds helper parsing logic, normalizes 6–8).
ors-engine/src/test/java/org/heigit/ors/routing/graphhopper/extensions/flagencoders/VehicleFlagEncoderTest.java	Introduces tests for getTrackGradeLevel, including list parsing and invalid/edge cases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aoles]

Thanks a lot @hwiks for your contribution and patience! ❤️

We have had a discussion it the team and came up with a somewhat standardised and simplified approach. The general idea is to stick with the values returned by getTrackGradeLevel() to ones corresponding to the official set of values ranging from grade1 to grade5. The will find the updated proposal in the comment on the issue.

Looking very much forward to reviewing your modified code 🤓

Cheers!
Andrzej

[hwiks]

Hello! Thank you for the clear added comments: I added the changes and updated the tests, as well as committed in the conventional commit format. Hopefully all is correct, the tests should also clarify how I expect the code to behave in some edge cases, such as: a list of grades where one of them is unparsable should return 0. If you think those edge cases should be handled differently, let me know and I'll update it 👍

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud