-
Notifications
You must be signed in to change notification settings - Fork 173
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
timepoint=empty (with no times specified) #61
Comments
Relevant thread from GTFS-changes here: https://groups.google.com/d/msg/transit-developers/dwd96EwJqIc/N5DJxP8VCQAJ |
My expectation for this feature when proposed/accepted was that there would be two types of feeds:
To clarify this, I suggest we remove
|
The spec currently reads:
Other notes are provided in the Disallowing an empty value for timepoint would not technically be a backwards-compatible change (though it's a very minor breaking change). Should we:
|
The definition of "empty" within the GTFS spec hasn't been standardized, and generally speaking it should be - although this is a broader issue than just about the I'd still like to see the spec clarified to define what is allowed and what is not about this field. In retrospect, IMHO the way the definition is written it's hard to decipher the original intent. This also needs some historical context of GTFS. Originally, prior to the timepoint field, GTFS spec said you should only provide arrival and departure times for
However, producers realized that for multiple consumers to show consistent scheduled arrival and departure times at each stop (i.e., so consumers didn't interpolate them and come up with their own values), they would need to share arrival/departure times for each stop in the trip. A large number of GTFS producers started doing the following, even though technically it was against the GTFS spec:
Now, to consumers, all the stops looked like timepoints, even though that wasn't the producer's intent. The So if producers want to provide times for every stop, they shouldn't be doing the above, and instead should provide the
This means as of today, IMHO, there are two valid ways to share arrival and departure times in GTFS. The first is the original GTFS spec without the timepoint field, where times are omitted for stops that are not timepoints:
Or, if they want to provide times for every stop, they should provide timepoint values for the entire stop-times.txt.
Here's a suggestion for clarifying the spec to try and capture the above intent:
Alternate suggestions, or alternate interpretations of the spec, are welcome. |
There has been a discussion in the canonical GTFS schedule validator around this issue, and we noticed that existing data had implemented timepoint in two opposite ways:
Sample from the Greater Glens Falls Transit (Mobility Database link), which doesn't contain any 1's in the timepoint column.
Sample from the Squaxin Island Transit (Mobility Database link), which doesn't contain any 0's in the timepoint column.
The GTFS validator won't interpret empty timepoint values as equivalent to 1 in order to avoid false positives, but it will flag:
I think @barbeau's suggestion above would help a lot implement timepoint in a consistent way. |
As discussed in this thread: ...how MobilityData/gtfs-validator#887 (comment) says:
...but this isn't documented anywhere in the spec. My comment here: ...said:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
keep open |
The intended meaning of an empty stop_times.timepoint value may be unclear. Quoted below from trips.txt. See, in particular, statements that are somewhat at odds with each other in bold italic below.
If there are no times provided and stop_times.timepoint is empty, then should feed consumers therefore assume that times should be interpolated? Is there any way of indicating times should not be interpolated, and would that ever be necessary?
The text was updated successfully, but these errors were encountered: