public-transport / transport-apis Goto Github PK

I wanted to check out the available documentation for the Ulm OTP endpoint, but the homepage does not work anymore. Do you know an updated version? Is it known whether the endpoint is still available, although the homepage isn't ?

https://auskunft.kvb.koeln/

You might know about MOTIS: https://motis-project.de/

As part of my job I started to work on a library to communicate with Motis-Instances and came to the point that it would make sense to have configuration files. So instead of creating my own format I would like to discuss the format here and ideally upstream the specification to this repo instead. Compared to TRIA, Hafas, EFA, etc. I am not aware of any "official" MOTIS-Servers provided by a public transport provider, but there are public instances like https://europe.motis-project.de/.

I also created a upstream issue here: motis-project/motis#276

If you have any additional aspects you would think about let me know in this issue. And if you would be fine adding the specification to this repository, I would similar to the TRIAS create a draft PR to discuss a proposed format.

I found that in

So imho it would make sense to add it there and maybe link to the possible values (e.g. this https://docs.opentripplanner.org/en/dev-2.x/RoutingModes/ if I'm not mistaken).

If you agree I could make a little PR adding the documentation

iRail/iRail#466 (comment)

To my surprise, bwegt-trias.json now supports Trias 1.2 without me noticing before.

If the request contains <Trias version="1.1", it answers like a Trias 1.1.
If the request contains <Trias version="1.2", it answers like a Trias 1.2.
The same holds for VVO Trias.

Before I write a PR updating those values, I'd like to discuss the Trias Schema:

It might be valuable for a client to know that a Trias instance supports version 1.1 AND 1.2.

Storing this information appears to be not possible with the current JSON schema.

In #53 I discovered that the bwegt-trias-endpoint blocks certain user-agent headers, as described here: https://python.tutorialink.com/post-request-to-trias-api-does-not-work-with-requests/

This seems to be a very weird issue and is rarely documented anywhere. However it would might make sense to document it in the .json as well, as else the requests will fail with 502 Error code, with no obvious reason. @derhuerst mentioned a similar issue in his comment I contacted a contact at nvbw regarding this issue and will update the issue when I get an answer. The solution for me was just to set the user-agent manually to a working string.

Some naive possibilities how to document the blocked user-agents:

• List all/some known working user-agents: This list will never be complete and can be exhausting, also usually the User-agent is used to identify a client. Manipulating it, does not make to much semantic sense and in my opinion (imo.) is rather a workaround then a fix.
• List all/some known to be blocked/broken user-agents: This would be never complete as well, but could be an easier list as people who trigger the problem could look up the list and check their clients user-agent and implement a workaround or contact upstream to fix it on the endpoint side. Personally I would prefer the second option.
• Instead of listing the known/broken user-agents we could document them in a markdown file as examples and give the users of this repository a starting point. This list would not need to be exhausting, but also couldn't be utilized by clients.
• We could also keep this issue rather general and start in a markdown file / the GitHub wiki a list of common technical issues and how to prevent them. This imo. would be such an issue. Especially if further similar issues exist, this would be an easy way to deal with the issue.

If anyone has any thoughts on that, or did encounter this issue as well, I would appreciate some opinions :)

@andaryjo started doing this in the trias-client docs.
@vkrause's kpublictransport also has support for >1 TRIAS endpoint.

Let's define a way to specify all relevant aspects of TRIAS API endpoints in a machine-readable way, so that client libraries can use this information! This way, there will be

• less maintenance, as upstream changes to the individual endpoints will only have to be investigated once.
• better coverage of all existing API endpoints, as client libraries can easily pull the list of all known ones.

In derhuerst/live-icomera-position#3, @Adwirawien proposed to have a central place to collect machine-readable knowledge about on-board (as in: available in the vehicle-local WiFi) APIs:

[...] I [...] noticed the wifi-on-ice-portal-client as well as digital-im-regio-portal-client and a few others. From what I can tell they are more or less all using the same icomera api with a few exceptions.

[...] This would prevent the sort of chaos, that we're noticing regarding public transport information apis and could act as a central place for documentation of all the available on-board information systems.

[...] it would be useful to have a central place, much like what WoBike is for bike/scooter sharing APIs, or transport-apis.

Let's focus the discussion here on how to add data to transport-apis, and keep the general discussion on how to obtain it and potential future projects building on top over at derhuerst/live-icomera-position#3.

What do you think @derf?