Open matitalatina opened 7 years ago
We from timetable.search.ch (which ist the new backend for the transport api) are still working to properly integrate the gtfs-rt data. It is almost ready but we found some big discrepanies between gtfsrt and the data displayed on sbb.ch in some cases. This bug should be fixed in the following weeks.
We will activate the delays as soon as we are confident to actually provide useful data.
Hi, I am also interested in this feature. Is it already enabled? Also, how fast are the delays updated? We are planning to impl. a notification service but I am not sure polling the delay is a good idea...
I reactivated the show_delays parameter in the timetable.search.ch API.
Look for arr_delay / dep_delay keys in the result to see the expected delays. If its value is set to 'X' that means that specific stop is cancelled.
Apart from marking the routes with these delays / cancellations, it should now show alternative trips as well (marked with a realtime key). Even dynamically added trips are supported.
Please be aware that this feature is still in beta and under heavy development. Especially the alternative routes. Also the gtfsrt feed from opentransportdata.swiss might still contain bugs.
Our gtfsrt feed currently only updates once every five minutes.
Did you disabled the show_delays parameter? I am trying to get the delay and in the opendata.ch API it always says Null. And in the timetable.search.ch API nothing gets returned, for example:
https://timetable.search.ch/api/stationboard.json?stop=Milchbuck&show_delays=1&limit=5
shows no arr_delay/ dep_delay
Delays are not disabled but in Zurich not all lines have realtime information. See https://fahrplan.search.ch/realtime_companies You can try different stations like "Zürich Hardbrücke" or "Zürich Hardbrücke, Bahnhof".
I have always
delay: null
since August (more or less). I caught the issue today.I was querying on station Mendrisio S. Martino (stationboard API call). Before August my application worked well. Then station name on stops became all
null
(there's already an open bug for this), also the delay became alwaysnull
.See the attachment.