Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PT Submode specific transfer constants #3013

Merged
merged 5 commits into from
Jan 5, 2024

Conversation

jfbischoff
Copy link
Collaborator

A transfer between different PT submodes can have a very different impact, depending on the transport modes - in our case, transfers between train journeys and local public transit should be evaluated differently by the transit router than those between two train sections. Obviously, the impact would be even bigger if long-distance modes are considered, i.e., switiching airplanes or changing from a train to a ship 🚢

This PR allows for additional constants in the SwissRailRaptor Config.

@sebhoerl
Copy link
Contributor

Hi, @jfbischoff, so if I see correctly this only affects the routing, not scoring. On a more general note: In most cases the routing costs (for finding the route) will not correspond to the utiltiies/scores for performing mode choice (based on the routed path in a particular situation). So for that reason already for some time we override the RaptorConfig via injection to make Raptor use different parameters than those used in scoring. Actually, we can quite nicely calibrate those parmeters from HTS data because we know the number of transfers and modes that everybody took on their trips, so we can calibrate the routing parameters such that we get good routes from Raptor that correspond to the people's behavior. Especially because we use individual VOTs for the PT modes.

Long story short: Are you planning in generalizing the configuration of routing parameters for Raptor like with those constants / decoupling it from scoring eventually? This would be quite useful, than we can avoid or injection overrides. And, potentially, this could refer to the TransitRoute mode, because also right now, to distinguish between modes, we have to register modes like "pt:bus", "pt:rail", "pt:subway" so Raptor picks up the different cost parameters.

@jfbischoff
Copy link
Collaborator Author

jfbischoff commented Jan 5, 2024

Hi @sebhoerl

Are you planning in generalizing the configuration of routing parameters for Raptor like with those constants / decoupling it from scoring eventually?

Yes, I think that would make a whole lot of sense. Right now, a person-specific PT routing is possible, but simply replacing all routing parameters is somewhat trickier. I think it's something to work on in the next time.

…nsfer-times

# Conflicts:
#	matsim/src/test/java/ch/sbb/matsim/config/SwissRailRaptorConfigGroupTest.java
@jfbischoff jfbischoff enabled auto-merge January 5, 2024 10:15
@jfbischoff jfbischoff merged commit 9561281 into master Jan 5, 2024
48 checks passed
@jfbischoff jfbischoff deleted the feature/improve-transfer-times branch January 5, 2024 10:33
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.

2 participants