Skip to content

Conversation

@MichaelsJP
Copy link
Member

@MichaelsJP MichaelsJP commented Oct 20, 2025

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 #2169 .

Information about the changes

  • added type-specific filtering of point features
  • implemented PostgreSQL-backed feature store with scheduled synchronization for dynamic routing data updates
  • enhanced status API to expose dynamic data statistics and feature store metrics
  • added matching endpoint documentation

@takb takb marked this pull request as ready for review November 13, 2025 14:26
@takb takb requested a review from Copilot November 13, 2025 14:26
Copilot finished reviewing on behalf of takb November 13, 2025 14:32
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR implements a feature store system that enables dynamic routing data updates without requiring graph rebuilds. The feature introduces matching capabilities for geographic features (points, lines, polygons) to graph edges, database-backed feature storage, and dynamic data synchronization.

Key Changes

  • Added feature matching service that maps geographic features (borders, bridges, roads) to graph edges with type-specific filtering
  • Implemented PostgreSQL-backed feature store with scheduled synchronization for dynamic routing data updates
  • Enhanced status API to expose dynamic data statistics and feature store metrics

Reviewed Changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated 32 comments.

Show a summary per file
File Description
EdgeFilterSequence.java Made add() method chainable by returning this
RoutingProfile.java Added dynamic data management methods and statistics tracking
MatchingRequest.java Refactored matching logic with feature-type-specific edge filtering (borders, bridges)
DynamicDataProperties.java Split into global configuration with database connection settings
DynamicDataProfileProperties.java New profile-specific dynamic data configuration
EncodedValuesProperties.java Added road_environment encoded value support
LogieRoads.java, LogieBorders.java Extended enums with additional states (UNSPECIFIED, UNCLEAR, ALTERNATIVE_ROUTE)
HashMapSparseEncodedValue.java Added statistics tracking with count and last-updated timestamp
MatchingService.java Enhanced to parse GeoJSON features with user data properties
DynamicDataService.java Refactored with incremental updates, timestamp tracking, and feature store statistics
StatusAPI.java Refactored to expose dynamic data and feature store statistics
Utils.java Added utility method to detect JUnit test context
AbstractContainerBaseTest.java Moved container setup to shared base class with feature store schema
ParamsTest.java Added feature-specific matching tests and timestamp validation
Configuration files Added maximum_search_radius and road_environment settings
Comments suppressed due to low confidence (1)

ors-api/src/test/java/org/heigit/ors/apitests/dynamicrouting/ResultTest.java:51

class ResultTest extends AbstractContainerBaseTest {

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

@aoles aoles marked this pull request as draft November 13, 2025 15:03
@aoles

This comment was marked as resolved.

This comment was marked as resolved.

@aoles aoles force-pushed the feat/matching_endpoint branch from 7ae0ecd to dc953d3 Compare November 18, 2025 00:19
@sonarqubecloud
Copy link

@github-actions github-actions bot added feature and removed feature labels Nov 18, 2025
@aoles aoles self-assigned this Nov 18, 2025
@aoles
Copy link
Member

aoles commented Nov 18, 2025

Still TODO: list all the individual additions & changes from this PR in the changelog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Documentation on matching endpoint missing

4 participants