DB: reachableFrom() query that causes the server to crash

[Mark531]

Hello,

This query (looking for the stations accessible from Badajoz, Spain in less than 200 min) causes the CGI server to crash:
https://v5.db.transport.rest/stops/reachable-from?latitude=38.890868&longitude=-6.981823&address=%27%27&maxDuration=200

Though, the GPS coordinates are the ones returned by the nearby API, i.e. they are the exact coordinates of the Badajoz's station for the API.

Could you please investigate?

Thanks,
Mark

[derhuerst]

Currently, I can't reproduce this server error, I get a regular response (with only 7100035 "Badajoz" in the results).

Also, please note that

• you're using the outdated v5.db.transport.rest API. Please switch to v6.db.transport.rest.
• you're using my wrapper API around the DB HAFAS API, so there is a small chance that the wrapper API is causing this error.
• you're not specifying when, so it defaults to now. This is relevant because it influences the computation of reachable stations (for example, a different set is reachable during the day than during the night). To help with debugging, please pick a date+time far in the future, so that I have some time to investigate this.
• you're specifying '' as the address (the actual value, not the JS literal). AFAICT, with most calls, HAFAS just passes through into the response whatever you're passing in via address, but I recommend you to pass an actual address.

[Mark531]

Hello,

Thanks for getting back to me on this error! Actually, I get many of these errors so I would appreciate if you could look into them.

I reproduce the problem easily, even after switching to the v6 version of the API. Here is a code snippet reproducing it:

import requests

URL = "https://v6.db.transport.rest/stops/reachable-from?latitude=38.890868&longitude=-6.981823&address=%27%27&maxDuration=200&when=tomorrow%202pm"

response = requests.get(URL)

Note that I don't know any address, what I want is to compute itineraries between train stations.

By the way, to specify a day in the future, I used the syntax "tomorrow 2 pm" since I've never been able to use a date format as specified in the API specs (https://v6.db.transport.rest/api.html#datetime-parameters). For instance, "2023-01-04T14:00+01:00" triggers a 500 error and "2023-01-04T14:00" a 400 error.

Thanks,
Mark

[derhuerst]

https://v6.db.transport.rest/stops/reachable-from?latitude=38.890868&longitude=-6.981823&address=%27%27&maxDuration=200&when=tomorrow%202pm

I can reproduce it too!

This is the failing HAFAS call:

{"lang":"en","svcReqL":[{"meth":"LocGeoReach","req":{"loc":{"type":"A","name":"''","lid":"A=2@O=''@X=-6981823@Y=38890868@"},"maxDur":200,"maxChg":5,"date":"20250106","time":"140000","period":120,"jnyFltrL":[{"type":"PROD","mode":"INC","value":"1023"}]},"cfg":{"rtMode":"REALTIME"}}],"client":{"type":"AND","id":"DB","v":21120000,"name":"DB Navigator"},"ext":"DB.R22.04.a","ver":"1.78","auth":{"type":"AID","aid":"n91dB8Z77MLdoR0K"}}

And this the response:

{"ver":"1.78","ext":"DB.R22.04.a","lang":"eng","id":"","err":"OK","cInfo":{"code":"OK"},"graph":{"id":"standard","index":0},"subGraph":{"id":"global","index":0},"view":{"id":"standard","index":0},"svcResL":[{"meth":"LocGeoReach","err":"CGI_READ_FAILED","errTxt":"CGI: Server died during request execution","errTxtOut":"An internal error occurred during the search"}]}

Even with Badajoz instead of '' as the address, the server crashes. I might be because the DB HAFAS endpoint has almost no data in spain? Not sure though.

---

Note that I don't know any address, what I want is to compute itineraries between train stations.

Use journeys()//journeys for this.

For instance, 2023-01-04T14:00+01:00 triggers a 500 error and 2023-01-04T14:00 a 400 error.

