Focus of transitous on routing or public transport data?

[anbraten]

As the readme stated, transitous aims to be a routing service:

A community-run provider-neutral international public transport routing service.

Will transitous (maybe motis is already doing that, but couldn't find anything in the docs) provide additional data like stop_times, trips, gbfs station data like deep-links to rent a vehicle and so on or is this out of scope.

Background:

For an OSS app (similar might be of interest to other apps, websites as well) we are showing realtime data from various different sources like gtfs, gtfs-rt, gbfs, ... and would be really interested instead of developing our own database / data-hub work on an open community project collecting and sharing this data.

For testing I've recently started a small project importing gtfs, gtfs-rt and gbfs feeds into a postgis database which provides data via rest and sends updates via websocket as well: https://github.com/kiel-live/transport-hub (something like this might also be interesting for having a dashboard / showing coverage of the transitious sources)

[jbruechert]

I'm not completely sure if I understand you correctly, but the current MOTIS setup can already provide a static list of departures by stations, and already provides stop times as well.
In some areas were GTFS-RT data is available, we also already have realtime coverage for these things.

At long as MOTIS implements the feature and it doesn't depend on huge hardware resources (some things we are currently missing depend on OSM import, which is hard), we are happy to enable it.

[anbraten]

Looking at the motis api description like, it looks like those endpoints are always intended to do routing and then provide data like stop_times from gtfs etc. However for apps it would be sometimes helpful to query stop arrivals / departures without a routing request. For example when you click on a train station marker. So my question is basically if there are api-endpoints I am missing somehow already or if it would be of interest to add such functionality somehow in the long term to the project. (Sorry, I hope it's more clear now what I wanted to ask)

[jbruechert]

Just click around in the web interface to see what is already implemented really. What you mentioned is aready there.
https://routing.spline.de/?motis=https%3A%2F%2Frouting.spline.de%2Fapi#/

[felixguendling]

As I understand it, you want to create a departure table. This is the API endpoint currently used:
https://europe.motis-project.de/openapi/#/operations/railvizGetStation

For train runs there is /trip_to_connection which takes a TripId (e.g. one contained in a routing result or departure/arrival table) and it returns the full Connection.

As you can see on the map, MOTIS has all information about the static as well as real-time situation and can therefore also be used as a highly efficient timetable database.

[anbraten]

Thanks for the hints. I just found those openapi docs as well. Previously I was mainly looking at https://routing.spline.de/doc/index.html which is quite tough to read and misses some parts from the other page (maybe because of what the proxy is allowing 🤔). Would it be worth it adding https://routing.spline.de/openapi/ to the new transitous.org website as well?

As you can see on the map, MOTIS has all information about the static as well as real-time situation and can therefore also be used as a highly efficient timetable database.

That's really helpful. Are there any specific endpoints for gbfs already as well. Saw that it seems to be on the long-term roadmap for transitous.

[jbruechert]

Right, the documentation situation needs improvement. You can open a pull request if you want, otherwise I'll have a look later.

Probably the best course of action is to add a link to the MOTIS Openapi documentation at the top of https://routing.spline.de/doc/index.html with a note that that schema only shows the allowed request contents.

[jbruechert]

ah well I just realized the openapi docs describe the other API style that we currently don't support. They are just contained in the web interface folder and not published on purpose.

The proxy should get support for this kind of API as well though, so far it just wasn't needed for anything (web interface or existing clients). It is a bit nicer though.

[felixguendling]

That's really helpful. Are there any specific endpoints for gbfs already as well

Yes, you can do uni-modal routing with the GBFS endpoint. There's a vector tile layer that gives all free vehicle locations as well as station locations with the number of available vehicles. You can render it with a custom style (example how it's done on the MOTIS web ui. As mentioned in motis-project/motis#452 MOTIS does not yet support zone exclusions (neither for parking nor for driving through).

In general there will still be changes in the MOTIS API as we don't have a stable API interface yet and currently we can't distinguish between internal (module to module) and external APIs as they're all publicly available. Journey format, etc. might also be adjusted on the way to a stable and versioned API. Still of course we try to keep things as stable as possible and won't make unnecessary changes.