fix: make stop_without_zone_id conditional on fare rule type (#1663) #1682
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`.
|
All notices dropped in acceptance testing are of type |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Revised notice description text (open to suggestions for improvement):
A fare rule in
fare_rules.txtis provided and uses at least one column amongorigin_id,destination_idandcontains_id, but does not assignstops.zone_idfor all associated stops and platforms (location_type = 0).
|
Closing this pr because I am unifying/deleting GitHub accounts and associated email addresses. Please see an identical new PR. |
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