• 2023-01-04T14:00 is missing a timezone offset, so it is ambiguous. It should be 2023-01-04T14:00+01:00. (Note that it doesn't fail because of that, but it's important nonetheless.)
• Note that, like with all URLs, you need to encode the query string parameters, so it should be when=2023-01-04T14%3A00%2B01%3A00.
• The HAFAS server reports the date+time as being outside the supported time period: "Error in date entry or date outside the timetable period (2023-12-10 - 2025-12-13)".

[Mark531]

Hi Jannis,

Thanks for looking into my issue!

Well, it seems that you wrote a wrapper for this HAFAS API, so it should be more adequate to report these issues directly to DB. Tell me, what's the official page of this API?

I gave you just one example of a failed call, but I ran into dozens, in different countries. I suspect big bugs in their API that should be investigated.

Note that I can't use journeys because I need to find all the stations reachable from another station.

Thanks for your tips about time encoding!

Mark

[derhuerst]

Well, it seems that you wrote a wrapper for this HAFAS API, so it should be more adequate to report these issues directly to DB. Tell me, what's the official page of this API?

AFAIK there is no official page about this API. In fact, hafas-client just uses this API inofficially. Also HAFAS is just a software product by HaCon (owned by Siemens) sold to DB.

So I'm not sure that a) you'll find someone responsible, and b) this person will take your feedback into account.

I gave you just one example of a failed call, but I ran into dozens, in different countries. I suspect big bugs in their API that should be investigated.

I have the same impression about the reachableFrom (a.k.a. LocGeoReach) API.

Note that I can't use journeys because I need to find all the stations reachable from another station.

At some point in the past, I worked around this by querying departures, their trips' intermediate stops, and then repeat, basically doing a graph search manually. I implemented this in hafas-discover-stations.

If you're more into static analysis of the rail/bus network of Spain, you could also look into using the GTFS data for Spain (see also public-transport/transitous#118).

[Mark531]

Too bad, I planned to use this free API in my app, so from what you explain, it's compromised.

Your program hafas-discover-stations looks interesting, unfortunately I'm using python and I'm not proficient in JS.

I'm looking into GTFS but it rather seems like a database so it would push me to re-implement all features that were offered by the HAFAS API. Note that I'm not interested in Spain only but in the whole European railway network.

Oh, a last issue that may come from your wrapper: since v6, reachableFrom returns data in another format, i.e. a dictionary with the keys "reachable" and "realtimeDataUpdatedAt". I don't see anything about it in your documentation.

[derhuerst]

I'm looking into GTFS but it rather seems like a database so it would push me to re-implement all features that were offered by the HAFAS API. Note that I'm not interested in Spain only but in the whole European railway network.

Covering the whole European rail network is a lot of work! You might want to use Transitous instead and report missing datasources there (related: public-transport/transitous#114, public-transport/transitous#751).

Oh, a last issue that may come from your wrapper: since v6, reachableFrom returns data in another format, i.e. a dictionary with the keys "reachable" and "realtimeDataUpdatedAt". I don't see anything about it in your documentation.

Thanks for reporting this, I will fix it.

[Mark531]

Thank you for suggesting Transitous! I didn't know that alternative API, I will check it.

[traines-source]

Watch out though, Transitous/Motis is currently transitioning ^^ to v2, with breaking API changes, to not say a completely new API. And the new API (https://api.transitous.org/) is not yet reliably running. I intend to build a FPTF wrapper around this new API so that it can be a drop-in-replacement for hafas-client and/or db-vendo-client, without needing to change much in the consuming code. Of course you're welcome to start that first :) At the same time I don't know if Motis offers a reachableFrom-like endpoint.

[dalbani]

At the same time I don't know if Motis offers a reachableFrom-like endpoint.

I'm not aware of such a capability, from what I can see on https://transitous.org/api/.
Isochrones will maybe be supported sometime according to motis-project/motis#195 (comment).