-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stations in the HAFAS API, but missing in db-stations #6
Comments
{
"ds100": "BJUF",
"nr": 3067,
"name": "Berlin Jungfernheide",
"zip": "10589",
"city": "Berlin",
"state": "BE",
"id": 8011167,
"latitude": 52.530276,
"longitude": 13.299437
} More specifically: curl -sL 'http://download-data.deutschebahn.com/static/datasets/haltestellen/D_Bahnhof_2016_01_alle.csv' | grep 8011167
# 8011167;BJUF;Berlin Jungfernheide;RV;13.299437;52.530276;; |
I've forwarded this to someone in DB S&S. |
I don't get what exactly the problem is, but here's some background info: DB S&S has around 5400 train stations ("Bahnhöfe" + "Haltepunkte"): This list contains around 6600 stops (also tram stops, bus stops, ...), but NOT only train stations, so it's not really Deutsche Bahn data (and I bet DB isn't keeping it up to date): So if you want to work with train stations data (DB S&S stations), you should work with the static "data-stationsdaten" or StaDa-API: And of course the data of DB RegioNetz Infrastruktur (RNI) stations (that is not part of DB S&S): |
@voland10557 Thanks for the explanation! Let me first outline the (ideological) standpoint of a non-DB programmer/user:
I'm trying to work with DB data. I, quite frankly, don't care which subdivision of Deutsche Bahn is responsible for which stations. I just want to consume the data. I don't intend to guess the dozens of DB internal abbreviations. As a someone from the outside, I can't reproduce why the local public transport data (buses, local trains, etc.) is outdated, especially since Deutsche Bahn afair tries to cover them with routing information. So if DB covers an area/agency, it's job is to have correct data about it. DB has, from my experience, a pretty long record of technical & legal excuses to provide a subpar user experience, both to end-users & to programmers. In the context of making long-distance public transport more convenient, to ultimately sell more tickets, it would make sense to overcome these limitations. Just like me, the 300 other community programmers & 200 other companies out there don't intend to figure out all the weird abbreviations. They don't intend to stick together 3 inconsistent datasets. They don't intend to make their programs extra-faulproof for cases like IDs or names missing completely.
Now the perspective of me, someone more motivated and technically involved:
|
My intention is to have a module
|
FYI this issue still prevails. |
When querying routes from
8011167
to8000261
, I get the following station as start location:The id
8011167
does not occur indb-stations@1.0.0
, taken from the stations API.PS: @lightsprint09 @highsource @juliuste any idea? 😉 In the long term, I'd guess the whole open data community would appreciate it if the API really contained all stations that DB provides routes for.
The text was updated successfully, but these errors were encountered: