MOTIS Notes

Reading/Watching Material

Be aware of https://github.com/motis-project/motis/issues/433 when testing against the public demo server.
There are detail controls for access/egress modes for journeys but not for the transport modes themselves it seems. Think e.g. of D-Ticket users wanting to exclude long distance trains and operators/providers not covered.
Times are all specified in UNIX timestamps, how do we translate that back to the corresponding local timezone everywhere?
Backward search (ie. searching journey by arrival time) is really backward, ie. start and destination change their meaning. That's fine, but very different from how other APIs deal with this.
Only parts of the API are mentioned in the documentation, you can find more by observing the web UI and looking into the protocol .fbs files. This includes API for looking up station by geo coordinate and for querying arrivals/departures at a given station, both things KPT/PTE expect/need.
Location lookup by geo coordinate needs https://github.com/motis-project/motis/pull/436 for getting correct names.
Are there ways to control minimum layover/connection times? Some connections by default are currently extremely ambitious.
There's only the bare minimum of GTFS data passed through to clients, things not relevant for routing are omitted (e.g. line colors).

Many bundled dependencies, some haven't been updated in a while and potentially interact with hostile data (e.g. Flatbuffers). Is there a security problem?
Should we expose MOTIS directly or put it behind a Apache/nginx/etc reverse proxy for SSL termination and handling the static content/UI? Would remove the HTTP and SSL parts in MOTIS from direct exposure to hostile input, and potentially give us support for more protocol details (HTTP2, compression, etc) should that be lacking in MOTIS' internal HTTP server.
Is there support for incremental OSM data updates? The full import process for this is very expensive.

Attempting to import the full European pbf fails even with 100G RAM. What are the limits here, are there any workarounds by doing this in smaller increments for example?
GTFS-RT in combination with nigiri as described in https://github.com/motis-project/motis/wiki/Real-Time-Updates fails on loading the ris module -> That is just outdated documentation, using the built-in GTFS-RT fetcher from nigiri works just fine without needing extra tooling even.
The code indicates support for parkendd compatible parking API, although that seems to be nowhere mentioned in the docs.
Importing the Swiss national GBFS feed needs https://github.com/motis-project/motis/pull/437.

osrm-foot vs ppr: aren't those two providing the same functionality? gbfs depends on osrm-foot so we practically need both for now?
what is osrm-bus needed for? is it needed at all given it's not in the demo instance config?
there is also a Valhalla module, how does that relate to osrm/ppr? If that's yet another alternative, which one is the one we want/is recommended?

Routing with car parking and footppr as access modes results in an infinite loop in the Swiss dataset.
Jonah mentioned excessively long running routing requests on some datasets, those might actually be infinite loops: https://github.com/motis-project/motis/issues/438.