Switch to DB API for train departure times

[Robert27]

Currently we use cheerio to get the data for the mobility tab (#26). It might be better and more reliable to switch to the "Timetables - v1" API provided by DB. The rate limit is 20/min which means we still have to cache it on our server. The same terms of use as for the "Web Bahnhofstafeln" apply.

[M4GNV5]

The API looks pretty cool. Here is what i received for a query of Ingolstadt Nord:

<?xml version='1.0' encoding='UTF-8'?>
<timetable station='Ingolstadt Nord'>
  <s id="-2307919218186410793-2204121308-4">
    <tl f="N" t="p" o="800765" c="RE" n="4023"/>
    <ar pt="2204121350" pp="4" l="1" ppth="N&#252;rnberg Hbf|Allersberg(Rothsee)|Kinding(Altm&#252;hltal)"/>
    <dp pt="2204121351" pp="4" l="1" ppth="Ingolstadt Hbf|Rohrbach(Ilm)|Pfaffenhofen(Ilm)|Petershausen(Obb)|M&#252;nchen Hbf"/>
  </s>
  [...]
</timetable>

ar seems to be arrival, dp seems to be departure. the pt attribute seems to be a timestamp in YYMMDDHHMM format.

Apart from that i think we need to rethink the way the train mobility page works. Currently you select one origin station and it simply shows you all trains departing from that station. I guess there are four major train routes: towards Munich, Nürnberg, Augsburg and Regensburg. While the Munich and Nürnberg students should be fine with a list of departures from Ingolstadt Nord students traveling to Augsburg or Regensburg often have to change trains at Ingolstadt main station or they take the bus directly to the main station and thus dont have much use for a simple train departure listing. With the Bahn API we can see all future train stops of all trains. In theory we could even allow users to select an origin and destination station. Or even more fancy: We could let the user pick only his "home" station and then recommend a train/bus connection to the THI based on the lectures he has on a specific day and a train/bus connection home after the last lecture.

[M4GNV5]

I guess for this issue we can simply track removing the web scraping / moving to the Bahn API and i will create a new user experience labeled issue for the fancy features we could implement

[Robert27]

Yes that sounds like a great plan, currently I think the feature to select the direction is most important.

Also there are many more APIs from DB, like parking or station information. Or the Ingolstadt traffic light API, where we could add real-time data to the map. Not to mention the Ingolstadt parking API to remove the scraping again.

In the long run, we could think about hosting and documenting all our own APIs independently from neuland.app, especially for the native app versions, like TUM does.

We also need to think about restricting access to our APIs, especially those of DB and Ingolstadt that are not public.

[M4GNV5]

Uhh it looks like the parking lot API documentation was created by our CTF sponsor response: https://www.ingolstadt.de/output/download.php?fid=3052.2437.1.PDF

The problem with the ingolstadt open data APIs is that their access is restricted and you have to manually contact them for API access. Afaik it was even necessary to sign some paperword, but we could look into that. Do you want to create a separate issue for the official parking API replacement? EDIT: that seems to be done already :smile:

[FabianSimonGross]

I'd suggest using the Marudor API:

https://docs.marudor.de/

It's more clean and you can display delays way more accurate

[FabianSimonGross]

Well Marudor has removed the API as I can see. So this lead is dead.