MOTIS Potential

[felixguendling]

This GitHub issue exists to give an overview of features that would extend MOTIS in a valuable way. If you want to discuss a specific feature in more detail, please open a separate issue. I will link those more detailed discussion issues here for reference to keep an overview. Most of the features would need to be implemented in the routing core nigiri.

• Via-Routing: give the routing a list of via via-(stations/coordinates) with a minimum required stay time for each station/coordinate. The routing should produce Pareto-optimal results (as always) for all journeys that go through this list of stops, staying at each stop at least the given time. Note: this is not a traveling salesman problem as the routing will not optimize the ordering of the via-stops.
• Mode of (public) transport restriction: for any combination of the transport classes: allow to compute Pareto-optimal journeys that only involve the selected modes of transportation.
• Limiting the number of transfers. This can also be done external to MOTIS by filtering the returned routing results. However, it's possible to save some computation time if the maximum number of transfers is known beforehand. This option is already supported by the routing core - it's just not available via the API.
• Override the minimum transfer time for every station when routing or multiplying each transfer time with a constant factor.
• GTFS-RT experimental ADDED support
• Limit the routing to connections where bicycle carriage is allowed (+parse GTFS). To stay algorithmically correct, this needs to be incorporated into the route definition (transports on a route segment need to either all allow or all not allow bicycle carriage).
• Support for NeTEx and SIRI. The main reason is that GTFS-RT currently does not support important use cases such as reroutings or additional trains.
• Support Service Alerts (e.g. for now: in GTFS-RT)
• During journey reconstruction, if there are several stations where it's possible to switch between two trips: chose the "best" transfer station regarding some criteria (e.g. station size).
• Read shapes.txt and output compressed polylines for the public transport part in API routing results.
• Read data (timetables, osm, etc.) directly from a S3 bucket
• Open Routing Architecture #451
• Intelligent / heuristic selection of start and destination stops Random expensive intermodal routing requests #439
• Intelligent / heuristic selection of search interval or interval search speedup in general (Routing in areas with little data is very slow #443)
• API stability:
  • make it clear which APIs are internal and which are external
  • version the external API and try to keep it as stable as possible
• Leg based journey format to get writ of index hell which is probably a prerequisite also for the "open intermodal orchestrator architecture" task.
• PPR: tile based routing approach similar to Valhalla or at least try to lower memory usage to be able to cover larger areas with less memory.
• PPR: delta-updates
• Implement GTFS-Flex
• GBFS: consider zone restrictions (where to drive, where to park, etc.), opening hours, etc.
• Change the configuration format to JSON/Yaml to not have separator strings like schedule-xyz:xyz.zip. This should be { type: "schedule", tag: "xyz", path: "xyz.zip" } in JSON/Yaml to improve readability and simplify the parsing code (no string splitting!).
• compressed polylines compressed polylines #455
• Enable use of (command line flags just as illustration - details can change or be closer to the current configuration)
  • motis import -i input -o data generates a data directory that can be uploaded to S3 or moved around between nodes
  • motis run -i data runs MOTIS with the data directory - no matter what. Currently, MOTIS requires the input directory to run, which would not be necessary. It's only used to check that all preprocessed files are up-to-date. If this is ensured in another way, it would be nice to not need input data on a production server.
• make routing limits configurable
• RAPTOR query multi threading using hpx or upgrading ctx to have processing units of M of N threads
• high priority thread pool for interactive queries such as address/station autocomplete or railviz

If you want to work on one of those issues, please discuss this first with the MOTIS team. One way to do this is to open an issue here to discuss the details and telling us that you want to work on it so an issue is not done 2x at the same time.

[kalon33]

GTFS-RT ADDED, shapes.txt support and NetEx+Siri-Lite (including zipped feeds) support would really be great. In France we have some sources (like Blablabus) that "based on Government advice" have decommissioned GTFS-RT, and "for performance reasons, according to Government recommandations" use zipped SIRI-Lite feeds.

So we end having GTFS + Siri-Lite, NetEx + SiriLite and GTFS + GTFS-RT data combinations. Would be useful to be able to deal with them including if live feed is compressed.

[PartTimeDataScientist]

So we end having GTFS + Siri-Lite, NetEx + SiriLite and GTFS + GTFS-RT data combinations. Would be useful to be able to deal with them including if live feed is compressed.

You missed NeTEX + GTFS-RT although I am not sure if this combination really exists... ;-)

In general I guess that is the reason why the Entur operates services to convert NeTEX and SIRI to GTFS / GTFS-RT respectively. It's easier to convert everything centrally to a common denominator than update every consumer of the data to handle both standards...

https://github.com/entur/damu
https://github.com/entur/kishar