[Clarification] from/to_stop_id presence and description in transfers.txt

[tzujenchanmbd]

Issue

Recently we have received requests to change the behavior of the Canonical GTFS Validator regarding transfers.from_stop_id and transfers.to_stop_id (e.g. MobilityData/gtfs-validator#1621), stemming from different interpretations of the current specification.

The current description of from_stop_id is:

Identifies a stop or station where a connection between routes begins. If this field refers to a station, the transfer rule applies to all its child stops. Refering to a station is forbiden for transfer_types 4 and 5.

Based on the description and the discussion in PR#303, it should indicate that from_stop_id and to_stop_id cannot be empty, and it cannot be a "station" (location_type =1) if transfer_type is 4 or 5.

However, some community members may interpret it as:

• from_stop_id is required for transfer_type 1, 2, and 3; optional for transfer_type 4 and 5 OR
• from_stop_id is required for transfer_type 1, 2, and 3; forbidden for transfer_type 4 and 5

To prevent such confusion from happening again, we propose the following modification:

Changes in this PR

• Change presence from Conditionally Required to Required. According to the definition of presence Required - "The field or file must be included in the dataset and contain a valid value for each record", these 2 fields should be Required.
• Remove the word "forbidden" from description to avoid potential confusion.

+@gcamp - the main contributor of PR#303

[gcamp]

LGTM on the stop vs station change, however it should still be Conditionally required. For transfer_type 4 and 5, the stop is optional and the main values used in this case are the trip_ids values.

[tzujenchanmbd]

Thanks for the clarification @gcamp !
158ad1d - Changed presence back to Conditionally Required and explicitly stated when is required or optional.

[gcamp]

👏

[isabelle-dr]

@tzujenchanmbd I made a few editorial edits for consistency with the rest pf the spec:

• having "Optional" not in bold
• enum values in code formatting
• added a formatting change to from_trip_id to reproduce in to_trip_id to fit with the rest of the spec

[isabelle-dr]

It might be worth seeing if pieces of #363 could also be included in this PR. The initial scope of it was to revert transfer_type=4 and 5 but it also contained good editorial/clarification fixes.

[tzujenchanmbd]

Included editorial suggestions from #363 . Changes from #363 that would potentially change semantics and/or validator behavior are not included in this PR