-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add that headsigns are recommended #485
Conversation
Sorry for not commenting on the issue, but I'm voting +0 on this. I would have preferred to have some language in the spec to enable a way to code the data in a way that explicitly says there are no headsigns on the trips. |
@evansiroky how about opening a separate GitHub issue for adding the functionality of indicating explicitly if a service has headings or not? |
I imagine the thumbs-up from @westontrillium @antrim @derhuerst means a general OK. This PR has been open for at least 7 days, as per the Spec Amendment Process, I am opening a vote to make headsigns a recommended field in GTFS. |
+1 Transit |
+1 Trillium |
+1 Catenary Maps. Some agencies don't provide a head sign and it's confusing. |
The voting period ended on 2024-08-15 at 23:59:59 UTC. With 3 votes in favor and no votes against, the vote passes. Thank you to everyone who participated! |
This PR closes #480.
Context and issue
Headsigns is one of the top-used optional field in GTFS. 82% of the datasets form the Mobility Database have it, which is more than route colors or feed_info.txt.
It's a field that often can and should be included and we believe there is value in calling it out specifically using the Best Practices (Recommended or Should), to promote higher-quality GTFS.
Discussions in the GH issue surfaced certain cases where there are no headsigns:
Solution proposed
Adding a statement that headsigns is recommended for all services with headsign text displayed on the vehicle which may be used to distinguish amongst trips in a route.
I acknowledge this isn't something we can easily validate automatically and trigger a WARNING for it in the Canonical GTFS Schedule Validator.
That being said, the spec contains instances of must/required and recommended/should that can't easily be checked by an automatic validator and would have to be checked by other means, and we think this is definitely better than nothing. For example:
Recommendations don't invalidate a GTFS dataset, this change is considered backwards-compatible.
Alternatives considered
In the GitHub issue, we've discussed adding a new
trips.has_headsigns
field that would have the Recommended status and maketrips.trip_headsign
Conditionally Required ifhas_headsigns==1
, but then concluded the simple statement would lead to a good enough outcome with less complexity added to the spec.Tagging folks involved in the GH issue @westontrillium @skinkie @antrim @evansiroky