How to migrate from OTP1 to OTP2

Command line

The command line parameters are changed. 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 access 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 support mixing any data sources that is supported.

OTP1 loads input data files(DEM, OSM, GTFS, NeTEx) based on the suffix(file extension). But for GTFS files OTP1 also open the zip-file and look for stops.txt. OTP2 identify GTFS files by the name only. OTP2 will read any zip-file or directory that contains "gtfs" as part of the name. All files-types in OTP2 is resolved by matching the name with a regexp pattern. You can configure the patterns in the build-config.json if the defaults does not suites you.

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

Build config

These properties changed names from:

These parameters is no longer supported:

Router config


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 documentation on what is currently supported - we are adding features one by one. The plan is to go over the API documentation before the release - we do not prioritize keeping the documentation up to date, except for this migration guide document.

The following parameters are missing in OTP2 but will be added: - startingTransitTripId The ability to plan a trip from on board a vehicle should be implemented by Q1 2021. - intermediatePlaces - ability to specify intermediate destinations along the route. It is not certain when this will be implemented. - nonpreferredTransferCost, (un)preferredRoutes, (un)preferredAgencies - these help diversify or customize the trips and operators visible in results. Due to the new transit routing algorithm, Entur plans to completely rewrite these features, accounting for market-neutrality requirements and showing relevant trips and operators in local vs. intercity trips.

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: * maxWalkDistance, maxTransferWalkDistance, & maxWait - walkReluctance and waitReluctance should be utilized. If implemented, they should be filters on top of Raptor search rather than embedded in search. But this shouldn't be necessary: if the trip is just beyond max distance/wait, rider should still see it if it is the only option. 
 * maxHours & useRequestedDateTimeInMaxHours - This is replaced by searchWindow, which limits the arrival or departure window of the trip
 * worstTime - This factor returns the “worst” trip in a depart after/arrive by search, i.e. the latest or earliest trip available. It is not a priority for current OTP2 users but could be added as a filter.
 * waitAtBeginningFactor - No longer necessary to weight the initial wait differently based on the the Range Raptor search algorithm, which no longer prefers a departure at one valid time over another. Filtering could be implemented on top of Raptor to show certain departure times before others.
 * pathComparator - The ability to set a sort order based on departure or arrival should be the domain of the API rather than the search. 
 * startingTransitStopId - duplicative with fromPlace
 * onlyTransitTrips - the new feature for specifying access, egress, transit and direct mode replace the need for this parameter.


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.

New/changed query parameters in the plan request

Response changes

Changes to the Index API


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.


The analyst API endpoints have been removed.


The scripting API endpoint has been removed.