fix: make stop_without_zone_id conditional on fare rule type (#1663) - #1693
Conversation
…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`.
|
Thanks for opening this pull request! You're awesome. We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix. Examples of titles with semantic prefixes:
|
davidgamez
left a comment
davidgamez
left a comment
There was a problem hiding this comment.
Great contribution! I added a minor suggestion before approving it.
| @GtfsValidationNotice( | ||
| severity = ERROR, | ||
| severity = INFO, | ||
| files = @FileRefs({GtfsStopSchema.class, GtfsFareRuleSchema.class})) |
There was a problem hiding this comment.
Add the additional file schema here to enhance the generated documentation: GtfsStopTimeSchema.class, GtfsTripSchema.class and GtfsRouteSchema.class
There was a problem hiding this comment.
Makes sense! Is it required or recommended or neither that a notice referencing a file includes a row number for that file?
There was a problem hiding this comment.
It's recommended as it helps the report's consumer fix the issues.
|
🥳 Congrats on getting your first pull request merged! |
2 participants
Summary:
Resolves #1663 by updating
StopZoneIdValidatorto issue notice about a stop withoutzone_iddefined 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 withoutzone_iddefined if any fare rules had zone fields defined.location_typeis0.fare_rules.txtareorigin_id,destination_id, andcontains_id.StopZoneIdValidatorTestto 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_type0does not have azone_iddefined, and that stop is defined as part of a trip instop_times.txt, and that trip is defined as part of a route intrips.txt, and that route is defined in a fare rule infare_rules.txt, and that fare rule has any oforigin_id,destination_id, orcontains_iddefined, then astop_without_zone_idnotice 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_iddefined, even if thatzone_idis 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 on test feed with fix:
Please make sure these boxes are checked before submitting your pull request - thanks!
gradle testto make sure you didn't break anything