You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a part of working on #46, I have noticed interesting side effects that will affect schedule interpretation. To begin this explanation, I must not that not all null stop times are equal. From a UI standpoint, there is no way to differentiate between a skipped stop and an interpolated stop. When a user first inserts a stop time into a pattern all trips affected will now have a null entry for the stop time, ie the data structure is as follows: null. However, if a user were to delete both departure and arrival times from a stop time, the datastore still stores the stop time, but the departure_time and arrival_time fields are simply set to null. In this case the data structure is now: { "stopId": "abcd", "departure_time": null, "arrival_time": null }.
Once the feed is actually exported to a gtfs each of these data structures are treated differently (see export code here). The first null stop time is not exported at all to the list of stop times of a trip. In this case, the stop is skipped completely by the trip. The second null stop time is included in the output and thus the interpretation is that the trip does serve the stop, but the time is interpolated.
The schedule editor needs to be changed in order to reflect these differences. Furthermore, this refactor could also be a good opportunity to investigate all other fields that can be set on a stop_time such as stop_headsign, pickup_type, drop_off_type, and timepoint.
Also, each trip needs a way to set trip_short_name, * wheelchair_accessible*, and bikes_allowed for a trip.
The text was updated successfully, but these errors were encountered:
Issue by evansiroky
Sunday Oct 29, 2017 at 03:39 GMT
Originally opened as catalogueglobal#44
As a part of working on #46, I have noticed interesting side effects that will affect schedule interpretation. To begin this explanation, I must not that not all null stop times are equal. From a UI standpoint, there is no way to differentiate between a skipped stop and an interpolated stop. When a user first inserts a stop time into a pattern all trips affected will now have a null entry for the stop time, ie the data structure is as follows:
null
. However, if a user were to delete both departure and arrival times from a stop time, the datastore still stores the stop time, but the departure_time and arrival_time fields are simply set to null. In this case the data structure is now:{ "stopId": "abcd", "departure_time": null, "arrival_time": null }
.Once the feed is actually exported to a gtfs each of these data structures are treated differently (see export code here). The first null stop time is not exported at all to the list of stop times of a trip. In this case, the stop is skipped completely by the trip. The second null stop time is included in the output and thus the interpretation is that the trip does serve the stop, but the time is interpolated.
The schedule editor needs to be changed in order to reflect these differences. Furthermore, this refactor could also be a good opportunity to investigate all other fields that can be set on a stop_time such as stop_headsign, pickup_type, drop_off_type, and timepoint.
Also, each trip needs a way to set trip_short_name, * wheelchair_accessible*, and bikes_allowed for a trip.
The text was updated successfully, but these errors were encountered: