delay information and documentation

[FreeApophis]

I am wondering:

Upto now I worked under the assumption that the delay information is just not working because it is realtime information, and I was not too bothered by that. However according to #108 #109 or #151 there should be delay information and there is even an undocumented field "delay" in the response... however it is still always null, at least on transport.opendata.ch - so I thought, ok the service is probably just not up to date.

But in Issue #40 there is a claim that the current master is running on that service, so I am curious, why is there no delay information.

The feature is hard to test, since you have to find a current connection which is actually delayed. (the outage in winterthur today made a good test case) Maybe setting it to 0 for no delay, and null for no information would be an option. However such behaviour should be documented.

Maybe there is just no delay information in the stationboard? However I tried today with connections aswell.

I wrote a little library to easily access the service, and relied so far mostly on the documentation. However after reading a few issues I see that the documentation and the actual interface are also running more and more out of sync - there are several fields which are undocumented, and the values in it aswell.

I would be willing to improve the documentation with a pull-request with the information I gathered.

[ghost]

It seems that the field delay is only used in the arrivals type stationboard, and for the delay of departures stop.prognosis.departure is used.

[FreeApophis]

What do you mean by "arrivals type stationboard"? - you mean the arrival time on a stationboard request? Thats fine, just needs documentation. But I have not seen a delay at all, not in arrivals nor departure time.

But I am pretty sure that I have never seen stop.prognosis.departure filled with any value. What should be the value in realtimeAvailability if it would work? Because realtimeAvailability is always null too.

I do not see the platform prognosis either, I just tested 2 Train-connections on two different trainstations with changed platforms and both had no prognosis.

The only thing I see from time to time is the capacity prognosis, but it is unreliable too. What does -1 mean in capacity anyway?

Maybe there are multiple unrelated problems: lets first clarify, for what kind of connections are there realtime prognosis anyway? Only trains?

[ghost]

I'm speaking of the arrivals stationboard: http://transport.opendata.ch/v1/stationboard?type=arrival

I certainly had values in both stop.prognosis.departure and stop.delay. But I have no response at hand hat would proof this. I'll try to get one, when there are delays.

the platform prognosis is difficult, it sometimes is null, "" or a integer. but even when its set to an integer value, that doesn't indicate a change in platforms. But that should maybe discussed in an own issue.

I'm only using trains and don't need the capacity information, so I can't say anything about it.

[fabian]

delay should have a value if the train/bus is delayed (both for /connections and /stationboard). As this indeed depends on realtime information and delayed trains it's hard to spot, but we do have some tests covering it.

realtimeAvailability is only available for /connections and can indicate if realtime information is available. Unfortunately we don't get that information from SBB for /stationboard, so it's a bit inconsistent.

I've tried to improve the documentation a bit by removing the outdated info about checkpoints and adding the delay field. Further Pull Requests are welcome!

[matitalatina]

delay is not working. I've just used /stationboard.

Here's the delay on sbb website: [

](url)

Here's the API output:

{ stop:
   { station:
      { id: '8518475',
        name: 'Mendrisio S. Martino',
        score: null,
        coordinate: [Object],
        distance: null },
     arrival: null,
     arrivalTimestamp: null,
     departure: '2017-02-28T18:50:00+0100',
     departureTimestamp: 1488304200,
     delay: null,
     platform: '1',
     prognosis:
      { platform: null,
        arrival: null,
        departure: null,
        capacity1st: 1,
        capacity2nd: 2 },
     realtimeAvailability: null,
     location:
      { id: '8518475',
        name: 'Mendrisio S. Martino',
        score: null,
        coordinate: [Object],
        distance: null } },
  name: 'S 10',
  category: 'S',
  subcategory: 'S',
  categoryCode: 5,
  number: '10',
  operator: 'SBB',
  to: 'Chiasso',
  passList:
   [ { station: [Object],
       arrival: '2017-02-28T18:50:00+0100',
       arrivalTimestamp: 1488304200,
       departure: null,
       departureTimestamp: null,
       delay: null,
       platform: '',
       prognosis: [Object],
       realtimeAvailability: null,
       location: [Object] },
     { station: [Object],
       arrival: '2017-02-28T18:53:00+0100',
       arrivalTimestamp: 1488304380,
       departure: null,
       departureTimestamp: null,
       delay: null,
       platform: '',
       prognosis: [Object],
       realtimeAvailability: null,
       location: [Object] },
     { station: [Object],
       arrival: '2017-02-28T18:58:00+0100',
       arrivalTimestamp: 1488304680,
       departure: null,
       departureTimestamp: null,
       delay: null,
       platform: '',
       prognosis: [Object],
       realtimeAvailability: null,
       location: [Object] },
     { station: [Object],
       arrival: '2017-02-28T19:02:00+0100',
       arrivalTimestamp: 1488304920,
       departure: null,
       departureTimestamp: null,
       delay: null,
       platform: '',
       prognosis: [Object],
       realtimeAvailability: null,
       location: [Object] } ],
  capacity1st: null,
  capacity2nd: null }

