Repository navigation
feat: implement multi transport types for the same dataset - #2579
Conversation
|
Add a TransportType value type and per-mode travel-time/distance matrices on Location, so the same routing problem can use more than one transport profile (e.g. car + bike). The default CAR mode keeps the existing scalar/ timeframe fields and index-cache fast path; extra modes are stored in opt-in maps that stay null for single-mode problems. The TravelTimeMatrixEnricher fetches one matrix set per transport type (each resolving to its own OSRM instance), and map-service.transport-type now accepts a comma-separated list of modes (first entry is primary). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ea51de8 to
862e09d
Compare
Resolved conflicts in TravelTimeMatrixEnricher and LocationsAwareSolverModel: keep the per-transport-type enrichment and getTransportTypes(), and take main's null check on the locations and the default getLocationSetName(). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…mething that the model builder can configure
|
There seem to be formatting issues; could you please have a look @diogodanielsoaresferreira ? |
rsynek
left a comment
There was a problem hiding this comment.
Thanks for addressing all the comments!
|
I think the downstream build fails as the branch name does not match, is that correct @diogodanielsoaresferreira ? @winklerm Looking at FSR, it uses the |
@rsynek @diogodanielsoaresferreira Very good catch! Looking at it now, it seems to me we should add it into the API package, or provide another way in the API to construct the The build passes locally, but I need to double check if the new Location API variants with transport type are called in all new places meanwhile merged to main. Update: checked and it seems all good at the moment. |
winklerm
left a comment
There was a problem hiding this comment.
Thank you, looks good to me!
I have left one question inline.
Other than that, it would be nice to resolve MapServiceOptionsSupplier being unavailable in the public API, see Radek's comment, but fine to leave that out of scope because it was not introduced by these changes.
| List<TransportType> datasetTransportTypes = solverModel.getTransportTypes().stream() | ||
| .filter(Objects::nonNull) | ||
| .distinct() | ||
| .sorted() // Deterministic order; CAR, when used, comes first and is therefore the primary one. |
There was a problem hiding this comment.
Q: Looks a bit fragile to me - if we add a new transport type BOAT, will it become primary?
There was a problem hiding this comment.
TLDR added a comparator to make car always first.
To be clear on what this does, the first transport type is used as primary, which means:
- if a request to the location is done without specifying the transport type, it will use that one as default
- that map is used to check the locations out of map.
I don't think it's that much of a deal to not have car first, but I think that it's a nice improvement, taking into account that maps with CAR are the ones usually running, so we can check if there is any location out of the map faster.
I updated to add a comparator and make the default transport type more visible
|
@diogodanielsoaresferreira today is a cut-off for the solver release and this PR is in my opinion close to merging. I would take the Could you please respond to Marek's other comment and rebase the PR on top of |
Done ✅ I agree with taking the MapServiceOptionsSupplier out of the scope. I also created a branch with the same name in FSR so that the tests can run (and they are 🟢 ). |


Allow to solve routing problems with more than one transportType.
Created additional properties in Location so that we keep the hot path without the Map access.
Related with https://github.com/TimefoldAI/timefold-platform/issues/2690