stops.zone_id conditional requirement with presence of route-based fare_rules?

[westontrillium]

Describe the problem

We have received multiple messages from agencies confused by an error (stop_without_zone_id) found in validation reports forwarded to them by the National Transit Database. I've investigated the error and am wondering if the way the spec handles zone_id requirements should be clarified, and if so, whether such a clarification would break backwards compatibility. I'm not sure, because it is a conditional requirement, and adding the exception I propose below would be easing a restriction, not adding a new one.

The current requirement is essentially: If fare_rules.txt contains records, then presence of zone_id is required for all stops in the dataset.

However, there are cases where you could define a fare_rule without the use of zone_ids, for example, with route-based fares. In my opinion, a feed should still be valid with partial zone_id presence IF those stops without a zone_id are present in stop_times records with a trip_id whose route_id is present in a fare_rules.txt record with only fare_id and route_id defined.

Use cases

Consider the following example

fare_rules.txt

fare_id	route_id	origin_id	destination_id
1855		A	B
7549	50

stops.txt

stop_id	...	zone_id
111	...
222	...	A
333	...	A
444	...	A
555	...	B
666	...	B

Given that stop_id=111 is present only in route_id=50 trips, you can determine that any itinerary that includes the stop will have a fare of fare_id=7549 since it belongs to route_id=50. Giving the stop a zone_id would be superfluous because there is no fare rule that zone would belong to.

Proposed solution

Is it possible to modify the conditional requirement, adding the following exception to the rule?

"Required if providing fare information using fare_rules.txt, unless stop is present only in stop_times.txt records with a trip_id whose route_id is present in a fare_rules.txt record with only fare_id and route_id defined."

Ideally written in a less confusing way 😅

Additional information

I have attached an example dataset you can run through the validator to see the stop_without_zone_id error in question.

stop_without_zone_id_feedTEST.zip

You will find several stops without zone_ids accounted for by route-based fares that trigger the error.

To my knowledge, feeds containing the stop_without_zone_id due to this reason have passed validation of consumers like Google.

[Sergiodero]

Thanks for flagging this @westontrillium! There are two things that might need to be addressed here: primarily a spec clarification (as you pointed out) and secondly an adjustment to the validator rules to avoid this notice when zone-based fares are not being used.

On our end we tried to put together two spec clarification alternatives for stops.zone_id, but we didn't ended up having a significant improvement from your proposal, perhaps they can serve as inspiration to make some adjustments (if any) to your proposal.

• "Required if providing fare information using fare_rules.txt, except when the stop is only assigned to a trip_id in stop_times.txt whose route_id is present in a fare_rules.txt record and provides fare information only for fare_id and route_id.

• "Required if providing fare information using fare_rules.txt, except if only fare_rules.fare_id and fare_rules.route_id are provided for the corresponding trip_id that is assigned to the stop in stoptimes.txt”

Regarding the second step, we’re already included this in our backlog of validator changes.

Would you be interested in carrying this over to a PR?

[westontrillium]

Yes I'd be happy to create a PR for this clarification. Thanks for the wording assistance–I'll pull something together with these in mind.

[bdferris-v2]

I just wanted to call out some additional complexity with the spec here. Fares v1 was always underspecified in the spec so I'm not surprised there are holes here. I wanted to call out another.

Namely, I don't think there is anything in the spec that requires a feed to exhaustively define fares for all service in the feed. I think that's true for a single-agency feed, but I think it's especially true for multi-agency feeds where a single agency might have Fares v1 information, but another agency in the feed does not, for whatever reason.

Under these circumstances, there very well might be stops that do not have zone_id specified and also aren't used by a route that matches a fare rule. For these reasons, we (Google) don't actually enable the StopZoneIdValidator when validating feeds.

Ignoring validation for a moment and focusing only on the spec, I'd argue that the field is not actually required under any circumstances. I can think of many should statements that might trigger warnings, but fewer musts.