Inconsistent results between this API and VBB Fahrinfo app / other HAFAS clients

[heyarne]

Hi!

We noted that in some cases we get inconsistent results between this API and what we can see on the VBB page.

Example request API: https://3.vbb.transport.rest/journeys?from=900000205466&to=900000205151&arrival=1582614000 Similar request made in the vbb Fahrinfo webapp (doesn't allow deep linking unfortunately):

Note that the last result does not show up in the vbb-rest response. I cross-validated this with https://transportr.app/ which to my knowledge uses the HAFAS API under the hood:

Can you help us find out what happened there?

[derhuerst]

Thanks for trying to solve this!

A quick question up front: Did you use the VBB endpoint with Transportr, or the BVG endpoint?

---

We noted that in some cases we get inconsistent results between this API and what we can see on the VBB page.

In which cases specifically? When there are delays or other disruptions? When there's very little or a lot of walking involved? When there are certain means of transport involved?

When you find examples where they differ, a) post the response from 3.vbb.transport.rest here (in addition to screenshots, just like you did already), and b) try to find out in which cases they do not differ (consider the questions above?).

Also, to let me debug this, you need to pick an example far enough in the future (e.g. 1 day), so I can look into this even when I don't read your response immediately. Debugging on past data usually doesn't work with HAFAS.

---

The reason I'm asking is: AFAIK the website, Transportr, Öffi and 3.vbb.transport.rest all use the same VBB HAFAS instance (when configured accordingly), so it's very likely that different default options/filters cause different results.

[heyarne]

A quick question up front: Did you use the VBB endpoint with Transportr, or the BVG endpoint?

I used the VBB endpoint.

In which cases specifically? When there are delays or other disruptions? When there's very little or a lot of walking involved? When there are certain means of transport involved?

This could have been more prominent probably, but there's the link to the API request here: https://3.vbb.transport.rest/journeys?from=900000205466&to=900000205151&arrival=1582614000

The request and both screenshots use the exact same time (25 February 2020, arrival at 7:00am), start and endpoint (see screenshots). There is no walking involved, it's from station to station. I'll let you know when I find additional examples.

Also, to let me debug this, you need to pick an example far enough in the future (e.g. 1 day), so I can look into this even when I don't read your response immediately. Debugging on past data usually doesn't work with HAFAS.

The request given here seems to work - do they get deleted eventually? For us especially requests in the past are interesting because we'd like to consider delays. We request this info within 24h.

[derhuerst]

The request given here seems to work - do they get deleted eventually? For us especially requests in the past are interesting because we'd like to consider delays. We request this info within 24h.

Yes, realtime data often (not always or with all endpoints, not sure what that depends on) disappears when

• the train has left the station, or
• the trip is over, or
• some statically configured retention time is over.

To get accurate historic data, it there makes sense to a) always request data for now or in the future, and b) periodically refresh it.

Eventually™, I will wrap this unintuitive behaviour in a layer of abstraction, e.g. storing and re-using old realtime data whenever it's not available.

[derhuerst]

Closing this for now because it's hard to debug this.

Please re-open if you have a specific example 1 day (or more) in the future.