Currently the departures lists inside stop objects returned by the API cannot be used for viewing a stop's actual departing trips, because the list also includes departures for which the stop is the last stop (and therefore they don't continue to anywhere).
To mitigate the problem, added field stops_after_this to StopTime model which tells if there actually are stops on the trip after the stop in question or not (and the number of those if someone is interested of that). The field is populated once after a successful GTFS feed import.
Added also a new filter exclude_final_stop_departures which can be used to exclude departures from their final stops' departure lists in route and stop API detail endpoints.
The naming of things is even more horrid than usual in this one, so feel free to propose better names for the stuff in here.
Currently the
departureslists inside stop objects returned by the API cannot be used for viewing a stop's actual departing trips, because the list also includes departures for which the stop is the last stop (and therefore they don't continue to anywhere).To mitigate the problem, added field
stops_after_thistoStopTimemodel which tells if there actually are stops on the trip after the stop in question or not (and the number of those if someone is interested of that). The field is populated once after a successful GTFS feed import.Added also a new filter
exclude_final_stop_departureswhich can be used to exclude departures from their final stops' departure lists in route and stop API detail endpoints.The naming of things is even more horrid than usual in this one, so feel free to propose better names for the stuff in here.