Open thekonz opened 8 years ago
isDelayed
would be fairly subjective. From my perspective one minute late could already mean delayed. I think either a delay, like you mentioned 00:05
, or a scheduled arrival 16:48
and actual arrival 16:53
would make more sense.
In Lufthansa API they have:
scheduledTimeLocal
, scheduledTimeUTC
estimatedTimeLocal``,
estimatedTimeUTC`actualTimeLocal``,
actualTimeUTC`Both for depature and arrival. They also have timeStatus
like delayed or early. This is subjective, but there is some official DB "opinion" on that.
The above Lufthansa API approach looks much more useful to me. There should be standard date format, which includes time and timezone. I think, if all dates include the given timezone of the local station, then the UTC fields might not needed. Having them could be convenient but increases the size of the JSON.
(How would cancelled trains will be displayed?)
I found now the documentation of cancelled trains in: http://open-api.bahn.de/bin/rest.exe/v1.0/xsd?name=hafasRestDepartureBoard.xsd
It would be nice, if all the spreaded documentation would be here at github. So changed to it would be clearly visible.
What about unknown delay times? https://twitter.com/ntvde/status/740084190843047937
the data is not mean to be realtime, just the schedule, so no delays or actual arrival/departure data is present.
There should be data about delays in the API.
It should show in the departureBoard, arrivalBoard and journeyDetail.
Proposed format for departureBoard and arrivalBoard:
With the
isDelayed
, you indicate, whether the train is delayed. If you have a delayed train without an estimated amount of delay time, thedelayAmount
would be00:00
ornull
, but theisDelayed
still shows the fact, that the train is delayed.Proposed format for journeyDetail:
What do you think about the format?