Clarify stops.zone_id conditional requirement for route-based fare_rules

[westontrillium]

Related issue: #429

This pull request modifies the conditional requirement for stops.zone_id to allow for the scenario in which the stop is only assigned to trip_ids whose route_id is present in a fare_rules.txt record with only fare_id and route_id defined (route-based fares).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Sergiodero]

Hi @westontrillium ,

Thanks for working on a proposal and opening this PR. I’m bringing over @bdferris-v2's comment made on Issue #429, considering this point, perhaps it would good to could consider the option of making this field a recommended field instead of required? It could be recommended if zone-based info is provided (i.e. keeping the text you are proposing but replacing required with recommended). Alternatively it could just be optional all together, I wonder if anyone would have a strong preference between recommended and completely optional.

In any case, I think in both options solve the problem of having stops without an assigned zone_id triggering an error by bringing more flexibility to the spec, making it a backwards compatible change for both cases.

Any thoughts?

[westontrillium]

Good points from @bdferris-v2. I also can't think of a scenario where this field would be strictly required, especially universally.

In light of this, I think optional would actually make the most sense. As @bdferris-v2 stated, there are cases where an agency justifiably avoids defining zone_id, even if the recommended condition of "providing fare information using fare_rules.txt" is met. Adjusting the condition for the recommendation to just be when using fare zones would only be creating a truism: "This field is used for assigning stops to a fare zone... Recommended if assigning stops to a fare zone."

I'll wait to give others a chance to share their opinion, but I'm happy to make the eventual change to the PR to make this optional.

[westontrillium]

I went ahead and updated the PR to change the conditional requirement to optional. At this point, I believe a vote may be called @Sergiodero?

[Sergiodero]

That's right @westontrillium! we need to cover a minimum 7-day period for discussion before calling a vote as per the Specification amendment process. Since this change is not bringing any new functionality or changing an existing one, I think it's okay to open a vote without testing (but happy to hear if someone else has a different opinion).

[westontrillium]

I am opening a vote to merge this Pull Request.

Voting ends on 2024-04-30 at 23:59:59 UTC.

[bdferris-v2]

+1 Google

[LeoFrachet]

+1 from Spare Labs

[e-lo]

❓ Isn't zone_id conditionally required if fare_rules.txt contains origin_id or destination_id?

[westontrillium]

@e-lo Not universally. The zone that origin_id/destination_id refers to does not necessarily refer to all stops, so all stops do not need a zone_id if they are not part of a zone. And conditional requirements on the basis of an id being referenced somewhere is somewhat redundant. It is always the case that a defined foreign id field needs to reference a primary key that actually exists. If we based id requirements on this, we'd need to add "required if a [foreign id field] references this id" for every id in the spec. I think such a requirement is a validation rule more than anything.

[e-lo]

I guess we need to differentiate between a field being optional (existing as a column) vs a field being nullable (have blank values). If you have any origin_id / destination_id the field is required...but individiual records can always be nullable....right?

[westontrillium]

If you have any origin_id / destination_id the field is required

I don't think so. If you have any origin_id/destination_id values, there must be at least one stop with a zone_id value that matches. Again, this to me is a data validation rule more than a conditional requirement that should be codified into the spec. It's a given that this would be a requirement because foreign ids as a rule reference primary keys.

I don't know how the presence of the column—empty or otherwise—is relevant. Dependencies are always based on the values within the fields.

[e-lo]

It's a given that this would be a requirement because foreign ids as a rule reference primary keys

I don't dispute that, but the term conditionally required has been used throughout the spec to note this in many places and I'd just want to make sure we are being consistent.

[westontrillium]

Hmm... I just went through all instances of "conditionally required" in the spec, and I didn't find a single case where "conditionally required" is invoked for the presence of a primary key if a foreign id field references it.

[jfabi]

The @mbta for a time published an internal-only version of the v1 fare_rules.txt for our OpenTripPlanner instance. It appears we were leaving zone_id null for some stops where the fare rule could be determined entirely by route_id, so it seems fitting that we should support this clarification.

+1 from @mbta

[halbertram]

+1 from Ito

[LuisLenta]

+1 from Ualabee

[eliasmbd]

@westontrillium It looks like this PR has passed and is now adopted to GTFS. Congratulations on passing your first PR.

+1 Google (@bdferris-v2)
+1 Spare Labs (@LeoFrachet)
+1 MBTA (@jfabi)
+1 Ito (@halbertram)
+1 Ualabee (@LuisLenta)

We have 5 votes for the change, 0 votes against the change, and 0 votes in abstention.
The vote has passed and the change can be merged.