Skip to content

fix: make stop_without_zone_id conditional on fare rule type (#1663) - #1682

Closed
ghost wants to merge 1 commit into
MobilityData:masterfrom
michaelandrewkearney:master
Closed

fix: make stop_without_zone_id conditional on fare rule type (#1663)#1682
ghost wants to merge 1 commit into
MobilityData:masterfrom
michaelandrewkearney:master

Conversation

@ghost

@ghost ghost commented Mar 1, 2024

Copy link
Copy Markdown

Summary:

Resolves #1663 by updating StopZoneIdValidator to issue notice about a stop without zone_id defined only when the stop is contained in a trip contained in a route defined in a fare rule with zone fields defined. Change from previous logic which warned about stops without zone_id defined if any fare rules had zone fields defined.

  • The warning is still only triggered for stops where location_type is 0.
  • Zone fields in fare_rules.txt are origin_id, destination_id, and contains_id.
  • Adds tests to StopZoneIdValidatorTest to confirm expected behavior as described below.

Note that a previous, nearly-identical version of this pull request was closed and abandoned because of issues with the commit email address and the CLA.

Expected behavior:

If a stop of location_type 0 does not have a zone_id defined, and that stop is defined as part of a trip in stop_times.txt, and that trip is defined as part of a route in trips.txt, and that route is defined in a fare rule in fare_rules.txt, and that fare rule has any of origin_id, destination_id, or contains_id defined, then a stop_without_zone_id notice is issued.

Exactly one notice is issued per stop that meets the criteria to issue a notice even if that stop meets the notice criteria through multiple combinations of trips, routes, and fare rules.

The notice is never issued if a stop has a zone_id defined, even if that zone_id is never defined in a zone field of a fare rule associated with the stop by the (stop_time > trip > route) chain described above.

This pull request fixes the issue on the test feed provided by westontrillium in google/transit #429.

Validator results on test feed without fix:
Validator results without fix

Validator results on test feed with fix:
Validator results with fix

Please make sure these boxes are checked before submitting your pull request - thanks!

  • Run the unit tests with gradle test to make sure you didn't break anything
  • Add or update any needed documentation to the repo
  • Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
  • Linked all relevant issues
  • Include screenshot(s) showing how this pull request works and fixes the issue(s)

…yData#1663)

- Update `StopZoneIdValidator` to issue notice about a stop without `zone_id` defined only when the stop is contained in a trip contained in a route defined in a fare rule with zone fields defined.
- Change from previous logic which warned about stops without `zone_id` defined if any fare rules had zone fields defined.
- The warning is still only triggered for stops of location type `0`.
- Zone fields in `fare_rules.txt` are `origin_id`, `destination_id`, and `contains_id`.
@ghost

ghost commented Mar 1, 2024

Copy link
Copy Markdown
Author

All notices dropped in acceptance testing are of type stop_without_zone_id.

@ghost
ghost marked this pull request as ready for review March 1, 2024 22:51

@emmambd emmambd 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.

Hi @krnlmstrd! Thanks for this great effort to improve the validator and reduce confusion in the spec! 🎉

You can expect a technical code review this week from other members of our team that includes other requested change, but after the new recommendations in the spec discussion, the severity of this notice should be downgraded from ERROR to an INFO, since it'll be optional rather than a "should" or "must" in any case. This will serve as a flag that having a stop without a zone id looks suspicious when other route-based fare fields are defined in fare_rules.txt and producers should consider reviewing it in case it's a problem.

* Stop without value for `stops.zone_id`.
* Stop without value for `stops.zone_id` contained in a route with a zone-dependent fare rule.
*
* <p>If `fare_rules.txt` is provided, and `fare_rules.txt` uses at least one column among

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.

Revised notice description text (open to suggestions for improvement):

A fare rule in fare_rules.txt is provided and uses at least one column among origin_id, destination_id and contains_id, but does not assign stops.zone_id for all associated stops and platforms (location_type = 0).

@ghost

ghost commented Mar 7, 2024

Copy link
Copy Markdown
Author

Closing this pr because I am unifying/deleting GitHub accounts and associated email addresses. Please see an identical new PR.

@ghost ghost closed this Mar 7, 2024
This pull request was closed.
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.

Rule change: make stop_without_zone_id conditional on fare rule type

2 participants