kumi/oebb_py
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
ÖBB API (kumitterer/oebb) re-implementation as a Python3 WSGI server
80 commits 1 branch 0 tags 117 KiB
Python 99.8%
Shell 0.2%
Find a file
Kumi 8b9488451e
Migrating first request types to new HTTPClient
2022-04-20 12:02:59 +02:00
classes Migrating first request types to new HTTPClient 2022-04-20 12:02:59 +02:00
workers Migrating first request types to new HTTPClient 2022-04-20 12:02:59 +02:00
.gitignore Add venv to .gitignore 2022-04-19 12:54:30 +02:00
gunicorn.py Fix gunicorn config file name 2022-04-19 13:32:27 +02:00
main.py autopep8 everything - how could I ever work like this? 2022-04-19 15:01:03 +02:00
oebbapi.service Add systemd service file, move Gunicorn config to gunicorn.cfg 2017-10-18 12:44:24 +02:00
passenger_wsgi.py Add passenger_wsgi.py 2020-02-01 14:15:57 +00:00
README.md Use threading to improve response times for connection detail requests, set default connection count to 6 again as it doesn't matter anymore, update README. 2017-10-25 23:07:36 +02:00
requirements.txt Kick requests module out, working Hafas request implementation 2022-04-20 10:53:42 +02:00
run.sh Fix gunicorn config file name 2022-04-19 13:32:27 +02:00

README.md

Python3 ÖBB API

This project aims to provide a functional API for the Austrian Federal Railways (Österreichische Bundesbahnen, ÖBB). It has four core features/request types:

  • Search for Public Transportation stops by name ("val")
  • Search for Public Transportation stops by coordinates ("nearby")
  • Search for Public Transportation connections between two stops ("conn")
  • Search for the current location of a train ("radar")

Request

A request is made by sending a GET or POST request to the endpoint, e.g. https://bahnapi.xyz/, with a "type" parameter and additional parameters as required for the request type.

The example requests below use GET for obvious reasons, but passing the same parameters in a POST request will yield the same results.

Search for stops by name ("val")

The following parameters are required for this type of request:

  • "type": "val"
  • "name": Name of the station

This request will return a list of station names most closely matching the name provided in the request as well as corresponding station IDs, ordered by match quality.

Search for stops by coordinates ("nearby")

The following parameters are required for this type of request:

  • "type": "nearby"
  • "lat": Decimal latitude
  • "lon": Decimal longitude

The following optional parameter is accepted:

  • "distance": Maximum distance in meters (as the crow flies, default: 1000)

This request will return a list of station names closest to given coordinates as well as the corresponding station IDs and distance in meters (as the crow flies), ordered by distance.

The "distance" parameter defaults to 1000, i.e. stations up to 1,000 meters from the provided coordinates will be returned. You may want to increase or decrease this value, but setting it too high may cause the request to time-out.

This makes a request to OpenStreetMap to find the stations closest to given coordinates. Issues may occur where station names in OSM differ from those used internally by ÖBB.

Search for connections between two stops ("conn")

The following parameters are required for this type of request:

  • "type": "conn"
  • "from": Name or ID (as returned by "val") of the station of departure
  • "to": Name or ID of the station of arrival

The following optional parameters are accepted:

  • "count": Number of connections to return (default: 6)
  • "date": Date on which to find a connection (e.g. 31.12.2017, default: today)
  • "time": Time at which to find a connection (e.g. 20:00, default: current time)
  • "mode": May be set to "arr" if "time" should be considered time of arrival
  • "details": May be set to return additional details to connections (see below)
  • "via": Return connections passing through a specific station

This request will return a list of connections between the two stations given in the "from" and "to" parameters, ordered by time of departure.

It is not required that the station names provided in "from" and "to" exactly match the stations' official names. A "val" request will always be made implicitly and the closest match will be used.

By default, the response will not include some information, including at which stations a change to a different service is required, if applicable. It will, however, return the total number of changes. If additional information is required, it may be requested by adding the "details" parameter to the request. Note that this request is going to take about two to three times as long to process.

If "count" is not set, six connection will be returned, which is the maximum retrievable at once.

The provided "time" will by default be considered as the requested time of departure. To use it as the time of arrival instead, the "mode" parameter may be set to "arr".

To make sure the connection passes through a specific station, the name or ID of that station may be passed as a "via" parameter. Up to three "via" parameters may be passed in a single request and will be applied in the order of their appearance in the request.

Search for current location of trains ("radar")

The following parameter is required for this type of request:

  • "type": "radar"

The following optional parameter is accepted:

  • "train": Train number (including prefix)

If "train" is not set, this will return the location and destination of all trains currently running. If "train" is set, only trains matching the passed train numbers are returned. Multiple "train" parameters may be passed in a single request.

Short requests

For "val" and "conn" requests, it is possible to use shorter requests by passing arguments in the path. Paths consisting of one part (i.e. /value) will be handled as "val" requests while those consisting of two parts (/value1/value2) will be handled as "conn" requests, where the first value would be the station of departure and the second value would be the station of arrival. Optional values can be passed as GET or POST parameters as usual.

This syntax is intended primarily for manual requests as additional sanity checks for input data would be required to use it programatically. Specifically, station names would not be allowed to include "/" and may not be empty or contain only whitespace, as this will make it impossible to detect the correct request type.

Output format

By default, the API returns its results as XML. If you prefer JSON, you may add the "json" parameter to your query.