[fabian]

Can't explain why the delay was not shown here in this example - maybe it was removed again until the API request was sent?

Bern is a good place to test, there's usually some delay there.

Here's an example of a delay visible on the SBB website and in the API:

http://transport.opendata.ch/v1/stationboard?station=Bern

"stationboard":[  
   {  
      "stop":{  
         "station":{  
            "id":"8507000",
            "name":"Bern",
            "score":null,
            "coordinate":{  
               "type":"WGS84",
               "x":46.948825,
               "y":7.439122
            },
            "distance":null
         },
         "arrival":null,
         "arrivalTimestamp":null,
         "departure":"2017-03-01T19:00:00+0100",
         "departureTimestamp":1488391200,
         "delay":7,
         "platform":"8",
         "prognosis":{  
            "platform":"8",
            "arrival":null,
            "departure":"2017-03-01T19:07:00+0100",
            "capacity1st":1,
            "capacity2nd":2
         },
         "realtimeAvailability":null,
         "location":{  
            "id":"8507000",
            "name":"Bern",
            "score":null,
            "coordinate":{  
               "type":"WGS84",
               "x":46.948825,
               "y":7.439122
            },
            "distance":null
         }
      },
      "name":"IR 2531",
      "category":"IR",
      "subcategory":"IR",
      "categoryCode":2,
      "number":"2531",
      "operator":"SBB",
      "to":"Luzern",

So I can't confirm a general problem with delays not being shown.

[fabian]

It would help if you could adjust quick-stationboard.php to the missing delay you're seeing, run the script with $ php quick-stationboard.php and post the produced HAFAS response (test/fixtures/stationboard/hafas_response_YYYY-MM-DD.xml).

[matitalatina]

Sorry, maybe I wrote the wrong date. I'll retry as soon as I can spot a delay in Mendrisio S. Martino / Chiasso station.

[matitalatina]

I just spotted a delay on Mendrisio S. Martino and it's working. :) Unfortunately it's not the train I'm interested in. But it's good to see it's showing its delay. Sorry for my last wrong report.

[neuhausf]

Sorry to post on a closed issue, but I think the delay isn't working for stationboard. I used the stationboard API for a home-assistant visualization (see here), and have never seen any delay for the past half year. So I queried each journey in the stationboard response again with the connections method and voilà: delays are visible. @fabian is there a known issue in the API? I would rather not query each connection again, as I fear hitting the rate limit.

right now: https://transport.opendata.ch/v1/stationboard?id=8504412&limit=15

-> no delay

but the connections search shows a delay: https://transport.opendata.ch/examples/connections.php?from=Sch%C3%BCpfen&to=Bern&datetime=

+1min

[fabian]

@neuhausf The API is basically just a proxy/wrapper of https://timetable.search.ch/api/help#stationboard. I just noticed a field show_delays which seems new... I have just enabled it now, does it work now as expected?

[neuhausf]

@fabian Hey, I guess that did the trick! That simplifies the fetching process a lot. Thank you very much!