Comparison with OpenTripPlanner

[laem]

Hi, I haven't found any comparison of goals and features with OpenTripPlanner.

It would be interesting for newcomers to this field.

[felixguendling]

Creating a very detailed comparison between both projects would require a lot of work (or at least more work than I have time for at the moment) for benchmarking, creating feature lists, etc. If someone wants to create such a document, I would be happy to support.

A very short comparison:

• MOTIS is born out of a ongoing research collaboration between Deutsche Bahn (Germanys government owned railway company) and Technical University of Darmstadt. So a lot of the requirements stem from this context.
• OpenTripPlanner has been open source for many more years than MOTIS and therefore (currently) has a bigger (open source) community, ecosystem (in terms of UIs, documentation, etc.), and more production usage. This is natural and has nothing to do with the quality of the software itself. OTP currently also has more features like support for GTFS-Flex or NeTEx/SIRI timetables. MOTIS can be extended to also support those features and contributions are welcome.
• MOTIS provides modules for map tiles, street autocomplete (geocoding), etc. and therefore covers more functionalities outside routing than OTP. With OTP you will need to search for a separate solution to server tiles, geocoding, etc. Of course you could also use separate solutions for these tasks with MOTIS, too. But with MOTIS we have a "batteries included" approach to make it very easy to create your own mobility platform.
• I would always recommend to benchmark with your own datasets but my guess would be that MOTIS has better performance and requires way less memory (including all aspects like tile server, geocoder, routing, etc.), which makes a big difference for large datasets. If you want to only cover a small dataset (a single city or region), this aspect is not very important. However, if you want to load data from a country like Germany or even Europe, the difference could be bigger. But that's just my guess - I didn't try it and would always recommend to measure with your specific datasets.

If someone would like to create a feature table and a performance comparison on different datasets, I would support this effort. But when making the decision to use OTP or MOTIS, I would always recommend to just create a small test setup with both, benchmark a bit and get a feel for the software. Both projects have setup instructions that should take only a few minutes to execute.

[felixguendling]

A general problem with those comparisons is that they can become outdated very fast. Then they are misleading and it would be better to have no comparison at all. So a comparison like mine can only be a snapshot of the current status-quo. Both projects are under active development (adding features, improving performance, etc.). So if you would ask the same question a few months later, the answer might change drastically.

[laem]

Thanks a lot for your quick answer. It's already very enlightening. I hope it will serve other people too.

However, if you want to load data from a country like Germany or even Europe, the difference could be bigger.

Well, I just tried to load the france.osm.pbf file in OTP 2.4, on my 16 go RAM computer, giving it 12 go (-Xmx12G), it resulted in a java.lang.OutOfMemoryError: Java heap space error.

I'll try with Motis right away.

If you want some background for my question : in France, Navitia was an open source altenrative to OTP, with an API alongside. SNCF (DB equivalent in France) is still using Navitia. But the company behind Navitia decided to close the source this year. So there exists no API based on open source software that serves transit navigation in France. Navitia can still be used, but trust is somewhat broken. SNCF still lets people use their Navitia API, but it's only for trains, not transit (even though their main booking platform, sncf-connect.com, provides transit navigation too, probably based on Navitia).

Therefore, I'm trying to setup my navigation serveur. From A to B, with transit information loaded from public GTFS files provided by transport.data.gouv.fr.

[laem]

Well, setup of motis with france.osm.pbf + french trains gtfs didn't go better than OTP on my 16go i7 laptop.

[felixguendling]

You seem to have a lot of modules enabled which is usually not necessary.

I would start with a minimal set of modules. If you want to have only routing for public transport including auto-complete for station names and map tiles, you can try with these modules enabled:

modules=intermodal
modules=tiles
modules=nigiri

# rest of the config the same as before
# maybe remove sections for modules that are now disabled if necessary

Let me know if it worked.

[laem]

Thanks for your help !

I've tried with just a French region (Bretagne), just one GTFS, and it works :)

Here's my config

#!/bin/sh

TARGET="linux-amd64"

# Download and extract MOTIS.
wget https://github.com/motis-project/motis/releases/latest/download/motis-${TARGET}.tar.bz2
tar xf motis-${TARGET}.tar.bz2


# Write config.ini
#
#paths=osm:input/pays-de-la-loire.osm.pbf
#paths=osm:input/basse-normandie.osm.pbf
#paths=osm:input/haute-normandie.osm.pbf

cat <<EOT >> config.ini
modules=intermodal
modules=address
modules=tiles
modules=ppr
modules=nigiri

intermodal.router=nigiri
server.static_path=motis/web
dataset.no_schedule=true

[import]
paths=schedule-avv:input/export-ter-gtfs-last.zip
paths=osm:input/bretagne.osm.pbf

[ppr]
profile=motis/ppr-profiles/default.json

[tiles]
profile=motis/tiles-profiles/background.lua
EOT

# Start MOTIS
./motis/motis

[felixguendling]

Nice! 🚀

Let me know when you hit any problems :-)

[laem]

See #424 for my following (and successful) atemps :)

[laem]

Demo : https://motis.cartes.app

All public transport (bus, coach, trains) of Brittany :)

[felixguendling]

Looks great! :)

I guess you're using nigiri (like in the example config.ini). If that's the case, you can easily set the nigiri.num_days property to large numbers. Currently, only two days are loaded. Since nigiri uses 512 bitfields anyway, the memory usage should not go up significantly if you set it for example to 356 days (or whatever your GTFS provides, up to 500 days).

[PartTimeDataScientist]

Not completely related to the comparison of MOTIS and OTP but it could be worth to collect known stable configs for various regions in the/a repository like e.g. Pelias is doing it for the geocoder:

https://github.com/pelias/docker/tree/master/projects

This would at the very minimal provide good starting points for further optimization and comparisons and should allow to get a working setup up and running very quickly.

The more advanced users could also easily copy&paste the interesting parts of a setup and build a new desired configuration that covers multiple regions

[laem]

@PartTimeDataScientist this is the code that I deploy on a VM https://github.com/laem/motis. Could be helpful for others. As you can see, haven't been able to deploy it on a PaaS, but on a Ubuntu VPS, it was easy :)

[leonardehrenfried]

As an OTP maintainer I can only say that Felix has done a good job at summarising the strengths and weaknesses of each project. I agree that a general recommendation is difficult so you should just try for yourself which one fits your need better. Immerse yourself in the respective communities and speak to other users.

[laem]

Hi @felixguendling , I'm reviving this thread to ask if hardware requirements have been listed for a proper Motis setup.
Could also be examples that work.

E.g. :

• the demo instance, covering Benelux+germany (400Mo GTFS + 2Go osm.pbf) runs on a 16Go RAM 4VCPU x.xyz cloud instance using 22 Go of disk space

I'm getting crashes when starting Motis with a 1Go osm.pbf file and I suspect my 4Go RAM set is too small.

Edit : switching to a 16Go server resolved the issue. However, I'm only trying with ~ 1/5th of France right now.

[felixguendling]

It heavily depends on the configuration, not just the dataset you use. Also vCPUs might differ across providers. In theory you can run MOTIS with 1 vCPU or even on a Raspberry Pi. But this will be very slow and you won't be able to handle multiple users in parallel. The more vCPUs, the more parallel queries can be handled. I think it's impossible to give a "one size fits all" recommendation.

I would recommend to use two servers:

• one is only temporary for the import to generate the data directory. This step requires more memory (and profits from more CPU because most steps are parallelized) than actually running the server.
• the other server can have less RAM and is only there to run MOTIS (but not do any preprocessing). You store the data directory in a .tar.zstd in S3 and this server downloads the archive, extracts it and runs MOTIS.

This way, you can run MOTIS on a cheaper instance.

My approach would be to do a preprocessing and a "production" run separately on a larger test instance and monitor peak memory usage. Then select a instance type that has this amount of memory and maybe a bit of buffer (e.g. if you monitor 5 GB of memory usage select the 8 GB instance type).

You might also be able to save money by using the ARM server types together with MOTIS's aarch64 distribution.

In general: only turn on MOTIS features/modules you really need.

[felixguendling]

As an example for the MOTIS Europe instance with datasets from: CH+NL+BE+PL
Production memory: 40GB
Preprocessing memory: 60GB

However, if we would use the Valhalla module instead of OSRM, this would be way less. However, Valhalla uses more memory the more parallel requests you have and is therefore more unpredictable in memory usage. Since OSRM is also faster and the server has enough memory anyway, we use OSRM here. But if you want to use less memory and it's fine that queries are slower, then you can use Valhalla. There are always different tradeoffs and IMO it doesn't make sense to give general advice. It always depends on your use case.

[laem]

Thanks Felix, your advice on building (preprocessing files) on another server is very helpful. In theory this could be done in a centralized VM server launched only once a month (or on hardware), while the production server would be a more decentralized architecture of PaaS on-demand instances.

I didn't expect your demo server to have such a big memory, it's very helpful to know this.

[felixguendling]

Be careful with real-time data. The trip ids only match if you use the correct GTFS-static. If you don't update, the matching rate will probably go down. So it's good to either know the exact times at which the GTFS-static feed is updated or otherwise import in a regular interval. Some servers also tell you E-Tag or last modified or you can check if the hash changed to know when to update and you poll e.g. 1x/15min or so.

[kalon33]

As an OTP maintainer I can only say that Felix has done a good job at summarising the strengths and weaknesses of each project. I agree that a general recommendation is difficult so you should just try for yourself which one fits your need better. Immerse yourself in the respective communities and speak to other users.

Same advice here as a OTP instance maintainer for years. TBH, what I miss is a web interface on par with what digitransit-ui provides, or at least a more complete android app with the ability to change the server used and language in app, and use current location and street addresses.

[laem]

What is digitransit-ui ? Is is an end-user UI created to work with OTP as a backend ? So you'd need a similar UI but plugged on a motis server ?

Do you have any examples of the UI in action ? Is https://www.hsl.fi/en a deployment of digitransit-ui ?

This is what the french UI I'm developing looks like for the public transport part :

It's on cartes.app, repo laem/futureco. It aims to be a generalist map app, rather than a specialised public transport app.

[felixguendling]

Until now, we never had the time to focus on a user interface. Since MOTIS is being developed at the algorithms group at Technical University of Darmstadt, I would also not consider UI development our main expertise. I do not expect this to change in the future.

or at least a more complete android app with the ability to change the server used and language in app, and use current location and street addresses.

Since MOTIS is open source, we're open to take contributions in this area. However, the current UIs are more or less deprecated since the web UI is based on the Elm programming language which is abandoned and the Android UI is using XML to define the UI which got replaced by JetPack Compose. I always thought about those UIs as examples, never as fully blown applications for real-world usage.

Making MOTIS (at least somewhat) compatible to the OTP GraphQL API used in digitransit would also be something I would like to have. Currently, I don't have capacity for this. I also guess that this would be a big effort. However, connecting MOTIS with the OTP ecosystem could have many advantages.

Another example of the digitransit-ui is this: https://herrenberg.stadtnavi.de

[GerdC]

Great. For my client, I implemented both, access to OTP GraphQL and Motis.
GraphQL is easier and you get more. And less data is transmitted over the network, because the client can define which properties it needs.

So supporting GraphQL is really good for clients.
(Not too much for me, as I already did the work to consume the Motis API)

BTW, there are two different GraphQL APIs for OTP. The other one is by Entur in Norway.
The main difference is that Entur added service calls. To understand what a service call is: Imagine you're in a train before the next stop. You hear an announcement over the loudspeaker. A service call is every information that makes sense in such an announcement.