How to migrate from OTP1 to OTP2

Command Line

The OTP2 command line parameters are different than in OTP1. Use the --help option to get the current documentation, and look at the Basic Tutorial, Start up OPT for examples. The possibility to build the graph in 2 steps (streets then transit) is new in OTP2. OTP2 does not support multiple routers.

File Loading

OTP1 accesses all files using the local file system, no other data-source is supported. In OTP2 we support accessing cloud storage. So far Google Cloud Storage is added and we plan to add support for AWS S3 as well. Config files (otp-config.json, build-config.json, router-config.json) are read from the local file system, while other files can be read/written from the local file-system or the cloud. OTP2 supports mixing any data sources that are supported.

OTP1 loads input data files (DEM, OSM, GTFS, NeTEx) based on the suffix (file extension). But for GTFS files OTP1 also opens the zip-file and looks for stops.txt. OTP2 identifies GTFS files by the name only: it will detect any zip-file or directory that contains "gtfs" as part of the name. All file types in OTP2 are resolved by matching the name with a regexp pattern. You can configure the patterns in the build-config.json if the defaults do not suit you.

OTP2 does not support multiple routers, but you can load as many GTFS and/or NeTEx feeds as you want into a single instance of OTP2.

Build Config

New parameters:

These properties changed names from:

These parameters are no longer supported:

OTP2 records the "parentStation" relationship between stops and stations in its internal transit model, based on the GTFS and/or NeTEx input. This enables OTP to search from all stop in a station without walking/waiting when the request from/to input field is a station id. There is no way to automatically infer this parent station relationship based on geographic proximity in OTP2.

Transfers in OTP2 are generated based on the stop location and the OSM data or GTFS Pathways. In future versions of OTP2 we also want to support generating simple transfers based on "line-of-sight" if no pathways or OSM data exist. See issue #3204.

Cleaning and patching input data is NOT a core feature of OTP, but anyone is welcome to implement a sandbox plugin to patch data. So, if any of the features above are needed they can be ported from OTP1 into an OTP2 sandbox feature.

Router Config

See the Router Configuration for a description of the new and existing routing parameters.

New parameters:

These parameters are no longer supported:

REST API

Trip Planning

Support for XML as a request/response format is removed. The only supported format is JSON.

Query parameter changes

A lot of the query parameters in the REST API are ignored/deprecated, see the RoutingRequest and the RoutingResource class for the documentation on what is now supported in 2.0. A few features did not make it into the 2.0, but is sheduled for the 2.1 release. See GitHub issues 2.1.

The following parameters are missing in OTP2 but will be added:

Some features in OTP1 will not be present upon launch in OTP2, and they are proposed to be removed permanently from OTP2, but may require some development to support valid important cases:

Parameters that have changed:

New parameters in OTP2:

Paging

In OTP1 most client provided a way to page the results by looking at the trips returned and passing in something like the last-depature-time + 1 minute to the next request, to get trips to add to the already fetched results. In OTP2 the recommended way to do this is to use the new TripPlan metadata returned by the router call.

Response changes

Changes to the Index API

AlertPatcher

The AlertPatcher, which was under the /patch path, is removed. In order to update alerts, please use a GTFS-RT Service Alert updater instead. An example of a simple service for producing static GTFS-RT Service Alert feed from JSON is manual-gtfsrt.

Querying for alerts has been moved under the index API, where /alerts can be appended to stop, route, trip and pattern.

Analyst

The analyst API endpoints have been removed.

Scripting

The scripting API endpoint has been removed.