Common configuration format for representing existing Motis-Instances

[1Maxnet1]

When dealing with our two different Motis-instances, I faced the challenge on how to save two different configuration files. I thought about having two configuration files, so I can tell our MOTIS-Client to choose the one or the other. Additionally there is the possibility to add some information about e.g. the loaded data of the MOTIS-instance into the client, so it already knows e.g. about the coverage. Before I come up with a format for this configuration file, I would like to discuss this, so maybe we can come up with a common format for configuration files, that can be used across different software, which communicates with MOTIS instances.

I did a similar thing for TRIAS-Clients and discussed the format here, where I would also specify the format and additionally we could collect configuration files of future public available instances.

What do you think? Any feedback or questions appreciated

[felixguendling]

Basically, MOTIS has already a configuration format (the config.ini) where all features (enabled modules and their options) and input files are specified. I would guess there are a lot of options to document. Just a few that come to mind:

• Which datasets are loaded? (there can be multiple timetables but only one OSM file)
• What is the timetable span of the loaded datasets?
• Which modules are enabled?
  • Are real-time information available (if yes, for which timetables specified above)?
  • Which routing modules are loaded?
  • Is the intermodal module available? If yes, which router is used (/routing, /tripbased, /csa, etc.)?
  • Which routers are loaded (Parking, OSRM-foot, OSRM-bike, OSRM-car, PPR-default, PPR-... (other profiles like wheelchair, etc.))
  • Is the tiles module for delivering map tiles enabled?
  • Is the railviz module for live map info + departure/arrival tables enabled?
  • Is the guesser module for station autocomplete enabled?
  • Is the address module for address autocomplete enabled?
  • Is the lookup module for basic info like the timetable span enabled?
  • Is the cc connection checking module enabled? Or the revise module to update connections according to RT updates.
  • Is the parking module for Park & Ride queries enabled?
  • Is the path module available for drawing exact paths where vehicles drive on the map?
  • Are RSL capabilities enabled?
• Does this MOTIS instance serve files (i.e. the MOTIS UI)?

Basic information such as endpoint address, MOTIS version, etc. should obviously also be included.

[felixguendling]

Basically, MOTIS delivers all active routes unter the /api URL. For example here our demo instance: https://europe.motis-project.de/api

[1Maxnet1]

Basically, MOTIS delivers all active routes unter the /api URL. For example here our demo instance: https://europe.motis-project.de/api

Then I wouldn't add it to a config file, as the software communicating with the motis-server can request them on it's own.

Basic information such as endpoint address, MOTIS version, etc. should obviously also be included.

Yep.

Which datasets are loaded? (there can be multiple timetables but only one OSM file)

Can these timetables overlap in the timespan they provide? If so I would include it in the config yes.

What is the timetable span of the loaded datasets?

Agree.

Would you mind if I create an issue at https://github.com/public-transport/transport-apis to discuss it there as well and create a draft on how that config could look like for further discussions?

[felixguendling]

Can these timetables overlap in the timespan they provide?

Yes. This is the case for the demo instance (Switzerland, Germany, Netherlands). They can but they don't have to overlap. You could also mix this years timetable and next years timetable. I think ideally, this would also be something that MOTIS communicates via the API but for now it's easier to include it in the client config.

Feel free to discuss this topic in the transport-apis repo.

[1Maxnet1]

See public-transport/transport-apis#61