Skip to content

feat: implement multi transport types for the same dataset - #2579

Merged
triceo merged 28 commits into
mainfrom
draft/transport-type-aware-location
Oct 14, 2026
Merged

triceo merged 28 commits into
mainfrom
draft/transport-type-aware-location

Conversation

@diogodanielsoaresferreira

@diogodanielsoaresferreira diogodanielsoaresferreira commented Aug 10, 2026 •

Copy link
Copy Markdown
Contributor

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

@sonarqubecloud

Copy link
Copy Markdown

Quality Gate Failed Quality Gate failed

Failed conditions
31.1% Coverage on New Code (required ≥ 70%)

See analysis details on SonarQube Cloud

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>
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>
@rsynek

rsynek commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

There seem to be formatting issues; could you please have a look @diogodanielsoaresferreira ?

@rsynek rsynek left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks for addressing all the comments!

@rsynek

rsynek commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

I think the downstream build fails as the branch name does not match, is that correct @diogodanielsoaresferreira ?

@winklerm Looking at FSR, it uses the MapServiceOptionsSupplier (an impl class, not a part of the API) in the validator.

@winklerm

winklerm commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

I think the downstream build fails as the branch name does not match, is that correct @diogodanielsoaresferreira ?

@winklerm Looking at FSR, it uses the MapServiceOptionsSupplier (an impl class, not a part of the API) in the validator.

@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 MapService with parameters respecting map service configuration. Having said that, this problem was already there before this PR, so up to you if you want to address it here or send another PR for that.

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 winklerm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Q: Looks a bit fragile to me - if we add a new transport type BOAT, will it become primary?

@diogodanielsoaresferreira diogodanielsoaresferreira Oct 14, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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

@rsynek

rsynek commented Oct 14, 2026

Copy link
Copy Markdown
Contributor

@diogodanielsoaresferreira today is a cut-off for the solver release and this PR is in my opinion close to merging.

I would take the MapServiceOptionsSupplier out of the scope, as it has been already introduced before.

Could you please respond to Marek's other comment and rebase the PR on top of main?

@diogodanielsoaresferreira

Copy link
Copy Markdown
Contributor Author

@diogodanielsoaresferreira today is a cut-off for the solver release and this PR is in my opinion close to merging.

I would take the MapServiceOptionsSupplier out of the scope, as it has been already introduced before.

Could you please respond to Marek's other comment and rebase the PR on top of main?

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 🟢 ).

@winklerm winklerm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thank you, looks good!

This branch was successfully deployed

2 active deployments
documentation (preview) — fd8b482c Deployed Oct 14, 2026 by diogodanielsoaresferreira via Build Documentation #787
internal — fd8b482c Deployed Oct 14, 2026 by diogodanielsoaresferreira via approval_required #5072
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants