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

[GTFS-Fares v2] Multi-leg Transfer: Same product/media transfer behavior #420

Open
tzujenchanmbd opened this issue Dec 21, 2023 · 2 comments · May be fixed by #423
Open

[GTFS-Fares v2] Multi-leg Transfer: Same product/media transfer behavior #420

tzujenchanmbd opened this issue Dec 21, 2023 · 2 comments · May be fixed by #423
Labels
Extension: GTFS-Fares Issues and Pull Requests that focus on GTFS-Fares Extension Status: Pull Request Created Issues that have been transferred to the Pull Request stage. Status: Stale Issues and Pull Requests that have remained inactive for 30 calendar days or more.

Comments

@tzujenchanmbd
Copy link
Collaborator

Use Case

  1. When riders transfer between multiple legs during their journey using fare products, there are typically two scenarios:
  • In the case of a "ticket-based system" (i.e., a product similar to a pass), special transfer rules between two legs (such as free transfers) must be applied using the same fare product.
  • In a "stored-value system" (i.e., a general pay-as-you-go product), special transfer rules between two legs do not require the use of the same fare product.
  1. Most transfer rules between two legs necessitate the use of the same fare media to apply, but there are exceptions. For instance, within a region, two networks might exist where one has introduced an app media while the other only uses paper tickets. In such cases, transfer rules might apply between two distinct fare media (for example, showing a paper ticket to the driver to get a free transfer).

Problem to solve

The current Fares v2 spec does not have mechanism for differentiating the above use cases or provide explanation within its description, leading to potential ambiguity. This is especially relevant for certain transit systems, such as STM, that operate 100% with a ticket-based system. Transit firstly posed the question, "Should fare transfers require that the same fare product is used on both legs?" Subsequently, Google also raised the following questions in this transfer semantics document [this issue only discusses the first three questions in this document]:

  • For a leg-to-leg transfer to match a row in fare_transfer_rules.txt, is it required that both legs have the same fare media type?
  • Is it intended that multiple rows in fare_transfer_rules.txt can match a single leg-to-leg transfer?

Proposed solution

On October 24th, the working group reached a consensus to clarify these questions, leaning towards a default behavior mechanism to minimize any potential breaking changes. Based on this consensus, we drafted this proposal that aims to resolve the above 3 questions.

In the November discussion, the working group is currently leaning towards option 1 proposed, which involves adding fare_product_behavior, fare_media_behavior, and filter_fare_product_id to fare_transfer_rules. This option is favored as this mechanism appears to be more like the attributes of fare_transfer_rules (with option 2 being an alternative).

We'd love to see any feedback on this proposal or any related use cases. Please feel free to share any thoughts on this issue.

@tzujenchanmbd tzujenchanmbd added the Extension: GTFS-Fares Issues and Pull Requests that focus on GTFS-Fares Extension label Dec 21, 2023
@npaun
Copy link
Contributor

npaun commented Dec 21, 2023

Given that this topic has already been discussed at two meetings, I think there is enough consensus to move to the PR stage, where we can easily handle any needed changes in wording.

@tzujenchanmbd tzujenchanmbd linked a pull request Jan 8, 2024 that will close this issue
@eliasmbd eliasmbd added the Status: Pull Request Created Issues that have been transferred to the Pull Request stage. label Jan 12, 2024
Copy link

This issue has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

@github-actions github-actions bot added the Status: Stale Issues and Pull Requests that have remained inactive for 30 calendar days or more. label Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Extension: GTFS-Fares Issues and Pull Requests that focus on GTFS-Fares Extension Status: Pull Request Created Issues that have been transferred to the Pull Request stage. Status: Stale Issues and Pull Requests that have remained inactive for 30 calendar days or more.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants