feat: enable ors surface ev

[sfendrich]

Pull Request Checklist

• 1. I have [rebased][rebase] 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][config]
  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][api].

Related to #2107 .

Information about the changes

• Key functionality added: enabled OrsSuface encoded value for custom profiles

[Copilot]

Pull Request Overview

This PR enables the OrsSurface encoded value for custom profiles by implementing the necessary parser infrastructure and updating the GraphHopper version. The change allows routing profiles to utilize surface type information (e.g., asphalt, gravel, dirt) in custom routing models.

• Upgrades GraphHopper version from v4.9.8 to v4.9.9
• Implements OrsSurfaceParser to handle surface tag parsing from OSM data
• Updates tag parser factory to register the new surface parser

Reviewed Changes

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

Show a summary per file

File	Description
pom.xml	Updates GraphHopper version to v4.9.9
OrsSurfaceParser.java	Implements new parser for surface encoded values with comprehensive surface type mapping
OrsTagParserFactory.java	Registers OrsSurfaceParser in the tag parser factory
OrsEncodedValueFactory.java	Refactors if-else to switch statement for better maintainability
ORSGraphHopperConfig.java	Updates surface encoded value reference from Surface to OrsSurface
ResultTest.java	Updates test to use correct encoded value name
CHANGELOG.md	Documents the new feature

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[aoles]

Thank you for enabling the first ORS-specific encoded value! 🚀

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud