-
Notifications
You must be signed in to change notification settings - Fork 177
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
Make headsigns a recommended GTFS field #480
Comments
The spec's description of The only concern I can think of is that sometimes a route does not have associated signage indicating trip destination/direction/etc., whether that's due to lack of vehicle/stop infrastructure features, the agency has not defined this piece of information explicitly, and/or their GTFS publisher has no agency contact to get it from. In these cases, would it be recommended for the publisher to unilaterally assign a headsign based on the limited information they have about the route (e.g., the last stop is the transit center, so one could safely assume a headsign of "Transit Center" is acceptable), or should it be left blank? Additionally, a static "destination headsign" doesn't always make sense when publishing Flex services. How would this be handled? |
Comments here are my own and do not represent Optibus & Trillium. +1 to @westontrillium's comments.
Yes, there are many. One example is Arcata, CA's (AMRTS) Red Route: Many GTFS applications assume a directional headsign. Not to pick on Apple Maps, but here is how the AMRTS Red Route shows in Apple Maps (no "Toward Transit Center" isn't meaningful for a rider. I suspect that Apple Maps is generating a headsign based on the last stop in the trip. So, at least with loop routes, recommending to provide a headsign might cause feed publishers to insert some junk data. Anecdote: At Trillium, feed consumers would occasionally require us to include I suggest revisiting the broader |
+1 to both @westontrillium and @antrim. I think it would be helpful to have a way to share in the data (possibly as a new column in the |
@evansiroky The additional has_headsign field is an interesting solution in being able to express that a trip positively does not have a headsign as opposed to missing data. I don't think, however, that we could retroactively make the existing |
Just brainstorming out loud... One issue with |
Given that the use case is presented that there are trips without headsigns, it should not become mandatory. The question is how mobiliydata envisions how recommended (eventually) would become required. If that would never happen, recommended isn't a problem. |
Do we have some precedents to work from here? Could @isabelle-dr How many feeds have a combination of empty and full text strings for |
Thank you for providing your thoughts!
@antrim We try to avoid "you can ignore this warning if..." as much as possible because we want to make it possible for datasets to be free of warnings. The validator can be used in RFPs or compliance checks against regulation, so this would be a risk to have producers filling incorrect data to avoid needing to explain why a particular warning is irrelevant here. That being said, the spec contains instances of must/required and recommended/should that can't easily be checked by the validator and would have to be checked by other means, and I think this is definitely better than nothing. For example:
So for headsigns, I think a statement that looks like this would be acceptable:
We could also potentially add the existing Best practice statement as well (source):
|
I think this would be backwards compatible, and adding a recommended |
I'd support adding the language proposed by @isabelle-dr: "This field is recommended for all services with headsign text displayed on the vehicle which may be used to distinguish amongst trips in a route." |
This issue picks up on the conversation in #461.
Context
Certain Optional files/fields are dependent on the service (e. g.
timeframes.txt
is for modeling fares based on time of day), whereas other files/fields can and should always be added regardless of the type of service being modeled (e. g.feed_info.txt
, ). We think there is value in calling out the latter explicitly using the terms associated with the Best Practices (Recommended or Should), to promote higher-quality GTFS.We looked at what are the most common optional features on the Mobility Database: ~1500 GTFS Static datasets across 79 countries - note that the US accounts for approx half of this, so we also looked at non-US based data. These are the 6 top represented optional features, in both cases.
There is currently a PR open for recommending Shapes in the spec.
Issue
This issue is for making
trips.trip_headsign
recommended in the spec, given its use in production data across the globe.Amongst the feeds that don't have headsigns, I didn't find obvious cases where it wouldn't be needed. Do we know of any?
Solution proposed
Adding the Recommended presence requirement for
trip_headsign
(see all presence requirements here).This is considered a backwards-compatible change because it wouldn't change the validity of feeds that don't have headsigns. They would trigger a WARNING in the canonical validator.
The text was updated successfully, but these errors were encountered: