From cd1ff8b07d1a7da83d735bc674b4f14766a76c3c Mon Sep 17 00:00:00 2001
From: OTP Bot <bot@opentripplanner.org>
Date: Tue, 30 Jan 2024 09:34:34 +0000
Subject: [PATCH] Deployed a5ad4cc853 to dev-2.x in en with MkDocs 1.5.3 and
 mike 1.2.0.dev0

---
 en/dev-2.x/Configuration/index.html    | 4 ++--
 en/dev-2.x/SandboxExtension/index.html | 2 +-
 en/dev-2.x/apis/Apis/index.html        | 2 +-
 en/dev-2.x/search/search_index.json    | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/en/dev-2.x/Configuration/index.html b/en/dev-2.x/Configuration/index.html
index 8da15a00..a60ae02e 100644
--- a/en/dev-2.x/Configuration/index.html
+++ b/en/dev-2.x/Configuration/index.html
@@ -2310,8 +2310,8 @@ <h2 id="otp-serialization-version-id-and-graphobj-file-header">OTP Serialization
 <li><code>head -c 29 Graph.obj ==&gt;  OpenTripPlannerGraph;0000007;</code> (file header)</li>
 <li><code>head -c 28 Graph.obj | tail -c 7 ==&gt;  0000007</code>  (version id)</li>
 </ul>
-<p>The Maven <em>pom.xml</em>, the <em>META-INF/MANIFEST.MF</em>, the OTP command line(<code>--serVerId</code>), log start-up
-messages and all OTP APIs can be used to get the OTP Serialization Version Id.</p>
+<p>The Maven <em>pom.xml</em>, the <em>META-INF/MANIFEST.MF</em>, the OTP command line(<code>--serializationVersionId</code>), 
+log start-up messages and all OTP APIs can be used to get the OTP Serialization Version Id.</p>
 <h2 id="include-file-directive">Include file directive</h2>
 <p>It is possible to inject the contents of another file into a configuration file. This makes it
 possible to keep parts of the configuration in separate files. To include the contents of a file,
diff --git a/en/dev-2.x/SandboxExtension/index.html b/en/dev-2.x/SandboxExtension/index.html
index 5ebf2893..5e279d65 100644
--- a/en/dev-2.x/SandboxExtension/index.html
+++ b/en/dev-2.x/SandboxExtension/index.html
@@ -1964,7 +1964,7 @@ <h2 id="available-extensions">Available extensions</h2>
 <ul>
 <li><a href="../sandbox/GoogleCloudStorage/">Google Cloud Storage</a> - Enable Google Cloud Storage as a OTP Data Source</li>
 <li><a href="../sandbox/ActuatorAPI/">Actuator API</a> - API used to check the health status of the OTP instance.</li>
-<li><a href="../sandbox/GeocoderAPI/">Geocoder API</a> - Adds an API to search for corners, stops and stations.</li>
+<li><a href="../sandbox/GeocoderAPI/">Geocoder API</a> - Adds an API to search for stops and stations.</li>
 <li><a href="../sandbox/transferanalyzer/">Transfer analyser</a> - Module used for analyzing the transfers between 
 nearby stops generated by routing via OSM data.</li>
 <li><a href="../sandbox/SiriUpdater/">SIRI Updater</a> - Update OTP with real-time information from a Transmodel SIRI data source.</li>
diff --git a/en/dev-2.x/apis/Apis/index.html b/en/dev-2.x/apis/Apis/index.html
index 5a4d969f..35bfc6a7 100644
--- a/en/dev-2.x/apis/Apis/index.html
+++ b/en/dev-2.x/apis/Apis/index.html
@@ -1939,7 +1939,7 @@ <h1 id="apis">APIs</h1>
 entities on a vector map.</p>
 <p>The <a href="../../sandbox/ActuatorAPI/">Actuator API</a> provides endpoints for checking the health status of the
 OTP instance and reading live application metrics. </p>
-<p>The <a href="../../sandbox/GeocoderAPI/">Geocoder API</a> allows you to geocode street corners and stop names.</p>
+<p>The <a href="../../sandbox/GeocoderAPI/">Geocoder API</a> allows you to geocode stop names.</p>
 <h2 id="legacy-apis-to-be-removed">Legacy APIs (to be removed)</h2>
 <p>The OTP REST API used to power many apps and frontends. For years it was the only way to access
 OTP programmatically.</p>
diff --git a/en/dev-2.x/search/search_index.json b/en/dev-2.x/search/search_index.json
index bac51eca..5ec97790 100644
--- a/en/dev-2.x/search/search_index.json
+++ b/en/dev-2.x/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":""},{"location":"#opentripplanner-2","title":"OpenTripPlanner 2","text":"<p>OpenTripPlanner (OTP) is an open source multi-modal trip planner, focusing on travel by scheduled public transportation in combination with bicycling, walking, and mobility services including bike share and ride hailing. Its server component runs on any platform with a Java virtual machine (including Linux, Mac, and Windows). It exposes GraphQL APIs that can be accessed by various clients including open source Javascript components and native mobile applications. It builds its representation of the transportation network from open data in open standard file formats (primarily GTFS and OpenStreetMap). It applies real-time updates and alerts with immediate visibility to clients, finding itineraries that account for disruptions and service changes. OTP is released under the LGPL license. As of 2020, the codebase has been in active development for over ten years, and is relied upon by transportation authorities and travel planning applications in deployments around the world.</p> <p>You are currently reading the documentation for OpenTripPlanner 2, the second major version of OTP.</p>"},{"location":"#versions-of-this-documentation","title":"Versions of this documentation","text":"<p>Several versions of this documentation are built and published automatically for different branches of OTP. Each of these has a different stable URL, and you may switch between these versions using the selector in the upper left of the published documentation.</p> <p>Releases</p> <ul> <li>Latest - Version 2.4.0 (the git master branch)</li> <li>v2.3.0 - Version 2.3</li> <li>v2.2.0 - Version 2.2</li> <li>v2.1.0 - Version 2.1</li> <li>v2.0.0 - Version 2.0</li> <li>v1.5.0 - Stable 1.x release</li> </ul> <p>Snapshot</p> <ul> <li>dev-2.x - OTP 2 active development</li> </ul>"},{"location":"#audience","title":"Audience","text":"<p>The end users of OTP are the millions of people who rely on it to help plan their daily travel, often without even knowing they are using OTP. As an infrastructure component, installation and configuration of OTP tends to be somewhat technical and essentially invisible to those end users. This documentation is intended for people who wish to perform such deployments of OTP without necessarily diving into the internal details of the software.</p> <p>For members of the OTP community interested in software development, additional documentation detailing algorithms, data structures etc. is available as markdown files within the source code packages. It can be read in your IDE or when browsing the source tree on Github. See OTP Architecture.</p>"},{"location":"#quick-start","title":"Quick Start","text":"<p>We encourage you to read the introductory sections of this documentation to familiarize yourself with OpenTripPlanner use cases and configuration. But if you want to get started right away running your own OTP instance, the best place to start is the Basic Tutorial page.</p>"},{"location":"#getting-help","title":"Getting help","text":"<p>The fastest way to get help is to use our Gitter chat room where most of the core developers are. You can also send questions and comments to the mailing list or file bug reports via the Github issue tracker.  Note that the issue tracker is not intended for support questions or discussions. Please use the chat or the mailing list instead.</p>"},{"location":"#financial-and-in-kind-support","title":"Financial and In-Kind Support","text":"<p>OpenTripPlanner is a member project of Software Freedom Conservancy, a 501(c)(3) organization incorporated in New York, and donations made to it are fully tax-deductible to the extent permitted by law. Donations can be made by credit card, wire transfer or paper check. Please contact accounting@sfconservancy.org for instructions.</p> <p>OTP development is primarily carried out by full-time software engineers employed by transportation authorities and consultancies. Even with funding, it can be difficult to engage staff who have the specialized skill set required. Therefore, one of the best ways to support OTP is to allocate software development staff at your organization with transportation domain knowledge to participate in weekly development meetings and contribute to this effort. This also builds connections between organizations favoring open source collaboration.</p>"},{"location":"Accessibility/","title":"Accessibility","text":""},{"location":"Accessibility/#preamble","title":"Preamble","text":"<p>GTFS and Netex define accessibility primarily in terms of binary access for wheelchair users: it's either on or off. Whilst it is the desire of the OTP developers to broaden the scope of accessibility the lack of data limits us to use this definition in the implementation and in this document.</p>"},{"location":"Accessibility/#unknown-data","title":"Unknown data","text":"<p>Many agencies have the same problem: data on wheelchair-accessibility is, if it exists at all, patchy. If you only included trips and stops that are explicitly set to be wheelchair-accessible rather than unknown, it would be hard to get any result at all. For this reason OTP allows you to configure which sort of unknown information should be taken into account.</p>"},{"location":"Accessibility/#configuration","title":"Configuration","text":"<p>If you want to allow trips and stops of unknown wheelchair-accessibility then add the following to <code>router-config.json</code>:</p> <pre><code>{\n  \"routingDefaults\": {\n    \"wheelchairAccessibility\": {\n      \"trip\": {\n        \"onlyConsiderAccessible\": false,\n        \"unknownCost\": 600,\n        \"inaccessibleCost\": 3600\n      },\n      \"stop\": {\n        \"onlyConsiderAccessible\": false,\n        \"unknownCost\": 600,\n        \"inaccessibleCost\": 3600\n      },\n      \"elevator\": {\n        \"onlyConsiderAccessible\": false\n      },\n      \"inaccessibleStreetReluctance\": 25,\n      \"maxSlope\": 0.08333,\n      \"slopeExceededReluctance\": 50,\n      \"stairsReluctance\": 25\n    }\n  },\n  \"updaters\": []\n}\n</code></pre> <p>The parameters for <code>stop</code>, <code>trip</code> and <code>elevator</code> mean the following:</p> name default <code>onlyConsiderAccessible</code> Whether to exclude unknown accessibility and inaccessible stops/trips/elevators in the search. <code>true</code> <code>unknownCost</code> The cost to add if an entity has unknown wheelchair accessibility 600 <code>inaccessibleCost</code> The cost to add if an entity is known to be inaccessible 3600 <p>Note: Unless your accessibility data coverage is complete you will receive much better results by setting <code>onlyConsiderAccessible=false</code>, because otherwise you receive barely any results.</p> <p>Other parameters are:</p> <ul> <li><code>inaccessibleStreetReluctance</code>: if a street is marked as wheelchair-inaccessible this is the   penalty that is applied for wheelchair users. This should be quite high so that those are only   chosen as a very last resort. default: 25</li> <li><code>maxSlope</code>: the maximum slope that a wheelchair user can use without incurring routing penalties (   leading to those ways being avoided). default: 0.083 (8.3 %)</li> <li><code>slopeExceededReluctance</code>: how steep should the cost increase when you exceed the maximum slope.   By default, every percent over the limit doubles the cost of the traversal, so if the regular cost   is 100, being 1 percent over the limit will lead to a cost of 200, 2 percent over will lead to 400   and so on.   If you want an even steeper increase then set a value higher than 1. If you want it shallower use   a value between 0 and 1. To disable the penalty set a value below 0. default: 1</li> <li><code>stairsReluctance</code>: how much should a wheelchair user avoid stairs. This should be quite high so   that they are used only as a last resort. default: 25</li> </ul>"},{"location":"Accessibility/#accessible-transfers","title":"Accessible transfers","text":"<p>By default OTP only pre-calculates transfers between stops for able-bodied walkers. If they have no obstacles wheelchair users can use them, too, but there won't be guaranteed to be one.</p> <p>If you want OTP to also pre-generate wheelchair-accessible transfers use the following configuration in <code>build-config.json</code>:</p> <pre><code>{\n  \"transferRequests\": [\n    {\n      \"modes\": \"WALK\"\n    },\n    {\n      \"modes\": \"WALK\",\n      \"wheelchairAccessibility\": {\n        \"enabled\": true\n      }\n    }\n  ]\n}\n</code></pre> <p>This results in OTP calculating an accessible transfer if the default one is found to be inaccessible to wheelchair users.</p>"},{"location":"Accessibility/#example","title":"Example","text":"<p>A full configuration example is available at <code>/docs/examples</code></p>"},{"location":"Basic-Tutorial/","title":"OpenTripPlanner Basic Tutorial","text":"<p>This page should allow you to set up and test your own OTP2 server. If all goes well it should only take a few minutes!</p>"},{"location":"Basic-Tutorial/#get-java","title":"Get Java","text":"<p>As a Java program, OTP must be run within a Java virtual machine (JVM), which is provided as part of the Java runtime (JRE) or Java development kit (JDK). OTP2 is compatible with Java 21 or later. We recommend running on Java 21 rather than a later version, as it is a long-term support release. Run <code>java -version</code> to check that you have version 21 or newer of the JVM installed. If you do not, you will need to install a recent OpenJDK or Oracle Java package for your operating system.</p>"},{"location":"Basic-Tutorial/#get-otp","title":"Get OTP","text":"<p>OpenTripPlanner is written in Java and distributed as a single runnable JAR file. This is a \"shaded\" JAR containing all other libraries needed for OTP to work, and is available from the Maven Central repository. You will be able to go to the OTP directory at Maven Central, navigate to the directory of releases, and download the file with <code>shaded.jar</code> suffix .</p> <p>You may also want to get your own copy of the OTP source code and build a bleeding edge development JAR from scratch, especially if you plan to do some development yourself. In that case, check out the branch <code>dev-2.x</code>.</p>"},{"location":"Basic-Tutorial/#get-some-data","title":"Get some data","text":""},{"location":"Basic-Tutorial/#gtfs-for-transit-schedules-and-stops","title":"GTFS for Transit Schedules and Stops","text":"<p>First you'll need GTFS data to build a transit network. There's an excellent description of the GTFS format here. Transport agencies throughout the world provide GTFS schedules to the public. Transitland has a registry of feeds and TransitFeeds also provides an extensive catalog. The best option is often to simply fetch the data directly from a transit operator or agency. If you know of a feed you want to work with, download it and put it in an empty directory you have created for your OTP instance such as <code>/home/username/otp</code> on Linux, <code>/Users/username/otp</code> on MacOS, or <code>C:\\Users\\username\\otp</code> on Windows. For OTP2 to detect a GTFS file, its name must end in <code>.zip</code> and must contain the letters 'gtfs'. We often use the convention of saving GTFS files with names ending in <code>.gtfs.zip</code> which meets both these criteria, reflecting the fact that a GTFS feed is just a ZIP file containing a specific set of files. If you don't have a particular feed in mind, the one for Portland, Oregon's TriMet agency is a good option. It is available at this URL. This is a moderate-sized input of good quality (TriMet initiated OTP development and helped develop the GTFS format). On Linux, this could be done on the command line as follows:</p> <pre><code>$ cd /home/username\n$ mkdir otp\n$ cd otp\n$ wget \"http://developer.trimet.org/schedule/gtfs.zip\" -O trimet.gtfs.zip\n</code></pre>"},{"location":"Basic-Tutorial/#osm-for-streets","title":"OSM for Streets","text":"<p>You'll also need OpenStreetMap data to build a road network for walking, cycling, and driving. OpenStreetMap is a global collaborative map database that rivals or surpasses the quality of commercial maps in many locations. Several services extract smaller geographic regions from this database. Interline Technologies maintains a collection of extracts updated daily for urban areas around the world . Geofabrik provides extracts for larger areas like countries or states, from which you can prepare your own smaller bounding-box extracts using Osmosis , osmconvert, or (our favorite) Osmium-Tool. There is also Protomaps which can create custom extracts  for any region of the world with an easy to use drag and drop interface. OSM data can be delivered as XML or in the more compact binary PBF format. OpenTripPlanner consumes only PBF because it's smaller and more efficient.</p> <p>Download OSM PBF data for the same geographic region as your GTFS feed, and place this PBF file in the same directory you created for the OSM data. If you are using the TriMet GTFS feed, you could download the Geofabrik extract for the US state of Oregon , then further trim that to just the TriMet service area using the bounding box switch of one of the above tools. On Linux or MacOS you could do that as follows:</p> <pre><code>$ cd /home/username\n$ wget http://download.geofabrik.de/north-america/us/oregon-latest.osm.pbf\n$ osmconvert oregon-latest.osm.pbf -b=-123.043,45.246,-122.276,45.652 --complete-ways -o=portland.pbf\n$ mv portland.pbf otp\n</code></pre> <p>We find this tool useful for determining the geographic coordinates of bounding boxes. The CSV option in that tool produces exactly the format expected by the <code>osmconvert -b</code> switch. The <code>--complete-ways</code> switch is important to handle roads that cross outside your bounding box.</p> <p>If you have extracted a smaller PBF file from a larger region, be sure to put only your extract (not the original larger file) in the directory with your GTFS data. Otherwise OTP will try to load both the original file and the extract in a later step. See the page on preparing OSM data for additional information and example commands for cropping and filtering OSM data.</p>"},{"location":"Basic-Tutorial/#starting-otp","title":"Starting OTP","text":"<p>A typical command to start OTP looks like <code>java -Xmx2G -jar otp.shaded.jar &lt;options&gt;</code>. The <code>-Xmx</code> parameter sets the limit on how much memory OTP is allowed to consume. GTFS and OSM data sets are often very large, and OTP is relatively memory-hungry. You will need at least 1GB of memory when working with the Portland TriMet data set, and several gigabytes for larger inputs. Here is more information about the system requirements. If you have sufficient memory in your computer, set this to a couple of gigabytes (e.g. <code>-Xmx2G</code>). Java uses a garbage collection approach to memory management, which requires some \"breathing room\" to efficiently operate. Without sufficient free memory OTP can grind to a halt. VisualVM is a good way to inspect Java memory usage, especially with the VisualGC plugin.</p>"},{"location":"Basic-Tutorial/#building-graphs","title":"Building Graphs","text":"<p>There are two main phases to preparing and deploying an OTP server. The first is to analyze the GTFS, OSM and any other inputs (such as elevation data) and build a representation of the transportation network. Following mathematical terminology we call this a 'graph', and refer to this phase as \"graph building\". The second phase is to start a server that provides trip planning and other API services for this graph.</p> <p>It is possible to save the graph to a file on disk after the first phase, then load the graph from the file in the second phase. This allows restarting the server or starting multiple instances of the server without repeating the often time-consuming process of building the graph. It is also possible to split the graph building process into separate OSM and GTFS stages for similar reasons: to allow reusing results from slow processes, such as applying elevation data to streets. These different options are controlled with command line switches, and will be described in more detail below and in other tutorials.</p>"},{"location":"Basic-Tutorial/#simple-one-step-server","title":"Simple One-step Server","text":"<p>The simplest way to use OTP is to build a graph in a single step and start a server immediately, without saving it to disk. The command to do so is:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --build --serve /home/username/otp\n</code></pre> <p>where <code>/home/username/otp</code> should be the directory where you put your configuration and input files.</p> <p>If you're using the Portland input data, the graph build operation should take about one minute to complete, and then you'll see a <code>Grizzly server running</code> message. At this point you have an OpenTripPlanner server running locally and can open http://localhost:8080/ in a web browser. You should be presented with a Javascript client application that will interact with your local OpenTripPlanner instance.</p> <p>This map-based user interface is in fact sending HTTP GET requests to the OTP server running on your local machine. It can be informative to watch the HTTP requests and responses being generated using the developer tools in your web browser. OTP's built-in web server will run by default on port 8080. If by any chance some other software is already using that port number, you can specify a different port number with a switch <code>--port 8801</code>.</p>"},{"location":"Basic-Tutorial/#saving-a-graph","title":"Saving a Graph","text":"<p>If you want speed up the process of repeatedly starting up a server with the same graph, you can build a graph from street and transit data then save it to a file using the <code>--build</code> and <code>--save</code> command line parameters together. If for example your current working directory (<code>.</code>) contains the input files and the OTP JAR file, you can use this command:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --build --save .\n</code></pre> <p>This will produce a file called <code>graph.obj</code> in the same directory as the inputs. The server can then be started later using the <code>--load</code> parameter, and will read this file instead of building the graph from scratch:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --load .\n</code></pre> <p>Another reason to perform these two phases separately is that the building process loads the entire GTFS and OSM data sets into memory, so can require significantly more memory than just running a server. Accordingly, you may want to perform the build on one machine (e.g. a throw-away cloud instance with more memory or compute capacity), then copy the resulting graph file to one or more smaller machines to serve the API.</p>"},{"location":"Basic-Tutorial/#layering-gtfs-onto-osm","title":"Layering GTFS onto OSM","text":"<p>Building the street graph (especially with elevation data) can take a long time. It is common for transit data to change more frequently than street data, so it can be convenient to build the street graph once, and then layer transit data on top of the streets to make the final graph.</p> <p>Again assuming the input files and OTP JAR file are in the current working directory, you can build a street graph with OSM and elevation data only (ignoring transit input files) with this command:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --buildStreet .\n</code></pre> <p>Then, to build a graph layering transit data on top of the saved street graph (built using the previous command):</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --loadStreet --save .\n</code></pre> <p>Finally, the server can be started using the <code>--load</code> parameter:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --load .\n</code></pre>"},{"location":"Basic-Tutorial/#command-line-switches","title":"Command Line Switches","text":"<p>The flow diagram below summarizes all the command line switches used in the above examples, and how they control which actions are taken when OTP starts up.</p> <p></p> <p>You must use at least one of the required parameters: <code>--load</code>, <code>--loadStreet</code>, <code>--build</code> , <code>--buildStreet</code>. A required parameter may imply other parameters when the flow allows for no other choice. For example, <code>--load</code> implies <code>--serve</code>, so <code>--serve</code> is not necessary and has no additional effect when used together with <code>--load</code>.</p> <p>You can run the OTP .jar file with the <code>--help</code> option for a full list of command line parameters.</p>"},{"location":"Basic-Tutorial/#exploring-the-api","title":"Exploring the API","text":"<p>If you want to learn how to use OTP's API's, check out the GraphQL tutorial.</p>"},{"location":"Bibliography/","title":"Routing Bibliography","text":"<p>This is a list of articles, dissertations, and books that have inspired and informed both the existing OTP routing engine and some ongoing experiments.</p> <p>OTP1 uses a single time-dependent (as opposed to time-expanded) graph that contains both street and transit networks. Walk-only and bicycle-only trips are generally planned using the A-star algorithm with a Euclidean heuristic. Walk+Transit or Bike+Transit trips are planned using A-star with the Tung-Chew heuristic (i.e. a graph grown backward from the destination providing a lower bound on aggregate weight) for queue ordering. For speed reasons we are performing single-variable generalized cost optimization, which is not ideal. We should be performing Pareto optimization on at least two variables (generalized cost and time).</p> <p>OTP2 splits the search into three segments: access from the origin to transit stops, egress from transit stops to the destination, and transit service connecting the two. For the transit segment, OTP2 uses the Multi-criteria Range Raptor algorithm. For the access and egress searches it uses the same approach as OTP1. Both splitting the search into three parts and use of a table-scanning algorithm like Raptor improve OTP2's performance significantly while increasing result quality by producing true Pareto-optimal sets of results.</p>"},{"location":"Bibliography/#algorithms-used-in-otp2-but-not-otp1","title":"Algorithms used in OTP2 but not OTP1","text":"<ul> <li> <p>Delling, Pajor, Werneck. Round-Based Public Transit Routing (2012)   This is a tabular approach to routing in public transit networks that does not use an (   explicit) graph. It is simpler and can outperform classic graph algorithms.   http://research.microsoft.com/pubs/156567/raptor_alenex.pdf</p> </li> <li> <p>Delling, Dibbelt, and Pajor. Fast and Exact Public Transit Routing with Restricted Pareto Sets (   2019)   Describes the heuristic used in OTP2 to eliminate options early when they are known to become   non-optimal before they reach the destination.   https://epubs.siam.org/doi/pdf/10.1137/1.9781611975499.5</p> </li> </ul>"},{"location":"Bibliography/#techniques-used-in-or-influencing-otp1-and-otp2","title":"Techniques used in or influencing OTP1 and OTP2","text":""},{"location":"Bibliography/#general-background","title":"General Background","text":"<ul> <li> <p>Bast, Hannah. Car or public transport -- two worlds. (2009)   Explains how car routing is different from schedule-based public transport routing.   http://www.mpi-inf.mpg.de/~bast/papers/car_or_public_transport.pdf</p> </li> <li> <p>Delling, Daniel. Engineering and augmenting route planning algorithms. (2009, dissertation)   Overview, including time-dependent and Pareto shortest paths.   http://i11www.ira.uka.de/extra/publications/d-earpa-09.pdf</p> </li> <li> <p>Delling, Sanders, Schultes, and Wagner. Engineering Route-Planning Algorithms. (2009)   Overview.   http://i11www.ira.uka.de/extra/publications/dssw-erpa-09.pdf</p> </li> </ul>"},{"location":"Bibliography/#path-search-speedup-techniques","title":"Path Search Speedup Techniques","text":"<ul> <li> <p>Delling and Wagner. Time-Dependent Route Planning. (2009)   Overview.   http://i11www.iti.uni-karlsruhe.de/extra/publications/dw-tdrp-09.pdf</p> </li> <li> <p>Delling and Wagner. Landmark-Based Routing in Dynamic Graphs. (2008)   http://i11www.ira.uka.de/extra/publications/dw-lbrdg-07.pdf</p> </li> <li> <p>Bauer, Delling, Sanders, Schultes, and Wagner. Combining Hierarchical and Goal-Directed Speed-Up   Techniques for Dijkstra\u2019s Algorithm. (2008)   http://algo2.iti.kit.edu/download/bdsssw-chgds-10.pdf</p> </li> <li> <p>Bauer and Delling. SHARC: Fast and Robust Unidirectional Routing. (2009)   SH ortcuts + ARC flags. Can be combined with ALT.   http://www.siam.org/proceedings/alenex/2008/alx08_02bauerr.pdf</p> </li> <li> <p>Delling, Daniel. Time-Dependent SHARC-Routing. (2008)   http://i11www.iti.uni-karlsruhe.de/extra/publications/d-tdsr-09.pdf</p> </li> <li> <p>Goldberg, Kaplan, and Werneck. Reach for A\u2217: Efficient Point-to-Point Shortest Path Algorithms.    (2005)    http://avglab.com/andrew/pub/msr-tr-2005-132.pdf</p> </li> </ul>"},{"location":"Bibliography/#multi-objective-pareto-shortest-paths","title":"Multi-objective Pareto Shortest Paths","text":"<ul> <li> <p>Das and Dennis. Drawbacks of minimizing weighted sums of objectives for Pareto set generation in   multicriteria optimization problems. (1997)</p> </li> <li> <p>M\u00fcller-Hannemann and Schnee. Finding All Attractive Train Connections by Multi-criteria Pareto   Search. (2007)   Deutsche Bahn information system. Does not account for on-street travel.</p> </li> <li> <p>Mandow &amp; P\u00e9rez de la Cruz. A New Approach to Multiobjective A Search. (2005)   NAMOA http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.8780&amp;rep=rep1&amp;type=pdf</p> </li> <li> <p>Mandow &amp; P\u00e9rez de la Cruz. Multiobjective A search with consistent heuristics. (2008)   NAMOA</p> </li> <li> <p>Machuca, Mandow and P\u00e9rez de la Cruz. Evaluation of Heuristic Functions for Bicriterion Shortest   Path Problems. (2009)   Evaluates heuristics from Tung &amp; Chew (1992) versus lexicographical ordering of priority   queue.   http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.160.4715&amp;rep=rep1&amp;type=pdf</p> </li> <li> <p>Perny and Spanjaard. Near Admissible Algorithms for Multiobjective Search. (2009)   Discusses relaxed Pareto dominance (Epsilon-dominance) and its use in Multi-objective A*. This   a scheme for approximating the entire pareto-optimal solution set that allows time and space   complexity polynomial in the number of nodes.   http://www-desir.lip6.fr/publications/pub_1052_1_ECAI08.pdf</p> </li> <li> <p>Tung and Chew. A multicriteria Pareto-optimal path algorithm. (1992)</p> </li> <li> <p>Delling and Wagner. Pareto Paths with SHARC. (2009)   http://i11www.iti.uni-karlsruhe.de/extra/publications/dw-pps-09.pdf</p> </li> </ul>"},{"location":"Bibliography/#resource-constrained-routing","title":"Resource-constrained Routing","text":"<ul> <li> <p>Dumitrescu &amp; Boland. Improved Preprocessing, Labeling and Scaling Algorithms for the   Weight-Constrained Shortest Path Problem. (2003)   Comparison of scaling and label-setting methods.</p> </li> <li> <p>Ziegelmann, Mark. Constrained Shortest Paths and Related Problems. (2001, dissertation)   http://scidok.sulb.uni-saarland.de/volltexte/2004/251/pdf/MarkZiegelmann_ProfDrKurtMehlhorn.pdf</p> </li> </ul>"},{"location":"Bibliography/#contraction-and-transfer-patterns","title":"Contraction and Transfer Patterns","text":"<ul> <li> <p>Geisberger, Robert. Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road   Networks. (2008, dissertation)   http://algo2.iti.kit.edu/documents/routeplanning/geisberger_dipl.pdf</p> </li> <li> <p>Geisberger, Robert. Contraction of Timetable Networks with Realistic Tranfers (2010)   Introduces the \"Station Model Graph\".   http://algo2.iti.kit.edu/download/time_table_ch.pdf</p> </li> <li> <p>Bast, Carlsson, Eigenwillig, Geisberger Harrelson, Raychev, and Viger. Fast Routing in Very Large   Public Transportation Networks Using Transfer Patterns. (2010)   http://ad.informatik.uni-freiburg.de/files/transferpatterns.pdf/at_download/file</p> </li> </ul>"},{"location":"Bibliography/#timetable-based-routing","title":"Timetable-based routing","text":"<ul> <li>Schulz, Frank. Timetable Information and Shortest Paths. (2005, dissertation)   Excellent reference.   http://d-nb.info/1001586921/34</li> </ul>"},{"location":"Bibliography/#alt-and-metric-embeddings","title":"ALT and Metric Embeddings","text":"<ul> <li> <p>Goldberg and Werneck. Computing Point-to-Point Shortest Paths from External Memory. (2005)   Introduced the ALT algorithm.   http://www.cs.princeton.edu/courses/archive/spring06/cos423/Handouts/GW05.pdf</p> </li> <li> <p>Linial, London, and Rabinovich. The Geometry of Graphs and Some of its Algorithmic Applications. (   1995)   http://pdf.aminer.org/000/798/423/the_geometry_of_graphs_and_some_of_its_algorithmic_applications.pdf</p> </li> <li> <p>Hjaltason and Samet. Contractive Embedding Methods for Similarity Searching in Metric Spaces. (   2000)   http://www.cs.umd.edu/~hjs/pubs/metricpruning.pdf</p> </li> <li> <p>Potamias, Bonchi, Castillo, and Gionis. Fast Shortest Path Distance Estimation in Large   Networks. (2009)   Briefly discusses the connection between landmark routing and more general research on metric   embeddings.   http://dcommon.bu.edu/xmlui/bitstream/handle/2144/1727/2009-004-shortest-distance-estimation.pdf</p> </li> </ul>"},{"location":"Bibliography/#calibration-and-implementation-details","title":"Calibration and Implementation Details","text":"<ul> <li> <p>Wardman, Mark. Public Transport Values of Time. (2004)   http://eprints.whiterose.ac.uk/2062/1/ITS37_WP564_uploadable.pdf</p> </li> <li> <p>A.M. El-Geneidy, K.J. Krizek, M.J. Iacono. Predicting bicycle travel speeds along different   facilities using GPS data: a proof of concept model. (2007)Proceedings of the 86th Annual   Meeting of the Transportation Research Board, Compendium of Papers, TRB, Washington, D.C., USA (   CD-ROM)</p> </li> <li> <p>Chen, Chowdhury, Roche, Ramachandran, Tong. Priority Queues and Dijkstra\u2019s Algorithm.   Summary: Despite better theoretical complexity for Fibonacci heaps, it is often as good or   better to use a binary heap as a priority queue when doing path searches.   http://www.cs.utexas.edu/users/shaikat/papers/TR-07-54.pdf</p> </li> </ul>"},{"location":"Bibliography/#post-dijkstra-public-transit-routing","title":"Post-Dijkstra Public Transit Routing","text":"<ul> <li> <p>Dibbelt, Pajor, Strasser, Wagner. Intriguingly Simple and Fast Transit Routing (2013).   Introduces the Connection Scan Algorithm (CSA).   http://www.ecompass-project.eu/sites/default/files/ECOMPASS-TR-021.pdf</p> </li> <li> <p>Delling, Katz, and Pajor. Parallel computation of best connections in public transportation   networks (2012).   \"In this work, we present a novel algorithm for the one-to-all profile-search problem in   public transportation networks. It answers the question for all fastest connections between a   given station S and any other station at any time of the day in a single query... two interesting   questions arise for time-dependent route planning: compute the best connection for a given   departure time and the computation of all best connections during a given time interval (e. g., a   whole day). The former is called a time-query, while the latter is called a pro\ufb01le-query.\"   http://www.ecompass-project.eu/sites/default/files/ECOMPASS-TR-021.pdf</p> </li> </ul>"},{"location":"BoardingLocations/","title":"Boarding locations","text":"<p>It is often the case that the coordinates of stops are relatively far away from where the passengers are expected to the wait for the vehicle.</p> <p>A good example of this is Buckhead subway station in Atlanta.</p> <p></p> <p>There the coordinates of the stop in GTFS are located near Peachtree Road so OTP would instruct  passengers to wait on the street rather than walking down the stairs to the platform.</p>"},{"location":"BoardingLocations/#osm-tagging","title":"OSM tagging","text":"<p>We can correct the waiting location for the passenger by adding some tags to OSM which help OTP decide to correct the location. In general, you should familiarise yourself with the OSM wiki page on public transport.</p> <p>You can add cross-references to a stop's id or code on all OSM entities (nodes, ways, relations) which have one of the following tag combinations:</p> <ul> <li><code>public_transport=platform</code></li> <li><code>highway=bus_stop</code></li> <li><code>railway=tram_stop</code></li> <li><code>railway=station</code></li> <li><code>railway=halt</code></li> <li><code>amenity=bus_station</code></li> <li><code>amenity=ferry_terminal</code></li> </ul>"},{"location":"BoardingLocations/#notes","title":"Notes","text":"<ul> <li><code>public_transport=stop_location</code> and <code>railway=stop</code> are explicitly not on the list as they denote   the place where the train stops, not the waiting area.</li> <li>The <code>railway</code> key is deprecated (even though still widespread) and you should use <code>public_transport</code>    instead.</li> <li>OTP does not process isolated nodes, but only nodes, which are part of routable ways. Therefore, adding a single ,  isloated boarding location node to OSM has no effect. There is an exception, though: isolated nodes, which are members of <code>public_transport=stop_area</code> relation, will be considered and automatically linked with the street graph. For more information, check the stop area documentation.</li> </ul>"},{"location":"BoardingLocations/#cross-referencing","title":"Cross-referencing","text":"<p>In order to tell OTP how to link up the OSM entities to the stops you need to add a <code>ref</code> tag whose value is the stop's id or code. </p> <p>However, tagging conventions vary from location to location so other tags can be configured, too.</p> <p>For example, there is a country-wide stop reference system in Germany called IFOPT and therefore if you want to use it to match stops (example platform),  add the following to <code>build-config.json</code>:</p> <pre><code>{\n  \"boardingLocationTags\": [\"ref\", \"ref:IFOPT\"]\n}\n</code></pre>"},{"location":"BoardingLocations/#multiple-stops-on-the-same-platform","title":"Multiple stops on the same platform","text":"<p>Some stations have a middle platform with a stop on either side of it. In such a case, you can  simply add two or more references separated by a semicolon, as seen in this example.</p>"},{"location":"BuildConfiguration/","title":"Build","text":""},{"location":"BuildConfiguration/#graph-build-configuration","title":"Graph Build Configuration","text":"<p>This table lists all the JSON properties that can be defined in a <code>build-config.json</code> file. These will be stored in the graph itself, and affect any server that subsequently loads that graph. Sections follow that describe particular settings in more depth.</p>"},{"location":"BuildConfiguration/#parameters-overview","title":"Parameters Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since areaVisibility <code>boolean</code> Perform visibility calculations. Optional <code>false</code> 1.5 buildReportDir <code>uri</code> URI to the directory where the graph build report should be written to. Optional 2.0 configVersion <code>string</code> Deployment version of the build-config.json. Optional 2.1 dataImportReport <code>boolean</code> Generate nice HTML report of Graph errors/warnings Optional <code>false</code> 2.0 distanceBetweenElevationSamples <code>double</code> The distance between elevation samples in meters. Optional <code>10.0</code> 2.0 embedRouterConfig <code>boolean</code> Embed the Router config in the graph, which allows it to be sent to a server fully configured over the wire. Optional <code>true</code> 2.0 graph <code>uri</code> URI to the graph object file for reading and writing. Optional 2.0 gsCredentials <code>string</code> Local file system path to Google Cloud Platform service accounts credentials file. Optional 2.0 includeEllipsoidToGeoidDifference <code>boolean</code> Include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge. Optional <code>false</code> 2.0 maxAreaNodes <code>integer</code> Visibility calculations for an area will not be done if there are more nodes than this limit. Optional <code>150</code> 2.1 maxDataImportIssuesPerFile <code>integer</code> When to split the import report. Optional <code>1000</code> 2.0 maxElevationPropagationMeters <code>integer</code> The maximum distance to propagate elevation to vertices which have no elevation. Optional <code>2000</code> 1.5 maxStopToShapeSnapDistance <code>double</code> Maximum distance between route shapes and their stops. Optional <code>150.0</code> 2.1 maxTransferDuration <code>duration</code> Transfers up to this duration with the default walk speed value will be pre-calculated and included in the Graph. Optional <code>\"PT30M\"</code> 2.1 multiThreadElevationCalculations <code>boolean</code> Configuring multi-threading during elevation calculations. Optional <code>false</code> 2.0 osmCacheDataInMem <code>boolean</code> If OSM data should be cached in memory during processing. Optional <code>false</code> 2.0 osmNaming <code>string</code> A custom OSM namer to use. Optional 2.0 platformEntriesLinking <code>boolean</code> Link unconnected entries to public transport platforms. Optional <code>false</code> 2.0 readCachedElevations <code>boolean</code> Whether to read cached elevation data. Optional <code>true</code> 2.0 staticBikeParkAndRide <code>boolean</code> Whether we should create bike P+R stations from OSM data. Optional <code>false</code> 1.5 staticParkAndRide <code>boolean</code> Whether we should create car P+R stations from OSM data. Optional <code>true</code> 1.5 stopConsolidationFile <code>string</code> Name of the CSV-formatted file in the build directory which contains the configuration for stop consolidation. Optional 2.5 streetGraph <code>uri</code> URI to the street graph object file for reading and writing. Optional 2.0 subwayAccessTime <code>double</code> Minutes necessary to reach stops served by trips on routes of route_type=1 (subway) from the street. Optional <code>2.0</code> 1.5 transitModelTimeZone <code>time-zone</code> Time zone for the graph. Optional 2.2 transitServiceEnd <code>duration</code> Limit the import of transit services to the given end date. Optional <code>\"P3Y\"</code> 2.0 transitServiceStart <code>duration</code> Limit the import of transit services to the given START date. Optional <code>\"-P1Y\"</code> 2.0 writeCachedElevations <code>boolean</code> Reusing elevation data from previous builds Optional <code>false</code> 2.0 boardingLocationTags <code>string[]</code> What OSM tags should be looked on for the source of matching stops to platforms and stops. Optional 2.2 dataOverlay <code>object</code> Config for the DataOverlay Sandbox module Optional 2.2 dem <code>object[]</code> Specify parameters for DEM extracts. Optional 2.2 elevationUnitMultiplier <code>double</code> Specify a multiplier to convert elevation units from source to meters. Overrides the value specified in <code>demDefaults</code>. Optional <code>1.0</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 demDefaults <code>object</code> Default properties for DEM extracts. Optional 2.3 elevationUnitMultiplier <code>double</code> Specify a multiplier to convert elevation units from source to meters. Optional <code>1.0</code> 2.3 elevationBucket <code>object</code> Used to download NED elevation tiles from the given AWS S3 bucket. Optional na emissions <code>object</code> Emissions configuration. Optional 2.5 fares <code>object</code> Fare configuration. Optional 2.0 gtfsDefaults <code>object</code> The gtfsDefaults section allows you to specify default properties for GTFS files. Optional 2.3 \u00a0\u00a0\u00a0blockBasedInterlining <code>boolean</code> Whether to create stay-seated transfers in between two trips with the same block id. Optional <code>true</code> 2.3 discardMinTransferTimes <code>boolean</code> Should minimum transfer times in GTFS files be discarded. Optional <code>false</code> 2.3 \u00a0\u00a0\u00a0maxInterlineDistance <code>integer</code> Maximal distance between stops in meters that will connect consecutive trips that are made with same vehicle. Optional <code>200</code> 2.3 \u00a0\u00a0\u00a0removeRepeatedStops <code>boolean</code> Should consecutive identical stops be merged into one stop time entry. Optional <code>true</code> 2.3 stationTransferPreference <code>enum</code> Should there be some preference or aversion for transfers at stops that are part of a station. Optional <code>\"allowed\"</code> 2.3 islandPruning <code>object</code> Settings for fixing street graph connectivity errors Optional 2.3 adaptivePruningDistance <code>integer</code> Search distance for analyzing islands in pruning. Optional <code>250</code> 2.3 adaptivePruningFactor <code>double</code> Defines how much pruning thresholds grow maximally by distance. Optional <code>50.0</code> 2.3 islandWithStopsMaxSize <code>integer</code> When a graph island with stops in it should be pruned. Optional <code>2</code> 2.3 islandWithoutStopsMaxSize <code>integer</code> When a graph island without stops should be pruned. Optional <code>10</code> 2.3 localFileNamePatterns <code>object</code> Patterns for matching OTP file types in the base directory Optional 2.0 dem <code>regexp</code> Pattern for matching elevation DEM files. Optional <code>\"(?i)\\.tiff?$\"</code> 2.0 gtfs <code>regexp</code> Patterns for matching GTFS zip-files or directories. Optional <code>\"(?i)gtfs\"</code> 2.0 netex <code>regexp</code> Patterns for matching NeTEx zip files or directories. Optional <code>\"(?i)netex\"</code> 2.0 osm <code>regexp</code> Pattern for matching Open Street Map input files. Optional <code>\"(?i)(\\.pbf\u00a6\\.osm\u00a6\\.osm\\.xml)$\"</code> 2.0 netexDefaults <code>object</code> The netexDefaults section allows you to specify default properties for NeTEx files. Optional 2.2 \u00a0\u00a0\u00a0feedId <code>string</code> This field is used to identify the specific NeTEx feed. It is used instead of the feed_id field in GTFS file feed_info.txt. Optional <code>\"NETEX\"</code> 2.2 groupFilePattern <code>regexp</code> Pattern for matching group NeTEx files. Optional <code>\"(\\w{3})-.*\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0ignoreFareFrame <code>boolean</code> Ignore contents of the FareFrame Optional <code>false</code> 2.3 ignoreFilePattern <code>regexp</code> Pattern for matching ignored files in a NeTEx bundle. Optional <code>\"$^\"</code> 2.0 \u00a0\u00a0\u00a0noTransfersOnIsolatedStops <code>boolean</code> Whether we should allow transfers to and from StopPlaces marked with LimitedUse.ISOLATED Optional <code>false</code> 2.2 sharedFilePattern <code>regexp</code> Pattern for matching shared NeTEx files in a NeTEx bundle. Optional <code>\"shared-data\\.xml\"</code> 2.0 sharedGroupFilePattern <code>regexp</code> Pattern for matching shared group NeTEx files in a NeTEx bundle. Optional <code>\"(\\w{3})-.*-shared\\.xml\"</code> 2.0 ferryIdsNotAllowedForBicycle <code>string[]</code> List ferries which do not allow bikes. Optional 2.0 osm <code>object[]</code> Configure properties for a given OpenStreetMap feed. Optional 2.2 osmTagMapping <code>enum</code> The named set of mapping rules applied when parsing OSM tags. Overrides the value specified in <code>osmDefaults</code>. Optional <code>\"default\"</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0timeZone <code>time-zone</code> The timezone used to resolve opening hours in OSM data. Overrides the value specified in <code>osmDefaults</code>. Optional 2.2 osmDefaults <code>object</code> Default properties for OpenStreetMap feeds. Optional 2.2 osmTagMapping <code>enum</code> The named set of mapping rules applied when parsing OSM tags. Optional <code>\"default\"</code> 2.2 \u00a0\u00a0\u00a0timeZone <code>time-zone</code> The timezone used to resolve opening hours in OSM data. Optional 2.2 transferRequests <code>object[]</code> Routing requests to use for pre-calculating stop-to-stop transfers. Optional 2.1 transitFeeds <code>object[]</code> Scan for transit data files Optional 2.2 \u00a0\u00a0\u00a0{ object } <code>object</code> Nested object in array. The object type is determined by the parameters. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"gtfs\" <code>enum</code> The feed input format. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0blockBasedInterlining <code>boolean</code> Whether to create stay-seated transfers in between two trips with the same block id. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>true</code> 2.3 discardMinTransferTimes <code>boolean</code> Should minimum transfer times in GTFS files be discarded. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>false</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0feedId <code>string</code> The unique ID for this feed. This overrides any feed ID defined within the feed itself. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0maxInterlineDistance <code>integer</code> Maximal distance between stops in meters that will connect consecutive trips that are made with same vehicle. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>200</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0removeRepeatedStops <code>boolean</code> Should consecutive identical stops be merged into one stop time entry. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>true</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 stationTransferPreference <code>enum</code> Should there be some preference or aversion for transfers at stops that are part of a station. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>\"allowed\"</code> 2.3 \u00a0\u00a0\u00a0{ object } <code>object</code> Nested object in array. The object type is determined by the parameters. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"netex\" <code>enum</code> The feed input format. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0feedId <code>string</code> This field is used to identify the specific NeTEx feed. It is used instead of the feed_id field in GTFS file feed_info.txt. Required 2.2 groupFilePattern <code>regexp</code> Pattern for matching group NeTEx files. Optional <code>\"(\\w{3})-.*\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ignoreFareFrame <code>boolean</code> Ignore contents of the FareFrame Optional <code>false</code> 2.3 ignoreFilePattern <code>regexp</code> Pattern for matching ignored files in a NeTEx bundle. Optional <code>\"$^\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0noTransfersOnIsolatedStops <code>boolean</code> Whether we should allow transfers to and from StopPlaces marked with LimitedUse.ISOLATED Optional <code>false</code> 2.2 sharedFilePattern <code>regexp</code> Pattern for matching shared NeTEx files in a NeTEx bundle. Optional <code>\"shared-data\\.xml\"</code> 2.0 sharedGroupFilePattern <code>regexp</code> Pattern for matching shared group NeTEx files in a NeTEx bundle. Optional <code>\"(\\w{3})-.*-shared\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 ferryIdsNotAllowedForBicycle <code>string[]</code> List ferries which do not allow bikes. Optional 2.0"},{"location":"BuildConfiguration/#specifying-uris","title":"Specifying URIs","text":"<p>As a general rule, references to data files are specified as absolute URIs and must start with the  protocol name.   </p> <p>Example</p> <p>Local files: <code>\"file:///Users/kelvin/otp/streetGraph.obj\"</code> HTTPS resources: <code>\"https://download.geofabrik.de/europe/norway-latest.osm.pbf\"</code> Google Cloud Storage files: <code>\"gs://otp-test-bucket/a/b/graph.obj\"</code> </p> <p>Alternatively if a relative URI can be provided, it is interpreted as a path relative to the base directory.</p> <p>Example</p> <p>File relative to the base directory (inside the base directory): <code>streetGraph.obj</code>  File relative to the base directory (outside the base directory): <code>../street-graphs/streetGraph.obj</code></p>"},{"location":"BuildConfiguration/#example-with-multiple-data-sources","title":"Example With Multiple Data Sources","text":"<p>For example, this configuration could be used to load GTFS and OSM inputs from Google Cloud Storage:</p> <pre><code>// build-config.json\n{\n  \"osm\": [\n    {\n      \"source\": \"gs://bucket-name/streets.pbf\"\n    }\n  ],\n  \"transitFeeds\": [\n    {\n      \"type\": \"netex\",\n      \"source\": \"gs://bucket-name/transit1.zip\"\n    },\n    {\n      \"type\": \"gtfs\",\n      \"source\": \"gs://bucket-name/transit2.zip\"\n    }\n  ]\n}\n</code></pre> <p>The Google Storage system will inherit the permissions of the server it's running on within Google Cloud. It is also possible to supply credentials in this configuration file (see example below).</p> <p>Note that when files are specified with URIs in this configuration, the file types do not need to be inferred from the file names, so these GTFS files can have any names - there is no requirement that they have the letters \"gtfs\" in them.</p> <p>The default behavior of scanning the base directory for inputs is overridden independently for each file type. So in the above configuration, GTFS and OSM will be loaded from Google Cloud Storage, but OTP2 will still scan the base directory for all other types such as DEM files. Supplying an empty array for a particular file type will ensure that no inputs of that type are loaded, including by local directory scanning.</p>"},{"location":"BuildConfiguration/#limit-transit-service-period","title":"Limit the transit service period","text":"<p>The properties <code>transitServiceStart</code> and <code>transitServiceEnd</code> can be used to limit the service dates. This affects both GTFS service calendars and dates. The service calendar is reduced and dates outside the period are dropped. OTP2 will compute a transit schedule for every day for which it can find at least one trip running. On the other hand, OTP will waste resources if a service end date is unbounded or very large (<code>9999-12-31</code>). To avoid this, limit the OTP service period. Also, if you provide a service with multiple feeds they may have different service end dates. To avoid inconsistent results, the period can be limited, so all feeds have data for the entire period. The default is to use a period of 1 year before, and 3 years after the day the graph is built. Limiting the period will not improve the search performance, but OTP will build faster and load faster in most cases.</p> <p>The <code>transitServiceStart</code> and <code>transitServiceEnd</code> parameters are set using an absolute date like <code>2020-12-31</code> or a period like <code>P1Y6M5D</code> relative to the graph build date. Negative periods is used to specify dates in the past. The period is computed using the system time-zone, not the feed time-zone. Also, remember that the service day might be more than 24 hours. So be sure to include enough slack to account for the this. Setting the limits too wide have very little impact and is in general better than trying to be exact. The period and date format follow the ISO 8601 standard.</p> <p>Example</p> <pre><code>// build-config.json\n{\n  // Include 3 months of history\n  \"transitServiceStart\" : \"-P3M\",\n  // Include 1 year 6 month and 5 days of scheduled data in the future \n  \"transitServiceEnd\" : \"P1Y6M5D\"\n}\n</code></pre>"},{"location":"BuildConfiguration/#openstreetmaposm-configuration","title":"OpenStreetMap(OSM) configuration","text":"<p>It is possible to adjust how OSM data is interpreted by OpenTripPlanner when building the road part of the routing graph.</p>"},{"location":"BuildConfiguration/#osm-tag-mapping","title":"OSM tag mapping","text":"<p>OSM tags have different meanings in different countries, and how the roads in a particular country or region are tagged affects routing. As an example roads tagged with `highway=trunk are (mainly) walkable in Norway, but forbidden in some other countries. This might lead to OTP being unable to snap stops to these roads, or by giving you poor routing results for walking and biking. You can adjust which road types that are accessible by foot, car &amp; bicycle as well as speed limits, suitability for biking and walking. It's possible to define \"safety\" values for cycling and walking which are used in routing.</p> <p>To add your own OSM tag mapping have a look at <code>org.opentripplanner.graph_builder.module.osm.tagmapping.NorwayTagMapper</code> and <code>org.opentripplanner.graph_builder.module.osm.tagmapping.DefaultMapper</code> as examples.  If you choose to mainly rely on the default rules, make sure you add your own rules first before applying the default ones. The mechanism is that for any two identical tags, OTP will use the first one.</p> <pre><code>// build-config.json\n{\n  \"osm\": [\n    {\n      \"source\": \"gs://marduk-dev/osm/oslo_norway.osm-160816.pbf\",\n      \"osmTagMapping\": \"norway\"\n    }\n  ]\n}\n</code></pre>"},{"location":"BuildConfiguration/#custom-naming","title":"Custom naming","text":"<p>You can define a custom naming scheme for elements drawn from OSM by defining an <code>osmNaming</code> field in <code>build-config.json</code>, such as:</p> <pre><code>// build-config.json\n{\n  \"osmNaming\": \"portland\"\n}\n</code></pre> <p>There is currently only one custom naming module called <code>portland</code> (which has no parameters).</p>"},{"location":"BuildConfiguration/#elevation-data","title":"Elevation data","text":"<p>OpenTripPlanner can \"drape\" the OSM street network over a digital elevation model (DEM). This allows OTP to draw an elevation profile for the on-street portion of itineraries, and helps provide better routing for bicyclists. It even helps avoid hills for walking itineraries. DEMs are usually supplied as rasters (regular grids of numbers) stored in image formats such as GeoTIFF.</p>"},{"location":"BuildConfiguration/#geoid-difference","title":"Geoid Difference","text":"<p>Some elevation data sets are relative to mean sea level. At a global scale sea level is represented as a surface called the geoid, which is irregular in shape due to local gravitational anomalies. On the other hand, GPS elevations are reported relative to the WGS84 spheroid, a perfectly smooth mathematical surface approximating the geoid. In cases where the two elevation definitions are mixed, it may be necessary to adjust elevation values to avoid confusing users with things like negative elevation values in places clearly above sea level. See issue #2301 for detailed discussion of this.</p> <p>OTP allows you to adjust the elevation values reported in API responses in two ways. The first way is to store ellipsoid (GPS) elevation values internally, but apply a single geoid difference value in the OTP client where appropriate to display elevations above sea level. This ellipsoid to geoid difference is returned in each trip plan response in the ElevationMetadata field. Using a single value can be sufficient for smaller OTP deployments, but might result in incorrect values at the edges of larger OTP deployments. If your OTP instance uses this, it is recommended to set a default request value in the <code>router-config.json</code> file as follows:</p> <pre><code>// router-config.json\n{\n    \"routingDefaults\": {\n        \"geoidElevation\": true   \n    }\n}\n</code></pre> <p>The second way is to precompute these geoid difference values at a more granular level and store all elevations internally relative to the geoid (sea level). Elevations returned in the API responses will then not need to be adjusted to match end users' intuitive understanding of elevation. In order to speed up calculations, these geoid difference values are calculated and cached using only 2 significant digits of GPS coordinates. This is more than enough detail for most regions of the world and should result in less than one meter of vertical error even in areas that have the largest geoid irregularities. To enable this, include the following in the <code>build-config.json</code> file:</p> <pre><code>// build-config.json\n{\n  \"includeEllipsoidToGeoidDifference\": true\n}\n</code></pre> <p>If the geoid difference values are precomputed, be careful to not set the routing resource value of <code>geoidElevation</code> to true in order to avoid having the graph-wide geoid added again to all elevation values in the relevant street edges in responses.</p>"},{"location":"BuildConfiguration/#other-raster-elevation-data","title":"Other raster elevation data","text":"<p>For other parts of the world you will need a GeoTIFF file containing the elevation data. These are often available from national geographic surveys, or you can always fall back on the worldwide Space Shuttle Radar Topography Mission (SRTM) data. This not particularly high resolution (roughly 30 meters horizontally) but it can give acceptable results.</p> <p>Simply place the elevation data file in the directory with the other graph builder inputs, alongside the GTFS and OSM data. Make sure the file has a <code>.tiff</code> or <code>.tif</code> extension, and the graph builder should detect its presence and apply the elevation data to the streets.</p> <p>OTP should automatically handle DEM GeoTIFFs in most common projections. You may want to check for elevation-related error messages during the graph build process to make sure OTP has properly discovered the projection. If you are using a DEM in unprojected coordinates make sure that the axis order is (longitude, latitude) rather than (latitude, longitude). Unfortunately there is no reliable standard for WGS84 axis order, so OTP uses the same axis order as the above-mentioned SRTM data,  which is also the default for the popular Proj4 library.</p> <p>DEM files(USGS DEM) is not supported by OTP, but can be converted to GeoTIFF with tools like GDAL. Use <code>gdal_merge.py -o merged.tiff *.dem</code> to merge a set of <code>dem</code> files into one <code>tif</code> file.</p> <p>See Interline PlanetUtils for a set of scripts to download, merge, and resample  Mapzen/Amazon Terrain Tiles.</p>"},{"location":"BuildConfiguration/#elevation-unit-conversion","title":"Elevation unit conversion","text":"<p>By default, OTP expects the elevation data to use metres. However, by setting  <code>elevationUnitMultiplier</code> in <code>build-config.json</code>, it is possible to define a multiplier that  converts the elevation values from some other unit to metres.</p> <pre><code>// build-config.json\n{\n  \"dem\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.dem.tif\",\n      // Correct conversion multiplier when source data uses decimetres instead of metres\n      \"elevationUnitMultiplier\": 0.1\n    }\n  ]\n}\n</code></pre>"},{"location":"BuildConfiguration/#elevation-data-calculation-optimizations","title":"Elevation Data Calculation Optimizations","text":"<p>Calculating elevations on all StreetEdges can take a dramatically long time. In a very large graph build for multiple Northeast US states, the time it took to download the elevation data and calculate all the elevations took roughly 1.5 hours.</p> <p>If you are using cloud computing for your OTP instances, it is recommended to create prebuilt images that contain the elevation data you need. This will save time because all the data won't need to be downloaded.</p> <p>However, the bulk of the time will still be spent calculating elevations for the street edges. Therefore, a further optimization can be done to calculate and save the elevation data during  a  graph build and then save it for future use.</p>"},{"location":"BuildConfiguration/#reusing-elevation-data-from-previous-builds","title":"Reusing elevation data from previous builds","text":"<p>In order to write out the precalculated elevation data, add this to your <code>build-config.json</code> file:</p> <p><pre><code>// build-config.json\n{  \n  \"writeCachedElevations\": true\n}\n</code></pre> See writeCachedElevations for details.</p>"},{"location":"BuildConfiguration/#parameter-details","title":"Parameter Details","text":""},{"location":"BuildConfiguration/#areaVisibility","title":"areaVisibility","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Perform visibility calculations.</p> <p>If this is <code>true</code> OTP attempts to calculate a path straight through an OSM area using the shortest way rather than around the edge of it. (These calculations can be time consuming).</p>"},{"location":"BuildConfiguration/#buildReportDir","title":"buildReportDir","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the directory where the graph build report should be written to.</p> <p>The html report is written into this directory. If the directory exist, any existing files are deleted. If it does not exist, it is created.</p>"},{"location":"BuildConfiguration/#configVersion","title":"configVersion","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Deployment version of the build-config.json.</p> <p>The config-version is a parameter which each OTP deployment may set to be able to query the OTP server and verify that it uses the correct version of the config. The version should be injected into the config in the (continuous) deployment pipeline. How this is done, is up to the deployment.</p> <p>The config-version has no effect on OTP, and is provided as is on the API. There is no syntax or format check on the version and it can be any string.</p> <p>Be aware that OTP uses the config embedded in the loaded graph if no new config is provided.</p>"},{"location":"BuildConfiguration/#dataImportReport","title":"dataImportReport","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Generate nice HTML report of Graph errors/warnings</p> <p>The reports are stored in the same location as the graph.</p>"},{"location":"BuildConfiguration/#distanceBetweenElevationSamples","title":"distanceBetweenElevationSamples","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10.0</code> Path: / </p> <p>The distance between elevation samples in meters.</p> <p>The default is the approximate resolution of 1/3 arc-second NED data. This should not be smaller than the horizontal resolution of the height data used.</p>"},{"location":"BuildConfiguration/#graph","title":"graph","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the graph object file for reading and writing.</p> <p>The file is created or overwritten if OTP saves the graph to the file.</p>"},{"location":"BuildConfiguration/#gsCredentials","title":"gsCredentials","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Local file system path to Google Cloud Platform service accounts credentials file.</p> <p>The credentials is used to access GCS urls. When using GCS from outside of Google Cloud you need to provide a path the the service credentials. Environment variables in the path are resolved.</p> <p>This is a path to a file on the local file system, not an URI.</p>"},{"location":"BuildConfiguration/#includeEllipsoidToGeoidDifference","title":"includeEllipsoidToGeoidDifference","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge.</p> <p>When set to true (it is false by default), the elevation module will include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge in the graph.</p> <p>NOTE: if this is set to true for graph building, make sure to not set the value of <code>RoutingResource#geoidElevation</code> to true otherwise OTP will add this geoid value again to all of the elevation values in the street edges.</p>"},{"location":"BuildConfiguration/#maxDataImportIssuesPerFile","title":"maxDataImportIssuesPerFile","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1000</code> Path: / </p> <p>When to split the import report.</p> <p>If the number of issues is larger then <code>maxDataImportIssuesPerFile</code>, then the files will   be split in multiple files. Since browsers have problems opening large HTML files.</p>"},{"location":"BuildConfiguration/#maxStopToShapeSnapDistance","title":"maxStopToShapeSnapDistance","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>150.0</code> Path: / </p> <p>Maximum distance between route shapes and their stops.</p> <p>This field is used for mapping routes geometry shapes. It determines max distance between shape points and their stop sequence. If mapper cannot find any stops within this radius it will default to simple stop-to-stop geometry instead.</p>"},{"location":"BuildConfiguration/#multiThreadElevationCalculations","title":"multiThreadElevationCalculations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Configuring multi-threading during elevation calculations.</p> <p>For unknown reasons that seem to depend on data and machine settings, it might be faster   to use a single processor. If multi-threading is activated, parallel streams will be used   to calculate the elevations.</p>"},{"location":"BuildConfiguration/#osmCacheDataInMem","title":"osmCacheDataInMem","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>If OSM data should be cached in memory during processing.</p> <p>When loading OSM data, the input is streamed 3 times - one phase for processing RELATIONS, one for WAYS and last one for NODES. Instead of reading the data source 3 times it might be faster to cache the entire osm file im memory. The trade off is of course that OTP might use more memory while loading osm data. You can use this parameter to choose what is best for your deployment depending on your infrastructure. Set the parameter to <code>true</code> to cache the data, and to <code>false</code> to read the stream from the source each time.</p>"},{"location":"BuildConfiguration/#readCachedElevations","title":"readCachedElevations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>true</code> Path: / </p> <p>Whether to read cached elevation data.</p> <p>When set to true, the elevation module will attempt to read this file in order to reuse calculations of elevation data for various coordinate sequences instead of recalculating them all over again.</p>"},{"location":"BuildConfiguration/#streetGraph","title":"streetGraph","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the street graph object file for reading and writing.</p> <p>The file is created or overwritten if OTP saves the graph to the file</p>"},{"location":"BuildConfiguration/#subwayAccessTime","title":"subwayAccessTime","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: / </p> <p>Minutes necessary to reach stops served by trips on routes of route_type=1 (subway) from the street.</p> <p>Note! The preferred way to do this is to update the OSM data. See In-station navigation.</p> <p>The ride locations for some modes of transport such as subways can be slow to reach from the street. When planning a trip, we need to allow additional time to reach these locations to properly inform the passenger. For example, this helps avoid suggesting short bus rides between two subway rides as a way to improve travel time. You can specify how long it takes to reach a subway platform.</p> <p>This setting does not generalize to other modes like airplanes because you often need much longer time to check in to a flight (2-3 hours for international flights) than to alight and exit the airport (perhaps 1 hour). Use <code>boardSlackForMode</code> and <code>alightSlackForMode</code> for this.</p>"},{"location":"BuildConfiguration/#transitModelTimeZone","title":"transitModelTimeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Time zone for the graph.</p> <p>This is used to store the timetables in the transit model, and to interpret times in incoming requests.</p>"},{"location":"BuildConfiguration/#transitServiceEnd","title":"transitServiceEnd","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"P3Y\"</code> Path: / </p> <p>Limit the import of transit services to the given end date.</p> <p>See Limit the transit service period for an introduction.</p> <p>The date is inclusive. If set, any transit service on a day AFTER the given date is dropped and will not be part of the graph. Use an absolute date or a period relative to the date the graph is build(BUILD_DAY).</p> <p>Use an empty string to make it unbounded.</p>"},{"location":"BuildConfiguration/#transitServiceStart","title":"transitServiceStart","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"-P1Y\"</code> Path: / </p> <p>Limit the import of transit services to the given START date.</p> <p>See Limit the transit service period for an introduction.</p> <p>The date is inclusive. If set, any transit service on a day BEFORE the given date is dropped and will not be part of the graph. Use an absolute date or a period relative to the date the graph is build(BUILD_DAY).</p> <p>Use an empty string to make unbounded.</p>"},{"location":"BuildConfiguration/#writeCachedElevations","title":"writeCachedElevations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Reusing elevation data from previous builds</p> <p>When set to true, the elevation module will create a file cache for calculated elevation data. Subsequent graph builds can reuse the data in this file.</p> <p>After building the graph, a file called <code>cached_elevations.obj</code> will be written to the cache directory. By default, this file is not written during graph builds. There is also a graph build parameter called <code>readCachedElevations</code> which is set to <code>true</code> by default.</p> <p>In graph builds, the elevation module will attempt to read the <code>cached_elevations.obj</code> file from the cache directory. The cache directory defaults to <code>/var/otp/cache</code>, but this can be overridden via the CLI argument <code>--cache &lt;directory&gt;</code>. For the same graph build for multiple Northeast US states, the time it took with using this pre-downloaded and precalculated data became roughly 9 minutes.</p> <p>The cached data is a lookup table where the coordinate sequences of respective street edges are used as keys for calculated data. It is assumed that all of the other input data except for the OpenStreetMap data remains the same between graph builds. Therefore, if the underlying elevation data is changed, or different configuration values for <code>elevationUnitMultiplier</code> or <code>includeEllipsoidToGeoidDifference</code> are used, then this data becomes invalid and all elevation data should be recalculated. Over time, various edits to OpenStreetMap will cause this cached data to become stale and not include new OSM ways. Therefore, periodic update of this cached data is recommended.</p>"},{"location":"BuildConfiguration/#boardingLocationTags","title":"boardingLocationTags","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>What OSM tags should be looked on for the source of matching stops to platforms and stops.</p> <p>Detailed documentation</p>"},{"location":"BuildConfiguration/#dem","title":"dem","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Specify parameters for DEM extracts.</p> <p>The dem section allows you to override the default behavior of scanning for elevation files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p> <p>If not specified OTP will fall back to auto-detection based on the directory provided on the command line.</p>"},{"location":"BuildConfiguration/#dem_0_elevationUnitMultiplier","title":"elevationUnitMultiplier","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /dem/[0] </p> <p>Specify a multiplier to convert elevation units from source to meters. Overrides the value specified in <code>demDefaults</code>.</p> <p>Unit conversion multiplier for elevation values. No conversion needed if the elevation values are defined in meters in the source data. If, for example, decimetres are used in the source data, this should be set to 0.1.</p>"},{"location":"BuildConfiguration/#demDefaults_elevationUnitMultiplier","title":"elevationUnitMultiplier","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /demDefaults </p> <p>Specify a multiplier to convert elevation units from source to meters.</p> <p>Unit conversion multiplier for elevation values. No conversion needed if the elevation values are defined in meters in the source data. If, for example, decimetres are used in the source data, this should be set to 0.1.</p>"},{"location":"BuildConfiguration/#elevationBucket","title":"elevationBucket","text":"<p>Since version: <code>na</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Used to download NED elevation tiles from the given AWS S3 bucket.</p> <p>In the United States, a high resolution National Elevation Dataset is available for the entire territory. It used to be possible for OTP to download NED tiles on the fly from a rather complex USGS SOAP service. This process was somewhat unreliable and would greatly slow down the graph building process. In any case the service has since been replaced. But the USGS would also deliver the whole dataset in bulk if you sent them a hard drive. We did this many years back and uploaded the entire data set to Amazon AWS S3. OpenTripPlanner contains another module that can automatically fetch data in this format from any Amazon S3 copy of the bulk data.</p> <p>This <code>ned13</code> bucket is still available on S3 under a \"requester pays\" policy. As long as you specify valid AWS account credentials you should be able to download tiles, and any bandwidth costs will be billed to your AWS account.</p> <p>Once the tiles are downloaded for a particular geographic area, OTP will keep them in local cache for the next graph build operation. You should add the <code>--cache &lt;directory&gt;</code> command line parameter to specify your NED tile cache location.</p>"},{"location":"BuildConfiguration/#gd_discardMinTransferTimes","title":"discardMinTransferTimes","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /gtfsDefaults </p> <p>Should minimum transfer times in GTFS files be discarded.</p> <p>This is useful eg. when the minimum transfer time is only set for ticketing purposes, but we want to calculate the transfers always from OSM data.</p>"},{"location":"BuildConfiguration/#gd_stationTransferPreference","title":"stationTransferPreference","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"allowed\"</code> Path: /gtfsDefaults  Enum values: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Should there be some preference or aversion for transfers at stops that are part of a station.</p> <p>This parameter sets the generic level of preference. What is the actual cost can be changed with the <code>stopTransferCost</code> parameter in the router configuration.</p>"},{"location":"BuildConfiguration/#islandPruning_adaptivePruningDistance","title":"adaptivePruningDistance","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>250</code> Path: /islandPruning </p> <p>Search distance for analyzing islands in pruning.</p> <p>The distance after which disconnected sub graph is considered as real island in pruning heuristics.</p>"},{"location":"BuildConfiguration/#islandPruning_adaptivePruningFactor","title":"adaptivePruningFactor","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>50.0</code> Path: /islandPruning </p> <p>Defines how much pruning thresholds grow maximally by distance.</p> <p>Expands the pruning thresholds as the distance of an island from the rest of the graph gets smaller. Even fairly large disconnected sub graphs should be removed if they are badly entangled with other graph.</p>"},{"location":"BuildConfiguration/#islandPruning_islandWithStopsMaxSize","title":"islandWithStopsMaxSize","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2</code> Path: /islandPruning </p> <p>When a graph island with stops in it should be pruned.</p> <p>This field indicates the pruning threshold for islands with stops. Any such island under this edge count will be pruned.</p>"},{"location":"BuildConfiguration/#islandPruning_islandWithoutStopsMaxSize","title":"islandWithoutStopsMaxSize","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10</code> Path: /islandPruning </p> <p>When a graph island without stops should be pruned.</p> <p>This field indicates the pruning threshold for islands without stops. Any such island under this edge count will be pruned.</p>"},{"location":"BuildConfiguration/#localFileNamePatterns","title":"localFileNamePatterns","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Patterns for matching OTP file types in the base directory</p> <p>When scanning the base directory for inputs, each file's name is checked against patterns to detect what kind of file it is.</p> <p>OTP1 used to peek inside ZIP files and read the CSV tables to guess if a ZIP was indeed GTFS. Now that we support remote input files (cloud storage or arbitrary URLs) not all data sources allow seeking within files to guess what they are. Therefore, like all other file types GTFS is now detected from a filename pattern. It is not sufficient to look for the <code>.zip</code> extension because Netex data is also often supplied in a ZIP file.</p>"},{"location":"BuildConfiguration/#lfp_dem","title":"dem","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)\\.tiff?$\"</code> Path: /localFileNamePatterns </p> <p>Pattern for matching elevation DEM files.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_gtfs","title":"gtfs","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)gtfs\"</code> Path: /localFileNamePatterns </p> <p>Patterns for matching GTFS zip-files or directories.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_netex","title":"netex","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)netex\"</code> Path: /localFileNamePatterns </p> <p>Patterns for matching NeTEx zip files or directories.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_osm","title":"osm","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)(\\.pbf|\\.osm|\\.osm\\.xml)$\"</code> Path: /localFileNamePatterns </p> <p>Pattern for matching Open Street Map input files.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#nd_groupFilePattern","title":"groupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching group NeTEx files.</p> <p>This field is used to match group files in the module file(zip file entries). group files are loaded right the after shared group files are loaded. Files are grouped together by the first group pattern in the regular expression. The pattern <code>\"(\\w{3})-.*\\.xml\"</code> matches <code>\"RUT-Line-208-Hagalia-Nevlunghavn.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#nd_ignoreFilePattern","title":"ignoreFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"$^\"</code> Path: /netexDefaults </p> <p>Pattern for matching ignored files in a NeTEx bundle.</p> <p>This field is used to exclude matching files in the module file(zip file entries). The ignored files are not loaded.</p>"},{"location":"BuildConfiguration/#nd_sharedFilePattern","title":"sharedFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"shared-data\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching shared NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared files(zip file entries) in the module file. Shared files are loaded first. Then the rest of the files are grouped and loaded.</p> <p>The pattern <code>\"shared-data.xml\"</code> matches <code>\"shared-data.xml\"</code></p> <p>File names are matched in the following order - and treated accordingly to the first match:</p> <ul> <li><code>ignoreFilePattern</code></li> <li><code>sharedFilePattern</code></li> <li><code>sharedGroupFilePattern</code></li> <li><code>groupFilePattern</code></li> </ul>"},{"location":"BuildConfiguration/#nd_sharedGroupFilePattern","title":"sharedGroupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*-shared\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching shared group NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared group files in the module file(zip file entries). Typically this is used to group all files from one agency together.</p> <p>Shared group files are loaded after shared files, but before the matching group files. Each group of files are loaded as a unit, followed by next group.</p> <p>Files are grouped together by the first group pattern in the regular expression.</p> <p>The pattern <code>\"(\\w{3})-.*-shared\\.xml\"</code> matches <code>\"RUT-shared.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#nd_ferryIdsNotAllowedForBicycle","title":"ferryIdsNotAllowedForBicycle","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /netexDefaults </p> <p>List ferries which do not allow bikes.</p> <p>Bicycles are allowed on most ferries however the Nordic profile doesn't contain a place where bicycle conveyance can be defined.</p> <p>For this reason we allow bicycles on ferries by default and allow to override the rare case where this is not the case.</p>"},{"location":"BuildConfiguration/#osm","title":"osm","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configure properties for a given OpenStreetMap feed.</p> <p>The osm section of build-config.json allows you to override the default behavior of scanning for OpenStreetMap files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p>"},{"location":"BuildConfiguration/#osm_0_osmTagMapping","title":"osmTagMapping","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"default\"</code> Path: /osm/[0]  Enum values: <code>default</code> | <code>norway</code> | <code>uk</code> | <code>finland</code> | <code>germany</code> | <code>atlanta</code> | <code>houston</code> | <code>portland</code> | <code>constant-speed-finland</code></p> <p>The named set of mapping rules applied when parsing OSM tags. Overrides the value specified in <code>osmDefaults</code>.</p>"},{"location":"BuildConfiguration/#od_osmTagMapping","title":"osmTagMapping","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"default\"</code> Path: /osmDefaults  Enum values: <code>default</code> | <code>norway</code> | <code>uk</code> | <code>finland</code> | <code>germany</code> | <code>atlanta</code> | <code>houston</code> | <code>portland</code> | <code>constant-speed-finland</code></p> <p>The named set of mapping rules applied when parsing OSM tags.</p>"},{"location":"BuildConfiguration/#transitFeeds","title":"transitFeeds","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Scan for transit data files</p> <p>The transitFeeds section of <code>build-config.json</code> allows you to override the default behavior of scanning for transit data files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p> <p>When a feed of a particular type (<code>netex</code> or <code>gtfs</code>) is specified in the transitFeeds section, auto-scanning in the base directory for this feed type will be disabled.</p>"},{"location":"BuildConfiguration/#tf_0_discardMinTransferTimes","title":"discardMinTransferTimes","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /transitFeeds/[0] </p> <p>Should minimum transfer times in GTFS files be discarded. Overrides the value specified in <code>gtfsDefaults</code>.</p> <p>This is useful eg. when the minimum transfer time is only set for ticketing purposes, but we want to calculate the transfers always from OSM data.</p>"},{"location":"BuildConfiguration/#tf_0_stationTransferPreference","title":"stationTransferPreference","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"allowed\"</code> Path: /transitFeeds/[0]  Enum values: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Should there be some preference or aversion for transfers at stops that are part of a station. Overrides the value specified in <code>gtfsDefaults</code>.</p> <p>This parameter sets the generic level of preference. What is the actual cost can be changed with the <code>stopTransferCost</code> parameter in the router configuration.</p>"},{"location":"BuildConfiguration/#tf_1_groupFilePattern","title":"groupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching group NeTEx files.</p> <p>This field is used to match group files in the module file(zip file entries). group files are loaded right the after shared group files are loaded. Files are grouped together by the first group pattern in the regular expression. The pattern <code>\"(\\w{3})-.*\\.xml\"</code> matches <code>\"RUT-Line-208-Hagalia-Nevlunghavn.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#tf_1_ignoreFilePattern","title":"ignoreFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"$^\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching ignored files in a NeTEx bundle.</p> <p>This field is used to exclude matching files in the module file(zip file entries). The ignored files are not loaded.</p>"},{"location":"BuildConfiguration/#tf_1_sharedFilePattern","title":"sharedFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"shared-data\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching shared NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared files(zip file entries) in the module file. Shared files are loaded first. Then the rest of the files are grouped and loaded.</p> <p>The pattern <code>\"shared-data.xml\"</code> matches <code>\"shared-data.xml\"</code></p> <p>File names are matched in the following order - and treated accordingly to the first match:</p> <ul> <li><code>ignoreFilePattern</code></li> <li><code>sharedFilePattern</code></li> <li><code>sharedGroupFilePattern</code></li> <li><code>groupFilePattern</code></li> </ul>"},{"location":"BuildConfiguration/#tf_1_sharedGroupFilePattern","title":"sharedGroupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*-shared\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching shared group NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared group files in the module file(zip file entries). Typically this is used to group all files from one agency together.</p> <p>Shared group files are loaded after shared files, but before the matching group files. Each group of files are loaded as a unit, followed by next group.</p> <p>Files are grouped together by the first group pattern in the regular expression.</p> <p>The pattern <code>\"(\\w{3})-.*-shared\\.xml\"</code> matches <code>\"RUT-shared.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#tf_1_ferryIdsNotAllowedForBicycle","title":"ferryIdsNotAllowedForBicycle","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transitFeeds/[1] </p> <p>List ferries which do not allow bikes.</p> <p>Bicycles are allowed on most ferries however the Nordic profile doesn't contain a place where bicycle conveyance can be defined.</p> <p>For this reason we allow bicycles on ferries by default and allow to override the rare case where this is not the case.</p>"},{"location":"BuildConfiguration/#build-config-example","title":"Build Config Example","text":"<pre><code>// build-config.json\n{\n  \"transitServiceStart\" : \"-P3M\",\n  \"transitServiceEnd\" : \"P1Y\",\n  \"osmCacheDataInMem\" : true,\n  \"localFileNamePatterns\" : {\n    \"osm\" : \"(i?)\\\\.osm\\\\.pbf$\",\n    \"dem\" : \"(i?)\\\\.dem\\\\.tiff?$\",\n    \"gtfs\" : \"(?i)gtfs\",\n    \"netex\" : \"(?i)netex\"\n  },\n  \"osmDefaults\" : {\n    \"timeZone\" : \"Europe/Rome\",\n    \"osmTagMapping\" : \"default\"\n  },\n  \"osm\" : [\n    {\n      \"source\" : \"gs://my-bucket/otp-work-dir/norway.osm.pbf\",\n      \"timeZone\" : \"Europe/Oslo\",\n      \"osmTagMapping\" : \"norway\"\n    }\n  ],\n  \"demDefaults\" : {\n    \"elevationUnitMultiplier\" : 1.0\n  },\n  \"dem\" : [\n    {\n      \"source\" : \"gs://my-bucket/otp-work-dir/norway.dem.tiff\",\n      \"elevationUnitMultiplier\" : 2.5\n    }\n  ],\n  \"netexDefaults\" : {\n    \"feedId\" : \"EN\",\n    \"sharedFilePattern\" : \"_stops.xml\",\n    \"sharedGroupFilePattern\" : \"_(\\\\w{3})_shared_data.xml\",\n    \"groupFilePattern\" : \"(\\\\w{3})_.*\\\\.xml\",\n    \"ignoreFilePattern\" : \"(temp|tmp)\",\n    \"ferryIdsNotAllowedForBicycle\" : [\n      \"RUT:B107\",\n      \"RUT:B209\"\n    ]\n  },\n  \"gtfsDefaults\" : {\n    \"stationTransferPreference\" : \"recommended\",\n    \"removeRepeatedStops\" : true,\n    \"discardMinTransferTimes\" : false,\n    \"blockBasedInterlining\" : true,\n    \"maxInterlineDistance\" : 200\n  },\n  \"islandPruning\" : {\n    \"islandWithStopsMaxSize\" : 2,\n    \"islandWithoutStopsMaxSize\" : 10,\n    \"adaptivePruningFactor\" : 50.0,\n    \"adaptivePruningDistance\" : 250\n  },\n  \"transitFeeds\" : [\n    {\n      \"type\" : \"gtfs\",\n      \"feedId\" : \"SE\",\n      \"source\" : \"https://skanetrafiken.se/download/sweden.gtfs.zip\"\n    },\n    {\n      \"type\" : \"netex\",\n      \"feedId\" : \"NO\",\n      \"source\" : \"gs://BUCKET/OTP_GCS_WORK_DIR/norway-netex.obj\",\n      \"sharedFilePattern\" : \"_stops.xml\",\n      \"sharedGroupFilePattern\" : \"_(\\\\w{3})_shared_data.xml\",\n      \"groupFilePattern\" : \"(\\\\w{3})_.*\\\\.xml\",\n      \"ignoreFilePattern\" : \"(temp|tmp)\"\n    }\n  ],\n  \"transferRequests\" : [\n    {\n      \"modes\" : \"WALK\"\n    },\n    {\n      \"modes\" : \"WALK\",\n      \"wheelchairAccessibility\" : {\n        \"enabled\" : true\n      }\n    }\n  ],\n  \"stopConsolidationFile\" : \"consolidated-stops.csv\",\n  \"emissions\" : {\n    \"carAvgCo2PerKm\" : 170,\n    \"carAvgOccupancy\" : 1.3\n  }\n}\n</code></pre>"},{"location":"Changelog/","title":"Changelog","text":"<p>The changelog lists most feature changes between each release. The list is automatically created based on merged pull requests. Search GitHub issues and pull requests for smaller issues.</p>"},{"location":"Changelog/#250-under-development","title":"2.5.0 (under development)","text":"<ul> <li>Gracefully handle nullable fields in TransitAlert #5349</li> <li>Remove transit with higher cost than best on-street itinerary filter #5222</li> <li>Remove banDiscouragedCycling and banDiscouragedWalking #5341</li> <li>Fix rental scooter access #5361</li> <li>De-duplicate stops returned by <code>stopsByRadius</code> #5366</li> <li>Fix value mapping for bikesAllowed in GTFS GraphQL API #5368</li> <li>Apply correct traversal permissions to barrier vertex #5369</li> <li>Move GTFS GraphQL API out of the sandbox #5339</li> <li>Transmodel GraphQL API for pass-through searches #5320</li> <li>Fix check for OSM relation members not being present in the extract #5379</li> <li>Add a configurable limit for the search window #5293</li> <li>Fix fare calculation for combined interlined legs #5408</li> <li>Fix board slack list mapping in Transmodel API #5420</li> <li>Fix flexible quay querying in Transmodel API #5417</li> <li>Add validation for missing calls in SIRI update #5403</li> <li>Import Occupancy Status from GTFS-RT Vehicle Positions #5372</li> <li>Add Roadmap epic template #5413</li> <li>Allow multiple zones in an unscheduled flex trip #5376</li> <li>Filter out null, empty and blank elements when mapping feed-scoped ids #5428</li> <li>Validate stop id in Transit leg reference #5440</li> <li>Add available types and spaces to <code>VehicleRentalStation</code> #5425</li> <li>Make vehicleRentalStation query optionally accept id without feed #5411</li> <li>Add stricter validation for flex areas #5457</li> <li>Remove HTTPS handling and its documentation #5439</li> <li>Add support for DSJ in transit leg reference #5455</li> <li>Ignore negative travel-times in Raptor #5443</li> <li>Fix sort order bug in optimized transfers #5446</li> <li>Siri file loader #5460</li> <li>Calculate CO\u2082 emissions of itineraries #5278</li> <li>Update NeTEx Java Model 2.0.15 #5466</li> <li>Migrate to Java 21 #5421</li> <li>Add Roadmap setup docs #5468</li> <li>Interpolate increasing stop times for GTFS-RT cancelled trips #5348</li> <li>Remove itineraries outside the search window in arriveBy search #5433</li> <li>Add back walk-reluctance in Transmodel API #5471</li> <li>Make <code>feedId</code> required for real-time updaters #5502</li> <li>Fix serialization of <code>AtomicInteger</code> #5508</li> <li>Improve linking of fixed stops used by flex trips #5503</li> <li>Keep min transfer filter is not local to group-by-filters #5436</li> <li>Add paging deduplication when cropping #5458</li> <li>Consolidate equivalent stops from several feeds  #5429</li> <li>Check transport mode when mapping GroupStops #5518</li> <li>Cleanup trip times - Part A #5437</li> <li>Transfer cost limit #5516</li> <li>Fix missed trip when arrive-by search-window is off by one minute #5520</li> <li>Transit group priority - Part 1 #4999</li> <li>Remove <code>matchBusRoutesToStreets</code> #5523</li> <li>Rename realtime to real-time in docs #5535</li> <li>Add same submode in alternative legs filter #5548</li> <li>Fix issue where stop points are sometimes added twice to index #5552</li> <li>Improve shutdown logic #5514</li> <li>Create TripOnServiceDate for new siri realtime servicejourneys #5542</li> <li>New debug client #5334</li> <li>Improve paging - avoid duplicates and missed itineraries when paging #5551</li> <li>Create own parking preferences for bike and car in the internal model #5521</li> <li>Make Transmodel GraphQl API an official OTP API #5573</li> <li>Add option to include stations in <code>nearest</code> search #5390</li> <li>GTFS Flex spec update: separate columns for <code>location_id</code>, <code>location_group_id</code> #5564</li> <li>Report NO_TRANSIT_CONNECTION when search-window is set. #5570</li> <li>Transit priority  - part 3 #5583</li> <li>Fix preference cost comparisons #5586</li> <li>Report and throw away trip-times which fail sanity check #5587</li> <li>Consider escalator edges in island pruning #5591</li> <li>Create own rental preferences for bike and car in the internal model #5562</li> <li>Adding situation-version to TransmodelGraphQL API #5592</li> <li>Move REST API into sandbox #5580</li> <li>Fix high walk reluctance leading to zero egress results for rental searches #5605</li> <li>Remove GTFS-RT websocket updater #5604</li> <li>Add stop layer to new Debug UI #5602</li> <li>Use fallback timezone if no transit data is loaded #4652</li> <li>Add new path for GTFS GraphQL API, remove batch feature #5581</li> <li>Restructure walk/bicycle/car preferences in router-config.json #5582</li> <li>Revert REST API spelling change of real-time #5629</li> <li>Remove <code>FareComponent</code> #5613</li> <li>Add AreaStop layer to new debug frontend #5636</li> <li>Allow configuration of vector tiles base path #5627</li> <li>Change Transmodel API path to <code>/otp/transmodel/v3</code> #5637</li> <li>Add flexibleArea to GroupStop Quays #5625 </li> </ul>"},{"location":"Changelog/#240-2023-09-13","title":"2.4.0 (2023-09-13)","text":""},{"location":"Changelog/#notable-changes","title":"Notable Changes","text":"<ul> <li>Improved support for Fares V2 #4917 #5227 </li> <li>Improved error and timeout handling #5047 #5092 #5121 #5114 #5133 #5130 #5192</li> <li>Enable GTFS GraphQL API by default, remove the word \"legacy\" from its name and documentation #5202</li> <li>Access and egress penalty on time and cost #5180</li> <li>Improve support for GBFS geofencing zones #5201</li> <li>Reduce memory consumption by 5-8% #5223</li> <li>Stop count limit for access/egress routing and new accessEgress configuration object #5214</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request","title":"Detailed changes by Pull Request","text":"<ul> <li>Generate static documentation for GTFS GraphQL API #5069</li> <li>Create a valid area even when it has too many vertices #5019</li> <li>Constant speed street routing #5057</li> <li>Remove dead build configuration parameter (extraEdgesStopPlatformLink) #5080</li> <li>Configure HTTP WebServer Transaction timeouts #5047</li> <li>Improve Graph updaters shutdown #5092</li> <li>Fix flex timeshift #5063</li> <li>Merge norway traversal calculator into default #5106</li> <li>Use correct GTFS sequence number in vehicle position matcher #5090</li> <li>OSM: Break out of processing a malformed level map #5096</li> <li>Handle JsonParseException #5121</li> <li>Do not enforce API processing timeout for parallel routing #5114</li> <li>Rename bikeRental options to vehicleRental #5089</li> <li>Fare sandbox cleanup, remove MultipleFareService #5100</li> <li>Add validation of NeTEx timetabled passing times #5081</li> <li>Return WALKING_BETTER_THAN_TRANSIT only on a fully walking leg #5091</li> <li>Handle CoercingParseValueException #5133</li> <li>Remove broken Jersey tracing configuration #5142</li> <li>Graceful timeout error handling #5130</li> <li>Log http request headers - like correlationId #5131</li> <li>Fix vertex removal race condition #5141</li> <li>Comment out replacing DSJ-ID from planned data with ID from real-time-data #5140</li> <li>Remove San Francisco and vehicle rental fare calculators #5145</li> <li>Remove batch query from Transmodel API #5147</li> <li>Fix nullable absolute direction in GTFS GraphQL API #5159</li> <li>Fix error in flex validation #5161</li> <li>Check service dates instead of service ids for block id transfers #5162</li> <li>Add support for mapping NeTEx operating day in operating period #5167</li> <li>Validate to/from in routing request #5164</li> <li>Changing default value for earlyStartSec #5165</li> <li>Add GTFS stop sequence to GTFS GraphQL API #5153</li> <li>Remove walk leg in a stay seated transfer #5135</li> <li>Validate distinct from/to temporary vertices #5181</li> <li>Add support for NeTEx taxi mode #5183</li> <li>Fix bike triangle in Transmodel API #5179</li> <li>Bug fixes in stop area relation processing #5166</li> <li>Allow underscores in GTFS feed IDs #5191</li> <li>Area vertex linking improvements #5209</li> <li>Allow multiple FlexibleAreas in a FlexibleStopPlace #4922</li> <li>Prevent NPE in vehicle position matching #5212</li> <li>Empty stop_headsign will fall back to trip_headsign #5205</li> <li>Treat escalator differently from stairs, add escalator reluctance #5046</li> <li>Flex build time and memory optimization for large zones #5233</li> <li>Fix pathway traversal time calculation when none is supplied #5242</li> <li>Add check for null value of serviceCodesRunning in TripPatternForDateMapper #5239</li> <li>Improve error handling in TransmodelGraph #5192</li> <li>Fix filtering by submode #5261</li> <li>Add leg.headsign to GTFS GraphQL API #5290</li> <li>Return client error for invalid Transmodel query JSON format #5277</li> <li>Validate missing intermediate location in via requests #5253</li> <li>Support Fares v2 FareMedium and update spec implementation #5227</li> <li>Improve walk step narrative for entering/exiting stations and signposted pathways #5285</li> <li>Fix walk board cost comparison and add escalatorReluctance to hash #5310</li> <li>Remove pathway id from REST API #5303</li> <li>Remove Winkki street note updater #5305</li> <li>Extend stop area relation linking to include bus stop and platform nodes #5319</li> <li>Add access/egress penalty transmodel api #5268</li> </ul>"},{"location":"Changelog/#230-2023-04-24","title":"2.3.0 (2023-04-24)","text":""},{"location":"Changelog/#notable-changes_1","title":"Notable Changes","text":"<ul> <li>The performance for trip search of large networks (&gt; 100k stops) is improved</li> <li>Run only a single heuristics request (instead of two) #4537</li> <li>Parse NeTEx fare zones from a FareFrame #4563</li> <li>Initial implementation of via search #4554</li> <li>Relaunched documentation theme #4575</li> <li>Add carpool and taxi modes #4641</li> <li>New filter API #4657</li> <li>Adaptive street graph island pruning #4688</li> <li>Experimental support for GBFS geofencing zones #4741</li> <li>Update GBFS support to v2.3 #4809</li> <li>Improve support for EPIP NeTex profile #4863</li> <li>Uber ride hailing #4979</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_1","title":"Detailed changes by Pull Request","text":"<ul> <li>Refactoring SIRI StopConditions from TransitAlert to EntitySelector #4196</li> <li>Add cost of egress leg to the cost of the last transit leg if transit leg arrives at destination #4547</li> <li>Add fallback for missing operator name #4588</li> <li>Add performance test for Switzerland #4576</li> <li>Fix interchange generation when identical consecutive stops are filtered #4586</li> <li>Add alerts to leg when reading in a leg reference #4595</li> <li>Remove KML bike parking updater #4602</li> <li>Add stationTransferPreference option for GTFS feeds #4599</li> <li>Fix osmDefaults so they are used if something is not set in source #4635</li> <li>Add demDefaults #4637</li> <li>Add vector tile layer in debug client for AreaStops #4565</li> <li>Prevent bicycles from using stairs #4614</li> <li>Bugfix for interchanges that start and end from the same stop #4597</li> <li>Add option to define gtfsDefaults and move some parameters from root to gtfs config #4624</li> <li>Fix: forBoarding and forAlighting on cancelled calls in transmodel api #4639</li> <li>Make maxFlexTripDuration configurable #4642</li> <li>Extract separate conditions for \"and\", \"greater than\", \"less than\" during OSM tag mapping, add Portland tag mapping #4593</li> <li>Better fallback in shape geometry processing #4617</li> <li>Fix batch queries in HSL graphql API #4663</li> <li>Add filter for minimum bike parking distance #4626</li> <li>Add limits for flex access/egress walking #4655</li> <li>Make Prometheus endpoint take Accept header into account #4674</li> <li>Add entrances to parking lots that are unconnected in OSM #4666</li> <li>Include crossing=traffic_signals and use it for walking/cycling penalty on crossings #4574</li> <li>Replace surface=cobblestone:flattened with surface=set as a mixin spec in default OsmTagMapper #4683</li> <li>Remove NYC fare service #4694</li> <li>Upgrade dependencies to take new spelling of GTFS Flex's 'drop off' into account #4693</li> <li>Configuration of additional HTTP headers for GTFS-RT updaters #4684</li> <li>Automatic Java dependency upgrades #4704</li> <li>GTFS-RT extension to add completely new routes #4667</li> <li>Add validation on NeTEx flexible area import #4765</li> <li>Do not return a leg from a leg reference, if trip does not exist on date #4758</li> <li>Fix direct transfer analyzer #4767</li> <li>Refactor data import issue reporting #4777</li> <li>Add support for deleted trips &amp; including real-time cancellations in trip search #4759</li> <li>Fix TPoint generation for real-time generated patterns #4787</li> <li>Improve resiliency of the Transmodel API #4806</li> <li>Use TripPatterns for filtering #4820</li> <li>Remove all edges from stop vertex in island pruning #4846</li> <li>Filter functionality for GroupOfLines/GroupOfRoutes in TransmodelAPI #4812</li> <li>Mapping for maxAccessEgressDurationPerMode in Transmodel API #4829</li> <li>Use headsign from the original pattern in a real-time added pattern if the stop sequence is unchanged #4845</li> <li>Remove RouteMatcher #4821</li> <li>Improve boarding location linking on platforms #4852</li> <li>Always check allowed modes in VehicleRentalEdge #4810</li> <li>Include cancelled stops when including cancelled trips in trip search #4851</li> <li>Unpreferred vehicle parking tags #4873</li> <li>Ignore UnrestrictedPublicTransportAreas that do not contain regular stops #4919</li> <li>Validate missing transit data before building transit graph #4930</li> <li>Use durations for Raptor search window configuration #4926</li> <li>Add graph build issue statistics to metrics endpoint #4869</li> <li>Add documentation about system requirements and suggestions #4937</li> <li>Fix initial A* state of car rental #4934</li> <li>Remove check for (now optional) ENV-variable for GCP Authentication #4966</li> <li>Improved walking routes when walking starts or ends in an area #4936</li> <li>Remove unconnected walking areas from graph #4981</li> <li>Filter out duplicate-like legs in alternative legs #4868</li> <li>Fix timeshifting of Flex ~ Walk ~ Flex paths in Raptor #4952</li> <li>Validate the number of service links mapped to a JourneyPattern #4963</li> <li>Make sure the default streetRoutingTimeout is used #4998</li> <li>Validate service date for SCHEDULED updates #4861</li> <li>Fix quay duplicates overwriting stop index #4964</li> <li>Allow OTP to start when unexpected enum values are encountered in config #4983</li> <li>Add filename to graph report #4984</li> <li>Support for second criteria in McRaptor #4996</li> <li>Initialize RAPTOR stop-to-stop transfers on server startup #4977</li> <li>Fix bugs related to DST and service date #5004</li> <li>Fix validation of running period for NeTEx flexible lines #5007</li> <li>JSON logging #5023</li> <li>Add allowOverloading parameter to GBFS updaters and fix use of it in routing #5024</li> <li>Fix precedence rules for NeTEx flexible line booking information #5021</li> <li>Fix transferCacheRequests when custom streetRoutingTimeout is set #5039</li> </ul>"},{"location":"Changelog/#220-2022-11-01","title":"2.2.0 (2022-11-01)","text":""},{"location":"Changelog/#notable-changes_2","title":"Notable Changes","text":"<ul> <li>The performance for trip search is improved by ~20-30% </li> <li>Support for GTFS-RT Vehicle Positions #3981</li> <li>Support for NeTex DatedServiceJourneys #3889</li> <li>Cost-based wheelchair-accessible routing #4045</li> <li>Improve stop linking by taking OSM platform polygons into account #4116</li> <li>Provide an OCI container image on DockerHub #4168</li> <li>Re-add block-based interlining #4264</li> <li>Add walk safety to street routing #4328</li> <li>Experimental support for GTFS Fares V2 #4338</li> <li>Document JVM configuration options #4492</li> <li>Support for HTTPS datasource for Graph Building #4482</li> <li>Metrics for real-time trip updaters #4471</li> <li>Configuration Documentation generated programmatically #4478</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_2","title":"Detailed changes by Pull Request","text":"<ul> <li>NeTEx mapping for WheelChairBoarding #3945</li> <li>OTP support for NeTEx GroupOfLines #3928</li> <li>Implement trip banning #3953</li> <li>Improve performance of Park+Ride, Bike+Ride and Bike+Transit #3906</li> <li>Re-add GraphCoherencyCheckerModule #3985</li> <li>Modify TripPattern logic for updating stop-to-stop geometry #3988</li> <li>Read translations from GTFS and Netex sources for stop names #3808</li> <li>Update to Java 17 and Kryo 5 #3994</li> <li>Remove optimize=TRANSFERS #4004</li> <li>Enable GBFS floating vehicles by default #4012</li> <li>Don't try to repair trips with negative dwell or driving times, drop them instead #4019</li> <li>Add support for SKIPPED stop time updates in SCHEDULED update handling #3960</li> <li>Elevation handling improvements #4033</li> <li>NeTEx mapping of WheelchairBoarding from ServiceJourney to Trip #4043</li> <li>Add GBFS form factors to GraphQL API #4062</li> <li>Add Geocoder API for debug client searches #4068</li> <li>Consider Wheelchair boarding/alightning when routing from or to directly to a stop #4046</li> <li>Add an implementation for fetching alternative legs #4071</li> <li>Allow single SIRI-situations to fail without affecting others #4083</li> <li>Fix problem with submode filter #4093</li> <li>Make maxWheelchairSlope not a hard cut-off, but apply a cost instead #4088</li> <li>Expose Leg.serviceDate in trip end-point #4096</li> <li>Enable overriding maxDirectStreetDuration per mode #4104</li> <li>Preserve language in SIRI/GTFS-RT alert messages #4117</li> <li>Use board/alight cost only for transits #4079</li> <li>Improve SIRI real-time performance by reducing stopPattern duplicates #4038</li> <li>Siri updaters for Azure ServiceBus #4106</li> <li>Fallback to recorded/expected arrival/departure time if other one is missing in SIRI-ET #4055</li> <li>Allow overriding GBFS system_id with configuration #4147</li> <li>Fix error with transfer-slack and GTFS minTransferTime #4120</li> <li>Use actual distance for walk distance in StreetEdge #4125</li> <li>Don't indicate stop has been updated when NO_DATA is defined #3962</li> <li>Implement nearby searches for car and bicycle parking #4165</li> <li>Do not link cars to stop vertices in routing #4166</li> <li>Add Siri real-time occupancy info #4180</li> <li>Add gtfs stop description translations #4158</li> <li>Add option to discard min transfer times #4195</li> <li>Use negative delay from first stop in a GTFS RT update in previous stop times when required #4035</li> <li>OTP2 no longer crashes on invalid GTFS stop time sequences #4205</li> <li>Cost-based wheelchair accessibility routing for streets #4163</li> <li>Expose SIRI ET PredictionInaccurate in Transmodel-API #4217</li> <li>Do not apply walkable area processing to open platform geometries #4225</li> <li>Add field 'routingErrors' to GTFS GraphQLAPI #4253</li> <li>Configure idempotent upload to Google Cloud Storage #4269</li> <li>Add support to unprefer certain routes #4238</li> <li>Fix inconsistent mapping of NeTEx quay publicCode #4282</li> <li>Take street legs into account when applying the similar legs filter #4280</li> <li>Make graph time zone configurable #4281</li> <li>Support real-time updated wheelchair accessibility for trips #4255</li> <li>Include waiting time at beginning and end in TransitGeneralizedCostFilter #4188</li> <li>Allow filtering out of time-shifted itineraries with same routes and stops #4298</li> <li>Remove unmaintained custom fare calculators for NYC, Seattle, SF Bay Area, Netherlands #4273</li> <li>Return meaningful error if origin and destination are the same #4364</li> <li>Allow configuring maxAccessEgressDuration, searchWindow, timetableView #4377</li> <li>Add custom bike rental data updater (vilkku) as an extension #4381</li> <li>Flex: when optimizing paths preserve egress transfers #4378</li> <li>Skip opening hours if no time-zone configured #4372</li> <li>Digitransit stop vector layer updates #4404</li> <li>Re-enable copying of submode to trip from route #4407</li> <li>Configure each transit feed properties individually  #4399</li> <li>Account for boarding restrictions when calculating direct transfers #4421</li> <li>Configure the import of OSM extracts individually #4419</li> <li>Configure the import of elevation data individually #4423</li> <li>Return typed errors from real-time updates, prepare for real-time statistics #4424</li> <li>Add feature switch for matching ET messages on stops #4347</li> <li>Make safety defaults customizable for walking and cycling #4438</li> <li>Fix block-based interlining when importing several GTFS feeds #4468</li> <li>Do not remove patterns with non-running DatedServiceJourneys #4474</li> <li>Discard direct walking results if direct mode is flex #4476</li> <li>Implement free transfers in GTFS Fares V2 #4460</li> <li>Read and expose time zone in NeTEx/Transmodel API #4480</li> <li>Remove filtering of flex patterns in NeTEX import #4493</li> <li>Make walk and bicycle safety defaults adjustable based on speed limits on ways #4484</li> <li>Enable fuzzyTripMatching in other SIRI-ET updaters #4495</li> <li>Add support for importing zip datasets containing large entries #4508</li> <li>Add feature toggle for turning off the debug client #4512</li> <li>Add 'exact match' specifier for way property sets #4505</li> <li>Remove unnecessary sourceType attribute from GTFS-RT configuration  #4525</li> <li>Do not allow boarding/alighting at GroupStops in RAPTOR #4534</li> <li>Read the feed id from the agency when storing agencies #4536</li> </ul>"},{"location":"Changelog/#210-2022-03-17","title":"2.1.0 (2022-03-17)","text":""},{"location":"Changelog/#notable-changes_3","title":"Notable Changes","text":"<ul> <li>GBFS 2.2 is supported including \"form factors\" (bike, scooter, car) and floating vehicles (with no fixed station)</li> <li>Constrained Transfers (Netex interchanges / GTFS <code>transfers.txt</code>)</li> <li>Transfers for bicycle and wheelchair users distinct from walking paths</li> <li>Support for GTFS-Flex v2</li> <li>Support for frequency-based trips (GTFS <code>frequencies.txt</code>, does not exist in Netex)</li> <li>Many 1.5 features not fully implemented in 2.0 have been reintroduced</li> <li>Improved result quality relative to both 1.5 and 2.0: filtering of itineraries and selection of transfer points between routes</li> <li>Car and bicycle parking has been combined into vehicle parking (enhanced with real-time details like remaining parking spaces)</li> <li>New system for paging of routing results via cursor token</li> <li>Response times should be roughly stable since 2.0. Performance much improved over OTP1 for long searches, may be somewhat slower for short searches. Extremely depdendent on data set used, so test on your specific data.</li> <li>System integration tests for ongoing performance measurement </li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_3","title":"Detailed changes by Pull Request","text":"<ul> <li>Fix NullPointerException when a Real-Time update do not match an existing TripPattern #3284</li> <li>Support for versioning the configuration files #3282</li> <li>Prioritize \"direct\" routes over transfers in group-filters #3309</li> <li>Remove poor transit results for short trips, when walking is better #3331</li> <li>GTFS Trips will by default not allow bikes if no explicit value is set #3359.</li> <li>Improve the dynamic search window calculation. The configuration parameters <code>minTransitTimeCoefficient</code> and <code>minWaitTimeCoefficient</code> replace the old <code>minTripTimeCoefficient</code> parameter. #3366 </li> <li>Allow loops caused by turn restriction in street routes #3399</li> <li>Apply turn restrictions when splitting edges. #3414</li> <li>Add separate no-thru handling for bicycles #3410</li> <li>Add German way property set #3359</li> <li>Process OSM bicycle routes correctly #3359</li> <li>Avoid turns across traffic on bicycles #3359</li> <li>Remove request parameter <code>driveOnRight</code> and derive information from way property set #3359</li> <li>Add basic support for routing using floating bikes #3370</li> <li>Optimize which stops are used for transfers, using generalized-cost, wait-time and transfer priority. Partially implements #2788</li> <li>Support for stay-seated and guaranteed transfers #3193</li> <li>Fix reading of cached elevation files #3455</li> <li>Added BikeRentalWithMostlyWalking filter #3446</li> <li>Import GTFS-Flex v2 Flexible trips #3453</li> <li>Add support for arriving at the destination with rented bicycles #3459</li> <li>Allow IntersectionTraversalCostModel to be specified in the WayPropertySet #3472</li> <li>Fix for traveling back in time when optimize transfers #3491</li> <li>Transit reluctance per transit mode #3440</li> <li>Allow the removal of P+R results consisting only of driving of walking #3515</li> <li>Allow http headers to be specified for bike rental updaters #3533</li> <li>Per-mode reluctance parameters are added so that itineraries with multiple modes may have varying reluctances. #3501</li> <li>Add <code>maxAreaNodes</code> configuration parameter for changing an area visibility calculation limit (https://github.com/opentripplanner/OpenTripPlanner/issues/3534)</li> <li>Add maxAccessEgressDurationSecondsForMode to RoutingRequest #3560</li> <li>Add bicycle safety report to report API #3563</li> <li>Optimize Transfers performance issue #3513</li> <li>Don't allow bicycle loops in A* #3574</li> <li>Cancel individual stop on StopPattern instead of TripTimes #3575</li> <li>Do not allow bicycle traversal on ways tagged with mtb:scale #3578</li> <li>Changes to the StopTimes call #3576</li> <li>Fix bug in optimize transfer service decorating path #3587</li> <li>Remove non-GBFS bicycle rental updaters #3562</li> <li>Remove possibility to import vehicle rental stations from OSM, make vehicle rental stations feed scoped #3601</li> <li>When importing Netex, allow bicycles on ferries by default #3596</li> <li>Safely catch some elevation interpolation exceptions #3412</li> <li>Route not found in some conditions with boarding/alighting restrictions #3621</li> <li>Load additional data from GBFS and expose it #3610</li> <li>Allow transfers to use customizable request options #3324</li> <li>Check boarding and alighting permissions in TransferGenerator #3641</li> <li>Stoptimes should return tripId on the REST API. #3589</li> <li>Handle non-symmetric transfers in RAPTOR #3634.</li> <li>Order RAPTOR input data so that plans are deterministic #3580</li> <li>Cost on transfer in Raptor #3617</li> <li>Allow for combined NeTEx and GTFS data sources #3650</li> <li>Generalized graph connectivity pruning #3426</li> <li>Stop linking to area/platform edges obeys area boundaries and traverse modes #3201</li> <li>Add service day mapping to REST API #3659</li> <li>Generalized cost on transfer in Raptor #3629</li> <li>Add two new filters for use within grouping filter #3638</li> <li>Correct usage of boardSlackForMode / alightSlackForMode #3693</li> <li>Do not parse pass-through information in GBFS mappers #3709</li> <li>Vehicle rental updates #3632</li> <li>add trolleybus &amp; monorail support #3658</li> <li>Do not create zero length StreetEdges #3716</li> <li>Add pickup and dropoff booking info to REST API #3710</li> <li>Use the whole duration of the filtered transit data for the raptor heuristic search #3664</li> <li>Performance improvement for flex access/egress searches #3661</li> <li>Add new routing errors for cases where all itineraries were filtered by post-processing #3628</li> <li>Fix combination of flex access and constrained transfer #3726</li> <li>Merge B+R and P+R functionality into vehicle parking #3480</li> <li>Add cost to maximize wait-time and avoid back-travel in optimize transfers #3654</li> <li>Calculate fares from itineraries not Raptor paths, calculate flex fares #3743</li> <li>Logging first time instance reports it is ready to use #3733</li> <li>Allow limiting the used vehicle rentals and parkings #3746</li> <li>Add support for car and scooter rental modes #3706</li> <li>Extra stop priority cost in optimized transfer service #3731</li> <li>Remove old visibility graph library from walkable area builder #3753</li> <li>Update GtfsRealtime and include severity, effect and cause from GTFS RT #3747</li> <li>Handle miscellaneous service as BUS instead of crashing build #3755</li> <li>Update all timers to micrometer instances #3744</li> <li>Bugfix: ClassCastException when planning flex routes #3762</li> <li>Add mode from parent StopPlace for Quays in Netex mapper #3751</li> <li>Minor performance improvements #3767</li> <li>Parallelise computing of trip pattern geometries #3766</li> <li>Add flex stop to TripTimes, return geometries in GraphQL API #3757</li> <li>Fix checking allowed boarding/alighting for unscheduled flex trips #3782</li> <li>Calculating number of days to use in StopTimes-request #3742</li> <li>Walkable area builder improvements #3765</li> <li>Remove hardcoded alighting/boarding on first/last stop #3784</li> <li>Add support for include-file-directive in config files. #3771</li> <li>Remove build parameter 'useTransfersTxt' #3791</li> <li>Add cursor-based paging #3759</li> <li>Data overlay sandbox feature #3760</li> <li>Add support for sandboxed real-time vehicle parking updaters #3796</li> <li>Add reading and exposing of Netex submodes #3793</li> <li>Fix: Account for wait-time in no-wait Raptor strategy  #3798</li> <li>Read in flex window from Netex feeds #3800</li> <li>Fix NPE when routing on a graph without transit data. #3804</li> <li>Read leg mode from trip, instead of route #3819</li> <li>Use API mapping in snapshot tests #3823</li> <li>Store stop indices in leg and use them to simplify logic in TripTimeShortHelper #3820</li> <li>Include all trips in <code>stopTimesForStop</code> #3817</li> <li>Store all alerts and add support for route_type and direction_id selectors #3780</li> <li>Remove outdated real-time-update from TimetableSnapshot #3770</li> <li>Contributing Guide #3769</li> <li>OTP support for NeTEx branding #3829</li> <li>Not allowed transfers and support for GTFS transfer points #3792</li> <li>Simple implementation of horizontally moving elevators (Elevator way) #3750</li> <li>fix: Avoid mixed path separators on Windows in Park API test #3845</li> <li>Filter out elevator ways that are also implicit areas #3850</li> <li>Dynamically compute additional search days #3824</li> <li>Mode &amp; submode filter for NeTEx Service Journeys #3844</li> <li>Return correct heuristic values, when constrained transfers is turned on #3841</li> <li>Adjust search window dynamically to fit the number of itineraries #3828</li> <li>Implement minimum transfer time from GTFS transfers.txt #3830</li> <li>Fix number format exception for elevator duration parsing OSM data #3871</li> <li>Include generalizedCost in the optimized transfers wait-time cost #3864</li> <li>Expose maxStopToShapeSnapDistance as build-config.json parameter #3874</li> <li>Implement in-seat transfers per GTFS draft #3831</li> <li>Add stairsTimeFactor to StreetEdge #3832</li> <li>Make sure we keep the itinerary with the least number of transfers when grouping the itineraries #3833</li> <li>Don't expect every pattern in a route to have the specified stop with constrained transfers #3868</li> <li>Add support for creating constrained transfers from real-time generated patterns #3878</li> <li>Account for stay seated transfers when calculating the number of transfers #3888</li> <li>Add Hungarian translation #3861</li> <li>Add support for \"via\" in NeTEx headsigns #3883</li> <li>NeTEx mapping to StopTime.timepoint #3898</li> <li>Optimize RAPTOR trip search by pre-calculating arrival/departure time arrays #3919</li> <li>Make turn restrictions faster and thread-safe by moving them into StreetEdge #3899</li> <li>Add routing using frequency trips #3916</li> <li>Remove ET real-time override code #3912</li> <li>Allow traversal of pathways without traversal time, distance or steps #3910</li> </ul>"},{"location":"Changelog/#200-2020-11-27","title":"2.0.0 (2020-11-27)","text":"<ul> <li>Sandbox for experimental features #2745</li> <li>Bugfix for Missing platforms for stops in GTFS import causes a NPE #2804</li> <li>Remove extra Djikstra implementations</li> <li>Remove redundant LineStrings in order to save memory #2795</li> <li>NeTEx import support #2769</li> <li>New Transit search algorithm, Raptor, replaces the AStar for all transit searches.</li> <li>Added NeTEx notices #2824</li> <li>Make transfers and access/egress use effectiveWalkDistance to take slopes into account #2857</li> <li>Add MultiModalStation and GroupOfStations to OTP model and added these to the NeTEx import #2813</li> <li>Combined OSM loaders, removing several rarely used ones #2878</li> <li>New Java Code Style (part of #2755)</li> <li>Cleanup and rename Graph Builder Annotations, now Data Import Issues #2871</li> <li>Bugfix for graph building crashing on unsupported modes #2899</li> <li>Add command line parameter for building partial graphs #2583</li> <li>Refactor GenericLocation/AStar/RoutingContext to allow multiple start vertices #2887 </li> <li>New Transit search algorithm, Raptor, replaces the AStar for all transit searches. </li> <li>Update only the relevant parts of the TransitLayer each time an update is applied #2918</li> <li>Ability to switch off the fare service#2912.</li> <li>Limit the transit service period#2925.</li> <li>Removed unwanted cost added for wait time between access and transit with RangeRaptor #2927</li> <li>Dynamic search parameters, calculate raptor search-window when needed. #2931</li> <li>Support for next/previous paging trip search results #2941</li> <li>Fix mismatch in duration for walk legs, resulting in negative wait times #2955</li> <li>NeTEx import now supports ServiceLinks #2951</li> <li>Also check TripPatterns added by real-time when showing stoptimes for stop #2954</li> <li>Copy geometries from previous TripPattern when real-time updates result in a TripPattern being replaced #2987</li> <li>Support for the Norwegian language.</li> <li>Update pathways support to official GTFS specification #2923</li> <li>Support for XML (de-)serialization is REMOVED from the REST API #3031</li> <li>Refactor how to specify access/egress/direct/transit modes in the internal model and the Transmodel API #3011</li> <li>Make agency id feed scoped #3035</li> <li>Refactor kiss and ride to a more general car pickup mode #3063</li> <li>Map NeTEx publicCode to OTP tripShortName and NeTEx private code to OTP internalPlanningCode #3088</li> <li>Add MQTT transport for the GTFS-RT trip update updater #3094</li> <li>Add FinlandWayPropertySetSource #3096</li> <li>Map NeTEx publicCode to OTP tripShortName and NeTEx private code to OTP internalPlanningCode #3088</li> <li>Reading and writing files(CONFIG, GRAPH, DEM, OSM, GTFS, NETEX, DATA_IMPORT_ISSUES) is changed. All files, except configuration files, are read from a data source. We support Google Cloud Storage and the local file system data sources for now, but plan to add at least support for AWS S3 #2891</li> <li>Remove AlertPatcher #3134</li> <li>Update DebugOutput to match new routing phases of OTP2 #3109</li> <li>Filter transit itineraries with relative high cost #3157</li> <li>Fix issue with colliding TripPattern ids after modifications form real-time updaters #3202</li> <li>Fix: The updater config type is unknown: gtfs-http #3195</li> <li>Fix: Problem building and loading the GTFS file in San Fransisco Bay Area #3195</li> <li>Fix: The <code>BusRouteStreetMatcher</code> and <code>TransitToTaggedStopsModule</code> graph builder modules are not run if the graph is build in two steps, and add progress tracker to BusRouteStreetMatcher. #3195</li> <li>Improvement: Insert project information like Maven version number into configuration files. #3254 </li> <li>Added pathway FeedScopedId as the route text to trip plan responses. #3287</li> </ul>"},{"location":"Changelog/#ported-over-from-14-and-15","title":"Ported over from 1.4 and 1.5","text":"<ul> <li>Add application/x-protobuf to accepted protobuf content-types #2839</li> <li>Make OTP run on Java 11 #2812</li> <li>Fixes surefire test failure during build #2816</li> <li>Disable linking from already linked stops #2372</li> <li>Add Way Property Set for the UK #2818</li> <li>Remove Open Traffic prototype code #2698</li> <li>Docs: improve configuration documentation</li> <li>Update onebusaway-gtfs to latest version from OBA project #2636</li> <li>Remove the coupling to OneBusAway GTFS within OTP's internal model by creating new classes replacing the external classes #2494</li> <li>Allow itineraries in response to be sorted by duration #2593</li> <li>Fix reverse optimization bug #2653, #2411</li> <li>increase GTFS-real-time feeds size limit from 64MB to 2G #2738</li> <li>Fix XML response serialization #2685</li> <li>Refactor InterleavedBidirectionalHeuristic #2671</li> <li>Add \"Accept\" headers to GTFS-RT HTTP requests #2796</li> <li>Fix minor test failure against BANO geocoder #2798</li> <li>Fix frequency bounds checking #2540</li> <li>Remove dependency on Conveyal jackson2-geojson</li> <li>Changed calculation of slope costs #2579</li> <li>Replace Java built in serialization with faster Kryo #2681</li> <li>Support OSM highway=razed tag #2660</li> <li>Add bicimad bike rental updater #2503</li> <li>Add Smoove citybikes updater #2515</li> <li>Allow big GTFS-real-time feeds by increasing protobuf size limit to 2G #2739</li> <li>Cannot transfer between stops at exactly the same location #2371</li> <li>Improve documentation for <code>mode</code> routing parameter #2809</li> <li>Switched to single license file, removing all OTP and OBA file license headers</li> </ul>"},{"location":"Changelog/#13-2018-08-03","title":"1.3 (2018-08-03)","text":"<ul> <li>Fix stop linking to only one edge of platform #2472</li> <li>Log and allow changing number of HTTP handler threads</li> <li>Update Dutch base fare from 89 to 90 cents #2608</li> <li>Add Dutch fare service #2571</li> <li>Revise unit tests to use less memory</li> <li>Run all graph updater setup methods sequentially #2545</li> <li>Allow vehicle rental systems with cars (stopgap parameter on bike rental)</li> <li>Bump R5 version to get newer gtfs-lib and FST serialization</li> <li>Move stopClusterMode parameter from routing config to build config #2558</li> <li>Update encrypted Maven artifact signing key (it expired)</li> <li>Clean up logging</li> <li>Remove/update deprecated HTTPClient, add missing SSL ciphers #2451</li> <li>Make maxTransfer options configurable through scripting API #2507</li> <li>Fix scripts when entity IDs contain colons #2474</li> <li>Add HTML report for stops more than 20m from linked road #2460</li> <li>Update fares in NycFareServiceImpl #2466</li> <li>Compact legs NPE fix #2449 #2490</li> <li>Docs: elevation data configuration, USGS DEM files</li> <li>Docs: Update list of deployments</li> <li>Docs: API, list of deployments, usage stats and tutorials</li> <li>Docs: Update leadership committee listing following Boston Summit</li> <li>Docs: Update OTP logo (Thanks Kate Chanba!)</li> </ul>"},{"location":"Changelog/#12-2017-09-18","title":"1.2 (2017-09-18)","text":"<ul> <li>Add support for consuming GBFS bike-rental availability feeds. #2458</li> <li>Add GBFS configuration example</li> <li>Add flag for including requested start/end time in maxHours in planner API. #2457</li> <li>Add maxTransferDistance graph builder parameter</li> <li>Add option for filtering non-pickup stops in TransitIndex stop times functions. #2377</li> <li>Support foot/bicycle=discouraged OSM tag. #2415</li> <li>Improve linking of transit platforms to connecting access ways. #2422 / #2428</li> <li>Fix bug when building graph with parent station transfers. #2404 / #2410</li> <li>Fix bugs in park and ride search. #2424</li> <li>Support different stop ID formats in field trip module</li> <li>Update URL in BANO geocoding module. #2438 / #2439</li> <li>Add more debug information related to trips matching using GTFS-RT feed. #2432</li> <li>Update default PATH_NOT_FOUND message to new wording developed w/ TriMet. #2355</li> <li>Update Travis build configuration to not attempt GPG operations. #2441</li> <li>Fix javadoc URL in scripting documentation. #2437</li> <li>Automatically link to GitHub issues in Changelog. #2426</li> <li>Expose FeedInfo objects in the Index API #2456</li> <li>Changes to Puget Sound region fare calculation #2484</li> <li>Fix coordinatates when clustering by parent station #2447</li> <li>Allow setting OSM Way Properties from build-config.json #2389</li> <li>Optionally compact (\"reverse-optimize\") results with complete reverse search #2449</li> <li>Add updater for urbaninfrastructure city bikes #2448</li> <li>Miscellaneous documentation updates</li> </ul>"},{"location":"Changelog/#11-2017-03-16","title":"1.1 (2017-03-16)","text":"<ul> <li>Deploy to Sonatype OSSRH and Maven Central</li> <li>Documentation updates including repo links</li> <li>New router-config stopClusterMode: clustering by parent station or geography #2364</li> <li>Spanish and Portuguese UI Translations</li> <li>In TimeSurface API, serialize travel times to every point when detail=true</li> <li>Make OSM highway=corridor pedestrian routable</li> <li>Fix GraphIndex.stopTimesForStop to search on the request day rather than now</li> <li>Update GraphQL to latest version and improve support for complex arguments #2367</li> <li>Add support for operationName to the graphql endpoint</li> <li>Fix findClosestStopsByWalking, properly set RoutingContext</li> <li>Fixed major routing problem where dead-end SimpleTransfers blocked walking paths #2414</li> <li>Created Github issue template</li> <li>Avoid negative elevation figures: Compute ellipsoid-geoid offset and optionally apply to elevation calculations #2301</li> <li>Fix VCub bike share updater using new API variable names.</li> <li>Fix spurious different-day warning #2399</li> <li>Shutdown hook to gracefully shut down Grizzly #2384</li> <li>Added headsign attribute for stoptimes in GraphQL #2224</li> <li>Allow Cars on highway=*;bicycle=designated #2374</li> <li>Expose PruneFloatingIslands parameters in build-config.json</li> <li>Lazy initialization of stop clusters where needed</li> <li>Include Agency/Route branding in responses</li> <li>Include turn-by-turn walking directions for transfer legs #1707</li> <li>Output error when edge lengths are negative, and set them to 1mm</li> <li>Add disableAlertFiltering API flag #2351</li> <li>Do not show arrival times at terminal stops in stop time viewer #2357</li> <li>Index API now returns stop information URL, enabling hyperlinks in trip viewer #2352</li> <li>Remove all unused model classes for index API #1301</li> <li>Apply an interlining fix from 0.10 branch</li> <li>Allow quoted search phrases in the Lucene search #2279</li> <li>Re-implement maxHours filter #2332</li> <li>Properly set wheelchairAccessible on area edges</li> <li>Fixed file URL in test #2339</li> <li>Add details field to fares, listing which legs each fare applies to #1699</li> </ul>"},{"location":"Changelog/#10-2016-09-09","title":"1.0 (2016-09-09)","text":"<ul> <li>Fix problem with missing embedded router-configs.</li> <li>Check whether trips have been banned when applying in-seat transfers (interlining).</li> <li>Load embedded config for existing graphs on disk.</li> <li>Apply max walk distance to transfers, not just initial and final walk.</li> <li>Remove Conveyal tiles from client (which was getting expensive), add free Carto/MapZen tiles.</li> <li>Fixed headsigns: in itineraries, headsign for a leg used to always be the last stop.</li> <li>Updated default map tile sets in the client because Mapquest is no longer gratis.</li> <li>Fix problem with empty list ??? #1873</li> <li>Rewrite of intermediate places handling in GraphPathFinder. Original request is cloned for each intermediate path.</li> <li>Routes in GraphQL API Change \"type\" to \"mode\" and add \"type\" as route type to Route for GraphQL</li> <li>Add effective end date to alerts (from HSL).</li> <li>Rutebanken Citybike bike share.</li> <li>Correct TPEG transport modes TPEG 401 and 402 to be \"subway\".</li> <li>Ignore exceptions caused by errors in OSM linear rings.</li> <li>Updated to version 2.18 of Jersey to fix hanging threads in Grizzly.</li> <li>Removed confusing \"Busish\" and \"Trainish\" pseudo-modes.</li> <li>FareService for Seattle: allow specifying fares in GTFS instead of hard-coding them in Java. Senior/youth fare prices are given in an extra column in fare attributes. Per-trip fares are taken into consideration when calculating fares in this region.</li> <li>Update new linker to link to transitStops if no streets are found.</li> <li>Show the name supplied in the request for the origin/destination points in the response.</li> <li>Throw a trivialPath exception if start/end point are on the same edge.</li> <li>Switch to only use the new SimpleStreetLinker, even for search start and end points. Completely removed old linker classes. Changes for proper handling of wheelchairs and bicycles at start and end points.</li> <li>Properly handle null timetableSnapshots when there is no real-time data.</li> </ul>"},{"location":"Changelog/#020-2016-06-10","title":"0.20 (2016-06-10)","text":"<ul> <li>Re-enabled Enunciate, which works properly with OTP now. This means we have auto-generated API docs.</li> <li>Make headsign and block ID visible in the Stop Viewer.</li> <li>NYC fare service: filter out non-NYC agencies.</li> <li>Optionally log all requests to a file.</li> <li>Make max distance for in-seat transfers (interlining) configurable. Previously it was hardcoded at 200m.</li> <li>Polish translation for web client.</li> <li>Introduced bikeShareId in trip plans (separate from stopIds).</li> <li>Support for ShareBike bike rental system in Oslo, Drammen, Trondheim, Milan, Barcelona and Mexico City among others.</li> <li>Changed default waitAtBeginningFactor and timeouts.</li> <li>Show alert in client when itinerary departure date differs from search date.</li> <li>Exposed realtimeState in GraphQL responses.</li> <li>Fixed a routerConfig NullPointerException.</li> <li>Support for San Francisco bike share from leoromanovsky.</li> <li>GraphQL API for most transit data from hannesj.</li> <li>Disallow shortcuts through multiple StationStopEdges.</li> <li>Add support for airplanes (from HSL)</li> <li>Major simplification and correction of the longDistance heuristic, removed obsolete runState.options.heuristicWeight.</li> <li>Return default OSM level for ways that are not found.</li> <li>Profile routing: use earliest arrival objective function on-street, properly handle TrivialPathExceptions.</li> <li>Fixed ID matching when applying AlertPatches.</li> <li>Fixed banning of agencies in multi agency feeds.</li> <li>More coherent handling of feed IDs as scope for GTFS IDs.</li> <li>Added transit service start and end timestamps to BuildInfo.</li> <li>Handle embeded router configuration for POSTed graphs and zips for building.</li> <li>Simplified router-config handling.</li> <li>Properly lazy-initialize profile routing stopClusters. Added stop clusters to the Index API.</li> <li>Completely removed the ill-advised path parser system, which was too clever for its own good.</li> <li>Sort itineraries by total travel time rather than in-transit time.</li> <li>Rental bikes: allow loading generic KML.</li> <li>Removed the experimental TransportNetwork classes, which shared no code with the rest of OTP and    were duplicated in the R5 project. There are still some elements that can be cleaned out when only   R5 is used by Conveyal's analysis system. The broker code in OTP is now able to start up R5    workers for Analyst.</li> <li>Use the Conveyal fork of the OBA GTFS loader, so that we can add our own extensions to GTFS.</li> <li>Updated docs to offer Conveyal Maven repo as a place to get prebuilt OTP.</li> </ul>"},{"location":"Changelog/#0190-2016-05-25","title":"0.19.0 (2016-05-25)","text":""},{"location":"Changelog/#0180-2015-05-29","title":"0.18.0 (2015-05-29)","text":"<ul> <li>Ability to load elevation from projected GeoTIFF</li> <li>Clarified axis order for unprojected GeoTIFFs</li> <li>Stop viewer and car distance fixed in client</li> <li>Server-side localization improvements</li> <li>Proper names for intersections</li> <li>JSON config for loading bikeshare and park and ride lots from OSM</li> <li>More ways to fetch isochrones</li> <li>Fixed frequency-based routing in repeated RAPTOR</li> <li>Calculate graph envelope at build time not runtime</li> <li>Fixed slow excessive HashGrid search</li> <li>Readthedocs documentation updates</li> </ul>"},{"location":"Changelog/#0170-2015-05-14","title":"0.17.0 (2015-05-14)","text":"<ul> <li>Allow fetching arrivals/departures over a particular time window</li> <li>Completely new spatial analysis implementation: repeated RAPTOR search at every minute in a departure time window</li> <li>More reproducible spatial analysis results across similar graphs, thanks to more consistent splitting of streets etc.</li> <li>Sigmoidal accessibility metric rolloff (rather than hard-edged cutoff)</li> <li>Correction of equirectangular projection used in spatial analysis</li> <li>Improved, simplified, deterministic linking of stops into the street network</li> </ul>"},{"location":"Changelog/#0160-2015-05-07","title":"0.16.0 (2015-05-07)","text":"<ul> <li>Several improvements to OSM tag based traversal permissions</li> <li>Scripting documentation</li> <li>Accept TIFF files whose names end in .tiff not .tif</li> <li>Store distances (not times) in Analyst Samples to allow variable walk speed</li> <li>Fixed bug in graph auto-scanning</li> <li>Fixed client-side bug in first and last itinerary buttons</li> <li>OTP startup scripts no longer use wildcards</li> <li>Transit, bike rental, and parking linking done in one module</li> <li>Elevation tiles for the US can be fetched from Amazon S3</li> <li>Bumped language level to Java 8 (lambda functions, method references, collection streams)</li> </ul>"},{"location":"Changelog/#0150-2015-04-14","title":"0.15.0 (2015-04-14)","text":"<ul> <li>Fare module for Seattle</li> <li>JSON fare module and OSM street naming configuration</li> <li>Significant improvements to speed and result quality of Profile Routing</li> <li>Support for added and modified GTFS-RT trips (thanks Jaap Koelewijn of DAT Mobility and Plannerstack)</li> <li>Detailed edge lists in profile routing responses (for Transitive.js)</li> <li>Support for multiple access modes including bike rental in profile routing</li> <li>Fixes to graph reloading via web API</li> <li>Improved comments in code and documentation of PointSets</li> <li>Pulled MapDB GTFS loader out into a separate repo</li> <li>Working artifact version was 0.15.0-SNAPSHOT instead of 1.0.0-SNAPSHOT (anticipating frequent point releases)</li> </ul>"},{"location":"Changelog/#0140-2015-03-28","title":"0.14.0 (2015-03-28)","text":"<ul> <li>JSON configuration of graph building and routers</li> <li>Began moving documentation (including this changelog) into the OTP repo and rewriting it page by   page. It is built statically from Markdown using mkdocs and published on readthedocs.</li> <li>Street edge lists and bike rental station IDs in profile routing results (allows better rendering)</li> <li>Improved correctness of profile routing</li> <li>Qualified modes including rented bikes work in profile routing</li> <li>Simplification of qualified mode sets</li> <li>Elevation models are loaded from TIFFs in graph directory</li> <li>Tiles for differences between TimeSurfaces</li> <li>Restructured relationship between Routers and Graphs</li> <li>Various changes enabling use of Analyst features in a cluster computing environment.</li> <li>Removed several single-implementation interfaces, factories, services and other superfluous abstractions</li> <li>Various client fixes related to the transit index API</li> <li>Revised nearby stops logic and transfer generation to eliminate useless transfer edges</li> <li>New Index API endpoints for geometries, transfers etc.</li> <li>Isochrone generation fixes</li> <li>Default mode of operation is now \u201clong distance mode\u201d</li> <li>Process for finding alternative routes is now based on banning trips and retrying, while reusing the heuristic</li> <li>Optimization objective functions are swappable, and have been simplified and corrected</li> <li>All client Javascript librariess are now pulled from a CDN</li> <li>Dutch BAG and French BANO geocoders</li> <li>Bus to street matching improvements</li> <li>Complete MapDB based GTFS and OSM loader libraries (will become separate projects, not yet   connected to OTP graph builder)</li> <li>API documentation generation working again</li> <li>Disable some time consuming graph building steps by default</li> <li>Finnish and Swedish translations</li> <li>Subway-specific JSON configuration options (street to platform time)</li> <li>Real-time fetch / streaming configurable via JSON</li> <li>Stairs reluctance is much higher when carrying a bike</li> <li>Graph visualizer routing progress animates when a search is triggered via the web API</li> <li>Assume WGS84 (spherical distance calculations) everywhere</li> <li>Removed custom motor vehicle (which was unmaintained and not documented)</li> <li>Ability to poll for bike rental locations only once at startup</li> <li>Stoptimes are fetched for a specific service day in index API</li> <li>Bicycle triangle support in profile routing</li> <li>Proper handling of multiple access modes with different speeds in profile routing</li> <li>Command line option to output OTP's version</li> </ul>"},{"location":"Changelog/#0130-2014-12-05","title":"0.13.0 (2014-12-05)","text":"<ul> <li>Detect apparent errors in GTFS interlining</li> <li>Long distance mode: use a pure weight-based state comparison, and use trip-banning retrying logic   to get multiple paths. This compromises correctness somewhat but brings search times back within   reason for large regional graphs. Also, we create significantly less SimpleTransfers.</li> <li>Progress on GTFS reading and writing library (not yet used by OTP).</li> <li>Bug fixes for tiny street edges, time zones.</li> <li>Deployment of artifacts to maven.conveyal.com via S3.</li> <li>Handle park and ride lots that have roads running through them, but don't share nodes with those roads.</li> </ul>"},{"location":"Changelog/#0121-2014-11-17","title":"0.12.1 (2014-11-17)","text":"<ul> <li>Fixed threading problem caused by graph visualization instrumentation #1611</li> <li>Fixed 'unconnected areas' infinite loop #1605</li> </ul>"},{"location":"Changelog/#0120-2014-11-11","title":"0.12.0 (2014-11-11)","text":"<ul> <li>Graph building from zipball of data sent over the wire</li> <li>OTP-specific GTFS loader library with error checking and recovery</li> <li>Bike and car park and ride improvements</li> <li>Stable hash codes for stop patterns and trips</li> <li>Bicycle safety and wheelchair access tile generators</li> <li>Newer versions of Grizzly, Jackson, and Enunciate (documentation generation now works)</li> <li>Redesigned HashGrid spatial index</li> <li>Significant reduction in graph size in memory and on disk</li> <li>Improved internationalization</li> <li>Ability to pause and step search in graph visualizer</li> <li>Additional graph visualizer modes for spotting overbranching</li> <li>Movement toward 1.0 web services API</li> <li>Kiss and Ride</li> <li>Complete removal of Spring</li> <li>Complete removal of Lombok</li> <li>CORS replaces JSONP</li> <li>Pointset classes for dealing with one-to-many calculations and accessibility calculations</li> <li>Experimental \"Profile routing\" which enumerates reasonable route combinations over a time range rather than exact itineraries</li> <li>Single-module Maven build (complete elimination of submodules)</li> <li>Alternate Gradle build script</li> <li>full internationalization of the map-based web client</li> <li>basic Lucene-based built-in geocoder</li> </ul>"},{"location":"Changelog/#0110-2014-03-24","title":"0.11.0 (2014-03-24)","text":"<ul> <li>Built-in HTTP server layer, making it possible to distribute OTP as a standalone JAR</li> <li>\"Long-distance\" mode for large graphs, including bidirectional goal direction heuristic.</li> <li>Simplified Maven project structure with less submodules</li> <li>GTFS-RT trip update support, including streaming incremental data, which directly affects route optimization</li> </ul>"},{"location":"Changelog/#0100-2014-03-18","title":"0.10.0 (2014-03-18)","text":"<p>This release was made to consolidate all the development that had occurred with a 0.9.x-SNAPSHOT Maven version. The changes were very significant and it was not appropriate to tag them as a minor bugfix release after the 0.9 tag. Though this release was performed at the same time as 0.11.0, it represents a much earlier stage in the development of OTP.</p>"},{"location":"Changelog/#070-2012-04-29","title":"0.7.0 (2012-04-29)","text":"<ul> <li>Bike rental support (thanks Laurent Gr\u00e9goire)</li> <li>Real-time bike rental availability feed support</li> <li>Updated to new version of One Bus Away GTFS/CSV, fixing timezone and string interning issues (thanks Brian Ferris)</li> <li>Bugfixes in area routing, OSM loading, nonexistant NED tiles, route short names</li> <li>Dutch and French language updates</li> <li>Catch negative edge weights due to broken GTFS</li> <li>Significant (10-20%) speedup by moving a field into StateData (thanks Laurent Gr\u00e9goire)</li> </ul>"},{"location":"Changelog/#060-2012-04-25","title":"0.6.0 (2012-04-25)","text":"<ul> <li>area routing</li> <li>more lenient parsing of times</li> <li>new directions icon set with SVG sources (thanks Laurent G)</li> </ul>"},{"location":"Changelog/#054-2012-04-06","title":"0.5.4 (2012-04-06)","text":"<ul> <li>catch 0 divisors in NED builder, preventing NaN propagation to edge lengths</li> <li>avoid repeated insertion of edges into edge lists, which are now threadsafe edge sets</li> <li>identity equality for edges</li> <li>bounding box check in UnifiedCoverage (speed up NED loading)</li> <li>Dutch API messages</li> <li>elevation override fix</li> <li>less verbose graph builder (be sure to check graphbuilder annotation summary)</li> <li>replacement streets given names</li> <li>geocoder bug fix (thanks Laurent Gregoire)</li> <li>git commit IDs included in MavenVersion, allowing clearer OTP/Graph version mismatch warnings</li> <li>fix problems with immediate reboarding and unexpected edges in itinerary builder</li> <li>favicon (thanks Joel Haasnoot)</li> <li>Legs in API response have TripId (for real-time information)</li> <li>Polish locale (thanks \u0141ukasz Witkowski)</li> <li>transfers.txt can define station paths, entry costs for stations</li> <li>allow loading a base graph into graphbuilder instead of starting from scratch</li> </ul>"},{"location":"Changelog/#053-2012-03-23","title":"0.5.3 (2012-03-23)","text":"<ul> <li>GTFS loader now loads feeds one-at-a-time, allowing per-feed configuration</li> <li>half-written graph files are now deleted on graph build error</li> <li>DST issue OTP-side fixes, tests adjusted to use timezones</li> <li>updated French translation</li> <li>fixed problem with loop ways in OSM</li> <li>graph coherency checking</li> <li>improved OSM floor number handling</li> <li>handle units in ele tags</li> <li>ferry icons (thanks Joel Haasnoot)</li> <li>mapbox streets tile layer is now the default</li> <li>complete Dutch translation</li> </ul>"},{"location":"Changelog/#052-2012-03-20","title":"0.5.2 (2012-03-20)","text":"<ul> <li>hop speed/distance checks, duplicate shape point filtering, etc.</li> </ul>"},{"location":"Changelog/#051-2012-03-16","title":"0.5.1 (2012-03-16)","text":"<ul> <li>more transit index features</li> <li>default agencyIDs now determined on a per-feed basis</li> <li>fixed fare overflow problem</li> <li>fixed bug in loop road turn conversion</li> <li>additional graphbuilder warnings and annotations</li> <li>fixed a batch of bugs found by fixbugs</li> </ul>"},{"location":"Changelog/#050-2012-03-09","title":"0.5.0 (2012-03-09)","text":"<ul> <li>stop codes, zones, and agency names in planner responses</li> <li>encapsulation of edge list modifications</li> <li>expanded edge and vertex type hierarchy</li> <li>use mapquest OSM server by default</li> <li>Turkish locale (thanks Hasan Tayyar Be\u015fik)</li> <li>German and Italian locales (thanks Gerardo Carrieri)</li> <li>bookmarkable trip URLs (thanks Matt Conway)</li> <li>elevator and OSM level support (thanks Matt Conway)</li> <li>BART/Muni fare service</li> <li>release and javadoc/apidoc publishing automation</li> <li>graph versioning based on Maven artifact version</li> <li>API for browsing graph internals</li> <li>improved stop linking</li> <li>optional island removal graphbuilder step</li> <li>and of course, lots of bugfixes</li> </ul>"},{"location":"Changelog/#044-2012-02-06","title":"0.4.4 (2012-02-06)","text":"<p>Release in anticipation of upcoming merges.</p>"},{"location":"Codestyle/","title":"Codestyle","text":"<p>We use the following code conventions for Java and JavaScript.</p>"},{"location":"Codestyle/#java","title":"Java","text":"<p>The OpenTripPlanner Java code style is revised in OTP v2.2. We use the Prettier Java as is. Maven is setup to run <code>prettier-maven-plugin</code>. A check is run in the CI build, which fails the build preventing merging a PR if the code-style is incorrect.</p> <p>There is two ways to format the code before checkin it in. You may run a normal build with maven - it takes a bit of time, but reformat the entire codebase. Only code you have changed should be formatted, since the existing code is already formatted. The second way is to set up prettier and run it manually or hick it into your IDE, so it runs every time a file is changed.</p>"},{"location":"Codestyle/#how-to-run-prittier-with-maven","title":"How to run Prittier with Maven","text":"<p>Format all code is done in the validate phase (run before test, package, install)</p> <pre><code>% mvn test\n</code></pre> <p>To skip the prettier formating use profile <code>prettierSkip</code>:</p> <pre><code>% mvn test -P prettierSkip\n</code></pre> <p>The check for formatting errors use profile <code>prettierCheck</code>:</p> <pre><code>% mvn test -P prettierSkip\n</code></pre> <p>The check is run by the CI server and will fail the build if the code is incorrectly formatted.</p>"},{"location":"Codestyle/#intellj-and-code-style-formatting","title":"IntellJ and Code Style Formatting","text":"<p>You should use the prettier Maven plugin to reformat the code or run prettier with Node(faster).</p> <p>The prettier does NOT format the doc and markdown files, only Java code. So, for other files you should use the project code-style. It is automatically imported when you first open the project. But, if you have set a custom code-style in your settings (as we used until OTP v2.1), then you need to change to the Project Code Style. Open the <code>Preferences</code> from the menu and select _ Editor &gt; Code Style_. Then select Project in the _Scheme drop down.</p>"},{"location":"Codestyle/#run-prettier-maven-plugin-as-an-external-tool-in-intellij","title":"Run Prettier Maven Plugin as an external tool in IntelliJ","text":"<p>You can run the Prettier Maven plugin as an external tool in IntelliJ. Set it up as an <code>External tool</code> and assign a key-shortcut to the tool execution.</p> <p></p> <pre><code>Name:              Prettier Format Current File\nProgram:           mvn\nArguments:         prettier:write -Dprettier.inputGlobs=$FilePathRelativeToProjectRoot$\nWorking Directory: $ProjectFileDir$\n</code></pre> <p>Tip!  Add a unused key shortcut to execute the external tool, then you can use the old  short-cut to format other file types.</p>"},{"location":"Codestyle/#install-file-watchers-plugin-in-intellij","title":"Install File Watchers Plugin in IntelliJ","text":"<p>You can also configure IntelliJ to run the prettier every time IntelliJ save a Java file. But, if you are editing the file at the same time you will get a warning that the file in memory and the file on disk both changed - and asked to select one of them.</p> <ol> <li>In the menyopen Prefernces... and select Plugins.</li> <li>Search for \"File Watchers\" in Marketplace</li> <li>Run Install</li> </ol>"},{"location":"Codestyle/#configure-file-watcher","title":"Configure File Watcher","text":"<p>You can run Prettier on every file save in Intellij using the File Watcher plugin. There is several ways to set it up. Below is hwo to configure it using Maven to run the formatter. The Maven way work without any installation of other components, but might be a bit slow. So, you might want to install prettier-java in your shell and run it instead.</p> <pre><code>Name:              Format files with Prettier\nFile type:         Java\nScope:             Project Files\nProgram:           mvn\nArguments:         prettier:write -Dprettier.inputGlobs=$FilePathRelativeToProjectRoot$\nWorking Directory: $ProjectFileDir$\n</code></pre>"},{"location":"Codestyle/#other-ides","title":"Other IDEs","text":"<p>We do not have support for other IDEs at the moment. If you use another editor and make one please feel free to share it.</p>"},{"location":"Codestyle/#sorting-class-members","title":"Sorting Class Members","text":"<p>Some of the classes in OTP have a lot of fields and methods. Keeping members sorted reduce the merge conflicts. Adding fields and methods to the end of the list will cause merge conflicts more often than inserting methods and fields in an ordered list. Fields and methods can be sorted in \"feature\" sections or alphabetically, but stick to it and respect it when adding new methods and fields.</p> <p>The provided formatter will group class members in this order:</p> <ol> <li>Getter and Setter methods are kept together</li> <li>Overridden methods are kept together</li> <li>Dependent methods are sorted in a breadth-first order.</li> <li>Members are sorted like this:<ol> <li><code>static</code> <code>final</code> fields</li> <li><code>static</code> fields</li> <li><code>static</code> initializer</li> <li><code>final</code> fields</li> <li>fields</li> <li>class initializer (avoid using it)</li> <li>Constructor</li> <li><code>static</code> methods</li> <li><code>static</code> getter and setters</li> <li>methods</li> <li>getter and setters</li> <li>enums</li> <li>interfaces</li> <li><code>static</code> classes</li> <li>classes</li> </ol> </li> <li>Each section of members are sorted by visibility:<ol> <li>\u00b4public\u00b4</li> <li>package private</li> <li>\u00b4protected\u00b4</li> <li>\u00b4private\u00b4</li> </ol> </li> </ol>"},{"location":"Codestyle/#javadoc-guidlines","title":"JavaDoc Guidlines","text":"<p>What to put in Javadoc:</p> <ul> <li>On methods:<ul> <li>Side effects on instance state (is it a pure function)</li> <li>Contract of the method<ul> <li>Input domain for which the logic is designed</li> <li>Range of outputs produced from valid inputs</li> <li>Is behavior undefined or will fail when conditions are not met</li> <li>Are null values allowed as inputs</li> <li>Will null values occur as outputs (what do they mean)</li> </ul> </li> <li>Invariants that hold if the preconditions are met</li> <li>Concurrency<ul> <li>Is method thread-safe</li> <li>Usage constraints for multi-threaded use</li> </ul> </li> </ul> </li> <li>On classes:<ul> <li>Initialization and teardown process</li> <li>Can instance be reused for multiple operations, or should it be discarded</li> <li>Is it immutable or should anything be treated as immutable</li> <li>Is it a utility class of static methods that should not be instantiated</li> </ul> </li> </ul>"},{"location":"Codestyle/#javascript","title":"JavaScript","text":"<p>As of #206, we follow Crockford's JavaScript code conventions. Further guidelines include:</p> <ul> <li>All .js source files should contain one class only</li> <li>Capitalize the class name, as well as the source file name (a la Java)</li> <li>Include the namespace definition in each and every file: <code>otp.namespace(\"otp.configure\");</code></li> <li>Include a class comment. For example,</li> </ul> <pre><code>/**\n * Configure Class\n *\n * Purpose is to allow a generic configuration object to be read via AJAX/JSON, and inserted into an\n * Ext Store\n * The implementation is TriMet route map specific...but replacing ConfigureStore object (or member\n * variables) with another implementation, will give this widget flexibility for other uses beyond\n * the iMap.\n *\n * @class\n */\n</code></pre> <p>Note: There is still a lot of code following other style conventions, but please adhere to consistent style when you write new code, and help clean up and reformat code as you refactor.</p>"},{"location":"Configuration/","title":"Introduction","text":""},{"location":"Configuration/#configuring-opentripplanner","title":"Configuring OpenTripPlanner","text":""},{"location":"Configuration/#base-directory","title":"Base Directory","text":"<p>On the OTP2 command line you must always specify a single directory after all the switches. This tells OTP2 where to look for any configuration files. By default OTP will also scan this directory for input files to build a graph (GTFS, OSM, elevation, and base street graphs) or the <code>graph.obj</code> file to load when starting a server.</p> <p>A typical OTP2 directory for a New York City graph might include the following:</p> <pre><code>otp-config.json\nbuild-config.json\nrouter-config.json\nnew-york-city-no-buildings.osm.pbf\nnyc-elevation.tiff\nlong-island-rail-road.gtfs.zip\nmta-new-york-city-transit.gtfs.zip\nport-authority-of-new-york-new-jersey.gtfs.zip\ngraph.obj\n</code></pre> <p>You could have more than one of these directories if you are building separate graphs for separate regions. Each one should contain one or more GTFS feeds, a PBF OpenStreetMap file, some JSON configuration files, and any output files such as <code>graph.obj</code>. For convenience, especially if you work with only one graph at a time, you may want to place your OTP2 JAR file in this same directory. Note that file types are detected through a case-insensitive combination of file extension and words within the file name. GTFS file names must end in <code>.zip</code> and contain the letters <code>gtfs</code>, and OSM files must end in <code>.pbf</code>.</p> <p>It is also possible to provide a list of input files in the configuration, which will override the default behavior of scanning the base directory for input files. Scanning is overridden independently for each file type, and can point to remote cloud storage with arbitrary URIs. See the storage section for further details.</p>"},{"location":"Configuration/#three-scopes-of-configuration","title":"Three Scopes of Configuration","text":"<p>OTP is configured via three configuration JSON files which are read from the directory specified on its command line. We try to provide sensible defaults for every option, so all three of these files are optional, as are all the options within each file. Each configuration file corresponds to options that are relevant at a particular phase of OTP usage.</p> <p>Options and parameters that are taken into account during the graph building process will be \"baked into\" the graph, and cannot be changed later in a running server. These are specified in <code>build-config.json</code>. Other details of OTP operation can be modified without rebuilding the graph. These run-time configuration options are found in <code>router-config.json</code>. Finally, <code>otp-config.json</code> contains simple switches that enable or disable system-wide features.</p>"},{"location":"Configuration/#configuration-types","title":"Configuration types","text":"<p>The OTP configuration files use the JSON file format. OTP allows comments and unquoted field names in the JSON configuration files to be more human-friendly. OTP supports all the basic JSON types: nested objects <code>{...}</code>, arrays <code>[]</code>, numbers <code>789.0</code> and boolean <code>true</code> or <code>false</code>. In addition to these basic types some configuration parameters are parsed with some restrictions. In the documentation below we will refer to the following types:</p> Type Description Examples <code>boolean</code> This is the Boolean JSON type <code>true</code>, <code>false</code> <code>string</code> This is the String JSON type. <code>\"This is a string!\"</code> <code>double</code> A decimal floating point number. 64 bit. <code>3.15</code> <code>integer</code> A decimal integer number. 32 bit. <code>1</code>, <code>-7</code>, <code>2100</code> <code>long</code> A decimal integer number. 64 bit. <code>-1234567890</code> <code>enum</code> A fixed set of string literals. <code>\"RAIL\"</code>, <code>\"BUS\"</code> <code>enum-map</code> List of key/value pairs, where the key is a enum and the value can be any given type. <code>{ \"RAIL: 1.2, \"BUS\": 2.3 }</code> <code>enum-set</code> List of enum string values <code>[ \"RAIL\", \"TRAM\" ]</code> <code>locale</code> <code>Language[\\_country[\\_variant]]</code>. A Locale object represents a specific geographical, political, or cultural region. For more information see the Java Locale. <code>\"en_US\"</code>, <code>\"nn_NO\"</code> <code>date</code> Local date. The format is YYYY-MM-DD (ISO-8601). <code>\"2020-09-21\"</code> <code>date-or-period</code> A local date, or a period relative to today. The local date has the format <code>YYYY-MM-DD</code> and the period has the format <code>PnYnMnD</code> or <code>-PnYnMnD</code> where <code>n</code> is a integer number. <code>\"P1Y\"</code>, <code>\"-P3M2D\"</code>, <code>\"P1D\"</code> <code>duration</code> A duration is a amount of time. The format is <code>PnDTnHnMnS</code> or <code>nDnHnMnS</code> where <code>n</code> is a  integer number. The <code>D</code>(days), <code>H</code>(hours), <code>M</code>(minutes) and <code>S</code>(seconds) are not case sensitive. <code>\"3h\"</code>, <code>\"2m\"</code>, <code>\"1d5h2m3s\"</code>, <code>\"-P2dT-1s\"</code> <code>regexp</code> A regular expression pattern used to match a sting. <code>\"$^\"</code>, <code>\"gtfs\"</code>, <code>\"\\w{3})-.*\\.xml\"</code> <code>uri</code> An URI path to a resource like a file or a URL. Relative URIs are resolved relative to the OTP base path. <code>\"http://foo.bar/\"</code>, <code>\"file:///Users/jon/local/file\"</code>, <code>\"graph.obj\"</code> <code>time-zone</code> Time-Zone ID <code>\"UTC\"</code>, <code>\"Europe/Paris\"</code>, <code>\"-05:00\"</code> <code>feed-scoped-id</code> FeedScopedId <code>\"NO:1001\"</code>, <code>\"1:101\"</code> <code>cost-linear-function</code> A cost-linear-function used to calculate a cost from another cost or time/duration.    Given a function of time:   <code>f(t) = a + b * t</code>   then <code>a</code> is the constant time part, <code>b</code> is the time-coefficient, and <code>t</code> is the variable.   If <code>a=0s</code> and <code>b=0.0</code>, then the cost is always <code>0</code>(zero).    Examples: <code>0s + 2.5t</code>, <code>10m + 0t</code> and <code>1h5m59s + 9.9t</code>    The <code>constant</code> must be 0 or a positive number or duration. The unit is seconds unless   specified using the duration format. A duration is automatically converted to a cost.   The <code>coefficient</code> must be in range: [0.0, 100.0] <code>time-penalty</code> A time-penalty is used to add a penalty to the duration/arrival-time/departure-time for   a path. It will be invisible to the end user, but used during the routing when comparing   stop-arrival/paths.    Given a function of time:   <code>f(t) = a + b * t</code>   then <code>a</code> is the constant time part, <code>b</code> is the time-coefficient, and <code>t</code> is the variable.   If <code>a=0s</code> and <code>b=0.0</code>, then the cost is always <code>0</code>(zero).    Examples: <code>0s + 2.5t</code>, <code>10m + 0 x</code> and <code>1h5m59s + 9.9t</code>    The <code>constant</code> must be 0 or a positive number(seconds) or a duration.   The <code>coefficient</code> must be in range: [0.0, 100.0] <code>map</code> List of key/value pairs, where the key is a string and the value can be any given type. <code>{ \"one\": 1.2, \"two\": 2.3 }</code> <code>object</code> Config object containing nested elements <code>\"walk\": { \"speed\": 1.3, \"reluctance\": 5 }</code> <code>array</code> Config object containing an array/list of elements <code>\"array\": [ 1, 2, 3 ]</code>"},{"location":"Configuration/#system-environment-and-project-information-substitution","title":"System environment and project information substitution","text":"<p>OTP supports injecting system environment variables and project information parameters into the configuration. A pattern like <code>${VAR_NAME}</code> in a configuration file is substituted with an environment variable with name <code>VAR_NAME</code>. The substitution is done BEFORE the JSON is parsed, so both json keys and values are subject to substitution. This is useful if you want OTPs version number to be part of the graph-file-name, or you want to inject credentials in a cloud based deployment.</p> <pre><code>{\n    \"gsCredentials\": \"${GCS_SERVICE_CREDENTIALS}\",\n    \"graph\": \"file:///var/otp/graph-${otp.serialization.version.id}.obj\"\n}\n</code></pre> <p>In the example above the environment variable <code>GCS_SERVICE_CREDENTIALS</code> on the local machine where OTP is deployed is injected into the config. Also, the OTP serialization version id is injected.</p> <p>The project information variables available are:</p> <ul> <li><code>maven.version</code></li> <li><code>maven.version.short</code></li> <li><code>maven.version.major</code></li> <li><code>maven.version.minor</code></li> <li><code>maven.version.patch</code></li> <li><code>maven.version.qualifier</code></li> <li><code>git.branch</code></li> <li><code>git.commit</code></li> <li><code>git.commit.timestamp</code></li> <li><code>graph.file.header</code></li> <li><code>otp.serialization.version.id</code></li> </ul>"},{"location":"Configuration/#config-version","title":"Config version","text":"<p>All three configuration files have an optional <code>configVersion</code> property. The property can be used to version the configuration in a deployment pipeline. The <code>configVersion</code> is not used by OTP in any way, but is logged at startup and is available as part of the server-info data in the REST API. The intended usage is to be able to check which version of the configuration the graph was build with and which version the router uses. In an deployment with many OTP instances it can be useful to ask an instance about the version, instead of tracking the deployment pipeline backwards to find the version used. How you inject a version into the configuration file is up to you, but you can do it in your build-pipeline, at deployment time or use system environment variable substitution.</p>"},{"location":"Configuration/#otp-serialization-version-id-and-graphobj-file-header","title":"OTP Serialization version id and Graph.obj file header","text":"<p>OTP has a OTP Serialization Version Id maintained in the pom.xml_ file. OTP stores the id in the serialized Graph.obj file header, allowing OTP to check for compatibility issues when loading the graph. The header info is available to configuration substitution:</p> <ul> <li><code>${graph.file.header}</code> Will expand to: <code>OpenTripPlannerGraph;0000007;</code></li> <li><code>${otp.serialization.version.id}</code> Will expand to: <code>7</code></li> </ul> <p>The intended usage is to be able to have a graph build pipeline that \"knows\" the matching graph and OTP planner instance. For example, you may build new graphs for every OTP serialization version id in use by the planning OTP instances you have deployed and plan to deploy. This way you can roll forward and backward new OTP instances without worrying about building new graphs.</p> <p>There are various ways to access this information. To get the <code>Graph.obj</code> serialization version id you can run the following bash command:</p> <ul> <li><code>head -c 29 Graph.obj ==&gt;  OpenTripPlannerGraph;0000007;</code> (file header)</li> <li><code>head -c 28 Graph.obj | tail -c 7 ==&gt;  0000007</code>  (version id)</li> </ul> <p>The Maven pom.xml, the META-INF/MANIFEST.MF, the OTP command line(<code>--serVerId</code>), log start-up messages and all OTP APIs can be used to get the OTP Serialization Version Id.</p>"},{"location":"Configuration/#include-file-directive","title":"Include file directive","text":"<p>It is possible to inject the contents of another file into a configuration file. This makes it possible to keep parts of the configuration in separate files. To include the contents of a file, use <code>${includeFile:FILE_NAME}</code>. The <code>FILE_NAME</code> must be the name of a file in the configuration directory. Relative paths are not supported.</p> <p>To allow both files (the configuration file and the injected file) to be valid JSON files, a special case is supported. If the include file directive is quoted, then the quotes are removed, if the  text inserted is valid JSON (starts with <code>{</code> and ends with <code>}</code>). </p> <p>Variable substitution is performed on configuration file after the include file directive; Hence variable substitution is also performed on the text in the injected file.</p> <p>Here is an example including variable substitution, assuming version 2.4.0 of OTP:</p> <pre><code>// build-config.json\n{\n  \"transitFeeds\" : \"${includeFile:transit.json}\"\n} \n</code></pre> <pre><code>// transit.json\n[\n  {\n  \"source\": \"netex-v${maven.version.short}.obj\"\n}\n]\n</code></pre> <p>The result will look like this:</p> <pre><code>{\n      \"transitFeeds\": [\n        {\n          \"source\": \"netex-v2.4.0.obj\"\n        }\n      ]\n} \n</code></pre>"},{"location":"Configuration/#system-wide-configuration","title":"System-wide Configuration","text":"<p>Using the file <code>otp-config.json</code> you can enable or disable different APIs and experimental Sandbox Extensions. By default, all supported APIs are enabled and all sandbox features are disabled. So for most OTP2 use cases it is not necessary to create this file. Features that can be toggled in this file are generally only affect the routing phase of OTP2 usage, but for consistency all such \"feature flags\", even those that would affect graph building, are managed in this one file. </p>"},{"location":"Configuration/#otp-features","title":"OTP Features","text":"<p>Here is a list of all features which can be toggled on/off and their default values.</p> Feature Description Enabled by default Sandbox <code>APIBikeRental</code> Enable the bike rental endpoint. \u2713\ufe0f <code>APIServerInfo</code> Enable the server info endpoint. \u2713\ufe0f <code>APIUpdaterStatus</code> Enable endpoint for graph updaters status. \u2713\ufe0f <code>ConsiderPatternsForDirectTransfers</code> Enable limiting transfers so that there is only a single transfer to each pattern. \u2713\ufe0f <code>DebugUi</code> Enable the debug GraphQL client and web UI and located at the root of the web server as well as the debug map tiles it uses. Be aware that the map tiles are not a stable API and can change without notice. Use the vector tiles feature if you want a stable map tiles API. \u2713\ufe0f <code>FloatingBike</code> Enable floating bike routing. \u2713\ufe0f <code>GtfsGraphQlApi</code> Enable the GTFS GraphQL API. \u2713\ufe0f <code>GtfsGraphQlApiRentalStationFuzzyMatching</code> Does vehicleRentalStation query also allow ids that are not feed scoped. <code>MinimumTransferTimeIsDefinitive</code> If the minimum transfer time is a lower bound (default) or the definitive time for the transfer. Set this to <code>true</code> if you want to set a transfer time lower than what OTP derives from OSM data. <code>OptimizeTransfers</code> OTP will inspect all itineraries found and optimize where (which stops) the transfer will happen. Waiting time, priority and guaranteed transfers are taken into account. \u2713\ufe0f <code>ParallelRouting</code> Enable performing parts of the trip planning in parallel. <code>TransferConstraints</code> Enforce transfers to happen according to the transfers.txt (GTFS) and Interchanges (NeTEx). Turning this off will increase the routing performance a little. \u2713\ufe0f <code>TransmodelGraphQlApi</code> Enable the Transmodel (NeTEx) GraphQL API. \u2713\ufe0f \u2713\ufe0f <code>ActuatorAPI</code> Endpoint for actuators (service health status). \u2713\ufe0f <code>AsyncGraphQLFetchers</code> Whether the @async annotation in the GraphQL schema should lead to the fetch being executed asynchronously. This allows batch or alias queries to run in parallel at the cost of consuming extra threads. <code>Co2Emissions</code> Enable the emissions sandbox module. \u2713\ufe0f <code>DataOverlay</code> Enable usage of data overlay when calculating costs for the street network. \u2713\ufe0f <code>FaresV2</code> Enable import of GTFS-Fares v2 data. \u2713\ufe0f <code>FlexRouting</code> Enable FLEX routing. \u2713\ufe0f <code>GoogleCloudStorage</code> Enable Google Cloud Storage integration. \u2713\ufe0f <code>LegacyRestApi</code> Enable legacy REST API. This API will be removed in the future. \u2713\ufe0f \u2713\ufe0f <code>RealtimeResolver</code> When routing with ignoreRealtimeUpdates=true, add an extra step which populates results with real-time data \u2713\ufe0f <code>ReportApi</code> Enable the report API. \u2713\ufe0f <code>RestAPIPassInDefaultConfigAsJson</code> Enable a default RouteRequest to be passed in as JSON on the REST API - FOR DEBUGGING ONLY! <code>SandboxAPIGeocoder</code> Enable the Geocoder API. \u2713\ufe0f <code>SandboxAPIMapboxVectorTilesApi</code> Enable Mapbox vector tiles API. \u2713\ufe0f <code>SandboxAPIParkAndRideApi</code> Enable park-and-ride endpoint. \u2713\ufe0f <code>SandboxAPITravelTime</code> Enable the isochrone/travel time surface API. \u2713\ufe0f <code>TransferAnalyzer</code> Analyze transfers during graph build. \u2713\ufe0f <code>VehicleToStopHeuristics</code> Enable improved heuristic for park-and-ride queries. \u2713\ufe0f <p>Example</p> <pre><code>// otp-config.json\n{\n    \"otpFeatures\" : {\n        \"APIBikeRental\" : false,\n        \"ActuatorAPI\" : true\n    }\n}\n</code></pre>"},{"location":"Configuration/#jvm-configuration","title":"JVM configuration","text":"<p>This section contains general recommendations for tuning the JVM in a production environment. It focuses mainly on garbage collection configuration and memory settings. See Garbage Collector Tuning for general information on garbage collection. See Large Pages in Java and  Transparent Huge Pages for general information on large memory pages.</p>"},{"location":"Configuration/#otp-server","title":"OTP server","text":"<p>The OTP server processes concurrent routing requests in real time. The main optimization goal for the OTP server is minimizing response time.</p>"},{"location":"Configuration/#garbage-collector","title":"Garbage collector","text":"<ul> <li>The G1 garbage collector (default since Java 9) offers a good compromise between low latency (i.e. low GC pause time) and GC overhead.</li> <li>If latency spikes are an issue, the ZGC garbage collector is an alternative. It produces in general more overhead than G1.  </li> </ul>"},{"location":"Configuration/#memory-settings","title":"Memory settings","text":"<ul> <li>Using Large Memory Pages can reduce pressure on the TLB cache and increase performance.  </li> <li>It is in general not recommended to use large memory page in Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>) for latency-sensitive applications, since memory is allocated on-demand and this can induce latency spikes if the memory is fragmented.   Thus TLBFS mode (<code>-XX:+UseHugeTLBFS</code>) should be the first choice.</li> <li>If TLBFS mode is not an option,  Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>) can be used instead, with additional provisions to mitigate the risk of latency spikes: The physical memory can be committed upfront, at JVM startup time. This can be done by forcing a fixed heap size and pre-touching the memory. Example: <code>-Xms18g -Xmx18g -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch</code> </li> </ul>"},{"location":"Configuration/#graph-builder","title":"Graph Builder","text":"<p>The Graph Builder is the non-interactive mode used to build street graphs and transit graphs.    The main optimization goal for the Graph Builder is minimizing total build time.  </p>"},{"location":"Configuration/#garbage-collector_1","title":"Garbage collector","text":"<ul> <li>In theory, the Parallel garbage collector offers the best throughput. In practice, it can be challenging to optimize the Parallel GC to build both a street graph and a transit graph, the memory usage patterns being different. </li> <li>The G1 garbage collector provides in general a good compromise.  </li> </ul>"},{"location":"Configuration/#memory-settings_1","title":"Memory settings","text":"<ul> <li>Using Large Memory Pages can reduce pressure on the TLB cache and increase performance.  </li> <li>Since latency is not an issue, Large Memory Pages can be used indifferently in TLBFS mode (<code>-XX:+UseHugeTLBFS</code>) or Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>)</li> </ul>"},{"location":"Container-Image/","title":"Container image","text":"<p>The CI pipeline deploys container images for runtimes like Docker, Kubernetes or Podman to  Dockerhub.</p> <p>The image assumes you use a volume to mount the input data (GTFS/NeTex, OSM) and config files into  <code>/var/opentripplanner/</code>. When serving a graph it's also expected to be in this directory.</p>"},{"location":"Container-Image/#quick-start","title":"Quick start","text":"<p>Let's use the image to build a graph in Berlin.</p> <pre><code># create directory for data and config\nmkdir berlin\n# download OSM\ncurl -L https://download.geofabrik.de/europe/germany/berlin-latest.osm.pbf -o berlin/osm.pbf  \n# download GTFS\ncurl -L https://vbb.de/vbbgtfs -o berlin/vbb-gtfs.zip\n# build graph and save it onto the host system via the volume\ndocker run --rm -v \"$(pwd)/berlin:/var/opentripplanner\" docker.io/opentripplanner/opentripplanner:latest --build --save \n# load and serve graph\ndocker run -it --rm -p 8080:8080 -v \"$(pwd)/berlin:/var/opentripplanner\" docker.io/opentripplanner/opentripplanner:latest --load --serve\n</code></pre> <p>Now open http://localhost:8080 to see your running OTP instance.</p>"},{"location":"Container-Image/#additional-notes","title":"Additional notes","text":"<p>Make sure to include the word \"gtfs\" when naming the gtfs files that you want to use for OTP. Otherwise, graph build will fail.</p> <p>If you want to set JVM options you can use the environment variable <code>JAVA_TOOL_OPTIONS</code>, so a full example to add to your docker command is <code>-e JAVA_TOOL_OPTIONS='-Xmx4g'</code>. </p>"},{"location":"Data-Sources/","title":"Data Sources","text":""},{"location":"Data-Sources/#input-formats","title":"Input Formats","text":"<p>At the core of OpenTripPlanner is a library of Java code that finds efficient paths through multi-modal transportation networks built from OpenStreetMap and GTFS data. It can also receive GTFS-RT (real-time) data.</p> <p>In addition to GTFS, OTP can also load data in the Nordic Profile of Netex, the EU-standard transit data interchange format. The upcoming EU-wide profile was heavily influenced by the Nordic Profile and uses the same schema, so eventual support for the full EU profile is a possibility.</p> <p>GTFS and Netex data are converted into OTP's own internal model which is a superset of both. It is therefore possible to mix Netex and GTFS data, and potentially even data from other sources.</p>"},{"location":"Deployments/","title":"OpenTripPlanner Deployments Worldwide","text":""},{"location":"Deployments/#official-production","title":"Official Production","text":"<p>The following are known deployments of OTP in a government- or agency-sponsored production capacity:</p> <ul> <li>Norway (nationwide) Since November 2017, the national integrated ticketing agency Entur has   prodvided a national journey planner which consumes schedule data in the EU   standard NeTEx format with SIRI real-time updates. Entur has contributed greatly to the OTP2 effort   and primarily uses OTP2 in production, handling peak loads in excess of 20 requests per second.    Most regional agencies in Norway, like Ruter, Oslo area uses OTP as a service provided by Entur.</li> <li>Finland (nationwide) The Helsinki Regional Transport Authority,   the Finnish Transport Agency, and   other Finnish cities have collaborated to   create Digitransit, providing OTP-based trip planners, APIs, open   data, Docker containers and open source code. Each member organisation runs its own instance of a   shared codebase and deployment environment. Their source code is   available on Github, including   a new custom UI. This system also has a strong   real-time component.</li> <li>Finland Intercity The Finnish intercity coach   service Matkahuolto   has developed a trip planner in partnership with Kyyti.</li> <li>Sk\u00e5ne, Sweden, the JourneyPlanner and mobile app for the regional transit agency Sk\u00e5netrafiken   uses OTP2 with the nordic profile of NeTEx and SIRI for real-time updates.</li> <li>Northern Colorado</li> <li>Philadelphia and surrounding areas</li> <li>Portland, Oregon TriMet is the agency that originally started the OpenTripPlanner project.   Their Regional Trip Planner is based on OTP and provides about 40,000   trip plans on a typical weekday.</li> <li>New York City</li> <li>New York State The State Department of   Transportation's transit trip planner provides itineraries   for public transit systems throughout the state in a single unified OTP instance.</li> <li>Los Angeles, California The new metro.net trip planner.</li> <li>Atlanta, Georgia The Metropolitan Atlanta Rapid Transit Authority's (   MARTA) trip planner and the Atlanta region's transit   information hub https://atlrides.com/ both use OTP to power their website trip   planners.</li> <li>Boston, Massachusetts   The Massachusetts Bay Transportation Authority trip planner.</li> <li>Seattle, Washington The Sound Transit Trip Planner   is based on OTP. OTP also powers the trip planning feature of   the OneBusAway native apps in the Puget Sound region. Technical details   are here   .</li> <li>Ride Metro Houston</li> <li>Tampa, Florida Hillsoborough Area Regional Transit uses an OpenTripPlanner server to power the   trip planning feature of the OneBusAway native apps in their region.   Technical details   are here   .</li> <li>Piemonte Region, Italy and the City of   Torino built on OpenTripPlanner   by 5T.</li> <li>Valencia, Spain from the Municipal   Transport Company of Valencia S.A.U.</li> <li>Grenoble, France from SMTC, Grenoble Alpes m\u00e9tropole, l'\u00c9tat   Fran\u00e7ais, the Rh\u00f4ne-alpes region, the Is\u00e8re council and the City of Grenoble.</li> <li>Rennes, France where the STAR network provides an OTP client   for iOS   , Android, Windows Phone   et Web.</li> <li>Alen\u00e7on, France integrated urban and school bus   network planner from R\u00e9unir Alen\u00e7on.</li> <li>Pozna\u0144, Poland from Urban Transport Authority of Pozna\u0144 (ZTM   Poznan).</li> <li>Trento Province, Italy</li> <li>ViaggiaTrento   and ViaggiaRovereto   were implemented as part of the SmartCampus Project, a research   project founded by TrentoRise, UNITN,   and FBK.</li> <li>University of South Florida (Tampa, Florida). The USF Maps App is a   responsive web application for that helps university students, staff, and visitors find their way   around the campus using multiple modes of transportation, including the USF Bull Runner campus   shuttle, Share-A-Bull bike share, and pedestrian pathways.   Open-sourced on Github.</li> <li>Lower Saxony, Germany The VBN transportation authority offers an OTP instance as alternative to the Hafas passenger information system.</li> <li>Leipzig, Germany As of summer 2020 Leipzig Move has been using   OpenTripPlanner.</li> </ul>"},{"location":"Deployments/#independent-production","title":"Independent Production","text":"<p>The following OTP-based services are presented as production-quality deployments, but are not backed by an official transportation authority or government. OTP is also known to be used on the back end of several popular multi-city mobile trip planning applications.</p> <ul> <li>The Netherlands (nationwide) Plannerstack Foundation provides   national scale trip planning APIs using OTP and other open source trip planners, based   on OpenOV's extremely detailed open data including minutely real-time   updates for every vehicle in the country.</li> <li>OTP Android   by CUTR-USF and Vreixo Gonz\u00e1lez can find itineraries on many different OTP servers via a service   discovery mechanism.</li> <li>ViviBus Bologna Bologna, Italy.</li> </ul>"},{"location":"Developers-Guide/","title":"Developers Guide","text":""},{"location":"Developers-Guide/#quick-setup","title":"Quick setup","text":"<p>A Quick guide to setting up the OpenTripPlanner project.</p> <p>You need Git, Maven and Java(JDK) and an IDE installed on your computer. Your IDE might have JDK and Maven embedded, if so you may skip step 3.</p> <ol> <li>Clone OpenTripPlanner from GitHub.</li> <li>Checkout the desired branch <code>git checkout dev-2.x</code></li> <li>Run <code>mvn package</code>- this will download all dependencies, build the project and run tests.</li> <li>Open the project in your IDE.</li> </ol>"},{"location":"Developers-Guide/#working-on-otp-in-an-ide","title":"Working on OTP in an IDE","text":"<p>Most people writing or modifying OTP code use an Integrated Development Environment (IDE). Some of the most popular IDEs for Java development are IntelliJ IDEA, Eclipse, and NetBeans. All three of these environments are good for working on OTP. IntelliJ is used by most OTP developers, and the only IDE we support with a code style formatter. You may choose another IDE, but Maven and Git integration is a plus since OTP is under Git version control and build with Maven.</p> <p>Many of the Core OTP developers use IntelliJ IDEA. It is an excellent IDE, and in my experience is quicker and more stable than the competition. IntelliJ IDEA is a commercial product, but there is an open source \"community edition\" that is completely sufficient for working on OTP.</p> <p>Rather than using the version control support in my IDE, I usually find it more straightforward to clone the OTP GitHub repository manually (on the command line or using some other Git interface tool), then import the resulting local OTP repository into my IDE as a Maven project. The IDE should then take care of fetching all the libraries OTP depends on, based on the Maven project description (POM file) in the base of the OTP repository. This step can take a long time because it involves downloading a lot of JAR files.</p> <p>When running your local copy of the OTP source within an IDE, all command line switches and configuration options will be identical to the ones used when running the OTP JAR from the command line (as described in the OpenTripPlanner Basic Tutorial and configuration reference). The only difference is that you need to manually specify the main class. When you run a JAR from the command line, the JVM automatically knows which class contains the entry point into the program (the <code>main</code> function), but in IDEs you must create a \"run configuration\".</p> <p>Both IntelliJ and Eclipse have \"run\" menus, from which you can select an option to edit the run configurations. You want to create a configuration for a Java Application, specifying the main class <code>org.opentripplanner.standalone.OTPMain</code>. Unlike on the command line, the arguments to the JVM and to the main class you are running are specified separately. In the field for the VM options you'll want to put your maximum memory parameter (<code>-Xmx2G</code>, or whatever limit you want to place on JVM memory usage). The rest of the parameters to OTP itself will go in a different field with a name like \"program arguments\".</p>"},{"location":"Developers-Guide/#contributing-to-the-project","title":"Contributing to the project","text":"<p>OpenTripPlanner is a community based open source project, and we welcome all who wish to contribute. There are several ways to get involved:</p> <ul> <li> <p>Join the Gitter chat room and the    user mailing list.</p> </li> <li> <p>Fix typos and improve the documentation within the <code>/docs</code> directory of the project (details   below).</p> </li> <li> <p>File a bug or new feature request.</p> </li> <li> <p>Create pull requests citing the relevant issue.</p> </li> <li> <p>Join developer meetings hosted twice a week. Check the specific times and URLs    on this page</p> </li> </ul>"},{"location":"Developers-Guide/#branches-and-branch-protection","title":"Branches and Branch Protection","text":"<p>As of August 2022, we work on OTP 2.x and are using a Git branching model derived from  Gitflow. All development will occur on the <code>dev-2.x</code> branch. Only release commits setting the Maven artifact version to a non-snapshot number should be pushed to the <code>master</code> branch of OTP. All other changes to master should result  from fast-forward merges of a Github pull request from the <code>dev-2.x</code> branch. In turn, all changes  to <code>dev-2.x</code> should result from a fast-forward merge of a Github pull request for a single feature,  fix, or other change. These pull requests are subject to code review. We require two pull request  approvals from developers part of the OTP Review Team. These developers act on behalf of the  leadership committee members. The reviewers should be from two different organizations. We also  have validation rules ensuring that the code compiles and all tests pass before pull requests can  be merged.</p> <p>The <code>dev-1.x</code> exist for patching OTP version 1.x, but with few people to do the reviews, very few PRs are accepted. We recommend getting in touch with the community before you spend time on making  a PR.</p>"},{"location":"Developers-Guide/#issues","title":"Issues","text":"<p>If no ticket exists for the feature or bug your code implements or fixes, you should create a new ticket prior to checking in, or ideally even prior to your development work since this provides a place to carry out implementation discussions (in the comments). The created issue should be referenced in a pull request. For really minor and uncontroversial pull requests, it is ok to not create an issue.</p>"},{"location":"Developers-Guide/#unit-tests-using-real-osm-data","title":"Unit tests using real OSM data","text":"<p>Sometimes it is useful to build a graph from actual OSM or GTFS data. Since building these graphs in a test can be quite slow they will be accepted in pull requests only if they conform to certain standards:</p> <ol> <li> <p>Use the smallest possible regional extract - the OSM file should not contain more than a few    hundred ways. Use <code>osmium-extract</code> to cut down a larger OSM file into a tiny subset of it.</p> </li> <li> <p>Strip out any unneeded information by using the <code>osmium filter-tags</code> as describe    in Preparing OSM</p> </li> </ol>"},{"location":"Developers-Guide/#code-comments","title":"Code Comments","text":"<p>As a matter of policy, all new methods, classes, and fields should include comments explaining what they are for and any other pertinent information. For Java code, the comments should use the JavaDoc conventions. It is best to provide comments that not only explain what you did but also why you did it while providing some context. Please avoid including trivial Javadoc or the empty Javadoc stubs added by IDEs, such as <code>@param</code> annotations with no description.</p>"},{"location":"Developers-Guide/#itinerary-and-api-snapshot-tests","title":"Itinerary and API Snapshot Tests","text":"<p>To test the itinerary generation, and the API there are snapshot test which save the result of the requests as <code>*.snap</code> JSON-like files. These are stored in git so that it is possible to compare to the expected result when running the tests.</p> <p>If the snapshots need to be recreated than running <code>mvn clean -Pclean-test-snapshots</code> will remove the existing <code>*.snap</code> files so that the next time the tests are run the snapshots will be recreated. The updated files may be committed after checking that the changes in the files are expected.</p>"},{"location":"Developers-Guide/#documentation","title":"Documentation","text":"<p>OTP documentation is included directly in the OpenTripPlanner repository. This allows version control to be applied to documentation as well as program source code. All pull requests that change how OTP is used or configured should include changes to the documentation alongside code modifications.</p> <p>The documentation files are in Markdown format and are in the <code>/docs</code> directory under the root of the project. On every push to the <code>dev-2.x</code> branch the documentation will be rebuilt and deployed as static pages to our subdomain of Github Pages.  MkDocs is a Python program and should run on any major platform.  See http://www.mkdocs.org/ for information on how to install it and  how to generate a live local preview of the documentation while you're writing it.</p> <p>In short:</p> <pre><code>$ pip install -r docs/requirements.txt\n$ mkdocs serve\n</code></pre> <p>The OTP GTFS GraphQL API documentation is available online at </p> <p>https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/</p> <p>You can also use the interactive GraphQL API client that is built into every instance at</p> <p>http://localhost:8080/graphiql</p>"},{"location":"Developers-Guide/#debug-layers","title":"Debug layers","text":"<p>Adding new renderer is very easy. You just need to create new class (preferably in <code>org.opentripplanner.inspector</code> package) which implements EdgeVertexRenderer. It is best if class name ends with Rendered. To implement this interface you need to write three functions <code>renderEdge</code>, <code>renderVertex</code> and <code>getName</code>. Both render functions accepts <code>EdgeVisualAttributes</code> object in which label of edge/vertex and color can be set. And both return <code>true</code> if edge/vertex should be rendered and <code>false</code> otherwise. <code>getName</code> function should return short descriptive name of the class and will be shown in layer chooser.</p> <p>For examples how to write renderers you can look into example renderers which are all in <code>org.opentripplanner.inspector</code> package.</p> <p>After your class is written you only need to add it to TileRenderManager:</p> <pre><code>//This is how Wheelchair renderer is added\nrenderers.put(\"wheelchair\", new EdgeVertexTileRenderer(new WheelchairEdgeRenderer()));\n</code></pre> <p><code>wheelchair</code> is internal layer key and should consist of a-zA-Z and -.</p> <p>By default all the tiles have cache headers to cache them for one hour. This can become problematic if you are changing renderers a lot. To disable this change <code>GraphInspectorTileResource</code>:</p> <pre><code>//This lines\nCacheControl cc = new CacheControl();\ncc.setMaxAge(3600);\ncc.setNoCache(false);\n\n//to this:\nCacheControl cc = new CacheControl();\ncc.setNoCache(true);\n</code></pre>"},{"location":"Developers-Guide/#date-format","title":"Date format","text":"<p>Please use only ISO 8601 date format (YYYY-MM-DD) in documentation, comments, and throughout the project. This avoids the ambiguity that can result from differing local interpretations of date formats like 02/01/12.</p>"},{"location":"Developers-Guide/#code-style","title":"Code style","text":"<p>The OTP code style is described on a separate style guide page.</p>"},{"location":"Developers-Guide/#code-conventions-and-architecture","title":"Code conventions and architecture","text":"<p>The architecture  and code conventions are only available on GitHub, not in the project documentation. These documents contain relative  links to code so, they are a bit easier to maintain that way. The target audience is also active  OTP developers that have the code checked out locally.</p>"},{"location":"Developers-Guide/#continuous-integration","title":"Continuous Integration","text":"<p>The OpenTripPlanner project uses the Github actions continuous integration system . Any time a change is pushed to the main OpenTripPlanner repository on GitHub or to an open pull request, Github actions will compile and test the new code, providing feedback on the stability of the build.</p>"},{"location":"Developers-Guide/#changelog-workflow","title":"Changelog workflow","text":"<p>The changelog file is generated from the pull-request(PR) title using the changelog workflow . The workflow runs after the PR is merged, and it changes, commits and pushes the Changelog.md. A secret personal access token is used to bypass the \"Require PR with 2 approvals\" rule. To exclude a PR from the changelog add the label <code>skip changelog</code> to the PR.</p>"},{"location":"Developers-Guide/#how-to-update-the-changelog_token","title":"How-to update the CHANGELOG_TOKEN","text":"<p>The <code>CHANGELOG_TOKEN</code> is used by the changelog workflow. It contains a Personal Access Token. The token must be generated by a Repository Owner and have the following rights (Settings / Developer settings / Personal access tokens):</p> <p></p>"},{"location":"Developers-Guide/#release-process","title":"Release Process","text":"<p>New releases can be found on GitHub.  Releases are performed off the master branch, and are tagged with git annotated tags.</p> <p>OpenTripPlanner is currently configured such that builds including releases upload JAR files to GitHub Packages. This is not the most convenient place for end users to find and download the files. Therefore we also attach a stand-alone \"shaded\" JAR to the GitHub tag/release page, and have historically also uploaded Maven artifacts to Maven Central including compiled and source code JARs as well as the \"shaded\" JAR containing all dependencies, allowing stand-alone usage. This release process is handled by the Sonatype Nexus Staging plugin, which is no longer configured in the OpenTripPlanner POM. This step currently requires making a few significant manual modifications to the POM.</p> <p>We no longer trigger deployment of artifacts to Maven Central or deployment of REST API documentation to AWS automatically in our build scripts (GitHub Actions). These steps are prone to failure and require storing a lot of infrequently used secret information in the repo and environment variables on GitHub. Our releases are currently not very frequent so we just carry out these steps manually by following the checklist. We aim to make a release every 6 months.</p> <p>Use the Release Checklist to perform the release.</p>"},{"location":"Getting-OTP/","title":"Getting OpenTripPlanner","text":""},{"location":"Getting-OTP/#pre-built-jars","title":"Pre-built JARs","text":"<p>OpenTripPlanner is distributed as a single stand-alone runnable JAR file. We create a tag and release page on GitHub for each release version, and also deploy them to the Maven Central repository. You can go to the release pages on GitHub or the OTP directory at Maven Central, navigate to the highest version number, and download the file whose name ends with <code>shaded.jar</code>.</p> <p>Note that version numbers like <code>v2.1.0-rc1</code> or <code>v2.4.0-SNAPSHOT</code> refer to development builds _ before_ the release version <code>v2.4.0</code>. The existence of a build <code>vX.Y.Z-SNAPSHOT</code> does not mean that <code>vX.Y.Z</code> has been released yet.</p> <p>We use the Github Actions CI system to build OTP every time a change is made. You can find the JARs resulting from those builds in the Github Packages repository . It can be harder to find the specific version you're looking for here, so we recommend using the release pages or Maven Central as described above.</p>"},{"location":"Getting-OTP/#building-from-source","title":"Building from Source","text":"<p>You may also choose to build OTP from its source code. If you will be modifying OTP you will need to know how to rebuild it (though your IDE may take care of this build cycle for you). If you have the right software installed, building OTP locally from its source code is not particularly difficult. You should only need the following software:</p> <ul> <li> <p>Git, a version control system</p> </li> <li> <p>Java Development Kit, preferably version 21</p> </li> <li> <p>Maven, a build and dependency management system</p> </li> </ul> <p>You will also need a reliable internet connection so Maven can fetch all of OTP's dependencies (the libraries it uses).</p> <p>Once you have these packages installed, create and/or switch to the directory where you will keep your Git repositories and make a local copy of the OTP source code:</p> <pre><code>mkdir git\ncd git\ngit clone git@github.com:opentripplanner/OpenTripPlanner.git\n</code></pre> <p>Then change to the newly cloned OpenTripPlanner repository directory and start a build:</p> <pre><code>cd OpenTripPlanner\nmvn clean package\n</code></pre> <p>Maven should then be able to download all the libraries and other dependencies necessary to compile OTP. If all goes well you should see a success message like the following:</p> <pre><code>[INFO] ------------------------------------------------------------------------\n[INFO] BUILD SUCCESS\n[INFO] ------------------------------------------------------------------------\n[INFO] Total time: 42.164s\n[INFO] Finished at: Tue Feb 18 19:35:48 CET 2014\n[INFO] Final Memory: 88M/695M\n[INFO] ------------------------------------------------------------------------\n</code></pre> <p>This build process should produce a JAR file called <code>otp-x.y.z-shaded.jar</code> in the <code>target/</code> directory which contains all the compiled OTP classes and their dependencies (the external libraries they use). The shell script called 'otp' in the root of the cloned repository will start the main class of that JAR file under a Java virtual machine, so after the Maven build completes you should be able to run <code>./otp --help</code> and see an OTP help message including command line options. Due to the way Maven works, this script is not executable by default, so you will need to do <code>chmod u+x ./otp</code> before you run it to mark it as executable.</p> <p>The words \"clean package\" are the build steps you want to run. You're telling maven to clean up any extraneous junk in the directory, then perform all the build steps, including compilation, up to and including \"package\", which bundles the compiled program into a single JAR file for distribution.</p> <p>If you have just cloned OTP you will be working with the default \"master\" branch, where most active development occurs. This is not the most stable or deployment-ready code available. To avoid newly minted bugs or undocumented behavior, you can use Git to check out a specific release (tag or branch) of OTP to work with. The Maven build also includes many time-consuming integration tests. When working with a stable release of OTP, you may want to turn them off by adding the switch: <code>-DskipTests</code>.</p> <p>For example, you could do the following:</p> <pre><code>cd OpenTripPlanner\ngit checkout v2.4.0\ngit clean -df\nmvn clean package -DskipTests\n</code></pre> <p>Please note that the build process creates two distinct versions of the OTP JAR file. The one ending in <code>-shaded.jar</code> is much bigger because it contains copies of all the external libraries that OTP uses. It serves as a stand-alone runnable distribution of OTP. The one with a version number but without the word <code>shaded</code> contains only OTP itself, without any external dependencies. This JAR is useful when OTP is included as a component in some other project, where we want the dependency management system to gather all the external libraries automatically.</p>"},{"location":"Getting-OTP/#maven-repository","title":"Maven Repository","text":"<p>OpenTripPlanner is a Maven project. Maven is a combined build and dependency management system: it fetches all the external libraries that OTP uses, runs all the commands to compile the OTP source code into runnable form, performs tests, and can then deploy the final \"artifact\" (the runnable JAR file) to the Maven repository, from which it can be automatically included in other Java projects.</p> <p>This repository is machine-readable (by Maven or other build systems) and also provides human readable directory listings via HTTP. You can fetch an OTP JAR from this repository by constructing the proper URL for the release you want. For example, release 2.4.0 will be found at <code>https://repo1.maven.org/maven2/org/opentripplanner/otp/2.4.0/otp-2.4.0-shaded.jar</code>.</p> <p>To make use of OTP in another Maven project, you must specify it as a dependency in that project's <code>pom.xml</code>:</p> <pre><code>&lt;dependency&gt;\n  &lt;groupId&gt;org.opentripplanner&lt;/groupId&gt;\n  &lt;artifactId&gt;otp&lt;/artifactId&gt;\n  &lt;version&gt;2.4.0&lt;/version&gt;\n&lt;/dependency&gt;\n</code></pre>"},{"location":"Governance/","title":"Project Governance","text":"<p>OpenTripPlanner is a member project of the Software Freedom Conservancy. Development of OpenTripPlanner is managed by a Project Leadership Committee (PLC) which makes decisions by simple majority vote. The current members of this committee are (in alphabetical order):</p> Name Affiliation Sean Barbeau University of South Florida Sheldon Brown Cambridge Systematics Andrew Byrd Conveyal Thomas Craig CALACT ITS4US Drew Dara-Abrams Interline David Emory IBI Group Thomas Gran Entur (Norway) Tuukka Hastrup Transpordiamet (Estonia) Joel Lappalainan Digitransit (Finland) Frank Purcell TriMet (Portland, Oregon) David Turner ex-OpenPlans Anders Varmy Skanetrafiken Leonard Ehrenfried Independent contractor <p>The PLC holds a quarterly video conference on the first Tuesday of June, September, December, and March. An agenda is prepared as a collaborative document in advance of each quarterly meeting. These meetings are held at 8AM US Pacific time to accommodate members in the US Pacific, US Eastern, and Central European time zones.</p> <p>We take care to avoid a governance system that is too conceptual or process-heavy. The main goal is to have regular agenda-driven meetings that yield clear decisions and action items assigned to specific people. The committee should ideally be composed of active, professional contributors to the OpenTripPlanner project, including representatives of organizations that host official public deployments of OTP.</p> <p>We enfore a policy on the review and merging of new changes to the OTP system, guided by a roadmap maintained by the committee. All changes must be reviewed and approved by at least two people from two different organizations. The list of approved reviewers is the PLC Github group, visible here https://github.com/orgs/opentripplanner/teams/plc/members</p>"},{"location":"History/","title":"OpenTripPlanner Project History","text":""},{"location":"History/#opentripplanner-1","title":"OpenTripPlanner 1","text":"<p>OpenTripPlanner was seeded by Portland, Oregon's transit agency TriMet with a Regional Travel Options grant and opened with a 3-day Kick-Off Workshop in July of 2009 bringing together transit agencies and the authors of the major open source transit passenger information software of the day: David Emory of FivePoints, Brian Ferris of OneBusAway, and Brandon Martin-Anderson of Graphserver. From 2009 through 2012, development was coordinated by New York nonprofit OpenPlans. In 2011 a second workshop was held to mark the end of the first phase of development. TriMet's 2009-2011 OTP Final Report summarizes progress at that point.</p> <p>The project has since grown to encompass a global community of users and developers. By early 2013, OpenTripPlanner had become the primary trip planning software used by TriMet in the Portland regional trip planner and was backing several popular mobile applications. Public-facing OpenTripPlanner instances were available in at least ten countries throughout the world. At this point the OpenPlans transportation software team became the independent consultancy Conveyal. The original OpenTripPlanner development team from OpenPlans still actively participates in programming, design, and community coordination via the mailing list and their roles on the OTP Project Leadership Committee.</p> <p>In summer of 2013, the OpenTripPlanner project was accepted for membership in the Software Freedom Conservancy (SFC). SFC handles the legal and financial details common to many open source projects.</p> <p>In 2013-2014 OpenTripPlanner was a focal point in the Dutch Transport Ministry's Beter Benutten Multimodale Reisinformatie (Better Utilization: Multimodal Travel Information) project which encouraged investment in trip planning platforms and services. Five companies worked together to improve OpenTripPlanner performance in large regional transport networks and add support for streaming real-time data, making itineraries reflect service modifications and delays only seconds after vehicles report their positions. Another consortium embarked on a full rewrite of the trip planning core called RRRR (or R4), a proof of concept validating extremely efficient routing techniques and serving as an early prototype for OTP2.</p> <p>In the fall of 2014, Arlington, Virginia launched a new commute planning site for the Washington, DC metropolitan area, depending on OpenTripPlanner to weigh the costs and benefits of various travel options. In 2015 the New York State department of transportation's 511 transit trip planner began using OTP to provide itineraries for public transit systems throughout the state from a single unified OTP instance. Starting in early 2016, the regional transport authorities of Helsinki, Finland (HSL) and Oslo, Norway (Ruter) began using a completely open source passenger information system based on OpenTripPlanner. National-scale OpenTripPlanner instances were also created in Finland and Norway.</p> <p>After seven years of hard work and almost 10,000 commits from over 100 contributors around the world, OTP version 1.0 was released on 9 September 2016.</p>"},{"location":"History/#opentripplanner-2","title":"OpenTripPlanner 2","text":"<p>The OTP community has a long history with round-based routing algorithms. FivePoints, one of the predecessor projects to OTP, used a round-based method several years before the now-familiar Raptor algorithm was published in an influential paper . OpenPlans carried out experiments with routing innovations like Raptor and contraction hierarchies as they emerged in the academic literature. Research and development work on OTP scalability has focused on round-based tabular approaches since the MMRI pre-commercial procurement projects of 2013-2014. Conveyal built its high-performance transportation network analysis system around its R5 router. So in strategy discussions, the expected technical direction was clear.</p> <p>In the second quarter of 2018, Ruter and Entur took the lead on finally integrating a new round-based transit routing engine inspired by R5 into OTP. They also began adding support for importing EU-standard Netex data, making it possible for passenger information services in Europe to achieve regulatory compliance with a fully open source software stack. In June 2018, at the first OTP international summit hosted by Cambridge Systematics in Boston, the project leadership committee officially approved this roadmap toward OTP2.</p> <p>In April of 2019, the second OTP international summit was hosted by Entur in Oslo. Encouraged by the crowd of participants from across the Nordic countries and North America, work on OTP2 continued unabated through 2019, 2020, and 2021 with twice-weekly videoconferences bringing together software developers from across the world. Videos of the full April 2019 OTP summit and the October 2019 OTP webinar are available.</p> <p>OTP2 went into feature freeze in September 2020, and the 2.0 release occurred at the end of November 2020. OTP2 is now seeing production use for a subset of requests in several national-scale trip planners. The project leadership committee is exploring the creation of an OTP1 working group to ensure follow-up maintenance of the final version of OTP1.</p>"},{"location":"In-Station-Navigation/","title":"In-station navigation","text":"<p>OTP offers a variety of ways to produce precise walking instructions for walking inside a station or between transit stops.</p>"},{"location":"In-Station-Navigation/#osm-generated-navigation","title":"OSM generated navigation","text":"<p>In the most common case, the walking instructions for reaching a transit stop are generated from the available OSM data. For this reason it is important that the coordinate of the stop is as close as  possible to where the passenger is expected to wait for the vehicle, not where the vehicle will stop.</p> <p>It is therefore a good idea to place the stop coordinates at a bus shelter or railway platform rather than at the middle of the road or the railway tracks.</p> <p>Of course you also want the data in OSM as precise as possible: data for railway platforms, stairs, tunnels and other infrastructure help OTP to generate good walking instructions.</p>"},{"location":"In-Station-Navigation/#example-exiting-a-railway-platform","title":"Example: exiting a railway platform","text":"<p>The train arrives in a railway station in Stuttgart (green line), the passenger alights and is instructed (grey line) to walk along the platform, up the stairs and across a bridge to continue to  their final destination.</p> <p></p>"},{"location":"In-Station-Navigation/#boarding-locations","title":"Boarding locations","text":"<p>If your stop coordinates are not very well-placed, OTP may direct passengers to the wrong waiting location or offer incorrect transfer paths and time. As this a common problem and stop coordinates  can be hard to change due to upstream systems, OTP offers a  way to derive the waiting coordinates from OSM data.</p> <p>Even if your stop coordinates are good, some stations are underground and to get correct walking  instructions it's required to use this feature so that correct instructions for using entrances and stairs are generated.</p>"},{"location":"In-Station-Navigation/#example-walking-downstairs-to-underground-stations","title":"Example: walking downstairs to underground stations","text":"<p>This shows an underground subway station in Stuttgart which can only be reached by using entrances at either end walking down to the platform via a series of stairs and walkways. OTP can only generate these detailed instructions because the platform has a tag <code>ref:IFOPT</code> which identifies it in the German national stop register.</p> <p></p>"},{"location":"In-Station-Navigation/#gtfs-pathways","title":"GTFS pathways","text":"<p>If your GTFS input file contains pathways this will override the OSM-generated instructions. It is therefore important that the pathways contain as much precision as possible.</p> <p>One advantage that pathways offer is the possibility to add information like \"follow signs for X\" which OTP adds to the textual turn-by-turn instructions.</p>"},{"location":"In-Station-Navigation/#example-transferring-at-sudkreuz","title":"Example: Transferring at S\u00fcdkreuz","text":"<p>Here the pathways don't offer a lot of precision: In a railway hub in Berlin  there are suboptimal instructions on how to move from one platform to another because the pathways  only contain rudimentary information about how to move inside the station. (The red lines represent  train lines with the grey line showing the walking path.)</p> <p></p>"},{"location":"In-Station-Navigation/#transfers","title":"Transfers","text":"<p>The above precedence rules of </p> <ul> <li>GTFS pathways, if it exists</li> <li>then OSM data </li> </ul> <p>also apply when computing transfers from one stop to another.</p>"},{"location":"In-Station-Navigation/#example-transferring-from-tram-to-rail-at-oslo-central","title":"Example: transferring from tram to rail at Oslo Central","text":"<p>Here the passenger arrives in a local tram (blue line) near the main station in Oslo. They are  instructed (grey line) to walk into the station right onto the correct platform and leave on a long-distance train (red line).</p> <p></p>"},{"location":"In-Station-Navigation/#example-transferring-between-platforms-at-oslo-central","title":"Example: transferring between platforms at Oslo Central","text":"<p>This example instructs the passenger to get off a train, then walking down the stairs and via a tunnel to another platform.</p> <p></p>"},{"location":"In-Station-Navigation/#transfer-time","title":"Transfer time","text":"<p>The routing engine calculates the time to move from one stop to another by how long it thinks the walking takes based on the navigation instructions outlined above. So, if OTP thinks that it takes 5 minutes to walk from platform 1 to platform 8, then the routing algorithm will not suggest a transit connection that departs less than 5 minutes after arriving at platform 1.</p> <p>However, how fast the passenger is assumed to walk is controllable through the walk speed parameter. This can be configured per installation or passed as an API call parameter.</p> <p>The parameters <code>alightSlack</code>, <code>transferSlack</code>  and <code>boardSlack</code> also allow you to define extra buffer time for transferring.</p> <p>GTFS minimum transfer times  are also supported but generally not advised. It is preferable to micromap your stations and improve the stop coordinates rather than force specific transfer times by adding this data.</p>"},{"location":"In-Station-Navigation/#common-data-errors","title":"Common data errors","text":"<ul> <li>Stop coordinates not where passengers are expected to board</li> <li>All stops/platforms in a railway station having the same coordinates</li> <li>OSM platforms not connected to the street network</li> </ul>"},{"location":"IslandPruning/","title":"Street graph pruning","text":"<p>A street graph created from OpenStreetMap data has sections which cannot be reached with some or all traverse modes. For example, true geographic islands are usually disconnected from the main graph. The street network of such islands should be kept so that routing within the island or continuing from a ferry stop on it works as expected. Even a tiny street network connected to a ferry stop improves routing to an island a lot, because coordinate based itinerary searches find something to project onto.</p> <p> Removing a small subgraph from an island causes poor routing. A ferry stop on the island links directly to mainland.</p> <p>Disconnected parts can also represent a strictly forbidden area, such as connections within an industrial unit, roads of a military base or another region which cannot and should not be accessed when using door to door routing of a public transit journey planner. Existence of such graph sections is harmful, because start and end points of an itinerary search request may accidentally get projected to such a private pathway. As a result, a user does not receive any itineraries and gets no explanation for the routing problem.</p> <p>In most cases, connectivity problems are caused by incorrect modeling of OSM data. The number of such errors is usually very large, and the problem cannot be solved by simply fixing OSM data as soon as errors are detected - the OSM street network in Finland contains over 10 000 detected walk connectivity issues! An algorithmic solution is needed to address a problem of such magnitude.</p> <p> A typical error: bus platforms are not connected to the street network at all</p> <p>A simple and efficient solution is to detect harmful disconnected parts and remove them from the street graph. Routing then uses the properly connected part of the graph and finds itineraries. As a side effect, the start point of an itinerary search which departs from the removed graph projects at the border of it, which usually is good enough. Transfers may include strange teleportation and unexpected walking, as public transit stops may link to somewhat remote streets, but at least transfers will work.</p> <p> A disconnected railway platform breaks routing. Traveler is guided to take a round trip around the country although there is one hour direct train connection.</p>"},{"location":"IslandPruning/#access-restriction-islands","title":"Access restriction islands","text":"<p>One common reason for OSM connectivity problems is access tagging. It is perfectly OK to tag a front yard of a private residence using <code>access=private</code> or <code>access=destination</code> tags, so that strangers are not guided to travel through the private area. Routing will still use the private streets if a trip starts or ends there - only pass through traversal gets prohibited. However, sometimes OSM contributors try to block the traffic by tagging only entrance segments of streets leading to a restricted area. Unfortunately this totally prevents access to the interior part of the network, because OTP interprets it as pass through traffic. Pruning handles such problems by converting streets behind an access restriction to have the same access properties.</p> <p> Some regular (gray colored) streets are blocked behind access restricted (red colored) connections. Walk routing to them fails because it would be considered as pass through traffic. The image on the right shows that pruning added walk nothrough restricition to those streets, and routing works again.</p>"},{"location":"IslandPruning/#pruning-algorithm","title":"Pruning algorithm","text":"<p>Pruning analyses the three traverse modes - walk, bike and car - separately. For example, a resting area by a motorway may include some walking paths, but the only way to get there is to use car. Therefore, it represents a disconnected 'island' when considering the walk mode. Pruning does not erase disconnected graph geometry as long as it can be reached using any of the traverse modes. Instead, pruning removes traversal permission for each disconnected mode from the island.</p> <p>Pruning uses four parameters and some heuristics to decide if a disconnected sub graph is a real island to be retained, or a harmful data error:</p> <ul> <li><code>islandWithStopsMaxSize</code> defines the threshold for graph islands, which include public transit stops. All stop islands which have less graph edges than this get pruned. Default value is 2.  </li> <li><code>islandWithoutStopsMaxSize</code> defines the threshold for graph islands, which do not have public transit stops. All stopless islands which have less edges than this get pruned. Defaults to 10.  </li> <li><code>adaptivePruningFactor</code> defines the maximal value for a distance based multiplier for the two thresholds defined above (default value 20).  </li> <li><code>adaptivePruningDistance</code> defines the search radius as meters when estimating distance between graphs (default value 250).  </li> </ul> <p>Pruning thresholds are increased adaptively so that if the distance between an examined sub graph and the other graph is zero, the threshold is multiplied by a full adaptivePruningFactor value. The idea is that if a sub graph is closely entangled with another graph, it is likely to be a harmful modeling error, not a remote place like a true geographic island. If the distance is more than <code>adaptivePruningDistance</code>, the actual nominal threshold values will be used. So, adaptiveness prunes much larger disconnected graphs in places where they have potential to cause routing errors.</p> <p>Adaptive pruning can be disabled by setting adaptivePruningFactor to 1. Constant pruning thresholds will then be applied.</p> <p>Pruning also examines the transport modes of graph islands with stops. If land transportation modes are not found (only ferry or no modes at all), the graph is retained. Unknown mode is accepted for island status, because ferry lines often operate only during warm seasons.</p>"},{"location":"IslandPruning/#some-examples","title":"Some examples","text":"<p> A disconnected small graph should be preserved, if it is located on a real island.</p> <p> A street section has tags which prevent traversal on it, and OTP has removed it from the graph. Some isolated streets remain left, and a public transit stop gets linked to them. Routing cannot use the stop unless traveler is leaving from or going to the small isolated sub graph. Isolated streets cannot be reached by walking either. After pruning, the stop is projected to the main graph. Transfers at the stop work fine. Itineraries can guide traveler quite close to the removed streets.</p> <p> The platform structure of a bus station is disconnected from the other graph. Most bus traffic of a medium size city becomes unusable. Despite of the complexity of the sub graph (54 edges and 21 stops), it must be removed in pruning, so that stops get linked to reachable and well connected streets.</p>"},{"location":"IslandPruning/#issue-reports","title":"Issue reports","text":"<p>Pruning creates a <code>GraphIsland</code> issue every time it prunes a sub graph. Issues may show up as duplicates, because pruning is run for each traverse mode.</p> <p>A <code>PrunedStopIsland</code> issue is added for every pruned graph island which has stops linked to it. Such islands are particularly harmful, because they are places where public transit transfers take place and hence are frequently used. Pruned stop island issues should be studied frequently and underlying OSM errors fixed, especially if the island has many stops and edges (i.e it is most likely a public transit station, see station island example above).</p>"},{"location":"Localization/","title":"Localization","text":"<p>NOTE: This documentation pertains to the client included in the main OTP repository. THIS BUILT-IN OTP CLIENT IS PROVIDED FOR TEST AND DEBUGGING PURPOSES. IT IS NOT MEANT FOR PRODUCTION USE.</p> <p>This page contains instructions for both developers and translators on how to make the OTP interface usable by people who speak different languages. Developers will need to take certain steps to mark translatable strings within the source code. Translators will need to edit specific files within the project to create or revise the translation for their language.</p> <p>In OTP we use gettext for localization, for the following reasons:</p> <ul> <li>Plural suport</li> <li>Context support</li> <li>Automatic extraction of translatable strings from source code</li> <li>Translator comments   support</li> <li>Source references (we can see where each translated string is used in the source code)</li> </ul> <p>In the Javascript UI the i18next library is used.</p> <p>Three types of files are used in the OTP localization process:</p> <ul> <li>The <code>.pot</code> file is the message template. It is a starting point for creating new <code>.po</code> files.</li> <li><code>.po</code> files are created and edited by translators based on the <code>.pot</code> file.</li> <li><code>.json</code> files are generated from the <code>.po</code> files for each language.</li> <li><code>.js</code> files are localization configuration files which specify units and time/date formats.</li> </ul> <p>Only the <code>.po</code> and <code>.js</code> files are directly edited. The <code>.pot</code> file is created from an automated analysis of annotated source code. The <code>.json</code> files are also automatically generated as an easy way for the Javascript UI to consume the contents of the <code>.po</code> files.</p> <p>All translation files are in the directory <code>/src/client/i18n</code>.</p>"},{"location":"Localization/#for-software-developers-adding-new-strings","title":"For Software Developers: Adding New Strings","text":"<p>When you add a string to Javascript source that will be seen by the end user, wherever that string is referenced you should surround it with a call to a special function. The name of the function depends on what kind of string it is:</p> <ul> <li>basic string: <code>_tr('string', parameters)</code></li> <li>basic string with context: <code>ngettext('context', 'string')</code></li> <li>string with plural: <code>ngettext('singular', 'plural', quantity)</code></li> <li>string with plural and context: <code>npgettext('context', 'singular', 'plural', quantity)</code></li> </ul> <p>For more detail, see Sprintf parameters.</p> <p>A \"context\" is any string (preferably short and without whitespace) that is used to disambiguate the translation of the main string. It is used when developers get input from translators that some string should be translated in different ways in different parts of the program. Each of those distinct places will be assigned a different context string.</p> <p>When you add strings to the source code, if you think that translators might not understand how the string is used or what parameters it requires, add translator comments like this:</p> <pre><code>//TRANSLATORS: Start: location at [time date] (Used in print itinerary  \n//when do you start your trip)                                          \nhtml += '&lt;h3&gt;' + _tr('Start: %s at %s', this.getStartLocationStr(), this.getStartTimeStr()) + '&lt;/h3&gt;';\n</code></pre> <p>Translator comments must always start with <code>TRANSLATORS:</code> and must be in the line immediately before translated string. Otherwise they won't be extracted together with the string.</p>"},{"location":"Localization/#examples","title":"Examples:","text":""},{"location":"Localization/#basic-translated-string","title":"Basic translated string","text":"<pre><code>//TRANSLATORS: Board Public transit route name (agency name     \n//Stop ID ) start time                                          \nhtml += '&lt;li&gt;&lt;b&gt;' + _tr('Board') + '&lt;/b&gt;: ' + leg.from.name + ' (' + leg.from.stopId.agencyId + ' Stop ID #' +\n\n//With named sprintf parameters (our preferred option)\n\n//TRANSLATORS: Start: location at [time date] (Used in print itinerary  \n//when do you start your trip)                                          \nhtml += '&lt;h3&gt;' + _tr('Start: %(location)s at %(time_date)s', {\n    'location': this.getStartLocationStr(),\n    'time_date': this.getStartTimeStr()\n}) + '&lt;/h3&gt;';\n\n//With positional sprintf parameters (to be avoided because word order changes between languages)\nhtml += '&lt;h3&gt;' + _tr('End: %1$s at %2$s', this.getEndLocationStr(), this.getEndTimeStr()) + '&lt;/h3&gt;';\n</code></pre>"},{"location":"Localization/#normal-string-with-context","title":"Normal string with context","text":"<pre><code> if (leg.headsign) html += pgettext(\"bus_direction\", \" to \") + leg.headsign;\n\n//same string could be different translation\n//TRANSLATORS: [distance] to [name of destination]              \nhtml += \" \" + otp.util.Itin.distanceString(leg.distance) + pgettext(\"direction\", \" to \") + leg.to.name;\n</code></pre>"},{"location":"Localization/#plural-strings","title":"Plural strings","text":"<pre><code>//TRANSLATORS: widget title                                             \nthis.setTitle(ngettext(\"%d Itinerary Returned\", \"%d Itineraries Returned\", this.itineraries.length));\n</code></pre> <p>If you add new strings to the source code, it is good practice to also update the translation template and the translations but it is not mandatory (these can be updated later). It is also recommended to include \"i18n string change\" in the commit message.</p>"},{"location":"Localization/#updating-translations","title":"Updating translations","text":"<p>Translations are updated with the help of Babel and i18next-conv (xgettext doesn't yet have great Javascript support).</p> <p>Babel is used to extract strings from the Javascript source code into the shared <code>.POT</code> translation template, and also for updating the existing <code>.PO</code> language translations when new strings are introduced in the template. i18next-conv is used to convert the <code>.PO</code> translation files for the individual languages to <code>.json</code> files which are used by the Javascript translation library.</p>"},{"location":"Localization/#installing-babel","title":"Installing Babel","text":"<p>You can install it from your operating system's package repository (if available) or you can use virtualenv.</p> <ol> <li>Install virtualenv (This depends on your operating system)</li> <li>Create virtualenv with name .venv in directory where src and other files resides (Root    OpenTripPlanner directory). <code>virtualenv2 .venv</code>(python 2) or <code>python3 -m venv .venv</code> (python 3)</li> <li>Use virtualenv <code>source .venv/bin/activate</code></li> <li>Install babel <code>pip install babel</code></li> </ol> <p>If you didn't install babel from virtualenv in root OpenTripPlanner directory you have to add path to babel in Makefile. change <code>PYBABEL</code> variable to path to pybabel.</p>"},{"location":"Localization/#installing-i18next-conv","title":"Installing i18next-conv","text":"<p>i18next-conv requires nodejs.</p> <p>Once you have NodeJS installed, use <code>npm install i18next-conv</code> to install i18next-conv in the same directory where you created virtualenv.</p>"},{"location":"Localization/#updating-the-pot-template","title":"Updating the <code>.pot</code> Template","text":"<p>In the root of the OTP repo, run <code>make</code>. The commands in the <code>Makefile</code> will extract the translatable strings from the Javascript files and update the translation template <code>messages.pot</code>, as well as the <code>.po</code> translation files for all the different languages.</p> <p>Once this is done, you can translate the new strings in the <code>.po</code> files. After saving the updated <code>.po</code> file, run <code>make update_js</code> to transform to PO files into <code>.json</code>, which is used at runtime by the Javascript translation library. After you rebuild OTP, all new strings should be visible in the UI.</p>"},{"location":"Localization/#for-translators-creating-new-translations","title":"For Translators: Creating New Translations","text":"<p>The following can get a bit technical. If you want to do a translation but don't want to / know how to install all this software, post to the Gitter chat room  stating what language you want to translate, and someone will make you a corresponding <code>.po</code> file.</p>"},{"location":"Localization/#creating-a-new-translation-file","title":"Creating a New Translation File","text":"<p>New <code>.po</code> files are created from the <code>.pot</code> template with the help of <code>msginit</code>, which is run like this: <code>msginit init -l &lt;LAN&gt; -i messages.pot -o &lt;LAN&gt;.po</code>, where <code>&lt;LAN&gt;</code> is a culture code. New <code>.po</code>files can also be created with the help of <code>Poedit</code>. All translation files should be placed in the directory <code>/src/client/i18n</code>.</p> <p>Please use the ISO language code as the culture code (e.g. <code>fr.po</code> for French). We will append country codes in the following limited circumstances:</p> <ul> <li>British versus US English (<code>en_GB.po</code> and <code>en_US.po</code>)</li> <li>Brazilian Portuguese <code>pt_BR.po</code>, as opposed to <code>pt.po</code> for European Portuguese</li> <li>Chinese: <code>zh_TW.po</code> for traditional characters as used in e.g. Taiwan and Hong Kong,   and <code>zh_CN.po</code> for simplified characters as used in mainland China, Singapore, etc.</li> </ul> <p>These conventions are based on the Launchpad Translation page.</p> <p>In Linux you can see the culture codes for all the locales you have installed with the command <code>locale -a</code>. A list of culture codes is also availible here .</p>"},{"location":"Localization/#performing-the-translation","title":"Performing the Translation","text":""},{"location":"Localization/#configuration","title":"Configuration","text":"<p>Copy the locale configuration script <code>English.js</code> from <code>/src/client/js/otp/locale</code> to <code>YourLanguage.js</code> and customize it to your language. Change the name, units, locale_short and datepicker_locale_short values. Translate infoWidgets and localize the time/date formats.</p> <p>Then take the following steps:</p> <ul> <li>Add the culture code to the <code>LANGS</code> variable in the Makefile`</li> <li>Add the new <code>YourLanguage.js</code> to the locales variable in <code>/src/client/js/otp/config.js</code></li> <li>Add a new datepicker translation to <code>/src/client/js/lib/jquery-ui/i18n</code></li> <li>Load the new datepicker translation and <code>YourLanguage.js</code> in <code>/src/client/index.html</code></li> </ul>"},{"location":"Localization/#translating-strings","title":"Translating Strings","text":"<p>For translating the strings themselves, you can use any program that supports gettext files. You can in theory use any text editor, but programs or plugins purpose-built for translating are recommended. Most of them support checking parameter correctness, translation memory, web translating services etc. to make the task easier.</p> <p>Here are some such programs (all free and open source):</p> <ul> <li>Poedit For Linux, Windows, and Mac. Use a version newer then 1.5. This is   the recommended choice for getting started with localization. It supports translation memory and   file context.</li> <li>Web Poedit Usable from within a web browser, you don't have to   install or register</li> <li>Gted A plugin for the Eclipse IDE.</li> <li>Lokalize Runs under KDE on Linux, has some Windows support.   Supports translation memory and file context.</li> <li>Virtaal For Linux, Windows, and beta for Mac.   Supports Google and Microsoft web translation and other translation memory services.</li> </ul> <p>All these programs support setting a string to \"fuzzy\", marking that it needs review etc. in case you translate something but aren't sure of it's correctness. Sometimes those flags are set automatically if the original string was changed and translators must check if the translation is still correct.</p>"},{"location":"Localization/#caveats","title":"Caveats","text":"<p>Be careful when translating that the translated strings have the same format as the original. If spaces appear at the start or end of the strings, they must also appear in the translation. The order of unnamed (positional) parameters may change depending on the target language. You can also leave parameter out of the translation if it is irrelevant in the target language.</p>"},{"location":"Logging/","title":"Logging","text":"<p>OTP uses logback and slj4j as a logging framework. Logging is configured in the <code>logback.xml</code> file inside the OTP jar file. See these frameworks for more documentation on log configuration.</p> <p>For developers, starting OTP using the <code>InteractiveOtpMain</code> is an easy way to configure debug logging.</p> <p>Some loggers useful for debugging.</p> <ul> <li><code>TRANSFERS_EXPORT</code>: Dump transfers to transfers-debug.csv file.</li> <li><code>DATA_IMPORT_ISSUES</code>: Write issues to debug lag as well as to the issue report.</li> <li><code>org.opentripplanner.raptor.RaptorService</code>: Debug Raptor request and response</li> </ul>"},{"location":"Logging/#format","title":"Format","text":"<p>By default, OTP logs in plain text to the console. However, it is possible to also log in JSON format.</p> <p>To enable it, set the Java property <code>otp.logging.format</code> to one of these values:</p> <ul> <li><code>plain</code>: regular plain text logging (default, no need to configure it)</li> <li><code>json</code>: Logstash-encoded JSON format understood by many log ingestion tools (Datadog, Loggly, Loki...)</li> </ul>"},{"location":"Logging/#complete-example","title":"Complete example","text":"<pre><code>java -Dotp.logging.format=json -jar otp.jar --load --serve data\n</code></pre>"},{"location":"Logging/#further-customization","title":"Further customization","text":"<p>If you want to customize the exact log output even further you can use your own logback configuration  by starting OTP with the following parameter:</p> <pre><code>java -Dlogback.configurationFile=/path/to/logback.xml -jar otp.jar --load --serve data\n</code></pre> <p>For example, Entur has their own custom log format configured as follows:</p> <pre><code>&lt;!-- Entur's custom log format  --&gt;\n&lt;appender name=\"entur\" class=\"ch.qos.logback.core.ConsoleAppender\"&gt;\n  &lt;encoder class=\"net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder\"&gt;\n     &lt;providers&gt;\n        &lt;!-- provides the timestamp &lt;timestamp/&gt; --&gt;\n        &lt;!-- provides the version &lt;version/&gt; --&gt;\n        &lt;!-- provides the fields in the configured pattern --&gt;\n        &lt;pattern&gt;\n           &lt;!-- the pattern that defines what to include --&gt;\n           &lt;pattern&gt;\n           {\n             \"serviceContext\": {\n               \"service\": \"otp2\"\n             },\n             \"message\": \"%message\\n%ex{full}\",\n             \"severity\": \"%level\",\n             \"reportLocation\": {\n               \"filePath\": \"%logger\",\n               \"lineNumber\": \"%line\",\n               \"functionName\": \"%method\"\n              }\n            }\n            &lt;/pattern&gt;\n        &lt;/pattern&gt;\n     &lt;/providers&gt;\n  &lt;/encoder&gt;\n&lt;/appender&gt;\n</code></pre>"},{"location":"Netex-Norway/","title":"Using European Data Standards","text":""},{"location":"Netex-Norway/#building-with-netex-data","title":"Building with Netex Data","text":"<p>One important new feature of OTP2 is the ability to load Netex data. Netex is a European specification for transit data exchange, comparable in purpose to GTFS but broader in scope. An EU directive aims to have all EU countries sharing Netex data by the end of 2019.</p> <p>Different countries are currently using different incompatible \"profiles\" of Netex, but an effort is underway to converge on a single European standard profile. This is based in large part on the Norwegian profile, and Norway's national passenger information and ticketing agency Entur has contributed the OTP2 Netex loading code. Therefore if you'd like to try loading Netex data, Norway is a good place to start.</p> <p>The Norwegian Netex data can be downloaded from the Entur developer pages. There is a column of Netex download links partway down the page, and the first row is for all of Norway.</p> <p>Full OSM data for Norway can be downloaded from the Geofabrik Norway downloads page. Get the <code>norway-latest.osm.pbf</code> file, which can then be filtered to remove buildings and other unused data before loading into OTP using a command like the one below. This filtering step can be skipped if you don't have the necessary Osmium tools installed.</p> <p><code>osmium tags-filter norway-latest.osm.pbf w/highway w/public_transport=platform w/railway=platform w/park_ride=yes r/type=restriction -o norway-filtered.osm.pbf -f pbf,add_metadata=false,pbf_dense_nodes=true</code></p> <p>Be sure to move the original unfiltered file out of your graph inputs directory (or rename it with a suffix like <code>norway-latest.osm.pbf.ignore</code>) otherwise OTP2 will try to include both the filtered and unfiltered OSM data in your graph.</p> <p>The <code>build-config.json</code> for a Norwegian graph using Netex data looks like this:</p> <pre><code>{\n  \"areaVisibility\": true,\n  \"platformEntriesLinking\": true,\n  \"islandWithoutStopsMaxSize\": 5,\n  \"islandWithStopsMaxSize\": 5,\n  \"dataImportReport\": true,\n  \"netexDefaults\" : {\n    \"moduleFilePattern\" : \".*-netex\\\\.zip\",\n    \"sharedFilePattern\": \"_stops.xml\",\n    \"sharedGroupFilePattern\": \"_(\\\\w{3})(_flexible)?_shared_data.xml\",\n    \"groupFilePattern\": \"(\\\\w{3})_.*\\\\.xml\",\n    \"feedId\": \"EN\",\n    \"ferryIdsNotAllowedForBicycle\": [\n      \"NYC:Line:1\",\n      \"NYC:Line:012fc5c4-131b-4dfc-8160-4e49136e531a\",\n      \"NYC:Line:8bfef12a-ac98-4376-8a2a-eb5a336d107b\"\n    ]\n  },\n  \"osm\": [\n    {\n      \"source\": \"norway-latest.osm.pbf\",\n      \"osmTagMapping\": \"norway\",\n      \"timeZone\": \"Europe/Oslo\"\n    }\n    ]\n}\n</code></pre> <p>Note the special section specifying how to find Netex XML files within the single ZIP archive you downloaded.</p> <p>Once you have the graph inputs (the OSM PBF file, the Netex ZIP file, and the <code>build-config.json</code>) saved together in a directory, you can instruct OTP2 to build a graph from these inputs:</p> <p><code>java -Xmx10G otp2.jar --build --save /path/to/graph/inputs</code></p> <p>This should produce a file <code>graph.obj</code> in the same directory as your inputs. Building this Norway graph takes approximately 16 minutes (without elevation data, as configured above), and can be done within 10GB of heap memory (JVM switch <code>-Xmx10G</code>). Increasing that to 12 or 14GB might speed it up a bit if you have the space. The Graph file it produces is just under 600MB. The server will take about 30 seconds to load this Graph and start up, and will consume about 4GB of heap memory under light use.</p> <p>You can then start up an OTP server with a command like this:</p> <p><code>java -Xmx6G otp2.jar --load /path/to/graph</code></p> <p>Once the server is started up, go to <code>http://localhost:8080</code> in a browser to try out your server using OTP's built in testing web client. Try some long trips like Oslo to Bergen and see if you can get long distance trains and flights as alternatives. You might need to increase the walking limit above its very low default value.</p>"},{"location":"Netex-Norway/#adding-siri-real-time-data","title":"Adding SIRI Real-time Data","text":"<p>Another important feature in OTP2 is the ability to use SIRI real-time data. Within the EU data standards, SIRI is analogous to GTFS-RT: a way to apply real-time updates on top of schedule data. While technically a distinct specification from Netex, both Netex and SIRI use the Transmodel vocabulary, allowing SIRI messages to reference entities in Netex schedule data. Like GTFS-RT, SIRI is consumed by OTP2 using \"graph updaters\" which are configured in the <code>router-config.json</code> file, which is placed in the same directory as the <code>graph.obj</code> file and loaded at server startup.</p> <pre><code>{\n    \"updaters\": [\n        {\n            \"type\": \"siri-sx-updater\",\n            \"frequency\": \"1m\",\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-sx\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"siri-et-updater\",\n            \"frequency\": \"20s\",\n            \"previewIntervalMinutes\": 180,\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-et\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"siri-vm-updater\",\n            \"frequency\": \"1m\",\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-vm\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"raptor-transit-layer\",\n            \"updateIntervalSeconds\": 20\n        }\n    ]\n}\n</code></pre> <p>The first three updaters fetch three different kinds of SIRI data:</p> <ul> <li>Situation Exchange (SX, text notices analogous to GTFS-RT Alerts)</li> <li>Estimated Timetable (ET, predicted arrival times analogous to GTFS-RT TripUpdates)</li> <li>Vehicle Monitoring (VM, location and status of vehicles analogous to GTFS-RT VehiclePositions)</li> </ul> <p>These updaters can handle differential updates, but they use a polling approach rather than the message-oriented streaming approach of the GTFS-RT Websocket updater. The server keeps track of clients, sending only the things that have changed since the last polling operation.</p> <p>Note that between these SIRI updaters and the GTFS-RT Websocket updater, we now have both polling and streaming examples of GTFS-RT \"incrementality\" semantics, so should be able to finalize that part of the specification.</p> <p>The final updater regularly performs a copy of the real-time data into a format suitable for use by OTP2's new Raptor router. Without this updater the real-time data will be received and cataloged, but not visible to the router.</p>"},{"location":"Preparing-OSM/","title":"Preparing OSM Data","text":""},{"location":"Preparing-OSM/#cropping-osm-data","title":"Cropping OSM data","text":"<p>Services producing automated extracts of OSM data like Geofabrik or Interline Extracts are limited to predefined areas. You'll often need to download an extract for a country or region larger than your true analysis area, then cut it down to size.</p> <p>Excessively large OSM data can lead to significant increases in computation time and complexity, both while building the graph and handling trip planning requests. You may want to crop the OSM data if they cover an area significantly larger than your transit network. Several command line tools are able to perform these cropping operations: Osmosis is a multi-platform Java tool that works on Windows, Linux, and MacOS but is relatively slow, OSMConvert is a fast tool pre-built for Windows and Linux and available on MacOS and Linux distributions as part of <code>osmctools</code> package. Osmium-Tool is a personal favorite that is extremely fast but only straightforward to install on Linux and MacOS platforms. Below are some example crop commands for these different tools:</p> <p>Osmosis: <code>osmosis --rb input.osm.pbf --bounding-box left=4.34 right=5.84 bottom=43.10 top=43.97 --wb cropped.osm.pbf</code></p> <p>OsmConvert: <code>osmconvert input.osm.pbf -b=-77.255859375,38.77764022307335,-76.81365966796875,39.02345139405933 --complete-ways -o=cropped.osm.pbf</code></p> <p>Osmium: <code>osmium extract --strategy complete_ways --bbox 2.25,48.81,2.42,48.91 input.osm.pbf -o cropped.osm.pbf</code></p> <p>The latter two commands expect bounding boxes to be specified in the format <code>min_lon,min_lat,max_lon,max_lat</code>. We frequently find bounding boxes using the convenient Klokantech bounding box tool. Selecting the \"CSV\" format in the lower left will give exactly the format expected by these tools.</p>"},{"location":"Preparing-OSM/#filtering-osm-data","title":"Filtering OSM data","text":"<p>The OSM database contains a lot of other data besides the roads, paths, and public transportation platform data we need for accessibility analysis. As of this writing, according to TagInfo 59% of the ways in OSM are buildings, and only 23% are roads or paths. Buildings frequently have more complex shapes than roads, and objects like waterways or political boundaries can be very large in size. It has been jokingly said that OSM should be renamed \"OpenBuildingMap\" rather than \"OpenStreetMap\".</p> <p>Removing unneeded data will reduce file sizes, facilitating copying or moving files around and reducing the size of project backups and archives. It may also speed up the processing stage where the OSM data is converted into a routable street network. Several command line tools exist to filter OSM data. Command line tools for this purpose include Osmosis and Osmium-Tool. Osmium-Tool is extremely fast but is only straightforward to install on Linux and MacOS platforms. Osmosis is often slower at filtering but will also work on Windows as it's a multi-platform Java application. OSMFilter cannot work with PBF format files so we rarely use it. Below are some example commands for retaining only OSM data useful for accessibility analysis. Here are some example commands:</p> <p>Osmosis: <code>osmosis --rb input.osm.pbf --tf reject-ways building=* --tf reject-ways waterway=* --tf reject-ways landuse=* --tf reject-ways natural=* --used-node --wb filtered.osm.pbf</code></p> <p>Osmium-Tool: <code>osmium tags-filter input.osm.pbf w/highway wa/public_transport=platform wa/railway=platform w/park_ride=yes r/type=restriction r/type=route -o filtered.osm.pbf -f pbf,add_metadata=false</code></p>"},{"location":"Presentations/","title":"Presentations related to OpenTripPlanner","text":""},{"location":"Presentations/#presentations-in-english","title":"Presentations in English","text":"<ul> <li>OpenTripPlanner past, present and the future. FOSDEM. Hannes Junnila. February, 2023</li> <li>OpenTripPlanner 2.2 webinar. Thomas Gran, Hannes Junnila and Leonard Ehrenfried. October, 2022</li> <li>Use of OpenTripPlanner in Norway. Andreas Tryti, Andrew Byrd and Brede Dammen. March, 2021</li> <li>OTP Webinar at Entur. Thomas Gran, Andrew Byrd and Gard Mellemstrand. October, 2019</li> <li>Multiple presentations at the OTP Open Day. April, 2019</li> <li>Simulating Cities with OpenStreetMap and OpenTripPlanner. State of the Map US. Kevin Webb. April, 2014</li> <li>OpenTripPlanner: Recent Developments in Multimodal Routing with OSM. State of the Map US. David Emory. June, 2013</li> </ul>"},{"location":"Presentations/#presentations-in-german","title":"Presentations in German","text":"<ul> <li>\u00d6PNV und Fahrgemeinschaften intermodal mit dem OpenTripPlanner. FOSSGIS 2019. Holger Bruch. March, 2019</li> </ul>"},{"location":"Product-Overview/","title":"Product Overview","text":""},{"location":"Product-Overview/#opentripplanner-project","title":"OpenTripPlanner project","text":"<p>OpenTripPlanner is a group of open source software applications that help individuals and organizations  calculate and deliver multimodal trip plans based on OpenStreetMap (OSM) and other standardized data  sources (e.g. GTFS, GBFS, NeTEx).</p> <p>A community of dozens of individuals and organizations work on OpenTripPlanner collaboratively to  improve multimodal trip planning best practices and to make it easier for public transit agencies and  public transit riders to publish and access information about transit services.</p> <p>OpenTripPlanner deployments are locally managed in many different ways by many different types of organizations.  OpenTripPlanner consistently and dependably delivers multimodal trip plans to millions of riders  everyday in dozens of countries around the globe. The project is actively maintained by the community,  with more than 50 commits most weeks during 2022, and 20 different developers having made 50 or more  commits during the life of the project.</p>"},{"location":"Product-Overview/#what-exactly-is-otp","title":"What exactly is OTP?","text":"<p>The most commonly used OpenTripPlanner component is a server-side Java application that is primarily  designed to interpret and combine map, transit service, and other mobility data sets, providing API  endpoints that receive user origins and destinations and return trip plans to other applications  along with vector map tiles, stop departures, and other rider information.</p> <p>In other words, OTP is a backend application that can work with other frontend user interfaces. OTP  works with your website, mobile app, physical signage or other applications in order to provide  relevant customer information and meaningful trip plans to riders.</p> <p>There's no official OTP user interface, although the OpenTripPlanner ecosystem includes several user  interface projects (for example Digitransit and  OTP-react-redux).  How your OTP deployment looks is entirely up to you. </p>"},{"location":"Product-Overview/#what-otp-can-do-for-you","title":"What OTP can do for you","text":""},{"location":"Product-Overview/#transit-agencies","title":"Transit agencies","text":"<p>Transit agencies can use OTP as a backend for their public website/app trip planner or internal trip planner  for their customer service team.</p> <ul> <li>Fully customizable for use with any frontend</li> <li>High-performance trip planning</li> <li>Fully multimodal routing, including walking, biking, bikeshare, demand-responsive services in  combined trip plans rather than presented in alternative trip plans</li> <li>Support for real-time alerts, trip re-routing based on real-time delays and vehicle positions</li> <li>Multi-criteria cost calculation allows for dynamic user inputs and requests including  mode, time, transfers, and other preferences while delivering balanced results</li> <li>One OTP backend can power both a website and app for use by riders, along with a separate frontend  with a different configuration for use by a customer service team</li> <li>Active development by dozens of agencies means new features every year (see the OTP common roadmap here)</li> </ul>"},{"location":"Product-Overview/#regions-countries-and-private-entities","title":"Regions, countries, and private entities","text":"<p>Regional, provincial, or national governments, or any private entity, can set up a trip planner including multiple transit agencies.</p> <ul> <li>Highly scalable software for large regions</li> <li>Interagency fare calculation</li> <li>Integrates multiple modes including bikeshare and demand-response</li> <li>Can be provided as a service to agencies for use in their websites and apps</li> </ul>"},{"location":"Product-Overview/#researchers","title":"Researchers","text":"<p>While historically, OpenTripPlanner has often been used by researchers for the programmatic calculation  of large numbers of trip plans, this is no longer an intended use case of OTP. You are welcome to use  OTP for any purpose, but you may also find applications like r5 to  be more appropriate for these purposes.</p>"},{"location":"Product-Overview/#talk-to-an-expert-about-otp","title":"Talk to an expert about OTP","text":"<p>Everyone interested in OTP is welcome to post questions on the Gitter chat or OpenTripPlanner-users group.</p> <p>If you\u2019re looking for a conversation with an individual from a similar organizational type, you can  make that request and include some info about your organization on the forum linked above and a member  of the OTP community will connect with you.</p>"},{"location":"ReleaseChecklist/","title":"Release Checklist","text":"<p>This section serves as a checklist for the person performing releases. Note that much of this mimics the actions taken by the Maven release plugin. Based on past experience, the Maven release plugin can fail at various points in the process leaving the repo in a confusing state. Taking each action manually is more tedious, but keeps eyes on each step and is less prone to failure.</p> <ul> <li>Check that your local copy of the dev branch is up to date with no uncommitted changes<ul> <li><code>git status</code></li> <li><code>git checkout dev-2.x</code></li> <li><code>git clean -df</code></li> <li><code>git pull</code></li> </ul> </li> <li>Make sure the documentation is up to date<ul> <li>Check all links and references to the release and update to the target release version. Search   all files for with a regular expression: <code>2\\.[012]\\.0</code> and replace if appropriate with the new   version.</li> <li>In <code>docs/index.md</code> replace what is the latest version and add a new line for the previous one</li> </ul> </li> <li>Update <code>docs/Changelog.md</code><ul> <li>Lines should have been added or updated as each pull request was merged</li> <li>If you suspect any changes are not reflected in the Changelog, review the commit log and add   any missing items</li> <li>Update the header at the top of the list from <code>x.y.z-SNAPSHOT</code> to just <code>x.y.z (current date)</code></li> <li>Check in any changes, and push to GitHub</li> <li>It is important to finalize the documentation before tagging the release, to ensure the    published documentation is associated with the release tag </li> </ul> </li> <li>Update the variable MASTER_BRANCH_VERSION in <code>cibuild.yml</code><ul> <li>This tells the GH Action that pushes the documentation on master what the name of the    current version is.    For version 2.3.0 Leonard has already done it: Example commit</li> </ul> </li> <li>Verify that all dependencies in the POM are non-SNAPSHOT versions (e.g. with <code>grep</code>)</li> <li>Check on GH Actions that the build is currently passing</li> <li>Switch to the HEAD of master branch, and ensure it's up to date with no uncommitted changes<ul> <li><code>git checkout master</code></li> <li><code>git status</code></li> <li><code>git clean -df</code></li> <li><code>git pull</code></li> </ul> </li> <li>Merge the dev branch into master<ul> <li><code>git merge dev-2.x</code></li> </ul> </li> <li>Bump the SNAPSHOT version in the POM to the release version<ul> <li>Edit version in POM, removing SNAPSHOT and increasing version numbers as needed (following   semantic versioning)</li> <li><code>git add pom.xml</code></li> <li><code>git commit -m \"prepare release x.y.z\"</code></li> </ul> </li> <li>Run a test build of the release locally, without deploying it<ul> <li><code>mvn clean install -Prelease</code></li> <li>The <code>install</code> goal will sign the Maven artifacts so you need the GPG signing certificate set   up</li> <li>You can also use the <code>package</code> goal instead of the <code>install</code> goal to avoid signing if you   don't have the GPG certificate installed.</li> <li>All tests should pass</li> </ul> </li> <li>Finally, if everything looks good, tag and push this release to make it official<ul> <li><code>git tag -a vX.Y.Z -m \"release X.Y.Z\"</code></li> <li><code>git push origin vX.Y.Z</code></li> <li><code>git push origin master</code></li> <li>Note that only one commit may have a particular non-snapshot version in the POM (this is   the commit that should be tagged as the release)</li> <li>Go to the GitHub tags page and use   the <code>...</code> button to mark the new tag as a release.</li> <li>Give the release a name like <code>v2.2.0 (November 2022)</code></li> <li>Optionally add a very condensed version of the changelog in the description box, with only the   5-10 most significant changes that might affect someone's choice to upgrade.</li> <li>Attach the JAR files produced in <code>/target</code> to the GitHub release page you just created.</li> </ul> </li> <li>Check that the push triggered an Actions build and that it was uploaded to GHPR.<ul> <li>Currently, pushing the tag does not trigger deployment of release Maven artifacts, only GHPR   JARs.</li> </ul> </li> <li>Deploy the build artifacts to Maven Central and GitHub and Maven Central<ul> <li>This step can get complicated and requires you to have the GPG keys and Maven repo credentials   set up.</li> <li>Apply the changes recorded   in https://github.com/opentripplanner/OpenTripPlanner/tree/signed-deploy-to-central</li> <li>While still on the tag commit, run <code>mvn deploy -Prelease</code>.</li> </ul> </li> <li>Set up next development iteration<ul> <li>Add a new section header to <code>docs/Changelog.md</code> like <code>x.y+1.0-SNAPSHOT (in progress)</code></li> <li>Edit minor version in <code>pom.xml</code> to <code>x.y+1.0-SNAPSHOT</code></li> <li><code>git add pom.xml docs/Changelog.md</code></li> <li><code>git commit -m \"Prepare next development iteration x.y+1.0-SNAPSHOT\"</code></li> <li><code>git push</code></li> </ul> </li> <li>Check that Maven artifact appears on Maven Central<ul> <li>Directory listing of OTP releases on Maven Central</li> <li>It may take a while (half an hour) for releases to show up in the central repo after Travis   uploads the artifacts</li> </ul> </li> <li>Merge master back into dev (to sync up the Maven artifact version from the POM)<ul> <li><code>git checkout dev-2.x</code></li> <li><code>git merge master</code></li> <li><code>git push</code></li> </ul> </li> <li>Email the OTP dev and users mailing lists<ul> <li>Mention the new version number.</li> <li>Provide links to the new developer documentation.</li> <li>Provide links to the artifacts directory on Maven Central.</li> </ul> </li> <li>Prepare for the next release in GitHub by renaming the released milestone and creating a new   milestone for the next release. Then make sure all issues and PRs are tagged with the correct   milestone.<ul> <li>Close open PRs older than 2 years, make sure the milestone is set to <code>Rejected</code>.</li> <li>Rename the old milestone from <code>x.y (Next Release)</code> to <code>x.y</code>. All issues and PRs assigned to    this milestone are automatically updated.</li> <li>Create a new milestone: <code>x.y+1 (Next Release)</code></li> <li>All PullRequests SHOULD have a milestone (except some very old ones) <ul> <li>Assign all open PRs to this new milestone <code>x.y+1 (Next Release)</code>.</li> <li>Assign all closed PRs without a milestone in the release to the released milestone    <code>x.y</code>. Make sure NOT to include very old PRs or PRs merged after the release(if any).</li> </ul> </li> <li>Some issues have a milestone, but not all.<ul> <li>Move all open issues with the released milestone <code>x.y</code> to the next release    <code>x.y+1 (Next Release)</code>. </li> </ul> </li> </ul> </li> </ul>"},{"location":"ReleaseChecklist/#artifact-signing","title":"Artifact Signing","text":"<p>Maven release artifacts must be digitally signed to prove their origin. This is a safeguard against compromised code from a malicious third party being disguised as a trusted library.</p> <p>The OTP artifact signing key was created by Conveyal. We export only that signing subkey, with our company's main key blanked out. Therefore, even if someone managed to acquire the decrypted key file and the associated GPG passphrase, they would not have the main key. We could deactivate the signing key and create a new one, without the main key being compromised.</p> <p>When modified for Maven Central deployment, OpenTripPlanner's POM is set up to sign artifacts in the verify phase, which means signing will happen for the <code>install</code> and <code>deploy</code> targets, but not the <code>package</code> target. When performing a local test build, if you do <code>mvn clean install site</code> it will test the signing process. If you do not have the certificate installed, you can instead do <code>mvn clean package site</code> to bypass signing, but this provides less certainty that everything is set up correctly for the CI-driven final release.</p>"},{"location":"Roadmap/","title":"Roadmap","text":"<p>The OTP community uses a GitHub-hosted Roadmap to document all long-term feature requests for OpenTripPlanner. Unlike typical OTP Issues, the Roadmap outlines quarterly and yearly product-focused goals the community intends to propose for OTP, rather than short-term bug fixes or feature requests.</p> <p>Twice a year, product owners (POs) and developers will review and clean up the issues at the PO meetings. Product owner (PO) meetings are open to everyone interested in OTP and are held on the first Tuesday of each month at 7 AM US Pacific / 10 AM  US Eastern / 4PM CET. To join, please consult this calender. For other questions, please contact members in the Gitter chat or the user mailing list.</p> <p>To create an issue on the OTP Roadmap, follow these steps:</p> <ol> <li>Navigate to the OpenTripPlanner GitHub.</li> <li>Select the \"Projects\" tab.    </li> <li>Choose the \"Roadmap\" project.    </li> <li>To add an issue, click \"Add item\" under the \"Wish list\" column.  </li> <li>Click the \"+\" icon, then \"Create a new issue.\" </li> <li>Select the \"Roadmap Epic\" type by clicking \"Choose.\"    </li> <li> <p>Complete the required fields:</p> <ul> <li>What: Clearly state the desired changes or new features.</li> <li>Why: Clearly state the expected impact or outcome of these changes.</li> <li>When: Provide a timeline or timeframe for implementing these changes.</li> <li>Link issue(s) related to or part of yours.</li> <li>Use labels to indicate which organizations have an interest in this Roadmap issue or to classify the Issue.</li> </ul> <p></p> </li> </ol> <p>Then, click \"Create.\"</p> <p>This is what your completed Roadmap Issue should like: </p> <p>Discussions about the Issue within the corresponding Gitter chat are encouraged, along with participation in the OTP product owner (PO) or developer meetings.</p>"},{"location":"RouteRequest/","title":"Route Request","text":""},{"location":"RouteRequest/#route-request","title":"Route Request","text":"<p>The RouteRequest is the type for the routingDefaults in router-config.json  and in the transferRequests in build-config.json.</p> Config Parameter Type Summary Req./Opt. Default Value Since alightSlack <code>duration</code> The minimum extra time after exiting a public transport vehicle. Optional <code>\"PT0S\"</code> 2.0 arriveBy <code>boolean</code> Whether the trip should depart or arrive at the specified date and time. Optional <code>false</code> 2.0 boardSlack <code>duration</code> The boardSlack is the minimum extra time to board a public transport vehicle. Optional <code>\"PT0S\"</code> 2.0 drivingDirection <code>enum</code> The driving direction to use in the intersection traversal calculation Optional <code>\"right\"</code> 2.2 elevatorBoardCost <code>integer</code> What is the cost of boarding a elevator? Optional <code>90</code> 2.0 elevatorBoardTime <code>integer</code> How long does it take to get on an elevator, on average. Optional <code>90</code> 2.0 elevatorHopCost <code>integer</code> What is the cost of travelling one floor on an elevator? Optional <code>20</code> 2.0 elevatorHopTime <code>integer</code> How long does it take to advance one floor on an elevator? Optional <code>20</code> 2.0 geoidElevation <code>boolean</code> If true, the Graph's ellipsoidToGeoidDifference is applied to all elevations returned by this query. Optional <code>false</code> 2.0 ignoreRealtimeUpdates <code>boolean</code> When true, real-time updates are ignored during this search. Optional <code>false</code> 2.0 intersectionTraversalModel <code>enum</code> The model that computes the costs of turns. Optional <code>\"simple\"</code> 2.2 locale <code>locale</code> TODO Optional <code>\"en_US\"</code> 2.0 maxDirectStreetDuration <code>duration</code> This is the maximum duration for a direct street search for each mode. Optional <code>\"PT4H\"</code> 2.1 maxJourneyDuration <code>duration</code> The expected maximum time a journey can last across all possible journeys for the current deployment. Optional <code>\"PT24H\"</code> 2.1 modes <code>string</code> The set of access/egress/direct/transit modes to be used for the route search. Optional <code>\"TRANSIT,WALK\"</code> 2.0 nonpreferredTransferPenalty <code>integer</code> Penalty (in seconds) for using a non-preferred transfer. Optional <code>180</code> 2.0 numItineraries <code>integer</code> The maximum number of itineraries to return. Optional <code>50</code> 2.0 otherThanPreferredRoutesPenalty <code>integer</code> Penalty added for using every route that is not preferred if user set any route as preferred. Optional <code>300</code> 2.0 relaxTransitGroupPriority <code>string</code> The relax function for transit-group-priority Optional <code>\"0s + 1.00 t\"</code> 2.5 relaxTransitSearchGeneralizedCostAtDestination <code>double</code> Whether non-optimal transit paths at the destination should be returned Optional 2.3 searchWindow <code>duration</code> The duration of the search-window. Optional 2.0 streetRoutingTimeout <code>duration</code> The maximum time a street routing request is allowed to take before returning the results. Optional <code>\"PT5S\"</code> 2.2 transferPenalty <code>integer</code> An additional penalty added to boardings after the first. Optional <code>0</code> 2.0 transferSlack <code>integer</code> The extra time needed to make a safe transfer in seconds. Optional <code>120</code> 2.0 turnReluctance <code>double</code> Multiplicative factor on expected turning time. Optional <code>1.0</code> 2.0 unpreferredCost <code>cost-linear-function</code> A cost function used to calculate penalty for an unpreferred route. Optional <code>\"0s + 1.00 t\"</code> 2.2 waitReluctance <code>double</code> How much worse is waiting for a transit vehicle than being on a transit vehicle, as a multiplier. Optional <code>1.0</code> 2.0 accessEgress <code>object</code> Parameters for access and egress routing. Optional 2.4 maxDuration <code>duration</code> This is the maximum duration for access/egress for street searches. Optional <code>\"PT45M\"</code> 2.1 maxStopCount <code>integer</code> Maximal number of stops collected in access/egress routing Optional <code>500</code> 2.4 maxDurationForMode <code>enum map of duration</code> Limit access/egress per street mode. Optional 2.1 penalty <code>enum map of object</code> Penalty for access/egress by street mode. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0FLEXIBLE <code>object</code> NA Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0costFactor <code>double</code> A factor multiplied with the time-penalty to get the cost-penalty. Optional <code>0.0</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0timePenalty <code>time-penalty</code> Penalty added to the time of a path/leg. Optional <code>\"0s + 0.00 t\"</code> 2.4 alightSlackForMode <code>enum map of duration</code> How much extra time should be given when alighting a vehicle for each given mode. Optional 2.0 bicycle <code>object</code> Bicycle preferences. Optional 2.5 boardCost <code>integer</code> Prevents unnecessary transfers by adding a cost for boarding a transit vehicle. Optional <code>600</code> 2.0 optimization <code>enum</code> The set of characteristics that the user wants to optimize for. Optional <code>\"safe-streets\"</code> 2.0 \u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad cycling is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 \u00a0\u00a0\u00a0speed <code>double</code> Max bicycle speed along streets, in meters per second Optional <code>5.0</code> 2.0 \u00a0\u00a0\u00a0parking <code>object</code> Preferences for parking a vehicle. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0cost <code>integer</code> Cost to park a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>duration</code> Time to park a vehicle. Optional <code>\"PT1M\"</code> 2.0 unpreferredVehicleParkingTagCost <code>integer</code> What cost to add if a parking facility doesn't contain a preferred tag. Optional <code>300</code> 2.3 bannedVehicleParkingTags <code>string[]</code> Tags with which a vehicle parking will not be used. If empty, no tags are banned. Optional 2.1 preferredVehicleParkingTags <code>string[]</code> Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised. Optional 2.3 requiredVehicleParkingTags <code>string[]</code> Tags without which a vehicle parking will not be used. If empty, no tags are required. Optional 2.1 \u00a0\u00a0\u00a0rental <code>object</code> Vehicle rental options Optional 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowKeepingAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffCost <code>integer</code> Cost to drop-off a rented vehicle. Optional <code>30</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffTime <code>duration</code> Time to drop-off a rented vehicle. Optional <code>\"PT30S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0keepingAtDestinationCost <code>integer</code> The cost of arriving at the destination with the rented vehicle, to discourage doing so. Optional <code>0</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupCost <code>integer</code> Cost to rent a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupTime <code>duration</code> Time to rent a vehicle. Optional <code>\"PT1M\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0useAvailabilityInformation <code>boolean</code> Whether or not vehicle rental availability information will be used to plan vehicle rental trips. Optional <code>false</code> 2.0 allowedNetworks <code>string[]</code> The vehicle rental networks which may be used. If empty all networks may be used. Optional 2.1 bannedNetworks <code>string[]</code> The vehicle rental networks which may not be used. If empty, no networks are banned. Optional 2.1 triangle <code>object</code> Triangle optimization criteria. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flatness <code>double</code> Relative importance of flat terrain (range 0-1). Optional <code>0.0</code> 2.0 safety <code>double</code> Relative importance of safety (range 0-1). Optional <code>0.0</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>double</code> Relative importance of duration of travel (range 0-1). Optional <code>0.0</code> 2.0 \u00a0\u00a0\u00a0walk <code>object</code> Preferences for walking a vehicle. Optional 2.5 hopCost <code>integer</code> The cost of hopping on or off a vehicle. Optional <code>0</code> 2.0 hopTime <code>duration</code> The time it takes the user to hop on or off a vehicle. Optional <code>\"PT0S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad walking with a vehicle is, compared to being in transit for equal lengths of time. Optional <code>5.0</code> 2.1 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0speed <code>double</code> The user's vehicle walking speed in meters/second. Defaults to approximately 3 MPH. Optional <code>1.33</code> 2.1 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0stairsReluctance <code>double</code> How bad is it to walk the vehicle up/down a flight of stairs compared to taking a detour. Optional <code>10.0</code> 2.3 boardSlackForMode <code>enum map of duration</code> How much extra time should be given when boarding a vehicle for each given mode. Optional 2.0 car <code>object</code> Car preferences. Optional 2.5 \u00a0\u00a0\u00a0accelerationSpeed <code>double</code> The acceleration speed of an automobile, in meters per second per second. Optional <code>2.9</code> 2.0 \u00a0\u00a0\u00a0decelerationSpeed <code>double</code> The deceleration speed of an automobile, in meters per second per second. Optional <code>2.9</code> 2.0 \u00a0\u00a0\u00a0pickupCost <code>integer</code> Add a cost for car pickup changes when a pickup or drop off takes place Optional <code>120</code> 2.1 \u00a0\u00a0\u00a0pickupTime <code>duration</code> Add a time for car pickup changes when a pickup or drop off takes place Optional <code>\"PT1M\"</code> 2.1 \u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad driving is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 \u00a0\u00a0\u00a0speed <code>double</code> Max car speed along streets, in meters per second Optional <code>40.0</code> 2.0 \u00a0\u00a0\u00a0parking <code>object</code> Preferences for parking a vehicle. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0cost <code>integer</code> Cost to park a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>duration</code> Time to park a vehicle. Optional <code>\"PT1M\"</code> 2.0 unpreferredVehicleParkingTagCost <code>integer</code> What cost to add if a parking facility doesn't contain a preferred tag. Optional <code>300</code> 2.3 bannedVehicleParkingTags <code>string[]</code> Tags with which a vehicle parking will not be used. If empty, no tags are banned. Optional 2.1 preferredVehicleParkingTags <code>string[]</code> Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised. Optional 2.3 requiredVehicleParkingTags <code>string[]</code> Tags without which a vehicle parking will not be used. If empty, no tags are required. Optional 2.1 \u00a0\u00a0\u00a0rental <code>object</code> Vehicle rental options Optional 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowKeepingAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffCost <code>integer</code> Cost to drop-off a rented vehicle. Optional <code>30</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffTime <code>duration</code> Time to drop-off a rented vehicle. Optional <code>\"PT30S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0keepingAtDestinationCost <code>integer</code> The cost of arriving at the destination with the rented vehicle, to discourage doing so. Optional <code>0</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupCost <code>integer</code> Cost to rent a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupTime <code>duration</code> Time to rent a vehicle. Optional <code>\"PT1M\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0useAvailabilityInformation <code>boolean</code> Whether or not vehicle rental availability information will be used to plan vehicle rental trips. Optional <code>false</code> 2.0 allowedNetworks <code>string[]</code> The vehicle rental networks which may be used. If empty all networks may be used. Optional 2.1 bannedNetworks <code>string[]</code> The vehicle rental networks which may not be used. If empty, no networks are banned. Optional 2.1 itineraryFilters <code>object</code> Configure itinerary filters that may modify itineraries, sort them, and filter away less preferable results. Optional 2.0 accessibilityScore <code>boolean</code> An experimental feature contributed by IBI which adds a sandbox accessibility score between 0 and 1 for each leg and itinerary. Optional <code>false</code> 2.2 bikeRentalDistanceRatio <code>double</code> Filter routes that consist of bike-rental and walking by the minimum fraction of the bike-rental leg using distance. Optional <code>0.0</code> 2.1 debug <code>enum</code> Enable this to attach a system notice to itineraries instead of removing them. This is very convenient when tuning the itinerary-filter-chain. Optional <code>\"off\"</code> 2.0 filterItinerariesWithSameFirstOrLastTrip <code>boolean</code> If more than one itinerary begins or ends with same trip, filter out one of those itineraries so that only one remains. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0groupSimilarityKeepOne <code>double</code> Pick ONE itinerary from each group after putting itineraries that are 85% similar together. Optional <code>0.85</code> 2.1 \u00a0\u00a0\u00a0groupSimilarityKeepThree <code>double</code> Reduce the number of itineraries to three itineraries by reducing each group of itineraries grouped by 68% similarity. Optional <code>0.68</code> 2.1 groupedOtherThanSameLegsMaxCostMultiplier <code>double</code> Filter grouped itineraries, where the non-grouped legs are more expensive than in the lowest cost one. Optional <code>2.0</code> 2.1 minBikeParkingDistance <code>double</code> Filter out bike park+ride results that have fewer meters of cycling than this value. Optional <code>0.0</code> 2.3 nonTransitGeneralizedCostLimit <code>cost-linear-function</code> The function define a max-limit for generalized-cost for non-transit itineraries. Optional <code>\"1h + 2.0 t\"</code> 2.1 parkAndRideDurationRatio <code>double</code> Filter P+R routes that consist of driving and walking by the minimum fraction of the driving using of time. Optional <code>0.0</code> 2.1 removeItinerariesWithSameRoutesAndStops <code>boolean</code> Set to true if you want to list only the first itinerary  which goes through the same stops and routes. Optional <code>false</code> 2.2 removeTransitWithHigherCostThanBestOnStreetOnly <code>cost-linear-function</code> Limit function for generalized-cost computed from street-only itineries applied to transit itineraries. Optional <code>\"1m + 1.30 t\"</code> 2.4 transitGeneralizedCostLimit <code>object</code> A relative limit for the generalized-cost for transit itineraries. Optional 2.1 costLimitFunction <code>cost-linear-function</code> The base function used by the filter. Optional <code>\"15m + 1.50 t\"</code> 2.2 intervalRelaxFactor <code>double</code> How much the filter should be relaxed for itineraries that do not overlap in time. Optional <code>0.4</code> 2.2 maxDirectStreetDurationForMode <code>enum map of duration</code> Limit direct route duration per street mode. Optional 2.2 transferOptimization <code>object</code> Optimize where a transfer between to trip happens. Optional 2.1 backTravelWaitTimeFactor <code>double</code> To reduce back-travel we favor waiting, this reduces the cost of waiting. Optional <code>1.0</code> 2.1 extraStopBoardAlightCostsFactor <code>double</code> Add an extra board- and alight-cost for prioritized stops. Optional <code>0.0</code> 2.1 minSafeWaitTimeFactor <code>double</code> Used to set a maximum wait-time cost, base on min-safe-transfer-time. Optional <code>5.0</code> 2.1 optimizeTransferWaitTime <code>boolean</code> This enables the transfer wait time optimization. Optional <code>true</code> 2.1 transitGroupPriority <code>object</code> Group transit patterns and give each group a mutual advantage in the Raptor search. Optional 2.5 transitReluctanceForMode <code>enum map of double</code> Transit reluctance for a given transport mode Optional 2.1 unpreferred <code>object</code> Parameters listing authorities or lines that preferably should not be used in trip patters. Optional 2.2 agencies <code>feed-scoped-id[]</code> The ids of the agencies that incur an extra cost when being used. Format: <code>FeedId:AgencyId</code> Optional 2.2 routes <code>feed-scoped-id[]</code> The ids of the routes that incur an extra cost when being used. Format: <code>FeedId:RouteId</code> Optional 2.2 walk <code>object</code> Walking preferences. Optional 2.5 \u00a0\u00a0\u00a0boardCost <code>integer</code> Prevents unnecessary transfers by adding a cost for boarding a vehicle. This is the cost that is used when boarding while walking. Optional <code>600</code> 2.0 \u00a0\u00a0\u00a0escalatorReluctance <code>double</code> A multiplier for how bad being in an escalator is compared to being in transit for equal lengths of time Optional <code>1.5</code> 2.4 reluctance <code>double</code> A multiplier for how bad walking is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 safetyFactor <code>double</code> Factor for how much the walk safety is considered in routing. Optional <code>1.0</code> 2.2 \u00a0\u00a0\u00a0speed <code>double</code> The user's walking speed in meters/second. Optional <code>1.33</code> 2.0 \u00a0\u00a0\u00a0stairsReluctance <code>double</code> Used instead of walkReluctance for stairs. Optional <code>2.0</code> 2.0 stairsTimeFactor <code>double</code> How much more time does it take to walk a flight of stairs compared to walking a similar horizontal length. Optional <code>3.0</code> 2.1 wheelchairAccessibility <code>object</code> See Wheelchair Accessibility Optional 2.2 \u00a0\u00a0\u00a0enabled <code>boolean</code> Enable wheelchair accessibility. Optional <code>false</code> 2.0 \u00a0\u00a0\u00a0inaccessibleStreetReluctance <code>double</code> The factor to multiply the cost of traversing a street edge that is not wheelchair-accessible. Optional <code>25.0</code> 2.2 maxSlope <code>double</code> The maximum slope as a fraction of 1. Optional <code>0.083</code> 2.0 slopeExceededReluctance <code>double</code> How much streets with high slope should be avoided. Optional <code>1.0</code> 2.2 stairsReluctance <code>double</code> How much stairs should be avoided. Optional <code>100.0</code> 2.2 \u00a0\u00a0\u00a0elevator <code>object</code> Configuration for when to use inaccessible elevators. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>20</code> 2.2 \u00a0\u00a0\u00a0stop <code>object</code> Configuration for when to use inaccessible stops. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>true</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>600</code> 2.2 \u00a0\u00a0\u00a0trip <code>object</code> Configuration for when to use inaccessible trips. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>true</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>600</code> 2.2"},{"location":"RouteRequest/#parameter-details","title":"Parameter Details","text":""},{"location":"RouteRequest/#rd_alightSlack","title":"alightSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults </p> <p>The minimum extra time after exiting a public transport vehicle.</p> <p>The slack is added to the time when going from the transit vehicle to the stop.</p>"},{"location":"RouteRequest/#rd_boardSlack","title":"boardSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults </p> <p>The boardSlack is the minimum extra time to board a public transport vehicle.</p> <p>The board time is added to the time when going from the stop (offboard) to onboard a transit vehicle.</p> <p>This is the same as the <code>transferSlack</code>, except that this also apply to to the first transit leg in the trip. This is the default value used, if not overridden by the <code>boardSlackList</code>.</p>"},{"location":"RouteRequest/#rd_drivingDirection","title":"drivingDirection","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"right\"</code> Path: /routingDefaults  Enum values: <code>right</code> | <code>left</code></p> <p>The driving direction to use in the intersection traversal calculation</p>"},{"location":"RouteRequest/#rd_intersectionTraversalModel","title":"intersectionTraversalModel","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"simple\"</code> Path: /routingDefaults  Enum values: <code>simple</code> | <code>constant</code></p> <p>The model that computes the costs of turns.</p>"},{"location":"RouteRequest/#rd_maxDirectStreetDuration","title":"maxDirectStreetDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT4H\"</code> Path: /routingDefaults </p> <p>This is the maximum duration for a direct street search for each mode.</p> <p>This is a performance limit and should therefore be set high. Results close to the limit are not guaranteed to be optimal. Use itinerary-filters to limit what is presented to the client. The duration can be set per mode(<code>maxDirectStreetDurationForMode</code>), because some street modes searches are much more resource intensive than others. A default value is applied if the mode specific value do not exist.\"</p>"},{"location":"RouteRequest/#rd_maxJourneyDuration","title":"maxJourneyDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT24H\"</code> Path: /routingDefaults </p> <p>The expected maximum time a journey can last across all possible journeys for the current deployment.</p> <p>Normally you would just do an estimate and add enough slack, so you are sure that there is no journeys that falls outside this window. The parameter is used find all possible dates for the journey and then search only the services which run on those dates. The duration must include access, egress, wait-time and transit time for the whole journey. It should also take low frequency days/periods like holidays into account. In other words, pick the two points within your area that has the worst connection and then try to travel on the worst possible day, and find the maximum journey duration. Using a value that is too high has the effect of including more patterns in the search, hence, making it a bit slower. Recommended values would be from 12 hours(small town/city), 1 day (region) to 2 days (country like Norway).\"</p>"},{"location":"RouteRequest/#rd_otherThanPreferredRoutesPenalty","title":"otherThanPreferredRoutesPenalty","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults </p> <p>Penalty added for using every route that is not preferred if user set any route as preferred.</p> <p>We return number of seconds that we are willing to wait for preferred route.</p>"},{"location":"RouteRequest/#rd_relaxTransitGroupPriority","title":"relaxTransitGroupPriority","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"0s + 1.00 t\"</code> Path: /routingDefaults </p> <p>The relax function for transit-group-priority</p> <p>A path is considered optimal if the generalized-cost is less than the generalized-cost of another path. If this parameter is set, the comparison is relaxed further if they belong to different transit groups.</p>"},{"location":"RouteRequest/#rd_relaxTransitSearchGeneralizedCostAtDestination","title":"relaxTransitSearchGeneralizedCostAtDestination","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Whether non-optimal transit paths at the destination should be returned</p> <p>Let c be the existing minimum pareto optimal generalized cost to beat. Then a trip with cost c' is accepted if the following is true: <code>c' &lt; Math.round(c * relaxRaptorCostCriteria)</code>.</p> <p>The parameter is optional. If not set a normal comparison is performed.</p> <p>Values equals or less than zero is not allowed. Values greater than 2.0 are not supported, due to performance reasons.</p>"},{"location":"RouteRequest/#rd_searchWindow","title":"searchWindow","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>The duration of the search-window.</p> <p>This is the time/duration in seconds from the earliest-departure-time(EDT) to the latest-departure-time(LDT). In case of a reverse search it will be the time from earliest to latest arrival time (LAT - EAT).</p> <p>All optimal travels that depart within the search window is guaranteed to be found.</p> <p>This is sometimes referred to as the Range Raptor Search Window - but could be used in a none Transit search as well; Hence this is named search-window and not raptor-search-window.</p> <p>This is normally dynamically calculated by the server. Use <code>null</code> to unset, and zero to do one Raptor iteration. The value is dynamically  assigned a suitable value, if not set. In a small to medium size operation you may use a fixed value, like 60 minutes. If you have a mixture of high frequency cities routes and  infrequent long distant journeys, the best option is normally to use the dynamic auto assignment. If not provided the value is resolved depending on the other input parameters, available transit options and realtime changes.</p> <p>There is no need to set this when going to the next/previous page. The OTP Server will increase/decrease the search-window when paging to match the requested number of itineraries.</p>"},{"location":"RouteRequest/#rd_streetRoutingTimeout","title":"streetRoutingTimeout","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT5S\"</code> Path: /routingDefaults </p> <p>The maximum time a street routing request is allowed to take before returning the results.</p> <p>The street search(AStar) aborts after this duration and any paths found are returned to the client. The street part of the routing may take a long time if searching very long distances. You can set the street routing timeout to avoid tying up server resources on pointless searches and ensure that your users receive a timely response. You can also limit the max duration. There are is also a 'apiProcessingTimeout'. Make sure the street timeout is less than the 'apiProcessingTimeout'.</p>"},{"location":"RouteRequest/#rd_transferPenalty","title":"transferPenalty","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /routingDefaults </p> <p>An additional penalty added to boardings after the first.</p> <p>The value is in OTP's internal weight units, which are roughly equivalent to seconds. Set this to a high value to discourage transfers. Of course, transfers that save significant time or walking will still be taken.</p>"},{"location":"RouteRequest/#rd_transferSlack","title":"transferSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>120</code> Path: /routingDefaults </p> <p>The extra time needed to make a safe transfer in seconds.</p> <p>An expected transfer time in seconds that specifies the amount of time that must pass between exiting one public transport vehicle and boarding another. This time is in addition to time it might take to walk between stops plus <code>boardSlack</code> and <code>alightSlack</code>.</p>"},{"location":"RouteRequest/#rd_unpreferredCost","title":"unpreferredCost","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"0s + 1.00 t\"</code> Path: /routingDefaults </p> <p>A cost function used to calculate penalty for an unpreferred route.</p> <p>Function should return number of seconds that we are willing to wait for preferred route or for an unpreferred agency's departure. For example: <code>5m + 2.0 t</code></p>"},{"location":"RouteRequest/#rd_accessEgress_maxDuration","title":"maxDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /routingDefaults/accessEgress </p> <p>This is the maximum duration for access/egress for street searches.</p> <p>This is a performance limit and should therefore be set high. Results close to the limit are not guaranteed to be optimal. Use itinerary-filters to limit what is presented to the client. The duration can be set per mode(<code>maxDurationForMode</code>), because some street modes searches are much more resource intensive than others. A default value is applied if the mode specific value do not exist.</p>"},{"location":"RouteRequest/#rd_accessEgress_maxStopCount","title":"maxStopCount","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>500</code> Path: /routingDefaults/accessEgress </p> <p>Maximal number of stops collected in access/egress routing</p> <p>Safety limit to prevent access to and egress from too many stops.</p>"},{"location":"RouteRequest/#rd_accessEgress_maxDurationForMode","title":"maxDurationForMode","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/accessEgress  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Limit access/egress per street mode.</p> <p>Override the settings in <code>maxDuration</code> for specific street modes. This is done because some street modes searches are much more resource intensive than others.</p>"},{"location":"RouteRequest/#rd_accessEgress_penalty","title":"penalty","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>enum map of object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/accessEgress  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Penalty for access/egress by street mode.</p> <p>Use this to add a time and cost penalty to an access/egress legs for a given street mode. This will favour other street-modes and transit. This has a performance penalty, since the search-window is increased with the same amount as the maximum penalty for the access legs used. In other cases where the access(CAR) is faster than transit the performance will be better.</p> <p>The default is no penalty, if not configured.</p> <p>Example: <code>\"car-to-park\" : { \"timePenalty\": \"10m + 1.5t\", \"costFactor\": 2.5 }</code></p> <p>Time penalty</p> <p>The <code>timePenalty</code> is used to add a penalty to the access/egress duration/time. The time including the penalty is used in the algorithm when comparing paths, but the actual duration is used when presented to the end user.</p> <p>Cost factor</p> <p>The <code>costFactor</code> is used to add an additional cost to the leg\u00b4s  generalized-cost. The time-penalty is multiplied with the cost-factor. A cost-factor of zero, gives no extra cost, while 1.0 will add the same amount to both time and cost.</p>"},{"location":"RouteRequest/#rd_alightSlackForMode","title":"alightSlackForMode","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>How much extra time should be given when alighting a vehicle for each given mode.</p> <p>Sometimes there is a need to configure a longer alighting times for specific modes, such as airplanes or ferries.</p>"},{"location":"RouteRequest/#rd_bicycle_boardCost","title":"boardCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>600</code> Path: /routingDefaults/bicycle </p> <p>Prevents unnecessary transfers by adding a cost for boarding a transit vehicle.</p> <p>This is the cost that is used when boarding while cycling. This is usually higher that walkBoardCost.</p>"},{"location":"RouteRequest/#rd_bicycle_optimization","title":"optimization","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"safe-streets\"</code> Path: /routingDefaults/bicycle  Enum values: <code>shortest-duration</code> | <code>safe-streets</code> | <code>flat-streets</code> | <code>safest-streets</code> | <code>triangle</code></p> <p>The set of characteristics that the user wants to optimize for.</p> <p>If the triangle optimization is used, it's enough to just define the triangle parameters</p>"},{"location":"RouteRequest/#rd_bicycle_parking_unpreferredVehicleParkingTagCost","title":"unpreferredVehicleParkingTagCost","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults/bicycle/parking </p> <p>What cost to add if a parking facility doesn't contain a preferred tag.</p> <p>See <code>preferredVehicleParkingTags</code>.</p>"},{"location":"RouteRequest/#rd_bicycle_parking_bannedVehicleParkingTags","title":"bannedVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Tags with which a vehicle parking will not be used. If empty, no tags are banned.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_parking_preferredVehicleParkingTags","title":"preferredVehicleParkingTags","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_parking_requiredVehicleParkingTags","title":"requiredVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Tags without which a vehicle parking will not be used. If empty, no tags are required.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_rental_allowedNetworks","title":"allowedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/rental </p> <p>The vehicle rental networks which may be used. If empty all networks may be used.</p>"},{"location":"RouteRequest/#rd_bicycle_rental_bannedNetworks","title":"bannedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/rental </p> <p>The vehicle rental networks which may not be used. If empty, no networks are banned.</p>"},{"location":"RouteRequest/#rd_bicycle_triangle","title":"triangle","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle </p> <p>Triangle optimization criteria.</p> <p>Optimization type doesn't need to be defined if these values are defined.</p>"},{"location":"RouteRequest/#rd_bicycle_triangle_safety","title":"safety","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/bicycle/triangle </p> <p>Relative importance of safety (range 0-1).</p> <p>This factor can also include other concerns such as convenience and general cyclist preferences by taking into account road surface etc.</p>"},{"location":"RouteRequest/#rd_bicycle_walk_hopCost","title":"hopCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /routingDefaults/bicycle/walk </p> <p>The cost of hopping on or off a vehicle.</p> <p>There are different parameters for the cost of renting or parking a vehicle and this is not meant for controlling the cost of those events.</p>"},{"location":"RouteRequest/#rd_bicycle_walk_hopTime","title":"hopTime","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults/bicycle/walk </p> <p>The time it takes the user to hop on or off a vehicle.</p> <p>Time it takes to rent or park a vehicle have their own parameters and this is not meant for controlling the duration of those events.</p>"},{"location":"RouteRequest/#rd_boardSlackForMode","title":"boardSlackForMode","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>How much extra time should be given when boarding a vehicle for each given mode.</p> <p>Sometimes there is a need to configure a board times for specific modes, such as airplanes or ferries, where the check-in process needs to be done in good time before ride.</p>"},{"location":"RouteRequest/#rd_car_parking_unpreferredVehicleParkingTagCost","title":"unpreferredVehicleParkingTagCost","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults/car/parking </p> <p>What cost to add if a parking facility doesn't contain a preferred tag.</p> <p>See <code>preferredVehicleParkingTags</code>.</p>"},{"location":"RouteRequest/#rd_car_parking_bannedVehicleParkingTags","title":"bannedVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Tags with which a vehicle parking will not be used. If empty, no tags are banned.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_parking_preferredVehicleParkingTags","title":"preferredVehicleParkingTags","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_parking_requiredVehicleParkingTags","title":"requiredVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Tags without which a vehicle parking will not be used. If empty, no tags are required.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_rental_allowedNetworks","title":"allowedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/rental </p> <p>The vehicle rental networks which may be used. If empty all networks may be used.</p>"},{"location":"RouteRequest/#rd_car_rental_bannedNetworks","title":"bannedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/rental </p> <p>The vehicle rental networks which may not be used. If empty, no networks are banned.</p>"},{"location":"RouteRequest/#rd_itineraryFilters","title":"itineraryFilters","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Configure itinerary filters that may modify itineraries, sort them, and filter away less preferable results.</p> <p>The purpose of the itinerary filter chain is to post process the result returned by the routing search. The filters may modify itineraries, sort them, and filter away less preferable results.</p> <p>OTP2 may produce numerous pareto-optimal results when using <code>time</code>, <code>number-of-transfers</code> and <code>generalized-cost</code> as criteria. Use the parameters listed here to reduce/filter the itineraries return by the search engine before returning the results to client. There is also a few mandatory non-configurable filters removing none optimal results. You may see these filters pop-up in the filter debugging.</p>"},{"location":"RouteRequest/#group-by-similarity-filters","title":"Group by similarity filters","text":"<p>The group-by-filter is a bit complex, but should be simple to use. Set <code>debug=true</code> and experiment with <code>searchWindow</code> and the three group-by parameters(<code>groupSimilarityKeepOne</code>, <code>groupSimilarityKeepThree</code> and <code>groupedOtherThanSameLegsMaxCostMultiplier</code>).</p> <p>The group-by-filter work by grouping itineraries together and then reducing the number of itineraries in each group, keeping the itinerary/itineraries with the best itinerary generalized-cost. The group-by function first pick all transit legs that account for more than N% of the itinerary based on distance traveled. This become the group-key. Two keys are the same if all legs in one of the keys also exist in the other. Note, one key may have a larger set of legs than the other, but they can still be the same. When comparing two legs we compare the <code>tripId</code> and make sure the legs overlap in place and time. Two legs are the same if both legs ride at least a common subsection of the same trip. The <code>keepOne</code> filter will keep ONE itinerary in each group. The <code>keepThree</code> keeps 3 itineraries for each group.</p> <p>The grouped itineraries can be further reduced by using <code>groupedOtherThanSameLegsMaxCostMultiplier</code>. This parameter filters out itineraries, where the legs that are not common for all the grouped itineraries have a much higher cost, than the lowest in the group. By default, it filters out itineraries that are at least double in cost for the non-grouped legs.</p>"},{"location":"RouteRequest/#rd_if_accessibilityScore","title":"accessibilityScore","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>An experimental feature contributed by IBI which adds a sandbox accessibility score between 0 and 1 for each leg and itinerary.</p> <p>This can be used by frontend developers to implement a simple traffic light UI.</p>"},{"location":"RouteRequest/#rd_if_bikeRentalDistanceRatio","title":"bikeRentalDistanceRatio","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter routes that consist of bike-rental and walking by the minimum fraction of the bike-rental leg using distance.</p> <p>This filters out results that consist of a long walk plus a relatively short bike rental leg. A value of <code>0.3</code> means that a minimum of 30% of the total distance must be spent on the bike in order for the result to be included.</p>"},{"location":"RouteRequest/#rd_if_debug","title":"debug","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"off\"</code> Path: /routingDefaults/itineraryFilters  Enum values: <code>off</code> | <code>list-all</code> | <code>limit-to-search-window</code> | <code>limit-to-num-of-itineraries</code></p> <p>Enable this to attach a system notice to itineraries instead of removing them. This is very convenient when tuning the itinerary-filter-chain.</p> <ul> <li><code>off</code> By default, the debug itinerary filters is turned off.</li> <li><code>list-all</code> List all itineraries, including all deleted itineraries.</li> <li><code>limit-to-search-window</code> Return all itineraries, including deleted ones, inside the actual search-window used    (the requested search-window may differ).</li> <li><code>limit-to-num-of-itineraries</code> Only return the requested number of itineraries, counting both actual and deleted ones.    The top <code>numItineraries</code> using the request sort order is returned. This does not work    with paging, itineraries after the limit, but inside the search-window are skipped when    moving to the next page.</li> </ul>"},{"location":"RouteRequest/#rd_if_filterItinerariesWithSameFirstOrLastTrip","title":"filterItinerariesWithSameFirstOrLastTrip","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>If more than one itinerary begins or ends with same trip, filter out one of those itineraries so that only one remains.</p> <p>Trips are considered equal if they have same id and same service day. Non-transit legs are skipped during comparison. Before filtering, trips are sorted by their generalized cost. The algorithm loops through the list from top to bottom. If an itinerary matches from any other itinerary from above, it is removed from list.</p>"},{"location":"RouteRequest/#rd_if_groupedOtherThanSameLegsMaxCostMultiplier","title":"groupedOtherThanSameLegsMaxCostMultiplier","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter grouped itineraries, where the non-grouped legs are more expensive than in the lowest cost one.</p> <p>Of the itineraries grouped to maximum of three itineraries, how much worse can the non-grouped legs be compared to the lowest cost. 2.0 means that they can be double the cost, and any itineraries having a higher cost will be filtered.</p>"},{"location":"RouteRequest/#rd_if_minBikeParkingDistance","title":"minBikeParkingDistance","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter out bike park+ride results that have fewer meters of cycling than this value.</p> <p>Useful if you want to exclude those routes which have only a few meters of cycling before parking the bike and taking public transport.</p>"},{"location":"RouteRequest/#rd_if_nonTransitGeneralizedCostLimit","title":"nonTransitGeneralizedCostLimit","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"1h + 2.0 t\"</code> Path: /routingDefaults/itineraryFilters </p> <p>The function define a max-limit for generalized-cost for non-transit itineraries.</p> <p>The max-limit is applied to itineraries with no transit legs, however all itineraries (including those with transit legs) are considered when calculating the minimum cost. The smallest generalized-cost value is used as input to the function. The function is used to calculate a max-limit. The max-limit is then used to filter non-transit itineraries by generalized-cost. Itineraries with a cost higher than the max-limit are dropped from the result set.</p> <p>For example if the function is <code>f(x) = 30m + 2.0 x</code> and the smallest cost is <code>30m = 1800s</code>, then all non-transit itineraries with a cost larger than <code>1800 + 2 * 5000 = 11 800</code> are dropped.</p>"},{"location":"RouteRequest/#rd_if_parkAndRideDurationRatio","title":"parkAndRideDurationRatio","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter P+R routes that consist of driving and walking by the minimum fraction of the driving using of time.</p> <p>This filters out results that consist of driving plus a very long walk leg at the end. A value of <code>0.3</code> means that a minimum of 30% of the total time must be spent in the car in order for the result to be included. However, if there is only a single result, it is never filtered.</p>"},{"location":"RouteRequest/#rd_if_removeItinerariesWithSameRoutesAndStops","title":"removeItinerariesWithSameRoutesAndStops","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>Set to true if you want to list only the first itinerary  which goes through the same stops and routes.</p> <p>Itineraries visiting the same set of stops and riding the exact same routes, departing later are removed from the result.</p>"},{"location":"RouteRequest/#rd_if_removeTransitWithHigherCostThanBestOnStreetOnly","title":"removeTransitWithHigherCostThanBestOnStreetOnly","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"1m + 1.30 t\"</code> Path: /routingDefaults/itineraryFilters </p> <p>Limit function for generalized-cost computed from street-only itineries applied to transit itineraries.</p> <p>The max-limit is applied to itineraries with transit legs, and only itineraries without transit legs are considered when calculating the minimum cost. The smallest generalized-cost value is used as input to the function. The function is used to calculate a max-limit. The max-limit is then used to filter transit itineraries by generalized-cost. Itineraries with a cost higher than the max-limit are dropped from the result set. Walking is handled with a different logic: if a transit itinerary has higher cost than a plain walk itinerary, it will be removed even if the cost limit function would keep it.</p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit","title":"transitGeneralizedCostLimit","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/itineraryFilters </p> <p>A relative limit for the generalized-cost for transit itineraries.</p> <p>The filter compares all itineraries against every other itinerary. If the generalized-cost plus a <code>transitGeneralizedCostLimit</code> is higher than the other generalized-cost, then the itinerary is dropped. The <code>transitGeneralizedCostLimit</code> is calculated using the <code>costLimitFunction</code> plus a relative cost for the distance in time between the itineraries. The relative cost is the <code>intervalRelaxFactor</code> multiplied with the interval in seconds. To set the <code>costLimitFunction</code> to be 1 hour plus 2 times cost use: <code>3600 + 2.0 x</code>. To set an absolute value(3000s) use: <code>3000 + 0x</code></p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit_costLimitFunction","title":"costLimitFunction","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"15m + 1.50 t\"</code> Path: /routingDefaults/itineraryFilters/transitGeneralizedCostLimit </p> <p>The base function used by the filter.</p> <p>This function calculates the threshold for the filter, when the itineraries have exactly the same arrival and departure times.</p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit_intervalRelaxFactor","title":"intervalRelaxFactor","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.4</code> Path: /routingDefaults/itineraryFilters/transitGeneralizedCostLimit </p> <p>How much the filter should be relaxed for itineraries that do not overlap in time.</p> <p>This value is used to increase the filter threshold for itineraries further away in time, compared to those, that have exactly the same arrival and departure times.</p> <p>The unit is cost unit per second of time difference.</p>"},{"location":"RouteRequest/#rd_maxDirectStreetDurationForMode","title":"maxDirectStreetDurationForMode","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Limit direct route duration per street mode.</p> <p>Override the settings in <code>maxDirectStreetDuration</code> for specific street modes. This is done because some street modes searches are much more resource intensive than others.</p>"},{"location":"RouteRequest/#rd_transferOptimization","title":"transferOptimization","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Optimize where a transfer between to trip happens. </p> <p>The main purpose of transfer optimization is to handle cases where it is possible to transfer between two routes at more than one point (pair of stops). The transfer optimization ensures that transfers occur at the best possible location. By post-processing all paths returned by the router, OTP can apply sophisticated calculations that are too slow or not algorithmically valid within Raptor. Transfers are optimized is done after the Raptor search and before the paths are passed to the itinerary-filter-chain.</p> <p>To toggle transfer optimization on or off use the OTPFeature <code>OptimizeTransfers</code> (default is on). You should leave this on unless there is a critical issue with it. The OTPFeature <code>GuaranteedTransfers</code> will toggle on and off the priority optimization (part of OptimizeTransfers).</p> <p>The optimized transfer service will try to, in order:</p> <ol> <li>Use transfer priority. This includes stay-seated and guaranteed transfers.</li> <li>Use the transfers with the best distribution of the wait-time, and avoid very short transfers.</li> <li>Avoid back-travel</li> <li>Boost stop-priority to select preferred and recommended stops.</li> </ol> <p>If two paths have the same transfer priority level, then we break the tie by looking at waiting times. The goal is to maximize the wait-time for each stop, avoiding situations where there is little time available to make the transfer. This is balanced with the generalized-cost. The cost is adjusted with a new cost for wait-time (optimized-wait-time-cost).</p> <p>The defaults should work fine, but if you have results with short wait-times dominating a better option or \"back-travel\", then try to increase the <code>minSafeWaitTimeFactor</code>, <code>backTravelWaitTimeFactor</code> and/or <code>extraStopBoardAlightCostsFactor</code>.</p> <p>For details on the logic/design see transfer optimization package documentation.</p>"},{"location":"RouteRequest/#rd_to_backTravelWaitTimeFactor","title":"backTravelWaitTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/transferOptimization </p> <p>To reduce back-travel we favor waiting, this reduces the cost of waiting.</p> <p>The wait time is used to prevent back-travel, the <code>backTravelWaitTimeFactor</code> is multiplied with the wait-time and subtracted from the optimized-transfer-cost.</p>"},{"location":"RouteRequest/#rd_to_extraStopBoardAlightCostsFactor","title":"extraStopBoardAlightCostsFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/transferOptimization </p> <p>Add an extra board- and alight-cost for prioritized stops.</p> <p>A stopBoardAlightCosts is added to the generalized-cost during routing. But this cost cannot be too high, because that would add extra cost to the transfer, and favor other alternative paths. But, when optimizing transfers, we do not have to take other paths into consideration and can boost the stop-priority-cost to allow transfers to take place at a preferred stop. The cost added during routing is already added to the generalized-cost used as a base in the optimized transfer calculation. By setting this parameter to 0, no extra cost is added, by setting it to <code>1.0</code> the stop-cost is doubled. Stop priority is only supported by the NeTEx import, not GTFS.</p>"},{"location":"RouteRequest/#rd_to_minSafeWaitTimeFactor","title":"minSafeWaitTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>5.0</code> Path: /routingDefaults/transferOptimization </p> <p>Used to set a maximum wait-time cost, base on min-safe-transfer-time.</p> <p>This defines the maximum cost for the logarithmic function relative to the min-safe-transfer-time (t0) when wait time goes towards zero(0). f(0) = n * t0</p>"},{"location":"RouteRequest/#rd_to_optimizeTransferWaitTime","title":"optimizeTransferWaitTime","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>true</code> Path: /routingDefaults/transferOptimization </p> <p>This enables the transfer wait time optimization.</p> <p>If not enabled generalizedCost function is used to pick the optimal transfer point.</p>"},{"location":"RouteRequest/#rd_transitGroupPriority","title":"transitGroupPriority","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Group transit patterns and give each group a mutual advantage in the Raptor search.</p> <p>Use this to separate transit patterns into groups. Each group will be given a group-id. A path (multiple legs) will then have a set of group-ids based on the group-id from each leg. Hence, two paths with a different set of group-ids will BOTH be optimal unless the cost is worse than the relaxation specified in the <code>relaxTransitGroupPriority</code> parameter. This is only available in the TransmodelAPI for now.</p> <p>Unmatched patterns are put in the BASE priority-group.</p> <p>THIS IS STILL AN EXPERIMENTAL FEATURE - IT MAY CHANGE WITHOUT ANY NOTICE!</p>"},{"location":"RouteRequest/#rd_transitReluctanceForMode","title":"transitReluctanceForMode","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>enum map of double</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>Transit reluctance for a given transport mode</p>"},{"location":"RouteRequest/#rd_unpreferred","title":"unpreferred","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Parameters listing authorities or lines that preferably should not be used in trip patters.</p> <p>A cost is applied to boarding nonpreferred authorities or routes.</p> <p>The routing engine will add extra penalty - on the unpreferred routes and/or agencies using a cost function. The cost function (<code>unpreferredCost</code>) is defined as a linear function of the form <code>A + B x</code>, where <code>A</code> is a fixed cost (in seconds) and <code>B</code> is reluctance multiplier for transit leg travel time <code>x</code> (in seconds).</p>"},{"location":"RouteRequest/#rd_unpreferred_agencies","title":"agencies","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>feed-scoped-id[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/unpreferred </p> <p>The ids of the agencies that incur an extra cost when being used. Format: <code>FeedId:AgencyId</code></p> <p>How much cost is added is configured in <code>unpreferredCost</code>.</p>"},{"location":"RouteRequest/#rd_unpreferred_routes","title":"routes","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>feed-scoped-id[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/unpreferred </p> <p>The ids of the routes that incur an extra cost when being used. Format: <code>FeedId:RouteId</code></p> <p>How much cost is added is configured in <code>unpreferredCost</code>.</p>"},{"location":"RouteRequest/#rd_walk_reluctance","title":"reluctance","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: /routingDefaults/walk </p> <p>A multiplier for how bad walking is, compared to being in transit for equal lengths of time.</p> <p>Empirically, values between 2 and 4 seem to correspond well to the concept of not wanting to walk too much without asking for totally ridiculous itineraries, but this observation should in no way be taken as scientific or definitive. Your mileage may vary. See https://github.com/opentripplanner/OpenTripPlanner/issues/4090 for impact on performance with high values.</p>"},{"location":"RouteRequest/#rd_walk_safetyFactor","title":"safetyFactor","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/walk </p> <p>Factor for how much the walk safety is considered in routing.</p> <p>Value should be between 0 and 1. If the value is set to be 0, safety is ignored.</p>"},{"location":"RouteRequest/#rd_walk_stairsTimeFactor","title":"stairsTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>3.0</code> Path: /routingDefaults/walk </p> <p>How much more time does it take to walk a flight of stairs compared to walking a similar horizontal length.</p> <p>Default value is based on: Fujiyama, T., &amp; Tyler, N. (2010). Predicting the walking speed of pedestrians on stairs. Transportation Planning and Technology, 33(2), 177\u2013202.</p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_maxSlope","title":"maxSlope","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.083</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>The maximum slope as a fraction of 1.</p> <p>9 percent would be <code>0.09</code></p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_slopeExceededReluctance","title":"slopeExceededReluctance","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>How much streets with high slope should be avoided.</p> <p>What factor should be given to street edges, which are over the max slope. The penalty is not static but scales with how much you exceed the maximum slope. Set to negative to disable routing on too steep edges.</p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_stairsReluctance","title":"stairsReluctance","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>100.0</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>How much stairs should be avoided.</p> <p>Stairs are not completely excluded for wheelchair users but severely punished. This value determines how much they are punished. This should be a very high value as you want to only include stairs as a last result.</p>"},{"location":"RouteRequest/#config-example","title":"Config Example","text":"<pre><code>// router-config.json\n{\n  \"routingDefaults\" : {\n    \"numItineraries\" : 12,\n    \"transferPenalty\" : 0,\n    \"turnReluctance\" : 1.0,\n    \"elevatorBoardTime\" : 90,\n    \"elevatorBoardCost\" : 90,\n    \"elevatorHopTime\" : 20,\n    \"elevatorHopCost\" : 20,\n    \"bicycle\" : {\n      \"speed\" : 5,\n      \"reluctance\" : 5.0,\n      \"boardCost\" : 600,\n      \"walk\" : {\n        \"reluctance\" : 10.0,\n        \"stairsReluctance\" : 150.0\n      },\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"1m\",\n        \"cost\" : 120\n      },\n      \"triangle\" : {\n        \"safety\" : 0.4,\n        \"flatness\" : 0.3,\n        \"time\" : 0.3\n      }\n    },\n    \"car\" : {\n      \"speed\" : 40,\n      \"reluctance\" : 10,\n      \"decelerationSpeed\" : 2.9,\n      \"accelerationSpeed\" : 2.9,\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"5m\",\n        \"cost\" : 600\n      }\n    },\n    \"walk\" : {\n      \"speed\" : 1.3,\n      \"reluctance\" : 4.0,\n      \"stairsReluctance\" : 1.65,\n      \"boardCost\" : 600,\n      \"escalatorReluctance\" : 1.5\n    },\n    \"waitReluctance\" : 1.0,\n    \"otherThanPreferredRoutesPenalty\" : 300,\n    \"transferSlack\" : 120,\n    \"boardSlackForMode\" : {\n      \"AIRPLANE\" : \"35m\"\n    },\n    \"alightSlackForMode\" : {\n      \"AIRPLANE\" : \"15m\"\n    },\n    \"transitReluctanceForMode\" : {\n      \"RAIL\" : 0.85\n    },\n    \"accessEgress\" : {\n      \"maxDuration\" : \"45m\",\n      \"maxDurationForMode\" : {\n        \"BIKE_RENTAL\" : \"20m\"\n      },\n      \"maxStopCount\" : 500,\n      \"penalty\" : {\n        \"FLEXIBLE\" : {\n          \"timePenalty\" : \"2m + 1.1t\",\n          \"costFactor\" : 1.7\n        }\n      }\n    },\n    \"itineraryFilters\" : {\n      \"transitGeneralizedCostLimit\" : {\n        \"costLimitFunction\" : \"15m + 1.5 x\",\n        \"intervalRelaxFactor\" : 0.4\n      },\n      \"nonTransitGeneralizedCostLimit\" : \"400 + 1.5x\",\n      \"removeTransitWithHigherCostThanBestOnStreetOnly\" : \"60 + 1.3x\",\n      \"bikeRentalDistanceRatio\" : 0.3,\n      \"accessibilityScore\" : true,\n      \"minBikeParkingDistance\" : 300,\n      \"debug\" : \"limit-to-search-window\"\n    },\n    \"ignoreRealtimeUpdates\" : false,\n    \"geoidElevation\" : false,\n    \"maxJourneyDuration\" : \"36h\",\n    \"unpreferred\" : {\n      \"agencies\" : [\n        \"HSL:123\"\n      ],\n      \"routes\" : [\n        \"HSL:456\"\n      ]\n    },\n    \"unpreferredCost\" : \"10m + 2.0 x\",\n    \"streetRoutingTimeout\" : \"5s\",\n    \"transferOptimization\" : {\n      \"optimizeTransferWaitTime\" : true,\n      \"minSafeWaitTimeFactor\" : 5.0,\n      \"backTravelWaitTimeFactor\" : 1.0,\n      \"extraStopBoardAlightCostsFactor\" : 8.0\n    },\n    \"wheelchairAccessibility\" : {\n      \"trip\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"stop\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"elevator\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 20,\n        \"inaccessibleCost\" : 3600\n      },\n      \"inaccessibleStreetReluctance\" : 25,\n      \"maxSlope\" : 0.083,\n      \"slopeExceededReluctance\" : 1,\n      \"stairsReluctance\" : 100\n    }\n  }\n}\n</code></pre>"},{"location":"RouterConfiguration/","title":"Router","text":""},{"location":"RouterConfiguration/#router-configuration","title":"Router configuration","text":"<p>This section covers all options that can be set for each router using the <code>router-config.json</code> file. These options can be applied by the OTP server without rebuilding the graph.</p>"},{"location":"RouterConfiguration/#configure-using-command-line-arguments","title":"Configure using command-line arguments","text":"<p>Certain settings can be provided on the command line, when starting OpenTripPlanner. See the <code>CommandLineParameters</code> class for a full list of arguments .</p>"},{"location":"RouterConfiguration/#routing-defaults","title":"Routing defaults","text":"<p>There are many trip planning options used in the OTP web API, and more exist internally that are not exposed via the API. You may want to change the default value for some of these parameters, i.e. the value which will be applied unless it is overridden in a web API request.</p> <p>A full list of them can be found in the RouteRequest.</p>"},{"location":"RouterConfiguration/#parameter-summary","title":"Parameter Summary","text":"Config Parameter Type Summary Req./Opt. Default Value Since configVersion <code>string</code> Deployment version of the router-config.json. Optional 2.1 flex <code>object</code> Configuration for flex routing. Optional 2.1 rideHailingServices <code>object[]</code> Configuration for interfaces to external ride hailing services like Uber. Optional 2.3 routingDefaults <code>object</code> The default parameters for the routing query. Optional 2.0 server <code>object</code> Configuration for router server. Optional 2.4 apiProcessingTimeout <code>duration</code> Maximum processing time for an API request Optional <code>\"PT-1S\"</code> 2.4 traceParameters <code>object[]</code> Trace OTP request using HTTP request/response parameter(s) combined with logging. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0generateIdIfMissing <code>boolean</code> If <code>true</code> a unique value is generated if no http request header is provided, or the value is missing. Optional <code>false</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0httpRequestHeader <code>string</code> The header-key to use when fetching the trace parameter value Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0httpResponseHeader <code>string</code> The header-key to use when saving the value back into the http response Optional 2.4 logKey <code>string</code> The log event key used. Optional 2.4 timetableUpdates <code>object</code> Global configuration for timetable updaters. Optional 2.2 maxSnapshotFrequency <code>duration</code> How long a snapshot should be cached. Optional <code>\"PT1S\"</code> 2.2 \u00a0\u00a0\u00a0purgeExpiredData <code>boolean</code> Should expired real-time data be purged from the graph. Apply to GTFS-RT and Siri updates. Optional <code>true</code> 2.2 transit <code>object</code> Configuration for transit searches with RAPTOR. Optional na iterationDepartureStepInSeconds <code>integer</code> Step for departure times between each RangeRaptor iterations. Optional <code>60</code> na maxNumberOfTransfers <code>integer</code> This parameter is used to allocate enough memory space for Raptor. Optional <code>12</code> na maxSearchWindow <code>duration</code> Upper limit of the request parameter searchWindow. Optional <code>\"PT24H\"</code> 2.4 scheduledTripBinarySearchThreshold <code>integer</code> This threshold is used to determine when to perform a binary trip schedule search. Optional <code>50</code> na searchThreadPoolSize <code>integer</code> Split a travel search in smaller jobs and run them in parallel to improve performance. Optional <code>0</code> na transferCacheMaxSize <code>integer</code> The maximum number of distinct transfers parameters to cache pre-calculated transfers for. Optional <code>25</code> na dynamicSearchWindow <code>object</code> The dynamic search window coefficients used to calculate the EDT, LAT and SW. Optional 2.1 maxWindow <code>duration</code> Upper limit for the search-window calculation. Optional <code>\"PT3H\"</code> 2.2 minTransitTimeCoefficient <code>double</code> The coefficient to multiply with <code>minTransitTime</code>. Optional <code>0.5</code> 2.1 minWaitTimeCoefficient <code>double</code> The coefficient to multiply with <code>minWaitTime</code>. Optional <code>0.5</code> 2.1 minWindow <code>duration</code> The constant minimum duration for a raptor-search-window. Optional <code>\"PT40M\"</code> 2.2 stepMinutes <code>integer</code> Used to set the steps the search-window is rounded to. Optional <code>10</code> 2.1 pagingSearchWindowAdjustments <code>duration[]</code> The provided array of durations is used to increase the search-window for the next/previous page. Optional na stopTransferCost <code>enum map of integer</code> Use this to set a stop transfer cost for the given transfer priority Optional 2.0 transferCacheRequests <code>object[]</code> Routing requests to use for pre-filling the stop-to-stop transfer cache. Optional 2.3 transmodelApi <code>object</code> Configuration for the Transmodel GraphQL API. Optional 2.1 hideFeedId <code>boolean</code> Hide the FeedId in all API output, and add it to input. Optional <code>false</code> na tracingHeaderTags <code>string[]</code> Used to group requests when monitoring OTP. Optional na updaters <code>object[]</code> Configuration for the updaters that import various types of data into OTP. Optional 1.5 vectorTiles <code>object</code> Vector tile configuration Optional na vehicleRentalServiceDirectory <code>object</code> Configuration for the vehicle rental service directory. Optional 2.0"},{"location":"RouterConfiguration/#parameter-details","title":"Parameter Details","text":""},{"location":"RouterConfiguration/#configVersion","title":"configVersion","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Deployment version of the router-config.json.</p> <p>The config-version is a parameter which each OTP deployment may set to be able to query the OTP server and verify that it uses the correct version of the config. The version should be injected into the config in the (continuous) deployment pipeline. How this is done, is up to the deployment.</p> <p>The config-version has no effect on OTP, and is provided as is on the API. There is no syntax or format check on the version and it can be any string.</p> <p>Be aware that OTP uses the config embedded in the loaded graph if no new config is provided.</p>"},{"location":"RouterConfiguration/#server","title":"server","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configuration for router server.</p> <p>These parameters are used to configure the router server. Many parameters are specific to a domain, these are set in the routing request.</p>"},{"location":"RouterConfiguration/#server_apiProcessingTimeout","title":"apiProcessingTimeout","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT-1S\"</code> Path: /server </p> <p>Maximum processing time for an API request</p> <p>This timeout limits the server-side processing time for a given API request. This does not include network latency nor waiting time in the HTTP server thread pool. The default value is <code>-1s</code>(no timeout). The timeout is applied to all APIs (REST, Transmodel &amp; GTFS GraphQL). The timeout is not enforced when the parallel routing OTP feature is in use.</p>"},{"location":"RouterConfiguration/#server_traceParameters","title":"traceParameters","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /server </p> <p>Trace OTP request using HTTP request/response parameter(s) combined with logging.</p> <p>OTP supports tracing user requests across log events and \"outside\" services. OTP can insert http-request-header parameters into all associated log events and into the http response. If the value is not present in the request, a unique value can be generated. The OTP generated value is a 6 characters long base 36[0-9a-z] character string.</p> <p>Use-case Correlation-ID</p> <p>A common use-case in a service oriented environment is to use a correlation-id to identify all log messages across multiple (micro-)services from the same user. This is done by setting the \"X-Correlation-ID\" http header in the http facade/gateway. Use the \"traceParameters\" to configure OTP to pick up the correlation id, insert it into the logs and return it. See the example below on how-to configure the \"server.traceParameters\" instance.</p>"},{"location":"RouterConfiguration/#server_traceParameters_0_logKey","title":"logKey","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /server/traceParameters/[0] </p> <p>The log event key used.</p> <p>OTP stores the key/value pair in the log MDC(Mapped Diagnostic Context). To use it you normally include the key in the log pattern like this: <code>%X{LOG-KEY}</code>. See your log framework for details. Only log4j and logback support this.</p>"},{"location":"RouterConfiguration/#timetableUpdates_maxSnapshotFrequency","title":"maxSnapshotFrequency","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT1S\"</code> Path: /timetableUpdates </p> <p>How long a snapshot should be cached.</p> <p>If a timetable snapshot is requested less than this number of milliseconds after the previous snapshot, then return the same instance. Throttles the potentially resource-consuming task of duplicating a TripPattern \u2192 Timetable map and indexing the new Timetables. Applies to GTFS-RT and Siri updates.</p>"},{"location":"RouterConfiguration/#transit","title":"transit","text":"<p>Since version: <code>na</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configuration for transit searches with RAPTOR.</p> <p>Some of these parameters for tuning transit routing are only available through configuration and cannot be set in the routing request. These parameters work together with the default routing request and the actual routing request.</p>"},{"location":"RouterConfiguration/#transit_iterationDepartureStepInSeconds","title":"iterationDepartureStepInSeconds","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>60</code> Path: /transit </p> <p>Step for departure times between each RangeRaptor iterations.</p> <p>This is a performance optimization parameter. A transit network usually uses minute resolution for the timetables, so to match that, set this variable to 60 seconds. Setting it to less than 60 will not give better result, but degrade performance. Setting it to 120 seconds will improve performance, but you might get a slack of 60 seconds somewhere in the result.</p>"},{"location":"RouterConfiguration/#transit_maxNumberOfTransfers","title":"maxNumberOfTransfers","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>12</code> Path: /transit </p> <p>This parameter is used to allocate enough memory space for Raptor.</p> <p>Set it to the maximum number of transfers for any given itinerary expected to be found within the entire transit network. The memory overhead of setting this higher than the maximum number of transfers is very little so it is better to set it too high than to low.</p>"},{"location":"RouterConfiguration/#transit_maxSearchWindow","title":"maxSearchWindow","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT24H\"</code> Path: /transit </p> <p>Upper limit of the request parameter searchWindow.</p> <p>Maximum search window that can be set through the searchWindow API parameter. Due to the way timetable data are collected before a Raptor trip search, using a search window larger than 24 hours may lead to inconsistent search results. Limiting the search window prevents also potential performance issues. The recommended maximum value is 24 hours. This parameter does not restrict the maximum duration of a dynamic search window (use the parameter <code>transit.dynamicSearchWindow.maxWindow</code> to specify such a restriction).</p>"},{"location":"RouterConfiguration/#transit_scheduledTripBinarySearchThreshold","title":"scheduledTripBinarySearchThreshold","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>50</code> Path: /transit </p> <p>This threshold is used to determine when to perform a binary trip schedule search.</p> <p>This reduce the number of trips departure time lookups and comparisons. When testing with data from Entur and all of Norway as a Graph, the optimal value was about 50. If you calculate the departure time every time or want to fine tune the performance, changing this may improve the performance a few percents.</p>"},{"location":"RouterConfiguration/#transit_searchThreadPoolSize","title":"searchThreadPoolSize","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /transit </p> <p>Split a travel search in smaller jobs and run them in parallel to improve performance.</p> <p>Use this parameter to set the total number of executable threads available across all searches. Multiple searches can run in parallel - this parameter have no effect with regard to that. If 0, no extra threads are started and the search is done in one thread.</p>"},{"location":"RouterConfiguration/#transit_transferCacheMaxSize","title":"transferCacheMaxSize","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>25</code> Path: /transit </p> <p>The maximum number of distinct transfers parameters to cache pre-calculated transfers for.</p> <p>If too low, requests may be slower. If too high, more memory may be used then required.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow","title":"dynamicSearchWindow","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /transit </p> <p>The dynamic search window coefficients used to calculate the EDT, LAT and SW.</p> <p>The dynamic search window coefficients is used to calculate EDT(earliest-departure-time), LAT(latest-arrival-time) and SW(raptor-search-window) request parameters using heuristics. The heuristics perform a Raptor search (one-iteration) to find a trip which we use to find a lower bound for the travel duration time - the \"minTransitTime\". The heuristic search is used for other purposes too, and is very fast.</p> <p>At least the EDT or the LAT must be passed into Raptor to perform a Range Raptor search. If unknown/missing the parameters(EDT, LAT, DW) are dynamically calculated. The dynamic coefficients affect the performance and should be tuned to match the deployment.</p> <p>The request parameters are calculated like this:</p> <pre><code>    DW  = round_N(C + T * minTransitTime + W * minWaitTime)\n    LAT = EDT + DW + minTransitTime\n    EDT = LAT - (DW + minTransitTime)\n</code></pre> <p>The <code>round_N(...)</code> method rounds the input to the closest multiplication of N.</p> <p>The 3 coefficients above are:</p> <ul> <li><code>C</code> is parameter: <code>minWindow</code></li> <li><code>T</code> is parameter: <code>minTransitTimeCoefficient</code></li> <li><code>W</code> is parameter: <code>minWaitTimeCoefficient</code></li> <li><code>N</code> is parameter: <code>stepMinutes</code></li> </ul> <p>In addition there is an upper bound on the calculation of the search window: <code>maxWindow</code>.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_maxWindow","title":"maxWindow","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT3H\"</code> Path: /transit/dynamicSearchWindow </p> <p>Upper limit for the search-window calculation.</p> <p>Long search windows consumes a lot of resources and may take a long time. Use this parameter to tune the desired maximum search time.</p> <p>This is the parameter that affects the response time most, the downside is that a search is only guaranteed to be pareto-optimal within a search-window.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minTransitTimeCoefficient","title":"minTransitTimeCoefficient","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.5</code> Path: /transit/dynamicSearchWindow </p> <p>The coefficient to multiply with <code>minTransitTime</code>.</p> <p>Use a value between <code>0.0</code> and <code>3.0</code>. Using <code>0.0</code> will eliminate the <code>minTransitTime</code> from the dynamic raptor-search-window calculation.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minWaitTimeCoefficient","title":"minWaitTimeCoefficient","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.5</code> Path: /transit/dynamicSearchWindow </p> <p>The coefficient to multiply with <code>minWaitTime</code>.</p> <p>Use a value between <code>0.0</code> and <code>1.0</code>. Using <code>0.0</code> will eliminate the <code>minWaitTime</code> from the dynamic raptor-search-window calculation.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minWindow","title":"minWindow","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT40M\"</code> Path: /transit/dynamicSearchWindow </p> <p>The constant minimum duration for a raptor-search-window. </p> <p>Use a value between 20 and 180 minutes in a normal deployment.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_stepMinutes","title":"stepMinutes","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10</code> Path: /transit/dynamicSearchWindow </p> <p>Used to set the steps the search-window is rounded to.</p> <p>The search window is rounded off to the closest multiplication of <code>stepMinutes</code>. If <code>stepMinutes</code> = 10 minutes, the search-window can be 10, 20, 30 ... minutes. It the computed search-window is 5 minutes and 17 seconds it will be rounded up to 10 minutes.</p> <p>Use a value between <code>1</code> and <code>60</code>. This should be less than the <code>min-raptor-search-window</code> coefficient.</p>"},{"location":"RouterConfiguration/#transit_pagingSearchWindowAdjustments","title":"pagingSearchWindowAdjustments","text":"<p>Since version: <code>na</code> \u2219 Type: <code>duration[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transit </p> <p>The provided array of durations is used to increase the search-window for the next/previous page.</p> <p>The search window is expanded when the current page return few options. If ZERO result is returned the first duration in the list is used, if ONE result is returned then the second duration is used and so on. The duration is added to the existing search-window and inserted into the next and previous page cursor. See JavaDoc for TransitTuningParameters#pagingSearchWindowAdjustments\" + for more info.\"</p>"},{"location":"RouterConfiguration/#transit_stopTransferCost","title":"stopTransferCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of integer</code> \u2219 Cardinality: <code>Optional</code> Path: /transit  Enum keys: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Use this to set a stop transfer cost for the given transfer priority</p> <p>The cost is applied to boarding and alighting at all stops. All stops have a transfer cost priority set, the default is <code>allowed</code>. The <code>stopTransferCost</code> parameter is optional, but if listed all values must be set.</p> <p>If not set the <code>stopTransferCost</code> is ignored. This is only available for NeTEx imported Stops.</p> <p>The cost is a scalar, but is equivalent to the felt cost of riding a transit trip for 1 second.</p> Config key Description Type <code>discouraged</code> Use a very high cost like <code>72 000</code> to eliminate transfers at the stop if not the only option. int <code>allowed</code> Allowed, but not recommended. Use something like <code>150</code>. int <code>recommended</code> Use a small cost penalty like <code>60</code>. int <code>preferred</code> The best place to do transfers. Should be set to <code>0</code>(zero). int <p>Use values in a range from <code>0</code> to <code>100 000</code>. All key/value pairs are required if the <code>stopTransferCost</code> is listed.</p>"},{"location":"RouterConfiguration/#transit_transferCacheRequests","title":"transferCacheRequests","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transit \u2219 See: RouteRequest.md </p> <p>Routing requests to use for pre-filling the stop-to-stop transfer cache.</p> <p>If not set, the default behavior is to cache stop-to-stop transfers using the default route request (<code>routingDefaults</code>). Use this to change the default or specify more than one <code>RouteRequest</code>.</p> <p>Example</p> <pre><code>// router-config.json\n{\n  \"transit\": {\n    \"transferCacheRequests\": [\n      { \"modes\": \"WALK\"                                                     },\n      { \"modes\": \"WALK\",    \"wheelchairAccessibility\": { \"enabled\": true  } }\n    ]\n  }\n}\n</code></pre>"},{"location":"RouterConfiguration/#transmodelApi_hideFeedId","title":"hideFeedId","text":"<p>Since version: <code>na</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /transmodelApi </p> <p>Hide the FeedId in all API output, and add it to input.</p> <p>Only turn this feature on if you have unique ids across all feeds, without the feedId prefix.</p>"},{"location":"RouterConfiguration/#transmodelApi_tracingHeaderTags","title":"tracingHeaderTags","text":"<p>Since version: <code>na</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transmodelApi </p> <p>Used to group requests when monitoring OTP.</p>"},{"location":"RouterConfiguration/#router-config-example","title":"Router Config Example","text":"<pre><code>// router-config.json\n{\n  \"configVersion\" : \"v2.4.0-EN000121\",\n  \"server\" : {\n    \"apiProcessingTimeout\" : \"7s\",\n    \"traceParameters\" : [\n      {\n        \"httpRequestHeader\" : \"X-Correlation-ID\",\n        \"httpResponseHeader\" : \"X-Correlation-ID\",\n        \"logKey\" : \"correlationId\",\n        \"generateIdIfMissing\" : true\n      }\n    ]\n  },\n  \"routingDefaults\" : {\n    \"numItineraries\" : 12,\n    \"transferPenalty\" : 0,\n    \"turnReluctance\" : 1.0,\n    \"elevatorBoardTime\" : 90,\n    \"elevatorBoardCost\" : 90,\n    \"elevatorHopTime\" : 20,\n    \"elevatorHopCost\" : 20,\n    \"bicycle\" : {\n      \"speed\" : 5,\n      \"reluctance\" : 5.0,\n      \"boardCost\" : 600,\n      \"walk\" : {\n        \"reluctance\" : 10.0,\n        \"stairsReluctance\" : 150.0\n      },\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"1m\",\n        \"cost\" : 120\n      },\n      \"triangle\" : {\n        \"safety\" : 0.4,\n        \"flatness\" : 0.3,\n        \"time\" : 0.3\n      }\n    },\n    \"car\" : {\n      \"speed\" : 40,\n      \"reluctance\" : 10,\n      \"decelerationSpeed\" : 2.9,\n      \"accelerationSpeed\" : 2.9,\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"5m\",\n        \"cost\" : 600\n      }\n    },\n    \"walk\" : {\n      \"speed\" : 1.3,\n      \"reluctance\" : 4.0,\n      \"stairsReluctance\" : 1.65,\n      \"boardCost\" : 600,\n      \"escalatorReluctance\" : 1.5\n    },\n    \"waitReluctance\" : 1.0,\n    \"otherThanPreferredRoutesPenalty\" : 300,\n    \"transferSlack\" : 120,\n    \"boardSlackForMode\" : {\n      \"AIRPLANE\" : \"35m\"\n    },\n    \"alightSlackForMode\" : {\n      \"AIRPLANE\" : \"15m\"\n    },\n    \"transitReluctanceForMode\" : {\n      \"RAIL\" : 0.85\n    },\n    \"accessEgress\" : {\n      \"maxDuration\" : \"45m\",\n      \"maxDurationForMode\" : {\n        \"BIKE_RENTAL\" : \"20m\"\n      },\n      \"maxStopCount\" : 500,\n      \"penalty\" : {\n        \"FLEXIBLE\" : {\n          \"timePenalty\" : \"2m + 1.1t\",\n          \"costFactor\" : 1.7\n        }\n      }\n    },\n    \"itineraryFilters\" : {\n      \"transitGeneralizedCostLimit\" : {\n        \"costLimitFunction\" : \"15m + 1.5 x\",\n        \"intervalRelaxFactor\" : 0.4\n      },\n      \"nonTransitGeneralizedCostLimit\" : \"400 + 1.5x\",\n      \"removeTransitWithHigherCostThanBestOnStreetOnly\" : \"60 + 1.3x\",\n      \"bikeRentalDistanceRatio\" : 0.3,\n      \"accessibilityScore\" : true,\n      \"minBikeParkingDistance\" : 300,\n      \"debug\" : \"limit-to-search-window\"\n    },\n    \"ignoreRealtimeUpdates\" : false,\n    \"geoidElevation\" : false,\n    \"maxJourneyDuration\" : \"36h\",\n    \"unpreferred\" : {\n      \"agencies\" : [\n        \"HSL:123\"\n      ],\n      \"routes\" : [\n        \"HSL:456\"\n      ]\n    },\n    \"unpreferredCost\" : \"10m + 2.0 x\",\n    \"streetRoutingTimeout\" : \"5s\",\n    \"transferOptimization\" : {\n      \"optimizeTransferWaitTime\" : true,\n      \"minSafeWaitTimeFactor\" : 5.0,\n      \"backTravelWaitTimeFactor\" : 1.0,\n      \"extraStopBoardAlightCostsFactor\" : 8.0\n    },\n    \"wheelchairAccessibility\" : {\n      \"trip\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"stop\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"elevator\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 20,\n        \"inaccessibleCost\" : 3600\n      },\n      \"inaccessibleStreetReluctance\" : 25,\n      \"maxSlope\" : 0.083,\n      \"slopeExceededReluctance\" : 1,\n      \"stairsReluctance\" : 100\n    }\n  },\n  \"flex\" : {\n    \"maxTransferDuration\" : \"5m\",\n    \"maxFlexTripDuration\" : \"45m\",\n    \"maxAccessWalkDuration\" : \"15m\",\n    \"maxEgressWalkDuration\" : \"15m\"\n  },\n  \"transit\" : {\n    \"maxNumberOfTransfers\" : 12,\n    \"dynamicSearchWindow\" : {\n      \"minTransitTimeCoefficient\" : 0.5,\n      \"minWaitTimeCoefficient\" : 0.5,\n      \"minWindow\" : \"1h\",\n      \"maxWindow\" : \"5h\"\n    },\n    \"stopTransferCost\" : {\n      \"DISCOURAGED\" : 1500,\n      \"ALLOWED\" : 75,\n      \"RECOMMENDED\" : 30,\n      \"PREFERRED\" : 0\n    },\n    \"transferCacheRequests\" : [\n      {\n        \"modes\" : \"WALK\"\n      },\n      {\n        \"modes\" : \"WALK\",\n        \"wheelchairAccessibility\" : {\n          \"enabled\" : true\n        }\n      }\n    ]\n  },\n  \"vehicleRentalServiceDirectory\" : {\n    \"url\" : \"https://entur.no/bikeRentalServiceDirectory\",\n    \"sourcesName\" : \"systems\",\n    \"updaterUrlName\" : \"url\",\n    \"updaterNetworkName\" : \"id\",\n    \"headers\" : {\n      \"ET-Client-Name\" : \"MY_ORG_CLIENT_NAME\"\n    }\n  },\n  \"transmodelApi\" : {\n    \"hideFeedId\" : true\n  },\n  \"vectorTiles\" : {\n    \"basePath\" : \"/otp_ct/vectorTiles\",\n    \"layers\" : [\n      {\n        \"name\" : \"stops\",\n        \"type\" : \"Stop\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"stations\",\n        \"type\" : \"Station\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 12,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"rentalPlaces\",\n        \"type\" : \"VehicleRental\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60,\n        \"expansionFactor\" : 0.25\n      },\n      {\n        \"name\" : \"rentalVehicle\",\n        \"type\" : \"VehicleRentalVehicle\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60\n      },\n      {\n        \"name\" : \"rentalStation\",\n        \"type\" : \"VehicleRentalStation\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"vehicleParking\",\n        \"type\" : \"VehicleParking\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60,\n        \"expansionFactor\" : 0.25\n      }\n    ]\n  },\n  \"timetableUpdates\" : {\n    \"purgeExpiredData\" : false,\n    \"maxSnapshotFrequency\" : \"2s\"\n  },\n  \"updaters\" : [\n    {\n      \"type\" : \"real-time-alerts\",\n      \"frequency\" : \"30s\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/FeedSpecAlerts/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Some-Header\" : \"A-Value\"\n      }\n    },\n    {\n      \"type\" : \"vehicle-rental\",\n      \"network\" : \"socialbicycles_coast\",\n      \"sourceType\" : \"gbfs\",\n      \"language\" : \"en\",\n      \"frequency\" : \"1m\",\n      \"allowKeepingRentedVehicleAtDestination\" : false,\n      \"geofencingZones\" : false,\n      \"url\" : \"http://coast.socialbicycles.com/opendata/gbfs.json\",\n      \"headers\" : {\n        \"Auth\" : \"&lt;any-token&gt;\",\n        \"&lt;key&gt;\" : \"&lt;value&gt;\"\n      }\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"hsl-park\",\n      \"feedId\" : \"hslpark\",\n      \"timeZone\" : \"Europe/Helsinki\",\n      \"facilitiesFrequencySec\" : 3600,\n      \"facilitiesUrl\" : \"https://p.hsl.fi/api/v1/facilities.json?limit=-1\",\n      \"utilizationsFrequencySec\" : 600,\n      \"utilizationsUrl\" : \"https://p.hsl.fi/api/v1/utilizations.json?limit=-1\",\n      \"hubsUrl\" : \"https://p.hsl.fi/api/v1/hubs.json?limit=-1\"\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"park-api\",\n      \"feedId\" : \"parkapi\",\n      \"timeZone\" : \"Europe/Berlin\",\n      \"frequency\" : \"10m\",\n      \"url\" : \"https://foo.bar\",\n      \"headers\" : {\n        \"Cache-Control\" : \"max-age=604800\"\n      },\n      \"tags\" : [\n        \"source:parkapi\"\n      ]\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"feedId\" : \"bikely\",\n      \"sourceType\" : \"bikely\",\n      \"url\" : \"https://api.safebikely.com/api/v1/s/locations\",\n      \"headers\" : {\n        \"X-Bikely-Token\" : \"${BIKELY_TOKEN}\",\n        \"Authorization\" : \"${BIKELY_AUTHORIZATION}\"\n      }\n    },\n    {\n      \"type\" : \"stop-time-updater\",\n      \"frequency\" : \"1m\",\n      \"backwardsDelayPropagationType\" : \"REQUIRED_NO_DATA\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/TripUpdate/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Authorization\" : \"A-Token\"\n      }\n    },\n    {\n      \"type\" : \"mqtt-gtfs-rt-updater\",\n      \"url\" : \"tcp://pred.rt.hsl.fi\",\n      \"topic\" : \"gtfsrt/v2/fi/hsl/tu\",\n      \"feedId\" : \"HSL\",\n      \"fuzzyTripMatching\" : true\n    },\n    {\n      \"type\" : \"vehicle-positions\",\n      \"url\" : \"https://s3.amazonaws.com/kcm-alerts-realtime-prod/vehiclepositions.pb\",\n      \"feedId\" : \"1\",\n      \"frequency\" : \"1m\",\n      \"headers\" : {\n        \"Header-Name\" : \"Header-Value\"\n      },\n      \"fuzzyTripMatching\" : false,\n      \"features\" : [\n        \"position\"\n      ]\n    },\n    {\n      \"type\" : \"siri-et-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Authorization\" : \"Some-Token\"\n      }\n    },\n    {\n      \"type\" : \"siri-sx-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Key\" : \"Value\"\n      }\n    },\n    {\n      \"type\" : \"siri-azure-sx-updater\",\n      \"topic\" : \"some_topic\",\n      \"servicebus-url\" : \"service_bus_url\",\n      \"feedId\" : \"feed_id\",\n      \"customMidnight\" : 4,\n      \"history\" : {\n        \"url\" : \"endpoint_url\",\n        \"fromDateTime\" : \"-P1D\",\n        \"toDateTime\" : \"P1D\",\n        \"timeout\" : 300000\n      }\n    }\n  ],\n  \"rideHailingServices\" : [\n    {\n      \"type\" : \"uber-car-hailing\",\n      \"clientId\" : \"secret-id\",\n      \"clientSecret\" : \"very-secret\",\n      \"wheelchairAccessibleProductId\" : \"545de0c4-659f-49c6-be65-0d5e448dffd5\",\n      \"bannedProductIds\" : [\n        \"1196d0dd-423b-4a81-a1d8-615367d3a365\",\n        \"f58761e5-8dd5-4940-a472-872f1236c596\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"RoutingModes/","title":"Routing modes","text":"<p>This page is intended as an exhaustive listing of what OTP's routing engine is capable of and  therefore documents internal names. Since OTP has multiple APIs where each works slightly differently, please consult your API documentation on how to select the appropriate mode.</p>"},{"location":"RoutingModes/#Street modes","title":"Street modes","text":"<p>Routing modes on streets, including walking, biking, driving, and car-sharing.</p>"},{"location":"RoutingModes/#BIKE","title":"BIKE","text":"<p>Cycling for the entirety of the route or taking a bicycle onto the public transport and cycling from the arrival station to the destination.</p>"},{"location":"RoutingModes/#BIKE_RENTAL","title":"BIKE_RENTAL","text":"<p>Taking a rented, shared-mobility bike for part or the entirety of the route.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#BIKE_TO_PARK","title":"BIKE_TO_PARK","text":"<p>Leaving the bicycle at the departure station and walking from the arrival station to the destination. This mode needs to be combined with at least one transit mode otherwise it behaves like an ordinary bicycle journey.</p> <p>Prerequisite: Bicycle parking stations present in the OSM file and visible to OTP by enabling the property <code>staticBikeParkAndRide</code> during graph build.</p>"},{"location":"RoutingModes/#CAR","title":"CAR","text":"<p>Driving your own car the entirety of the route. This can be combined with transit, where will return routes with a Kiss &amp; Ride component. This means that the car is not parked in a permanent parking area but rather the passenger is dropped off (for example, at an airport) and the driver continues driving the car away from the drop off location.</p>"},{"location":"RoutingModes/#CAR_HAILING","title":"CAR_HAILING","text":"<p>Using a car hailing app like Uber or Lyft to get to a train station or all the way to the destination.</p> <p>See the sandbox documentation on how to configure it.</p>"},{"location":"RoutingModes/#CAR_PICKUP","title":"CAR_PICKUP","text":"<p>Walking to a pickup point along the road, driving to a drop-off point along the road, and walking the rest of the way.  This can include various taxi-services or kiss &amp; ride.</p>"},{"location":"RoutingModes/#CAR_RENTAL","title":"CAR_RENTAL","text":"<p>Walk to a car rental point, drive to a car rental drop-off point and walk the rest of the way. This can include car rental at fixed locations or free-floating services.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#CAR_TO_PARK","title":"CAR_TO_PARK","text":"<p>Driving a car to the park-and-ride facilities near a station and taking publictransport. This mode needs to be combined with at least one transit mode otherwise, it behaves like an ordinary car journey. Prerequisite: Park-and-ride areas near the stations need to be present in the OSM input file.</p>"},{"location":"RoutingModes/#FLEXIBLE","title":"FLEXIBLE","text":"<p>Encompasses all types of on-demand and flexible transportation for example GTFS Flex or NeTEx Flexible Stop Places.</p>"},{"location":"RoutingModes/#SCOOTER_RENTAL","title":"SCOOTER_RENTAL","text":"<p>Walking to a scooter rental point, riding a scooter to a scooter rental drop-off point, and walking the rest of the way. This can include scooter rental at fixed locations or free-floating services.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#WALK","title":"WALK","text":"<p>Walking some or all of the way of the route.</p>"},{"location":"RoutingModes/#Transit modes","title":"Transit modes","text":"<p>Routing modes for transit, including rail, bus, ferry, etc. Equivalent to GTFS <code>route_type</code> or to NeTEx TransportMode. </p>"},{"location":"RoutingModes/#AIRPLANE","title":"AIRPLANE","text":"<p>Taking an airplane</p>"},{"location":"RoutingModes/#BUS","title":"BUS","text":"<p>Used for short- and long-distance bus routes.</p>"},{"location":"RoutingModes/#CABLE_CAR","title":"CABLE_CAR","text":"<p>Used for street-level cable cars where the cable runs beneath the car.</p>"},{"location":"RoutingModes/#CARPOOL","title":"CARPOOL","text":"<p>Private car trips shared with others.</p> <p>This is currently not specified in GTFS so we use the mode type values 1550-1560 which are in the range of private taxis.</p>"},{"location":"RoutingModes/#COACH","title":"COACH","text":"<p>Used for long-distance bus routes.</p>"},{"location":"RoutingModes/#FERRY","title":"FERRY","text":"<p>Used for short- and long-distance boat service.</p>"},{"location":"RoutingModes/#FUNICULAR","title":"FUNICULAR","text":"<p>Used for any rail system that moves on steep inclines with a cable traction system.</p>"},{"location":"RoutingModes/#GONDOLA","title":"GONDOLA","text":"<p>Gondola or suspended cable car. Typically used for aerial cable cars where the car is suspended from the cable.</p>"},{"location":"RoutingModes/#MONORAIL","title":"MONORAIL","text":"<p>Used for any rail system that runs on a single rail.</p>"},{"location":"RoutingModes/#RAIL","title":"RAIL","text":"<p>Used for intercity or long-distance travel.</p>"},{"location":"RoutingModes/#SUBWAY","title":"SUBWAY","text":"<p>Subway or Metro, used for any underground rail system within a metropolitan area.</p>"},{"location":"RoutingModes/#TAXI","title":"TAXI","text":"<p>Using a taxi service</p>"},{"location":"RoutingModes/#TRAM","title":"TRAM","text":"<p>Tram, streetcar or light rail. Used for any light rail or street level system within a metropolitan area.</p>"},{"location":"RoutingModes/#TROLLEYBUS","title":"TROLLEYBUS","text":"<p>Used for trolleybus systems which draw power from overhead wires using poles on the roof of the vehicle.</p>"},{"location":"SandboxExtension/","title":"OTP Sandbox Extensions","text":"<ul> <li>The sandbox is a place to test and implement new \"experimental\" features.</li> <li>This should not be used for bug fixes and smaller changes.</li> <li>Consider forking if the feature is valuable to one deployment only.</li> </ul>"},{"location":"SandboxExtension/#available-extensions","title":"Available extensions","text":"<p>Here is a list of features implemented as OTP Sandbox Extensions. The Sandbox extensions are provided \"as is\".</p> <ul> <li>Google Cloud Storage - Enable Google Cloud Storage as a OTP Data Source</li> <li>Actuator API - API used to check the health status of the OTP instance.</li> <li>Geocoder API - Adds an API to search for corners, stops and stations.</li> <li>Transfer analyser - Module used for analyzing the transfers between  nearby stops generated by routing via OSM data.</li> <li>SIRI Updater - Update OTP with real-time information from a Transmodel SIRI data source.</li> <li>SIRI Azure Updater - fetch SIRI real-time data through Azure Service Bus</li> <li>VehicleRentalServiceDirectory - GBFS service directory endpoint.</li> <li>Smoove Bike Rental Updator Support - Smoove Bike Rental Updator(HSL)</li> <li>Mapbox Vector Tiles API - Mapbox Vector Tiles API</li> <li>Flex Routing - Flexible transit routing for GTFS and Netex data sources</li> <li>Park and Ride API - Park and Ride API</li> <li>Data Overlay - StreetEdge grid data populating affecting the route planning</li> <li>Vehicle Parking - Vehicle Parking updaters</li> <li>Vehicle-to-stop heuristics - Speeding up Park+Ride, Bike+Ride and Bike+Transit searches</li> <li>Travel Time (Isochrone &amp; Surface) API - Travel Time API</li> <li>IBI accessibility score - IBI accessibility score</li> <li>Fares - Fare calculation</li> <li>Ride hailing - Ride hailing services like Uber</li> </ul>"},{"location":"SandboxExtension/#terminology","title":"Terminology","text":"<p>Main/core   -- All OTP code and additional files, NOT part of the sandbox. (<code>docs</code>, <code>src/main</code>, <code>src/test</code> and so on)</p> <p>Extensions -- All features implemented in the OTP Sandbox, provided with no guarantees. (<code>src/ext</code>, <code>src/ext-test</code>)</p>"},{"location":"SandboxExtension/#sandbox-goals","title":"Sandbox Goals","text":"<ul> <li>Reduce work for PR approval</li> <li>Allow experimental code to evolve (in a Sandbox)</li> <li>Encourage refactoring and creation of extension points in the main code.</li> <li>Increase visibility and cooperation of development of new features.</li> <li>Feature toggle<ul> <li>Sandbox features should use the OTPFeature to enable the code. Sandbox features are by   default off. To toggle features on/off se the configuration documentation.</li> </ul> </li> </ul>"},{"location":"SandboxExtension/#contract","title":"Contract","text":"<ul> <li>Give your feature a name: <code>&lt;extension name&gt;</code></li> <li>A new feature is isolated from the rest of the code by putting it in the directory <code>src/ext</code>. Java   code should have package prefix <code>org.opentripplanner.ext.&lt;extension name&gt;</code>. Unit tests should be   added in the test directory: <code>src/ext-test</code></li> <li>To integrate the new feature into OTP you may have to create new extension points in the main/core   code. Changes to the core OTP are subject to normal a review process.</li> <li>Create a readme file (<code>docs/sandbox/&lt;Extension Name&gt;.md</code> package including:<ul> <li>Extension Name</li> <li>Contact info</li> <li>Change log</li> <li>Documentation of the feature (optional)</li> </ul> </li> <li>List your extension in the Available extensions section and in the   mkdocs config file.</li> <li>Use feature toggling to enable a feature at runtime. The feature must be disabled by default. A   feature is toggled on using the config files.</li> <li>Only code modifying the main code(<code>src/main</code>, not <code>src/ext</code>) is reviewed. The current coding   standard apply to the extension code as well - but the code is not necessarily reviewed.</li> <li>There are no grantees - the authors of an extension can change its API any time they want.</li> <li>Anyone can request the feature to be merged into the main code. An approval from the PLC and a new   review is then required. The reviewers may request any changes, including API changes.</li> <li>If an extension is taken into the core/main OTP code, any API included may change, no BACKWARD   compatibility is guaranteed. I.e. the reviewers may require changes before it is merged.</li> <li>The feature submitters is responsible for maintaining and testing the extension code, but do not   need to provide any guarantees or support. If the extension is merged into the main code the   author will in fact need to provide support and maintenance.</li> <li>When someone at a later point in time want to change the main code the only thing they are   responsible for - with regard to the extension code - is:<ul> <li>that it compiles.</li> <li>that the unit tests run. If a test is not easy to fix, it can be tagged with @Ignore. If   ignored it would be polite to notify the author.</li> </ul> </li> <li>Changes to the main OTP API that cannot be toggled in must be clearly marked/tagged as part of   an experimental feature and documented - This code is subject to review.</li> <li>If a feature is old and not maintained it can be removed 1 month after notifying the submitter   (using contact info in README file).</li> <li>Introducing new dependencies needs approval. They are NOT approved if they are likely to be a   maintenance challenge (many transitive dependencies or potential conflicts with other   versions/libraries).</li> </ul>"},{"location":"StopAreas/","title":"Stop Areas","text":"<p>Public transit stations and stops can be modeled using a relation tagged with <code>public_transport=stop_area</code>. Description of such relations can be found from this OSM wiki page.</p> <p>OpenTripPlanner detects such relations and applies some special logic to them. Nodes, which are linked to street network, and are located within platform areas, are interpreted as connection points from the street network to the platform. OTP automatically links such points with the platform geometry in order to improve walk routing.</p> <p>For example, an elevator or stairs can connect a normal street to a railway platform above it. There is no need to add an explicit edge, which connects the entrance point with the actual geometry of the platform.</p> <p>An  example: Huopalahti railway station in Helsinki</p>"},{"location":"StopAreas/#instructions","title":"Instructions","text":"<ul> <li>Add platforms, which need special linking, as members of a <code>stop_area</code> tagged relation</li> <li>Set role=platform to these platform members</li> <li>Platforms must be also proper areas, tagged as routable highways and <code>area=yes</code>. Also a single tag <code>public_transport=platform</code> will do.</li> <li>Model required entrance points and stop linking points inside platform geometry and make them relation members, too.</li> <li>Entrances can be tagged using <code>railway=subway_entrance</code>, <code>highway=elevator</code>, <code>entrance=yes</code> or <code>entrance=main</code>.</li> <li>Stop linking points should be tagged as boarding locations, e.g. using the tag <code>public_transport=platform</code>.</li> <li>Connect entrance points to the street network. Stop linking points can have reference tags to instruct how to link them with public transit stops as instructed in the document about boarding locations.</li> <li>Platform and its entrance point must have the same <code>level</code> tag value. Also matching by default value zero is accepted.</li> <li>If <code>level</code> tag is not set, <code>layer</code> tag is also considered</li> </ul>"},{"location":"System-Requirements/","title":"System Requirements and Suggestions","text":""},{"location":"System-Requirements/#system-requirements","title":"System requirements","text":""},{"location":"System-Requirements/#memory","title":"Memory","text":"<p>OTP is relatively memory-hungry as it includes all the required data in memory. How much memory is required to build the graph for OTP, or to run the OTP server, depends on the used data sets (is OSM, elevation and/or transit data included?), on the size of the covered geographical area and the density of the transit and street network. The required memory can vary from less than one GB to more than 100 GB. For example, including all available data for Finland takes a bit over 10 GB but for Germany it requires 95 GB.</p>"},{"location":"System-Requirements/#processor","title":"Processor","text":"<p>Single thread performance is an important factor for OTP's performance. Additionally, OTP benefits from larger CPU cache as reading from memory can be a bottleneck.</p> <p>OTP's performance scales with the number of available CPU cores. OTP processes each request in a separate thread and usually one request doesn't utilize more than one thread, but with some requests and configurations, it's possible that multiple threads are used in parallel for a small part of a request or to process multiple queries within one request. How much parallel processing we utilize in requests might change in the future. Real-time updates also run in a separate thread. Therefore, to have a good performance, it makes sense to have multiple cores available. How OTP uses parallel processing also depends on the available cores (&lt;= 2 cores vs &gt;2 cores) in some cases. Therefore, load testing should be done against a machine that doesn't differ too much from production machines.</p> <p>Entur and the Digitransit project have found that the 3rd generation AMD processors have a slightly better performance for OTP2 than the Intel 3rd generation CPUs (and especially better than the 2nd generation CPUs).</p>"},{"location":"System-Requirements/#suggested-vm-types-in-cloud-service-providers","title":"Suggested VM types in cloud service providers","text":""},{"location":"System-Requirements/#azure","title":"Azure","text":"<p>For Azure, the Digitransit project did benchmarking of the available virtual machines types for OTP 2.3 in early 2023 and found that the <code>D2as \u2013 D96as v5</code> family had the best performance of the reasonable priced virtual machines types. These machines use the 3rd generation AMD EPYCTM 7763v (Milan) processor. The 3rd generation Intel machines had a slightly worse performance and a slightly higher cost. Digitransit chose to use the <code>D8as v5</code> machine as it had enough memory for running OTP in Finland and a reasonable number of vCPUs.</p>"},{"location":"System-Requirements/#google-cloud","title":"Google Cloud","text":"<p>Entur uses a scalable fleet of instances of type <code>c2d-standard-8</code>.</p>"},{"location":"Troubleshooting-Routing/","title":"Troubleshooting Routing","text":""},{"location":"Troubleshooting-Routing/#graph-builder-data-import-issues","title":"Graph Builder Data Import Issues","text":"<p>When you build a graph, OTP may encounter clearly incorrect or ambiguous data, or may detect less severe, but potentially problematic situations in the input data. Such problems should result in a \"Data Import Issue\" being generated. These issues are logged the the <code>DATA_IMPORT_ISSUES</code> console logger, depending on your need you might turn this logger on/off. At the end of the graph build process, OTP prints a summary of all the issues, like the following:</p> <pre><code> 11:35:57.515 INFO (Graph.java:970) Summary (number of each type of issues):\n 11:35:57.518 INFO (Graph.java:976)     TurnRestrictionBad - 560\n 11:35:57.518 INFO (Graph.java:976)     TurnRestrictionException - 15\n 11:35:57.518 INFO (Graph.java:976)     StopLinkedTooFar - 22\n 11:35:57.518 INFO (Graph.java:976)     HopSpeedSlow - 22\n 11:35:57.518 INFO (Graph.java:976)     Graphwide - 1\n 11:35:57.518 INFO (Graph.java:976)     GraphConnectivity - 407\n 11:35:57.519 INFO (Graph.java:976)     ParkAndRideUnlinked - 1\n 11:35:57.519 INFO (Graph.java:976)     StopNotLinkedForTransfers - 31\n 11:35:57.519 INFO (Graph.java:976)     NoFutureDates - 1\n</code></pre> <p>The full set of issues can be written out to an HTML report for closer inspection. To enable the creation of these (potentially voluminous) HTML reports, add <code>\"dataImportReport\" : true</code> to your graph builder JSON configuration.</p> <p>If the graph is saved to a file, these issues are saved with it and can be examined later. Currently the only tool for doing this is the \"Graph Visualizer\", which is not particularly well maintained and is intended for use by software developers familiar with OTP who can patch up the code as needed.</p>"},{"location":"Troubleshooting-Routing/#debug-layers","title":"Debug layers","text":"<p>OpenTripplanner has option to ease debugging problems with graph. Older option is graph visualizer. Which you can enable with <code>--visualize</code> parameter instead of <code>--server</code> when starting OTP. There you can see whole graph. You can click on edges and vertices and see the metadata. It is useful to see if street has expected options. And if connections are where they are expected.</p> <p>It can be hard to use on large graphs since, whole graph is displayed at once. And it can be hard to search for specific streets since only street graph is shown without the rest of information.</p> <p>Another option is to use debug layers, which shows extra layers on top of the normal debug UI map. If you want to see them you need to open the map layer selector on the top left hand side and choose the requested layer.</p> <p>Currently you can choose between:</p> <ul> <li>Wheelchair access (which colors street edges red if they don't allow wheelchair or green   otherwise)</li> <li>Bicycle safety (colors street edges based on   how good are for cycling [smaller is better])</li> <li>Traversal permissions (colors street edges based on what types of transit modes are allowed to   travel on them (Pedestrian, cycling, car are currently supported)) Traversal permissions layer   also draws links from transit stops/vehicle rentals and P+R to graph. And also draws transit   stops, vehicle rentals and P+R vertices with different color.</li> <li>No thru traffic - streets are colored if the edge has thru traffic restrictions (car and bicycle   = <code>red</code>, car only = <code>orange</code>, bicycle only = <code>blue</code>, and no-restriction = <code>light gray</code>)</li> </ul>"},{"location":"Troubleshooting-Routing/#interpretation-traversal-permissions-layer","title":"Interpretation Traversal permissions layer","text":"<p>A sample traversal permissions layer looks like the following </p> <ul> <li>Yellow lines is the link between a stop and the street graph.</li> <li>Grey lines are streets one can travel with the mode walk, bike, or car</li> <li>Green lines are paths one can travel with the mode walk only</li> <li>Red lines are streets one can travel with the mode car only</li> <li>Grey dots vertices where edges are connected. If two edges are crossing w/o a vertice at the   intersection point, users will not be able to go from one street to the other. But this can be   valid in case of over/under pass for example. If it's an error, it's usually caused by improperly   connected OSM data (a shared OSM node is required).</li> </ul>"},{"location":"Troubleshooting-Routing/#openstreetmap-data","title":"OpenStreetMap Data","text":""},{"location":"Troubleshooting-Routing/#tags-affecting-permissions-and-bicycle-safety","title":"Tags affecting permissions and bicycle safety","text":"<p>OTP has a very flexible system for deciding when a street is to be allowed by pedestrians, bicycles or cars.</p> <p>To configure the which settings to use for your location, please use the osmTagMapping config attribute.</p> <p>In the following section we will discuss the default case, which will be used if the property is not set.</p>"},{"location":"Troubleshooting-Routing/#default-settings","title":"Default settings","text":"<p>Access tags (such as bicycle/foot = yes/no/designated) can be used to override default graph-building parameters.</p> <p>As a default, foot and bicycle traffic is ''not'' allowed on <code>highway=trunk</code>, <code>highway=trunk_link</code> , <code>highway=motorway</code>, <code>highway=motorway_link</code>, or <code>highway=construction</code>.</p> <p>Both are allowed on <code>highway=pedestrian</code>, <code>highway=cycleway</code>, and <code>highway=footway</code>.</p> <p>Finally, bicycles are not allowed on highway=footway when any of the following tags appear on a footway: <code>footway=sidewalk</code>, <code>public_transport=platform</code>, or <code>railway=platform</code>.</p> <p>Other access tags (such as <code>access=no</code> and <code>access=private</code> affect routing as well, and can be overridden similarly. While <code>access=no</code> prohibits all traffic, <code>access=private</code> disallows through traffic.</p>"},{"location":"Troubleshooting-Routing/#bicycle-safety-factor","title":"Bicycle safety factor","text":"<p>Bicycle routing is even more configurable than the other traverse modes: during graph build a so-called bicycle safety score is computed for each street. You can think of this score as a penalty for traversing this way so the lower the score the better.</p> <p>For example if a way is tagged with <code>surface=sand</code> it receives a safety score of 100 which means that it's 100 times worse to cycle on when compared to a way which has a safety score of 1.</p> <p>How this is calculated depends on two things</p> <ul> <li>the incline of the way (not read from OSM but from   the separately configured elevation data)</li> <li>its OSM tags</li> </ul> <p>At request time you can then use the <code>triangleFactors</code> to decide how important bicycle safety is compared to shorter distances and flatness.</p> <p>Each <code>WayPropertySet</code> contains rules for a given set of tag matchers that influence the bicycle safety score. For example, a rule looks like this:</p> <pre><code>props.setProperties(\"highway=track\", StreetTraversalPermission.ALL, 1.3, 1.3);\n</code></pre> <p>This means that an OSM way with the tag <code>highway=track</code> is traversable by all modes (pedestrian, bicycle, car) and that its bicycle safety score when you traverse in order of the way is <code>1.3</code> and also <code>1.3</code> when going the other way (smaller means more cycle-friendly).</p> <p>If there is a more specific matcher like <code>highway=track;bicycle=no</code> and it matches a given OSM way, it is chosen instead and its settings applied.</p> <p>The score can be any positive number but the range (as of writing this) goes from <code>0.6</code> for bike lanes to <code>100</code> for ways that consist of sand. To figure out a good value for your set of tags you should read the bicycle safety report (see below) or the source code of your <code>OsmTagMapper</code> to get a feeling for how much certain tags are penalised or rewarded.</p> <p>There are also so-called mixins. These are applied on top of the most specific matchers and a single OSM way can match many mixins. The mixins' safety values are multiplied with the value of the base (non-mixin) match. A mixin looks like this (note the <code>true</code> at the end):</p> <pre><code>props.setProperties(\"surface=mud\", StreetTraversalPermission.ALL, 1.5, 1.5, true);\n</code></pre> <p>The Javadoc of <code>OSMSpecifier.java</code> contains the precise documentation about the syntax of the matchers.</p> <p>There are a lot of rules for which tags results in a specific safety score so it's not easy to get an overview. There is however an OTP feature to get an HTML viewer with a search feature that lets you browse through the rules.</p> <p></p> <p>To enable it activate the Report API sandbox feature.</p> <p>To view the output of the bicycle safety calculation on a map, check the debug layers.</p>"},{"location":"Troubleshooting-Routing/#railway-platforms","title":"Railway Platforms","text":"<p>OTP users in Helsinki have documented their best practices for coding railway platforms in OpenStreetMap. These guidelines are available in the OSM Wiki.</p>"},{"location":"Troubleshooting-Routing/#transit-search","title":"Transit search","text":"<p>The Raptor implementation support instrumentation of ACCEPT, REJECT, and DROP events for stop-arrivals and trip boardings. Use the SpeedTest to pass in a set of stops and/or a specific path to debug. This is useful when debugging why you do (not) get a particular result.</p> <p>Read the logging page for more information.</p>"},{"location":"Troubleshooting-Routing/#gtfs-transferstxt-and-netex-interchange-import","title":"GTFS Transfers.txt and NeTEx Interchange import","text":"<p>Transfers may have effects on the routing which may be difficult to predict. OTP can dump all imported transfers to file - transfers-debug.csv. This may help verify the result of the import or find special test cases. To turn on the export enable the slf4j logger:</p> <pre><code>  &lt;logger name=\"TRANSFERS_EXPORT\" level=\"info\" /&gt;\n</code></pre>"},{"location":"Troubleshooting-Routing/#further-information","title":"Further information","text":"<ul> <li>General information</li> <li>Bicycle routing</li> <li>Indoor mapping</li> <li>Elevators</li> </ul>"},{"location":"UpdaterConfig/","title":"Realtime Updaters","text":""},{"location":"UpdaterConfig/#updater-configuration","title":"Updater configuration","text":"<p>This section covers options that can be set in the updaters section of <code>router-config.json</code>.  See the parameter summary and examples in the router configuration documentation</p> <p>Real-time data are those that are not added to OTP during the graph build phase but during runtime.</p> <p>Real-time data sources are configured in the <code>updaters</code> section is an array of JSON objects, each of which has a <code>type</code> field and other configuration fields specific to that type. </p>"},{"location":"UpdaterConfig/#gtfs-realtime","title":"GTFS-Realtime","text":"<p>GTFS feeds contain schedule data that is published by an agency or operator in advance. The feed does not account for unexpected service changes or traffic disruptions that occur from day to day. Thus, this kind of data is also referred to as 'static' data or 'theoretical' arrival and departure times.</p> <p>GTFS-Realtime complements GTFS with three additional kinds of feeds. In contrast to the base GTFS schedule feed, they provide real-time updates ('dynamic' data) and are updated from minute to minute.</p>"},{"location":"UpdaterConfig/#alerts","title":"Alerts","text":"<p>Alerts are text messages attached to GTFS objects, informing riders of disruptions and changes.  The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"real-time-alerts\" <code>enum</code> The type of the updater. Required 1.5 earlyStartSec <code>integer</code> How long before the posted start of an event it should be displayed to users Optional <code>0</code> 1.5 feedId <code>string</code> The id of the feed to apply the alerts to. Required 1.5 frequency <code>duration</code> How often the URL should be fetched. Optional <code>\"PT1M\"</code> 1.5 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 1.5 url <code>string</code> URL to fetch the GTFS-RT feed from. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u_0_headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[0] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"real-time-alerts\",\n      \"frequency\" : \"30s\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/FeedSpecAlerts/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Some-Header\" : \"A-Value\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#tripupdates-via-https","title":"TripUpdates via HTTP(S)","text":"<p>TripUpdates report on the status of scheduled trips as they happen, providing observed and  predicted arrival and departure times for the remainder of the trip. The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"stop-time-updater\" <code>enum</code> The type of the updater. Required 1.5 backwardsDelayPropagationType <code>enum</code> How backwards propagation should be handled. Optional <code>\"required-no-data\"</code> 2.2 feedId <code>string</code> Which feed the updates apply to. Required 1.5 frequency <code>duration</code> How often the data should be downloaded. Optional <code>\"PT1M\"</code> 1.5 fuzzyTripMatching <code>boolean</code> If the trips should be matched fuzzily. Optional <code>false</code> 1.5 url <code>string</code> The URL of the GTFS-RT resource. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details_1","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__5__backwardsDelayPropagationType","title":"backwardsDelayPropagationType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"required-no-data\"</code> Path: /updaters/[5]  Enum values: <code>required-no-data</code> | <code>required</code> | <code>always</code></p> <p>How backwards propagation should be handled.</p> <p>REQUIRED_NO_DATA:   Default value. Only propagates delays backwards when it is required to ensure that the times   are increasing, and it sets the NO_DATA flag on the stops so these automatically updated times   are not exposed through APIs.</p> <p>REQUIRED:   Only propagates delays backwards when it is required to ensure that the times are increasing.   The updated times are exposed through APIs.</p> <p>ALWAYS   Propagates delays backwards on stops with no estimates regardless if it's required or not.   The updated times are exposed through APIs.</p>"},{"location":"UpdaterConfig/#u__5__url","title":"url","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[5] </p> <p>The URL of the GTFS-RT resource.</p> <p><code>file:</code> URLs are also supported if you want to read a file from the local disk.</p>"},{"location":"UpdaterConfig/#u__5__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[5] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"stop-time-updater\",\n      \"frequency\" : \"1m\",\n      \"backwardsDelayPropagationType\" : \"REQUIRED_NO_DATA\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/TripUpdate/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Authorization\" : \"A-Token\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#streaming-tripupdates-via-mqtt","title":"Streaming TripUpdates via MQTT","text":"<p>This updater connects to an MQTT broker and processes TripUpdates in a streaming fashion. This means that they will be applied individually in near-realtime rather than in batches at a certain interval.</p> <p>This system powers the realtime updates in Helsinki and more information can be found  on Github.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"mqtt-gtfs-rt-updater\" <code>enum</code> The type of the updater. Required 1.5 backwardsDelayPropagationType <code>enum</code> How backwards propagation should be handled. Optional <code>\"required-no-data\"</code> 2.2 feedId <code>string</code> The feed id to apply the updates to. Required 2.0 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 2.0 qos <code>integer</code> QOS level. Optional <code>0</code> 2.0 topic <code>string</code> The topic to subscribe to. Required 2.0 url <code>string</code> URL of the MQTT broker. Required 2.0"},{"location":"UpdaterConfig/#parameter-details_2","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__6__backwardsDelayPropagationType","title":"backwardsDelayPropagationType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"required-no-data\"</code> Path: /updaters/[6]  Enum values: <code>required-no-data</code> | <code>required</code> | <code>always</code></p> <p>How backwards propagation should be handled.</p> <p>REQUIRED_NO_DATA:   Default value. Only propagates delays backwards when it is required to ensure that the times   are increasing, and it sets the NO_DATA flag on the stops so these automatically updated times   are not exposed through APIs.</p> <p>REQUIRED:   Only propagates delays backwards when it is required to ensure that the times are increasing.   The updated times are exposed through APIs.</p> <p>ALWAYS:   Propagates delays backwards on stops with no estimates regardless if it's required or not.   The updated times are exposed through APIs.</p>"},{"location":"UpdaterConfig/#example-configuration_2","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"mqtt-gtfs-rt-updater\",\n      \"url\" : \"tcp://pred.rt.hsl.fi\",\n      \"topic\" : \"gtfsrt/v2/fi/hsl/tu\",\n      \"feedId\" : \"HSL\",\n      \"fuzzyTripMatching\" : true\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#vehicle-positions","title":"Vehicle Positions","text":"<p>VehiclePositions give the location of some or all vehicles currently in service, in terms of  geographic coordinates or position relative to their scheduled stops. The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-positions\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> Feed ID to which the update should be applied. Required 2.2 frequency <code>duration</code> How often the positions should be updated. Optional <code>\"PT1M\"</code> 2.2 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 2.5 url <code>uri</code> The URL of GTFS-RT protobuf HTTP resource to download the positions from. Required 2.2 features <code>enum set</code> Which features of GTFS RT vehicle positions should be loaded into OTP. Optional 2.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details_3","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__7__features","title":"features","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>enum set</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[7]  Enum values: <code>position</code> | <code>stop-position</code> | <code>occupancy</code></p> <p>Which features of GTFS RT vehicle positions should be loaded into OTP.</p>"},{"location":"UpdaterConfig/#u__7__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[7] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_3","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-positions\",\n      \"url\" : \"https://s3.amazonaws.com/kcm-alerts-realtime-prod/vehiclepositions.pb\",\n      \"feedId\" : \"1\",\n      \"frequency\" : \"1m\",\n      \"headers\" : {\n        \"Header-Name\" : \"Header-Value\"\n      },\n      \"fuzzyTripMatching\" : false,\n      \"features\" : [\n        \"position\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#gbfs-vehicle-rental-systems","title":"GBFS vehicle rental systems","text":"<p>Besides GTFS-RT transit data, OTP can also fetch real-time data about vehicle rental networks including the number of vehicles and free parking spaces at each station. We support vehicle rental systems that use the GBFS standard.</p> <p>GBFS can be used for a variety of shared mobility services, with partial support for both v1 and v2.2 (list of known GBFS feeds). OTP supports the following GBFS form factors:</p> <ul> <li>bicycle</li> <li>scooter</li> <li>car</li> </ul> Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-rental\" <code>enum</code> The type of the updater. Required 1.5 allowKeepingRentedVehicleAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.1 frequency <code>duration</code> How often the data should be updated. Optional <code>\"PT1M\"</code> 1.5 geofencingZones <code>boolean</code> Compute rental restrictions based on GBFS 2.2 geofencing zones. Optional <code>false</code> 2.3 language <code>string</code> TODO Optional 2.1 network <code>string</code> The name of the network to override the one derived from the source data. Optional 1.5 overloadingAllowed <code>boolean</code> Allow leaving vehicles at a station even though there are no free slots. Optional <code>false</code> 2.2 sourceType <code>enum</code> What source of vehicle rental updater to use. Required 1.5 url <code>string</code> The URL to download the data from. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 1.5"},{"location":"UpdaterConfig/#parameter-details_4","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u_1_allowKeepingRentedVehicleAtDestination","title":"allowKeepingRentedVehicleAtDestination","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /updaters/[1] </p> <p>If a vehicle should be allowed to be kept at the end of a station-based rental.</p> <p>In some cases it may be useful to not drop off the rented vehicle before arriving at the destination. This is useful if vehicles may only be rented for round trips, or the destination is an intermediate place.</p> <p>For this to be possible three things need to be configured:</p> <ul> <li>In the updater configuration <code>allowKeepingRentedVehicleAtDestination</code> should be set to <code>true</code>.</li> <li><code>allowKeepingRentedVehicleAtDestination</code> should also be set for each request, either using routing defaults, or per-request.</li> <li>If keeping the vehicle at the destination should be discouraged, then <code>keepingRentedVehicleAtDestinationCost</code> (default: 0) may also be set in the routing defaults.</li> </ul>"},{"location":"UpdaterConfig/#u_1_geofencingZones","title":"geofencingZones","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /updaters/[1] </p> <p>Compute rental restrictions based on GBFS 2.2 geofencing zones.</p> <p>This feature is somewhat experimental and therefore turned off by default for the following reasons:</p> <ul> <li>It delays start up of OTP. How long is dependent on the complexity of the zones. For example in Oslo it takes 6 seconds to compute while Portland takes 25 seconds.</li> <li>It's easy for a malformed or unintended geofencing zone to make routing impossible. If you encounter such a case, please file a bug report.</li> </ul>"},{"location":"UpdaterConfig/#u_1_network","title":"network","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[1] </p> <p>The name of the network to override the one derived from the source data.</p> <p>GBFS feeds must include a system_id which will be used as the default <code>network</code>. These ids are sometimes not helpful so setting this property will override it.</p>"},{"location":"UpdaterConfig/#u_1_sourceType","title":"sourceType","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[1]  Enum values: <code>gbfs</code> | <code>smoove</code></p> <p>What source of vehicle rental updater to use.</p>"},{"location":"UpdaterConfig/#u_1_headers","title":"headers","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[1] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_4","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-rental\",\n      \"network\" : \"socialbicycles_coast\",\n      \"sourceType\" : \"gbfs\",\n      \"language\" : \"en\",\n      \"frequency\" : \"1m\",\n      \"allowKeepingRentedVehicleAtDestination\" : false,\n      \"geofencingZones\" : false,\n      \"url\" : \"http://coast.socialbicycles.com/opendata/gbfs.json\",\n      \"headers\" : {\n        \"Auth\" : \"&lt;any-token&gt;\",\n        \"&lt;key&gt;\" : \"&lt;value&gt;\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#other-updaters-in-sandboxes","title":"Other updaters in sandboxes","text":"<ul> <li>Vehicle parking</li> <li>Siri over HTTP</li> <li>Siri over Azure Message Bus</li> <li>VehicleRentalServiceDirectory</li> </ul>"},{"location":"Version-Comparison/","title":"Comparing OTP2 and OTP1","text":""},{"location":"Version-Comparison/#summary","title":"Summary","text":"<p>OpenTripPlanner has been under development since 2009, leading up to a 1.0 release in 2016. Research and development on higher performance routing has been ongoing since 2013-2014, and work on the second major release referred to as OTP2 officially began in 2018. As of Q3 2023, OTP2 is the only version to receive regular updates and OTP1 is considered legacy and unsupported. This page explains  key differences between the two versions (referred to as OTP1 and OTP2). </p> <p>OTP1 has existed for over a decade and is in widespread use. It aims to do many things for many people: it provides passenger-facing itinerary services over APIs, but also serves as a network analysis toolkit for urban planning and research. Though OTP1 is widely used and gets the job done, its transit routing approach is obsolete. We have long recognized that more resource-efficient approaches were possible. Reasonable response times and scaling to larger data sets have been achieved through a series of complex incremental interventions that became difficult to maintain. OTP1 has also accumulated large amounts of experimental code and specialized tools, which can be useful in a research or consulting setting but complicate long-term maintenance.</p> <p>OTP2 offers much better performance in larger transportation networks and geographic areas, and a wider variety of alternative itineraries. OTP2's public transit routing component has been completely rewritten, and is now distinct from bike, walk, and motor vehicle routing. Non-transit routing remains very similar to OTP1, benefiting from years of adaptations to nuances of OpenStreetMap data and end-user walking and biking preferences. Unlike OTP1, OTP2 is completely focused on passenger-facing itinerary services. The innovations in OTP2 have already been applied to planning, research, and analysis work for several years through Conveyal's R5 project, which informed and inspired the OTP2 transit routing system.</p>"},{"location":"Version-Comparison/#otp2-use-cases","title":"OTP2 Use Cases","text":"<p>The benefits of OTP2 will be most evident in large or dense networks spanning multiple cities: entire countries (Netherlands, Switzerland, Norway), US states, metropolitan regions and cross-border conurbations (e.g. NYC metro area). Although the scale of trip planners is sometimes limited by the geographic extent of administrative structures (national rail or bus operators or ticketing agencies), OTP2 should be capable of handling even larger networks, and we do for example regularly test on a unified Nordic trip planner in hopes that such systems will materialize over time as more territories adopt OTP.</p> <p>OTP2 development has been driven by adoption of open source routing software in Northern Europe. Importantly for deployments in Europe, OTP2 introduces support for EU-standard Netex and SIRI data sources in addition to GTFS. The Nordic profile of Netex understood by OTP2 uses the same schema as the EU profile, and generalization to the EU profile should be feasible once it is standardized.</p>"},{"location":"Version-Comparison/#high-level-feature-comparison","title":"High-level feature comparison","text":"Feature OTP1 OTP2 OSM street data yes yes GTFS transit data yes yes Netex transit data no yes(Nordic profile) GTFS-Realtime yes(streaming, polling, incremental) yes(streaming, polling, incremental) SIRI Realtime no yes Elevation data TIFF and NED TIFF and NED One-to-many routing, isochrones and scripting yes no Isochrones yes yes Java version 8+ 21+ Multiple regions per server yes no Hot reloading of graphs yes no Street (OSM) routing algorithm Generalized cost A* Generalized cost A* Transit routing algorithm Generalized cost A* Multi-criteria range-RAPTOR Search segmentation Single search through access, transit, egress Access/egress separate from transit search Goal direction Upper bound search backward from destination, over streets and transit, interleaved with forward search Upper bound search backward from destination  on transit only, before forward search begins Alternative itineraries \"Trip banning\", N lowest generalized costs True Pareto-optimal results Departure/arrival time Single departure or arrival time only Every minute in a window up to several days long API Paging no yes Timetable View no yes Plugin Sandbox Extensions no yes (See extensions) Data storage local, S3 (elevation only) extensible with local, ZIP,and Google Cloud plugins, S3 available Transfer Priority yes yes"},{"location":"Version-Comparison/#commentary-on-otp1-features-removed-from-otp2","title":"Commentary on OTP1 features removed from OTP2","text":"<p>OTP2 brings significant improvements in speed and scalability, but does not retain all features of OTP1. We have chosen to prioritize long-term maintainability, so only those features that are  \"owned\" by a team of professional developers will be carried over to OTP2.</p> <p>Some features have been removed to simplify the code base and improve maintainability. Others have been removed to reflect separation of concerns: following principles of modular design they should be handled outside OTP, or are already covered by other projects where they are more actively developed.</p>"},{"location":"Version-Comparison/#analysis","title":"Analysis","text":"<p>Many OpenTripPlanner contributors have been primarily interested in transportation and urban planning use cases. We consider these use cases quite important. This has been a major area of application for OpenTripPlanner and has helped popularize cumulative opportunities accessibility metrics. For example, the University of Minnesota Accessibility Observatory used OpenTripPlanner for Access Across America. Nonetheless, the analysis code in OTP1 is essentially an unmaintained and unsupported early prototype for later projects, specifically Conveyal's R5 (and the Conveyal Analysis system built upon it). OTP1 seems to have gained popularity for analysis uses due to the existence of documentation and an active user community, but has significant technical shortcomings. One of these is simply speed: OTP1 can be orders of magnitude slower (and more memory-intensive) than the approaches exemplified in R5. The other is the requirement to search at a single specific time. Travel times and especially wait times on scheduled transit vary greatly depending on when you depart. Accounting for variation over a time window requires repeated independent searches at each possible departure time, which is very inefficient. R5 is highly optimized to capture variations in travel time across time windows and account for uncertainty in waiting times on frequency-based routes.</p> <p>Due to its similarity to the R5 approach, OTP2's transit router would not have these same problems. Nonetheless, we have decided not to port the OTP1 analysis features over to OTP2 since it would broaden the focus away from passenger information and draw finite attention away from existing projects like R5 and Conveyal Analysis.</p> <p>Accordingly, we have made an effort to clean up and augment OTP1 analysis documentation for researchers who will continue to need it. It should remain possible for people to continue using OTP1 if they prefer. If you would instead like to apply the innovations present in OTP2, we recommend looking into R5 or Conveyal Analysis.</p>"},{"location":"Version-Comparison/#routers-api-and-hot-reloading","title":"Routers API and Hot Reloading","text":"<p>Via it's Routers API, OTP1 allows loading data and serving APIs for multiple separate geographic areas. This is functionally equivalent to running more than one OTP server with separate data sets. This system also allows reloading transportation network data when it changes, or even pushing new data over a network connection.</p> <p>These were all adaptations to the very different IT environment that existed earlier in OTP history. These days, containerization and on-demand cloud servers have become ubiquitous, and most users solve these problems in totally different ways - by provisioning and starting up entirely new virtual servers, then switching a load balancer over to those new servers. Because the Routers API is complex and exposes potentially damaging functionality over the network, it has been removed from OTP2 to simplify the code base and make it easier to reason about security.</p>"},{"location":"Version-Comparison/#routing-request-parameters","title":"Routing request parameters","text":"<p>Less parameters are available on the OTP2 REST API than in OTP1. Often there is no practical loss of functionality, just a different way of expressing things due to the new routing algorithms. A summary of parameters that have been removed and their replacements can be found in the migration guide</p>"},{"location":"Version-Comparison/#otp-trip-planning-and-transit-index-apis","title":"OTP Trip planning and Transit index APIs","text":"<p>OTP1 had two APIs for trip planning, the REST API and an GraphQL API (early version of the GTFS GraphQL API). This API has been formalised and is now, together with the Transmodel  GraphQL API, the only supported way of sending requests to the OTP routing engine.</p> <p>Details of those two APIs are available at the following pages:</p> <ul> <li>GTFS GraphQL API - HSL's GraphQL API used by the Digitransit   project.</li> <li>Transmodel API - Entur's Transmodel API</li> </ul> <p>The plan is to merge the two APIs above, clean it up and make it the new official API. The HSL API uses GTFS terminology, while the Entur API is Transmodel (NeTEx) based. Both APIs are similar in semantics and structure, and provide the same functionality. </p>"},{"location":"Version-Comparison/#additional-characteristics-added-in-otp2","title":"Additional characteristics added in OTP2","text":"<p>Sandbox Extensions OTP2's Sandbox system allows for plugins, proprietary extensions, and experimental feature development with less overhead. It forces OTP2 to become more extensible, while reducing process overhead when developing non-core features.</p> <p>Cloud support In OTP1 all data access (config, input data, and graph output) is by direct access to the local filesystem. The only exception is elevation data, which can be loaded from AWS S3 as well. In OTP2, all data access is through an abstraction layer. This can be configured to support individual local files, zip files, and Google Cloud Storage. The new data access treats directories and zip files as \u201cequal\u201d, and this functionality is used to read the contents of GTFS and NeTEx archives. Other data sources can be supported by writing plugins. Entur has written a plugin for AWS S3 which has not been merged. If requested they can provide this code for AWS S3.</p> <p>Library upgrades We have adapted OTP2 to run on Java 11+ and moved to newer versions of some dependencies such as GraphQL and One Bus Away.</p> <p>Bugfixes At least bug issues have been resolved in OTP2. Critical fixes have been backported to OTP1. See https://github.com/issues?q=is%3Aclosed+is%3Aissue+label%3AOTP2+label%3Abug</p>"},{"location":"Version-Comparison/#other-features-removed-from-otp2","title":"Other features removed from OTP2","text":"<p>AlertPatch GTFS-RT Service Alerts will no longer affect routing (e.g. cancel trips). A GTFS-RT Trip Updates feed should be used for this purpose.</p>"},{"location":"Version-Comparison/#migration-guide","title":"Migration guide","text":"<p>The development community has maintained a migration guide from version 1.5.0 up to 2.2.0 when it was no longer feasible to document every change as version 2 was considered the only supported one. The document can be found in the documentation of version 2.2.0.</p>"},{"location":"Visual-Identity/","title":"OpenTripPlanner Visual Identity","text":"<p>This is the OpenTripPlanner logo in scalable vector format, with knockout transparency:</p> <p></p> <p>Here is a link to this SVG logo as a downloadable file. This is the raw SVG XML source code:</p> <pre><code>&lt;?xml version=\"1.0\" encoding=\"utf-8\"?&gt;\n&lt;!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\" \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\"&gt;\n&lt;svg version=\"1.1\" id=\"Layer_1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    x=\"0px\" y=\"0px\" width=\"512px\" height=\"512px\" viewBox=\"0 0 125.333 125.334\" xml:space=\"preserve\"&gt;\n&lt;path fill=\"#2179BF\" d=\"M62.668,0C33.83,0,9.559,19.483,2.258,46l72.681-0.003c4.729-0.011,8.555-3.837,8.561-8.568\n    c-0.006-4.729-3.831-8.555-8.561-8.559c-4.731,0.004-8.557,3.83-8.564,8.559v4.592h-13.7v-4.592\n    c0-12.294,9.962-22.261,22.265-22.263c12.298,0.002,22.262,9.969,22.266,22.263c-0.003,12.3-9.968,22.264-22.266,22.271H0.074\n    C0.028,60.684,0,61.671,0,62.666c0,34.611,28.057,62.668,62.668,62.668c34.609,0,62.665-28.057,62.665-62.668\n    C125.333,28.057,97.277,0,62.668,0 M92.222,85.667v-3.473v-4.86l-47.058,0.003c-4.729,0.011-8.556,3.837-8.561,8.568\n    c0.005,4.728,3.831,8.555,8.561,8.559c4.731-0.004,8.558-3.831,8.565-8.559v-4.592h13.699v4.592\n    c0,12.294-9.961,22.261-22.265,22.263c-12.298-0.002-22.26-9.969-22.264-22.263c0.002-12.3,9.966-22.264,22.264-22.271h47.058V56.12\n    l21.712,14.775L92.222,85.667z\"/&gt;\n&lt;/svg&gt;\n</code></pre> <p>This concept behind this logo design was \"infinite roads\". Besides the clear references to movement and wayfinding through a transportation network, it (somewhat subliminally) contains the letters O T and P. This design is more geometric and austere than our previous logo, which makes it readily recognizable in a crowd of small app icons, bookmarks, or favicons. It also channels the high modern logos and 1970s supergraphics that were the visual style of public transport for a generation.</p> <p>The color of the logo in the RGB colorspace is <code>#2179BF</code>.</p> <p>The name of the OpenTripPlanner project is written in CamelCase: capital letters at the beginning of each word, with no spaces between the words. For the logotype we do not strictly adhere to a standard typeface. The OTP website just uses the CSS declarations <code>font: 30pt helvetica, sans-serif; font-weight: bold;</code>.</p> <p>The OpenTripPlanner logo was created by Brooklyn-based cartographer and graphic designer Kate Chanba, who has also done extensive work on transit system maps.</p>"},{"location":"apis/Apis/","title":"APIs","text":"<p>Several services are built upon OTP's routing and transit data indexing engines. They expose these APIs:</p> <p>The GTFS GraphQL API has been used by the Digitransit and otp-react-redux  projects as a general purpose routing and transit data API in production for many years.  If your input data is mostly GTFS then this is probably the best choice as it uses the same vocabulary.</p> <p>The Transmodel GraphQL API is used at Entur in production since 2020. Like the GTFS GraphQL API it is also a general purpose API. If your input data is mostly NeTeX then you might want to investigate this API as it uses the Transmodel vocabulary to describe  its entities.</p> <p>The Vector tiles API is a special purpose API for displaying entities on a vector map.</p> <p>The Actuator API provides endpoints for checking the health status of the OTP instance and reading live application metrics. </p> <p>The Geocoder API allows you to geocode street corners and stop names.</p>"},{"location":"apis/Apis/#legacy-apis-to-be-removed","title":"Legacy APIs (to be removed)","text":"<p>The OTP REST API used to power many apps and frontends. For years it was the only way to access OTP programmatically.</p> <p>Over time it has been replaced by the GraphQL APIs and is scheduled to be disabled by default and eventually removed completely. It's therefore not recommended to use it.</p>"},{"location":"apis/GTFS-GraphQL-API/","title":"GTFS GraphQL API","text":"<p>The GTFS GraphQL API is a general purpose API which was created for the Digitransit project and is  used heavily by digitransit-ui.</p> <p>otp-react-redux has also migrated to this API in 2023.</p>"},{"location":"apis/GTFS-GraphQL-API/#urls","title":"URLs","text":"<ul> <li>GraphQL endpoint: <code>http://localhost:8080/otp/gtfs/v1</code></li> <li>HTML schema documentation: https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/</li> <li>Built-in visual GraphQL client: http://localhost:8080/graphiql</li> </ul>"},{"location":"apis/GTFS-GraphQL-API/#built-in-api-client","title":"Built-in API client","text":"<p>A browser based GraphQL API client is available at http://localhost:8080/graphiql</p> <p></p> <p><code>curl</code> example</p> <p>A complete example that fetches the list of all stops from OTP is:</p> <pre><code>curl --request POST \\\n  --url http://localhost:8080/otp/gtfs/v1 \\\n  --header 'Content-Type: application/json' \\\n  --header 'OTPTimeout: 180000' \\\n  --data '{\"query\":\"query stops {\\n  stops {\\n    gtfsId\\n    name\\n  }\\n}\\n\",\"operationName\":\"stops\"}'\n</code></pre>"},{"location":"apis/GTFS-GraphQL-API/#configuration","title":"Configuration","text":"<p>The API is enabled by default.</p> <p>If you want to disable it, do it in <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\" : {\n    \"GtfsGraphQlApi\": false\n  }\n}\n</code></pre>"},{"location":"apis/GraphQL-Tutorial/","title":"GraphQL Tutorial","text":""},{"location":"apis/GraphQL-Tutorial/#graphql-tutorial","title":"GraphQL tutorial","text":"<p>This document will give you a quick start tutorial on how to get started with OTP's GraphQL APIs. For  this tutorial we will be using the GTFS GraphQL API as this is the most commonly used one.</p> <p>First of all, make sure that you've loaded street and transit data into your instance by following the basic tutorial</p>"},{"location":"apis/GraphQL-Tutorial/#visual-graphql-api-client","title":"Visual GraphQL API client","text":"<p>OTP has a built-in API client to help you build queries and view documentation. After having started OTP, visit http://localhost:8080/graphiql to open it.</p> <p>It should look like this:</p> <p></p>"},{"location":"apis/GraphQL-Tutorial/#sending-your-first-query","title":"Sending your first query","text":"<p>For our first query we want to get the list of routes loaded into OTP. Therefore paste the following  GraphQL query in the left hand panel of the page:</p> <pre><code>{\n    routes {\n        longName\n        shortName\n        gtfsId\n        agency {\n            gtfsId\n            name\n        }\n        mode\n        bikesAllowed\n    }\n}\n</code></pre> <p>After pressing the \"Execute query\" button you should see the result of the query on the right hand side panel.</p> <p>Now would be a good time to explore the auto-complete capabilities of the tool by moving the cursor into the query panel and hitting Ctrl-Space to see what other query parameters are possible.</p> <p></p> <p>The explorer also has documentation built into it. If you hover your pointer over a property on the  left hand side you can see its documentation.</p> <p></p>"},{"location":"apis/GraphQL-Tutorial/#a-more-advanced-query","title":"A more advanced query","text":"<p>Most people want to get routing results out of OTP, so lets see the query for this:</p> <pre><code>{\n    plan(\n        # these coordinates are in Portland, change this to YOUR origin\n        from: { lat: 45.5552, lon: -122.6534 }\n        # these coordinates are in Portland, change this to YOUR destination\n        to: { lat: 45.4908, lon: -122.5519 }\n        # use the correct date and time of your request\n        date: \"2023-02-15\",\n        time: \"11:37\",\n        # choose the transport modes you need\n        transportModes: [\n            {\n                mode: WALK\n            },\n            {\n                mode: TRANSIT\n            },\n        ]) {\n        itineraries {\n            startTime\n            endTime\n            legs {\n                mode\n                startTime\n                endTime\n                from {\n                    name\n                    lat\n                    lon\n                    departureTime\n                    arrivalTime\n                }\n                to {\n                    name\n                    lat\n                    lon\n                    departureTime\n                    arrivalTime\n                }\n                route {\n                    gtfsId\n                    longName\n                    shortName\n                }\n                legGeometry {\n                    points\n                }\n            }\n        }\n    }\n}\n</code></pre> <p>Again, please use the autocomplete and documentation viewers to figure out what each input parameter and property means.</p> <p>More examples for a variety of queries can also be found in the test code.</p>"},{"location":"apis/TransmodelApi/","title":"Transmodel GraphQL API","text":""},{"location":"apis/TransmodelApi/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"apis/TransmodelApi/#documentation","title":"Documentation","text":"<p>This is the official OTP2 API for Transmodel (NeTEx). The terminology is based on the  Transmodel (NeTEx) with some limitations/simplification. It provides both a routing API  (trip query) and index API for transit data.</p> <p>Entur provides a GraphQL explorer where you may browse the GraphQL schema and try your own queries.</p> <p>When running OTP locally the endpoint is available at: <code>http://localhost:8080/otp/transmodel/v3</code></p> <p>Note! Versions <code>v1</code> and <code>v2</code> do not exist in the main OTP git repository, but in  the Entur fork from which this code originates from.</p>"},{"location":"apis/TransmodelApi/#configuration","title":"Configuration","text":"<p>To turn this API off, add the feature <code>TransmodelGraphQlApi : false</code> in <code>otp-config.json</code>.</p>"},{"location":"apis/TransmodelApi/#changelog-old","title":"Changelog - old","text":"<p>The Transmodel API is now part of the main OTP supported APIs. New changes in the changelog  will be added to the main change log, and NOT here (2023-12-13).</p> <ul> <li>Initial version of Transmodel Graph QL API (September 2019)</li> <li>Added support for multimodal StopPlaces (November 2019)</li> <li>Fix bug querying stopPlaces #3591</li> <li>Fix the field bikesAllowed #3586</li> <li>Add triangle factors for bicycle   routing #3585</li> <li>Fix correct type for BookingArrangementType#latestBookingDay</li> <li>Fix NPE in BookingArrangementType data   fetchers #3649</li> <li>Add BookingInfo to TimetabledPassingTime and   EstimatedCall #3666</li> <li>Use correct capitalization for GraphQL   fields #3707</li> <li>Allow filtering by a list of   ids #3738</li> <li>Don't filter out stops who don't have multimodal parents in the nearest   query #3752</li> <li>Restore ability to filter by private   code #3764</li> <li>Narrow down non-null types   type #3803</li> <li>Fix issue with fetching parent StopPlaces in nearest query in Transmodel   API #3807</li> <li>Fix invalid cast in situations resolver for line   type #3810</li> <li>Deduce enum for bookWhen in Transmodel   API #3854</li> <li>Fix coercion of default parameter for maximumDistance in   nearest #3846</li> <li>Expose stopPositionInPattern on   EstimatedCall #3846</li> <li>Allow selecting first or last quays in a   ServiceJourney #3846</li> <li>Make language nullable in MultilingualString, as it is not set in NonLocalizedString   #4074</li> <li>Transmodel API transport mode not present or null is all transport modes   #4123</li> <li>Expose datedServiceJourney from EstimatedCall   #4128</li> <li>Expose stop-to-stop journey pattern geometries   #4161</li> <li>Add possibility to filter dated service journeys by replacementFor   #4198</li> <li>Add support for groupOfLines in top level query   #4232</li> <li>Fix issue when ServiceJourney is created by an updater and expose necessary information via DSJ   #4365</li> <li>Allow specifying allowed/banned rental networks in trip query   #4459</li> <li>Add flexible stops   #4485</li> </ul>"},{"location":"examples/Readme/","title":"Example configurations","text":"<p>When setting up OTP it is often useful to have some examples to look at. If you have an example to share just add it here.</p>"},{"location":"examples/Readme/#examples","title":"Examples","text":"Name Organisation Description entur Entur, Norway Deployment Configuration with NeTEX input data ibi IBI Group, USA Allow routing for wheelchair users even if accessibility data is incomplete skanetrafiken Sk\u00e5netrafiken, Sweden, Sk\u00e5ne Deployment Configuration with combination of NeTEx and GTFS input data"},{"location":"examples/Readme/#support","title":"Support","text":"<p>The examples are provided \"as is\" - they may get outdated over time or miss information, and it is left to the provider, not the PLC, to include whatever the provider find useful.</p>"},{"location":"examples/Readme/#how-to-share-an-example","title":"How to share an example","text":"<p>Anyone who want can add their example here as long as it is OTP \"related\". Just create a normal pull-request to add it. </p>"},{"location":"examples/entur/Readme/","title":"Entur Deployment Configuration","text":"<p>This is a snapshot of Enturs deployment configuration. At Entur we run OTP in the cloud, so some of the provided config will not work outside Enturs cluster, but it is provided \"as is\" for others to replicate if they want.</p>"},{"location":"examples/entur/Readme/#config-files","title":"Config files","text":"<p>See the config files provided. The <code>updaters</code> section of the <code>router-config.json</code> is provided, but is not working. Remove it if you want to run OTP. It is provided for others as an example on how to configure the SIRI updaters. The same goes for the <code>storage</code> section in the <code>build-config.json</code>, remove it run OTP locally.</p> <p>The <code>&lt;host&gt;</code>, <code>&lt;OperatorNameSpace&gt;</code> and <code>${GCS_BUCKET}</code> are placeholders you need to change.</p>"},{"location":"examples/entur/Readme/#data-input-files","title":"Data input files","text":"<p>At Entur we run OTP with the latest NeTEx data we have. You may download it from here:</p> <p>https://developer.entur.org/stops-and-timetable-data</p> <p>We use the Entire Norway file.</p> <p>In the past the file did not contain the stops, so they needed to be downloaded separably (Entire Norway (Current stops) - Latest valid version of all country stops) and inserted into the Netex-file. Unpack the stops zipfile, rename the stops file to <code>_stops.xml</code>. Unpack the netex file and move the <code>_stops.xml</code> into the netex directory. Copy the netex directory and config files into the same directory and start OTP with it as the base directory.</p> <p>We also build with elevation data, which is not available on the internet without transformation. Send us a request, and we will find a way to share it.</p> <p>We download the OSM data file norway-latest.osm.pbf every night and build a street-graph with OSM and elevation data. We also use some custom OSM files for areas outside Norway, but they in most cases insignificant. If requested, we can provide them.</p>"},{"location":"examples/skanetrafiken/Readme/","title":"Sk\u00e5netrafiken Deployment Configuration","text":"<p>This is a snapshot of Sk\u00e5netrafiken deployment configuration. At Sk\u00e5netrafiken we deploy our OTP instances as microservices to a Kubernetes cluster. Some parts of the config are missing due to confidentiality.</p>"},{"location":"examples/skanetrafiken/Readme/#data-input-files","title":"Data input files","text":""},{"location":"examples/skanetrafiken/Readme/#netex","title":"NeTEx","text":"<p>NeTEx is used for transport data inside Sweden. Each night the system automatically builds new file based on data from SQL database. At the moment those files are not accessible through any public endpoint.</p>"},{"location":"examples/skanetrafiken/Readme/#gtfs","title":"GTFS","text":"<p>GTFS data is used for traffic inside Denmark. GTFS for danish public transport can be downloaded here. There is some processing applied to the original data so that unnecessary trips are filtered out and ID structure for journeys and stop point / stop places matches with the NeTEx. The modified GTFS is not accessible through any public endpoint either.</p>"},{"location":"examples/skanetrafiken/Readme/#osm","title":"OSM","text":"<p>Two different OSM files are used:</p>"},{"location":"examples/skanetrafiken/Readme/#sweden","title":"Sweden","text":"<p>OSM data is downloaded from <code>http://download.geofabrik.de/europe/sweden-latest.osm.pbf</code>. To reduced graph size, only data for southern part of Sweden is used.</p>"},{"location":"examples/skanetrafiken/Readme/#denmark","title":"Denmark","text":"<p>OSM data is downloaded from <code>http://download.geofabrik.de/europe/denmark-latest.osm.pbf</code>. To reduce graph size, only data for northern part of Denmark is used.</p>"},{"location":"examples/skanetrafiken/Readme/#real-time","title":"Real-time","text":"<p>The Azure Service Bus is used to propagate SIRI SX and ET real-time messages to OTP. This is solved through Siri Azure updaters that Sk\u00e5netrafiken had implemented in OTP. There are separate updaters for SIRI SX and ET. Those updaters are used to provide data for Swedish traffic (NeTEx). Right now, there is no connection to any real-time source for danish traffic (GTFS data).</p> <p>Except for receiving messages from Service Bus there are two endpoints through which historical ET and SX messages can be downloaded at OTP startup. The updater will first create new subscription on ServiceBus topic and then send request to the history endpoint. It can take some time get a response from the endpoint, so the timeout is set quite high. Once OTP is done with processing of history messages the updater will start querying messages from the subscription.</p> <p>Once the updaters are done with processing of history messages they will change their status to primed, and the system will start channeling request to this OTP instance. This ensures that no real-time message is omitted and all OTP instance that ran in the cluster does have exact same real-time data. Thi means that no matter which instance the client is hitting it will always get the same search results.</p>"},{"location":"examples/skanetrafiken/Readme/#history-endpoint-contract","title":"History endpoint contract","text":"<p>See the <code>updaters</code> section of <code>router-config.json</code> file provided in this folder. This is an example configuration for the updaters. The <code>history</code> configuration is optional. It can be skipped so that OTP does not fetch any historical messages on startup.</p> <p>There are two separate endpoints for respectively SX and ET. They are basic GET endpoints with following query parameters:</p> parameters format fromDateTime ISO 8601 toDateTime ISO 8601 <p>Those two parameters are used to define time boundaries for the messages.</p> <p>Both endpoints generate XML response which is an SIRI object containing SX or ET messages. Messages are formatted according to Siri Nordic Profile. Since in SIRI ET standard each messages contains all necessary data, Sk\u00e5netrafikens implementation of the endpoint returns only the last message for each DatedServiceJourney ID (sending multiple messages would be pointless since they will override each other). The messages are processed in the same order as they came in (in the list) so it would still work to include multiple messages on same DatedServiceJourney as long as they are sorted in correct order and the newest message is the last one in the list.</p>"},{"location":"examples/skanetrafiken/Readme/#matching-on-stop-arrival-times","title":"Matching on stop arrival-times","text":"<p>Normally ET messages are matched with corresponding trips based on ServiceJourney or DatedServiceJourney id from the message. In case OTP was not able to find corresponding trip additional search will be performed based on arrival-times/stop-patterns from the ET message. This feature turned off by default but can be activated by adding fuzzyTripMatching property to updater configuration. </p>"},{"location":"sandbox/ActuatorAPI/","title":"Actuator API","text":""},{"location":"sandbox/ActuatorAPI/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/ActuatorAPI/#changelog","title":"Changelog","text":"<ul> <li>Initial implementation of readiness endpoint (November 2019)</li> <li>Prometheus metrics added using Micrometer (October 2021)</li> <li>GraphQL metrics added to prometheus export (November 2021)</li> </ul>"},{"location":"sandbox/ActuatorAPI/#documentation","title":"Documentation","text":"<p>This provides endpoints for checking the health status of the OTP instance. It can be useful when running OTP in a container.</p> <p>The API will be at the endpoint <code>http://localhost:8080/otp/actuators</code> and follows the Spring Boot actuator API standard.</p>"},{"location":"sandbox/ActuatorAPI/#configuration","title":"Configuration","text":"<p>To enable this you need to add the feature <code>ActuatorAPI</code>.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\" : {\n    \"ActuatorAPI\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/ActuatorAPI/#endpoints","title":"Endpoints","text":""},{"location":"sandbox/ActuatorAPI/#health","title":"/health","text":"<p>The health endpoints returns an 200 OK status code once the graph is loaded and all updaters are ready. Otherwise, a 404 NOT FOUND is returned.</p>"},{"location":"sandbox/ActuatorAPI/#prometheus","title":"/prometheus","text":"<p>Prometheus metrics are returned using Micrometer. The default JVM and jersey metrics are enabled.</p> <p>Also, GraphQL timing metrics are exported under <code>graphql.timer.query</code> and <code>graphql.timer.resolver</code>, if the GraphQL endpoints are enabled.</p>"},{"location":"sandbox/DataOverlay/","title":"Data Overlay","text":"<p>Use grid data in NetCDF format to populate the graph. Also provides custom route endpoint parameters for the data \"penalty\" and \"threshold\". This allows route planning to be based on the custom data calculated penalties. Data examples: air quality, environmental, and other data types that are tied to certain geographical locations.</p>"},{"location":"sandbox/DataOverlay/#contact-info","title":"Contact Info","text":"<p>Developed and maintained by Metatavu OY, Finland.</p> <p>Developers:</p> <p>Katja Danilova - katja.danilova@metatavu.fi\\ Simeon Platonov - simeon.platonov@metatavu.fi\\ Daniil Smirnov - daniil.smirnov@metatavu.fi</p> <p>In case of any questions please contact any of the people above by emails. We would like to continue developing and improving this feature and would love to hear any ideas from the community.</p> <p>Company email: info@metatavu.fi</p>"},{"location":"sandbox/DataOverlay/#changelog","title":"Changelog","text":"<ul> <li>Initial version (December 2021)</li> </ul>"},{"location":"sandbox/DataOverlay/#documentation","title":"Documentation","text":"<p>We have been working with OTP since version 1 mainly for producing the Air Quality affected routing for the city of Helsinki, Finland. That project required us to modify the original OTP quite a lot so we didn't propose our efforts for the community.</p> <p>With the OTP2 release we decided to create a dedicated layer on top of OTP2 which not only leaves the initial structure of the OpenTripPlanner intact, but also brings some additional features for those, who actually need them. This layer's main feature is populating the graph with a grid data ( i.e air quality, temperature, humidity, pressure, wind speed and direction, and e.t.c). For this to work two files are required: the actual data file (i.e in NetCDF format) and a .json settings file which describes the contents of the data file. Please refer to the diagram for more information.</p> <p>It is a sandbox feature.</p> <p>Please see the configuration part for setup instructions and examples.</p>"},{"location":"sandbox/DataOverlay/#configuration","title":"Configuration","text":"<p>Enable the feature by including it to the <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{ \"otpFeatures\": { \"DataOverlay\" : true } }\n</code></pre> <p>Plugin configuration should explain the NetCDF data file and request parameters that use the data file.</p> <ul> <li>fileName points to the data file</li> <li>latitudeVariable, longitudeVariable and timeVariable should be equal to the corresponding   variable names of the data file</li> <li>timeFormat options: MS_EPOCH, SECONDS, HOURS</li> <li>indexVariables contain a list of variables of data file that will affect the routing.<ul> <li>name can have any value and exists to act as a reference for requestPatameters (see below)</li> <li>displayName is a variable name in human-readable form that should make it more   understandable</li> <li>variable is the actual name of the variable from data file</li> </ul> </li> <li>requestParameters contains the list of REST request parameters that affects the cost   calculation.<ul> <li>name should be chosen from the list of enums:   org.opentripplanner.ext.dataoverlay.api.ParameterName</li> <li>variable should correspond to the name of one of the entries from indexVariables list   and explain which data field this parameter corresponds to</li> <li>formula should use the keywords VALUE and THRESHOLD and describe the way the penalty is   calculated. Note: if the result of the formula is negative it is ignored.</li> </ul> </li> </ul> <p>Example of build-config.json that includes the dataOverlay plugin configuration:</p> <pre><code>// build-config.json\n{\n  \"dataOverlay\" :\n  {\n    \"fileName\": \"graphs/data-file.nc4\",\n    \"latitudeVariable\": \"lat\",\n    \"longitudeVariable\": \"lon\",\n    \"timeVariable\": \"time\",\n    \"timeFormat\": \"HOURS\",\n    \"indexVariables\": [\n      {\n        \"name\": \"harmfulMicroparticlesPM2_5\",\n        \"displayName\": \"Harmful micro particles pm 2.5\",\n        \"variable\": \"cnc_PM2_5\"\n      },\n      {\n        \"name\": \"harmfulMicroparticlesPM10\",\n        \"displayName\": \"Harmful micro particles pm 10\",\n        \"variable\": \"cnc_PM10\"\n      }\n    ],\n    \"requestParameters\": [\n      {\n        \"name\": \"PARTICULATE_MATTER_2_5\",\n        \"variable\": \"harmfulMicroparticlesPM2_5\",\n        \"formula\": \"(VALUE + 1 - THRESHOLD) * PENALTY\"\n      },\n      {\n        \"name\": \"PARTICULATE_MATTER_10\",\n        \"variable\": \"harmfulMicroparticlesPM10\",\n        \"formula\": \"(VALUE + 1 - THRESHOLD) * PENALTY\"\n      }\n    ]\n  }\n\n}\n</code></pre> <p>Default values for Data overlay plugin can also be included in router-config instead of being sent with each request. If any Data overlay parameters are passed in user query, all the default values from router-config are ignored.</p> <pre><code>// router-config.json\n{\n  \"routingDefaults\": {\n    \"dataOverlay\" : {\n      \"particulate_matter_10_threshold\" : 100,\n      \"particulate_matter_10_penalty\" : 19\n    }\n  }\n}\n</code></pre>"},{"location":"sandbox/Emissions/","title":"CO\u2082 Emissions calculation","text":""},{"location":"sandbox/Emissions/#contact-info","title":"Contact Info","text":"<ul> <li>Digitransit Team</li> </ul>"},{"location":"sandbox/Emissions/#documentation","title":"Documentation","text":"<p>Graph build import of CO\u2082 Emissions from GTFS data sets (through custom emissions.txt extension) and the ability to attach them to itineraries by Digitransit team. The emissions are represented in grams per kilometer (g/Km) unit.</p> <p>Emissions data is located in an emissions.txt file within a gtfs package and has the following columns:</p> <p><code>route_id</code>: route id</p> <p><code>avg_co2_per_vehicle_per_km</code>: Average carbon dioxide equivalent value for the vehicles used on the route at grams/Km units.</p> <p><code>avg_passenger_count</code>: Average passenger count for the vehicles on the route.</p> <p>For example: <pre><code>route_id,avg_co2_per_vehicle_per_km,avg_passenger_count\n1234,123,20\n2345,0,0\n3456,12.3,20.0\n</code></pre></p> <p>Emissions data is loaded from the gtfs package and embedded into the graph during the build process.</p>"},{"location":"sandbox/Emissions/#configuration","title":"Configuration","text":"<p>To enable this functionality, you need to enable the \"Co2Emissions\"  feature in the <code>otp-config.json</code> file.</p> <p><pre><code>//otp-config.json\n{\n  \"Co2Emissions\": true\n}\n</code></pre> Include the <code>emissions</code> object in the <code>build-config.json</code> file. The <code>emissions</code> object should contain parameters called <code>carAvgCo2PerKm</code> and <code>carAvgOccupancy</code>. The <code>carAvgCo2PerKm</code> provides the average emissions value for a car in g/km and the <code>carAvgOccupancy</code> provides the average number of passengers in a car.</p>"},{"location":"sandbox/Emissions/#example-configuration","title":"Example configuration","text":"<pre><code>// build-config.json\n{\n  \"emissions\" : {\n    \"carAvgCo2PerKm\" : 170,\n    \"carAvgOccupancy\" : 1.3\n  }\n}\n</code></pre>"},{"location":"sandbox/Emissions/#overview","title":"Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since carAvgCo2PerKm <code>integer</code> The average CO\u2082 emissions of a car in grams per kilometer. Optional <code>170</code> 2.5 carAvgOccupancy <code>double</code> The average number of passengers in a car. Optional <code>1.3</code> 2.5"},{"location":"sandbox/Emissions/#details","title":"Details","text":""},{"location":"sandbox/Emissions/#changelog","title":"Changelog","text":""},{"location":"sandbox/Emissions/#otp-25","title":"OTP 2.5","text":"<ul> <li>Initial implementation of the emissions calculation.</li> </ul>"},{"location":"sandbox/Fares/","title":"Fares","text":""},{"location":"sandbox/Fares/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried (mail@leonard.io)</li> </ul>"},{"location":"sandbox/Fares/#documentation","title":"Documentation","text":"<p>The code in this sandbox used to be part of OTP core but to allow more experimentation - in  particular regarding GTFS Fares V2 - it was moved into a sandbox.</p>"},{"location":"sandbox/Fares/#fares-v2","title":"Fares V2","text":"<p>In 2022 the GTFS spec was extended to contain a powerful new model, called Fares V2, to describe fares, prices and products for public transport tickets. A baseline effort was merged into the main spec in May.</p> <p>OTP experimentally supports the merged baseline plus a few extensions from the larger, unmerged spec.</p> <p>To enable Fares V2 support, add the following to <code>otp-config.json</code>:</p> <pre><code>{\n  \"otpFeatures\" : {\n    \"FaresV2\" : true\n  }\n}\n</code></pre>"},{"location":"sandbox/Fares/#supported-fares-v2-fields","title":"Supported Fares V2 fields","text":"<p>A full list of the fields that OTP supports is available in the Fares V2 Adoption Google Sheet.</p>"},{"location":"sandbox/Fares/#custom-fare-calculators","title":"Custom fare calculators","text":"<p>When the GTFS Fares V1 spec was not enough, some organizations have developed their own calculators which are also part of the sandbox code.</p> <p>The classes and their maintainers are as follows:</p> class maintainer HighestFareInFreeTransferWindowFareService IBI Group (David Emory) AtlantaFareService IBI Group (David Emory) CombinedInterlinedLegsFareService IBI Group (David Emory) HSLFareServiceImpl HSL (Viljami Nurminen) OrcaFareService IBI Group (Daniel Heppner)"},{"location":"sandbox/Fares/#fares-configuration","title":"Fares configuration","text":"<p>By default OTP will compute fares according to the GTFS specification if fare data is provided in your GTFS input. It is possible to turn off this by setting the fare to \"off\". For more complex scenarios or to handle vehicle rental fares, it is necessary to manually configure fares using the <code>fares</code> section in <code>build-config.json</code>. You can combine different fares (for example transit and vehicle-rental) by defining a <code>combinationStrategy</code> parameter, and a list of sub-fares to combine (all fields starting with <code>fare</code> are considered to be sub-fares).</p> <pre><code>// build-config.json\n{\n  // Select the custom fare \"seattle\"\n  \"fares\": \"seattle\"\n}\n</code></pre> <p>Or this alternative form that could allow additional configuration</p> <pre><code>// build-config.json\n{\n  \"fares\": {\n    \"type\": \"seattle\"\n  }\n}\n</code></pre> <p>Turning the fare service off, this will ignore any fare data in the provided GTFS data.</p> <pre><code>// build-config.json\n{\n  \"fares\": \"off\"\n}\n</code></pre> <p>The current list of custom fare type is:</p> <ul> <li><code>highest-fare-in-free-transfer-window</code> Will apply the highest observed transit fare (across all   operators) within a free transfer window, adding to the cost if a trip is boarded outside the free   transfer window. It accepts the following parameters:<ul> <li><code>freeTransferWindow</code> the duration (in ISO8601-ish notation) that free transfers are   possible after the board time of the first transit leg. Default: <code>2h30m</code>.</li> <li><code>analyzeInterlinedTransfers</code> If true, will treat interlined transfers as actual transfers.   This is merely a work-around for transit agencies that choose to code their fares in a   route-based fashion instead of a zone-based fashion. Default: <code>false</code></li> </ul> </li> <li><code>atlanta</code> (no parameters)</li> <li><code>combine-interlined-legs</code> Will treat two interlined legs (those with a stay-seated transfer in   between them) as a single leg for the purpose of fare calculation.   It has a single parameter <code>mode</code> which controls when exactly the combination should happen:<ul> <li><code>ALWAYS</code>: All interlined legs are combined. (default)</li> <li><code>SAME_ROUTE</code>: Only interlined legs whose route ID are identical are combined.</li> </ul> </li> <li><code>orca</code> (no parameters)</li> <li><code>off</code> (no parameters)</li> </ul>"},{"location":"sandbox/Fares/#removed-fare-calculators","title":"Removed fare calculators","text":"<p>The following calculators used to be part of the OTP codebase but since their maintainership was unclear and no-one offered to maintain, they were removed in July 2022.</p> <ul> <li>SeattleFareServiceImpl</li> <li>DutchFareServiceImpl</li> </ul> <p>The NYC fare calculator was removed in #4694.</p> <p>The <code>MultipleFareService</code> was removed in #5100.</p> <p>The <code>SFBayFareServiceImpl</code> and <code>TimeBasedVehicleRentalFareService</code> were removed in #5145.</p> <p>If you were using these calculators, you're welcome to re-add them to the code base and become their maintainer.</p>"},{"location":"sandbox/Fares/#changelog","title":"Changelog","text":"<ul> <li>Initial move into sandbox #4241</li> <li>Add HighestFareInFreeTransferWindowFareService #4267</li> <li>Add Fares V2 #4338</li> <li>Add CombineInterlinedLegsFareService #4509</li> </ul>"},{"location":"sandbox/Flex/","title":"Flexible transit routing","text":""},{"location":"sandbox/Flex/#contact-info","title":"Contact Info","text":"<ul> <li>Kyyti Group Oy, Finland</li> <li>Entur, Norway</li> <li>Hannes Junnila</li> </ul>"},{"location":"sandbox/Flex/#documentation","title":"Documentation","text":"<p>To enable this turn on <code>FlexRouting</code> as a feature in <code>otp-config.json</code>.</p> <p>The GTFS feeds should conform to the GTFS-Flex v2.1 draft</p>"},{"location":"sandbox/Flex/#configuration","title":"Configuration","text":"<p>This feature allows a limited number of config options. To change the configuration, add the  following to <code>router-config.json</code>.</p>"},{"location":"sandbox/Flex/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"flex\" : {\n    \"maxTransferDuration\" : \"5m\",\n    \"maxFlexTripDuration\" : \"45m\",\n    \"maxAccessWalkDuration\" : \"15m\",\n    \"maxEgressWalkDuration\" : \"15m\"\n  }\n}\n</code></pre>"},{"location":"sandbox/Flex/#overview","title":"Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since maxAccessWalkDuration <code>duration</code> The maximum duration the passenger will be allowed to walk to reach a flex stop or zone. Optional <code>\"PT45M\"</code> 2.3 maxEgressWalkDuration <code>duration</code> The maximum duration the passenger will be allowed to walk after leaving the flex vehicle at the final destination. Optional <code>\"PT45M\"</code> 2.3 maxFlexTripDuration <code>duration</code> How long can a non-scheduled flex trip at maximum be. Optional <code>\"PT45M\"</code> 2.3 maxTransferDuration <code>duration</code> How long should a passenger be allowed to walk after getting out of a flex vehicle and transferring to a flex or transit one. Optional <code>\"PT5M\"</code> 2.3"},{"location":"sandbox/Flex/#details","title":"Details","text":""},{"location":"sandbox/Flex/#flex_maxAccessWalkDuration","title":"maxAccessWalkDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>The maximum duration the passenger will be allowed to walk to reach a flex stop or zone.</p> <p>If you have multiple overlapping flex zones the high default value can lead to performance problems. A lower value means faster routing.</p> <p>Depending on your service this might be what you want to do anyway: many flex services are used by passengers with mobility problems so offering a long walk might be problematic. In other words, if you can walk 45 minutes to a flex stop/zone you're unlikely to be the target audience for those services.</p>"},{"location":"sandbox/Flex/#flex_maxEgressWalkDuration","title":"maxEgressWalkDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>The maximum duration the passenger will be allowed to walk after leaving the flex vehicle at the final destination.</p> <p>If you have multiple overlapping flex zones the high default value can lead to performance problems. A lower value means faster routing.</p> <p>Depending on your service this might be what you want to do anyway: many flex services are used by passengers with mobility problems so offering a long walk might be problematic. In other words, if you can walk 45 minutes to a flex stop/zone you're unlikely to be the target audience for those services.</p>"},{"location":"sandbox/Flex/#flex_maxFlexTripDuration","title":"maxFlexTripDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>How long can a non-scheduled flex trip at maximum be.</p> <p>This is used for all trips which are of type <code>UnscheduledTrip</code>. The value includes the access/egress duration to the boarding/alighting of the flex trip, as well as the connection to the transit stop.</p>"},{"location":"sandbox/Flex/#flex_maxTransferDuration","title":"maxTransferDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT5M\"</code> Path: /flex </p> <p>How long should a passenger be allowed to walk after getting out of a flex vehicle and transferring to a flex or transit one.</p> <p>This was mainly introduced to improve performance which is also the reason for not using the existing value with the same name: fixed schedule transfers are computed during the graph build but flex ones are calculated at request time and are more sensitive to slowdown.</p> <p>A lower value means that the routing is faster.</p>"},{"location":"sandbox/Flex/#changelog","title":"Changelog","text":""},{"location":"sandbox/Flex/#otp-21","title":"OTP 2.1","text":"<ul> <li>Initial implementation of Flexible transit routing</li> <li>Use one-to-many search in order to make the performance of the StreetFlexPathCalculator   acceptable. (April 2021)</li> <li>Also link transit stops used by flex trips to the closest car traversable edge. This allows flex   street routing all the way to the stop. (April 2021)</li> <li>Fix performance issues with the   StreetFlexPathCalculator #3460</li> <li>Improve performance of flex access/egress   routing #3661</li> <li>Allow getting on and off at the same flex stop   time #3720</li> <li>Calculate fare for flex   routes #3743</li> </ul>"},{"location":"sandbox/Flex/#otp-23","title":"OTP 2.3","text":"<ul> <li>Enable configuration of <code>maxFlexTripDuration</code> and change of type of <code>maxTransferDuration</code>   routes #4642</li> </ul>"},{"location":"sandbox/GeocoderAPI/","title":"Geocoder API","text":""},{"location":"sandbox/GeocoderAPI/#contact-info","title":"Contact Info","text":"<ul> <li>realCity, Hungary</li> <li>Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/GeocoderAPI/#documentation","title":"Documentation","text":"<p>This sandbox feature implements geocoding endpoints for a number of use cases.</p> <p>To enable this you need to add the feature to <code>otp-config.json</code>. </p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"SandboxAPIGeocoder\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/GeocoderAPI/#endpoints","title":"Endpoints","text":""},{"location":"sandbox/GeocoderAPI/#debug-ui","title":"Debug UI","text":"<p>The required geocode API for Stop and From/To searches in the debug client.</p> <p>Path: <code>/otp/routers/{routerId}/geocode</code></p> <p>It supports the following URL parameters:</p> Parameter Description <code>query</code> The query string we want to geocode <code>autocomplete</code> Whether we should use the query string to do a prefix match <code>stops</code> Search for stops, either by name or stop code <code>clusters</code> Search for clusters by their name"},{"location":"sandbox/GeocoderAPI/#stop-clusters","title":"Stop clusters","text":"<p>A stop cluster is a deduplicated groups of stops. This means that for any stop that has a parent station only the parent is returned and for stops that have identical names and are very close to each other, only one is returned.</p> <p>This is useful for a general purpose fuzzy \"stop\" search.</p> <p>Path: <code>/otp/routers/{routerId}/geocode/stopClusters</code></p> <p>It supports the following URL parameters:</p> Parameter Description <code>query</code> The query string we want to geocode"},{"location":"sandbox/GeocoderAPI/#changelog","title":"Changelog","text":"<ul> <li>Initial version (June 2021)</li> <li>Updated to use Lucene (March 2022)</li> <li>Add stop clusters (May 2023)</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/","title":"Google Cloud Storage - Using GCS Bucket as a OTP Data Source","text":""},{"location":"sandbox/GoogleCloudStorage/#contact-info","title":"Contact Info","text":"<ul> <li>Thomas Gran, Entur, Norway</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/#changelog","title":"Changelog","text":""},{"location":"sandbox/GoogleCloudStorage/#otp-20","title":"OTP 2.0","text":"<ul> <li>Initial implementation to access Google Cloud Storage (read and write). (December 2019)</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/#documentation","title":"Documentation","text":"<p>To enable this turn on the feature <code>GoogleCloudStorage</code>. OTP can load or store artifacts from one or more Google Cloud Storge locations. Each artifact must be configured in the build-config.json: See <code>BuildConfig</code> on how to configure artifacts.</p> <p>Example (build-config.json):</p> <pre><code>{\n  \"gcsCredentials\": \"file:///Users/alf/secret/otp-test-1234567890.json\",\n  \"graph\": \"gs://otp-test-bucket/a/b/graph.obj\",\n  \"buildReportDir\": \"gs://otp-test-bucket/a/b/np-report\",\n  \"osm\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.pbf\"\n    }\n    ],\n  \"dem\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.dem.tif\"\n    }\n    ],\n  \"transitFeeds\": [\n    {\n      \"type\": \"gtfs\",\n      \"source\": \"gs://otp-test-bucket/a/b/gtfs.zip\"\n    }\n    ]\n}\n</code></pre>"},{"location":"sandbox/IBIAccessibilityScore/","title":"IBI Group Accessibility Score - OTP Sandbox Extension","text":""},{"location":"sandbox/IBIAccessibilityScore/#contact-info","title":"Contact Info","text":"<ul> <li>IBI Group (transitrealtime@ibigroup.com)</li> </ul>"},{"location":"sandbox/IBIAccessibilityScore/#changelog","title":"Changelog","text":"<ul> <li>Create initial   implementation #4221</li> </ul>"},{"location":"sandbox/IBIAccessibilityScore/#documentation","title":"Documentation","text":"<p>This extension computes a numeric accessibility score between 0 and 1 and adds it to the itinerary and its legs.</p> <p>Note: the information to calculate this score are all available to the frontend, however calculating them on the backend makes life a little easier and changes are automatically applied to all frontends.</p> <p>To enable the feature add the following to <code>router-config.json</code>:</p> <pre><code>// router-config.json\n{\n  \"routingDefaults\": {\n    \"itineraryFilters\": {\n      // add IBI accessibility score between 0 and 1\n      \"accessibilityScore\": true\n    }\n  }\n}\n</code></pre> <p>The score is only computed when you search for wheelchair-accessible routes.</p>"},{"location":"sandbox/InteractiveOtpMain/","title":"Interactive OTP Launcher","text":"<p>A GUI popup window to which help you to start OTP Main interactively.</p>"},{"location":"sandbox/InteractiveOtpMain/#contact-info","title":"Contact Info","text":"<ul> <li>Thomas Gran, Norway</li> </ul>"},{"location":"sandbox/InteractiveOtpMain/#changelog","title":"Changelog","text":"<ul> <li>Initial version (October 2020)</li> </ul>"},{"location":"sandbox/InteractiveOtpMain/#documentation","title":"Documentation","text":"<p>This is a simple GUI to help launch OTP Main. It is useful if you frequently launch OTP with data set and/or configuration. The <code>InteractiveOtpMain</code> search for all OTP data configurations directories available and help the user configure and start OTP.  </p>"},{"location":"sandbox/MapboxVectorTilesApi/","title":"Mapbox Vector Tiles API","text":""},{"location":"sandbox/MapboxVectorTilesApi/#contact-info","title":"Contact Info","text":"<ul> <li>HSL, Finland</li> <li>Arcadis, US</li> </ul>"},{"location":"sandbox/MapboxVectorTilesApi/#documentation","title":"Documentation","text":"<p>This API produces Mapbox vector tiles, which are used by Digitransit-ui and  <code>otp-react-redux</code> to show information about public transit entities on the map.</p> <p>The tiles can be fetched from <code>/otp/routers/{routerId}/vectorTiles/{layers}/{z}/{x}/{y}.pbf</code>, where <code>layers</code> is a comma separated list of layer names from the configuration.</p> <p>Maplibre/Mapbox GL JS also requires a tilejson.json endpoint which is available at <code>/otp/routers/{routerId}/vectorTiles/{layers}/tilejson.json</code>.</p> <p>Translatable fields in the tiles are translated based on the <code>accept-language</code> header in requests. Currently, only the language with the highest priority from the header is used.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#configuration","title":"Configuration","text":"<p>To enable this you need to add the feature <code>otp-config.json</code>.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"SandboxAPIMapboxVectorTilesApi\": true\n  }\n}\n</code></pre> <p>The feature must be configured in <code>router-config.json</code> as follows</p> <pre><code>{\n  \"vectorTiles\": {\n    \"basePath\": \"/only/configure/if/required\",\n    \"layers\": [\n      {\n        \"name\": \"stops\",\n        \"type\": \"Stop\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600\n      },\n      {\n        \"name\": \"stations\",\n        \"type\": \"Station\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 12,\n        \"cacheMaxSeconds\": 600\n      },\n      // all rental places: stations and free-floating vehicles\n      {\n        \"name\": \"citybikes\",\n        \"type\": \"VehicleRental\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60,\n        \"expansionFactor\": 0.25\n      },\n      // just free-floating vehicles\n      {\n        \"name\": \"rentalVehicles\",\n        \"type\": \"VehicleRentalVehicle\",\n        \"mapper\": \"DigitransitRealtime\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60\n      },\n      // just rental stations\n      {\n        \"name\": \"rentalStations\",\n        \"type\": \"VehicleRentalStation\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600\n      },\n      // Contains just stations and real-time information for them\n      {\n        \"name\": \"realtimeRentalStations\",\n        \"type\": \"VehicleRentalStation\",\n        \"mapper\": \"DigitransitRealtime\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60\n      },\n      // This exists for backwards compatibility. At some point, we might want\n      // to add a new real-time parking mapper with better translation support\n      // and less unnecessary fields.\n      {\n        \"name\": \"stadtnaviVehicleParking\",\n        \"type\": \"VehicleParking\",\n        \"mapper\": \"Stadtnavi\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60,\n        \"expansionFactor\": 0.25\n      },\n      // no real-time, translatable fields are translated based on accept-language header\n      // and contains less fields than the Stadtnavi mapper\n      {\n        \"name\": \"vehicleParking\",\n        \"type\": \"VehicleParking\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600,\n        \"expansionFactor\": 0.25\n      },\n      {\n        \"name\": \"vehicleParkingGroups\",\n        \"type\": \"VehicleParkingGroup\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 17,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600,\n        \"expansionFactor\": 0.25\n      }\n    ] \n  }\n}\n</code></pre> <p>For each layer, the configuration includes:</p> <ul> <li><code>name</code> which is used in the url to fetch tiles, and as the layer name in the vector tiles.</li> <li><code>type</code> which tells the type of the layer. Currently supported:<ul> <li><code>Stop</code></li> <li><code>Station</code></li> <li><code>VehicleRental</code>: all rental places: stations and free-floating vehicles</li> <li><code>VehicleRentalVehicle</code>: free-floating rental vehicles</li> <li><code>VehicleRentalStation</code>: rental stations</li> <li><code>VehicleParking</code></li> <li><code>VehicleParkingGroup</code></li> </ul> </li> </ul> Config Parameter Type Summary Req./Opt. Default Value Since basePath <code>string</code> The path of the vector tile source URLs in <code>tilejson.json</code>. Optional 2.5 layers <code>object[]</code> Configuration of the individual layers for the Mapbox vector tiles. Optional 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"stop\" <code>enum</code> Type of the layer. Required 2.0 cacheMaxSeconds <code>integer</code> Sets the cache header in the response. Optional <code>-1</code> 2.0 expansionFactor <code>double</code> How far outside its boundaries should the tile contain information. Optional <code>0.25</code> 2.0 mapper <code>string</code> Describes the mapper converting from the OTP model entities to the vector tile properties. Required 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0maxZoom <code>integer</code> Maximum zoom levels the layer is active for. Optional <code>20</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0minZoom <code>integer</code> Minimum zoom levels the layer is active for. Optional <code>9</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name <code>string</code> Used in the url to fetch tiles, and as the layer name in the vector tiles. Required 2.0"},{"location":"sandbox/MapboxVectorTilesApi/#details","title":"Details","text":""},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_basePath","title":"basePath","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /vectorTiles </p> <p>The path of the vector tile source URLs in <code>tilejson.json</code>.</p> <p>This is useful if you have a proxy setup and rewrite the path that is passed to OTP.</p> <p>If you don't configure this optional value then the path returned in <code>tilejson.json</code> is in the format <code>/otp/routers/default/vectorTiles/layer1,layer2/{z}/{x}/{x}.pbf</code>. If you, for example, set a value of <code>/otp_test/tiles</code> then the returned path changes to <code>/otp_test/tiles/layer1,layer2/{z}/{x}/{x}.pbf</code>.</p> <p>The protocol and host are always read from the incoming HTTP request. If you run OTP behind a proxy then make sure to set the headers <code>X-Forwarded-Proto</code> and <code>X-Forwarded-Host</code> to make OTP return the protocol and host for the original request and not the proxied one.</p> <p>Note: This does not change the path that OTP itself serves the tiles or <code>tilejson.json</code> responses but simply changes the URLs listed in <code>tilejson.json</code>. The rewriting of the path is expected to be handled by a proxy.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers","title":"layers","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /vectorTiles </p> <p>Configuration of the individual layers for the Mapbox vector tiles.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_cacheMaxSeconds","title":"cacheMaxSeconds","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>-1</code> Path: /vectorTiles/layers/[0] </p> <p>Sets the cache header in the response.</p> <p>The lowest value of the layers included is selected.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_expansionFactor","title":"expansionFactor","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.25</code> Path: /vectorTiles/layers/[0] </p> <p>How far outside its boundaries should the tile contain information.</p> <p>The value is a fraction of the tile size. If you are having problem with icons and shapes being clipped at tile edges, then increase this number.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_mapper","title":"mapper","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /vectorTiles/layers/[0] </p> <p>Describes the mapper converting from the OTP model entities to the vector tile properties.</p> <p>Currently <code>Digitransit</code> is supported for all layer types.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#extending","title":"Extending","text":"<p>If more generic layers are created for this API, the code should be moved out from the sandbox, into  the core, perhaps potentially leaving specific property mappers in place.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#creating-a-new-layer","title":"Creating a new layer","text":"<p>In order to create a new type of layer, you need to create a new class extending <code>LayerBuilder&lt;T&gt;</code>. You need to implement two methods, <code>List&lt;Geometry&gt; getGeometries(Envelope query)</code>, which returns a list of geometries, with an object of type <code>T</code> as their userData in the geometry, and <code>double getExpansionFactor()</code>, which describes how much information outside the tile bounds should be included. This layer then needs to be added into <code>VectorTilesResource.layers</code>, with a new <code>LayerType</code> enum as the key, and the class constructor as the value.</p> <p>A new mapper needs to be added every time a new layer is added. See below for information.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#creating-a-new-mapper","title":"Creating a new mapper","text":"<p>The mapping contains information of what data to include in the vector tiles. The mappers are defined per layer.</p> <p>In order to create a new mapper for a layer, you need to create a new class extending <code>PropertyMapper&lt;T&gt;</code>. In that class, you need to implement the method <code>Collection&lt;KeyValue&lt;String, Object&gt;&gt; map(T input)</code>. The type T is dependent on the layer for which you implement the mapper for. It needs to return a list of attributes, as key-value pairs which will be written into the vector tile.</p> <p>The mapper needs to be added to the <code>mappers</code> map in the layer, with a new <code>MapperType</code> enum as the key, and a function to create the mapper, with a <code>Graph</code> object as a parameter, as the value.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#changelog","title":"Changelog","text":"<ul> <li>2020-07-09: Initial version of Mapbox vector tiles API</li> <li>2021-05-12: Make expansion factor configurable</li> <li>2021-09-07: Rename <code>BikeRental</code> to <code>VehicleRental</code></li> <li>2021-10-13: Correctly serialize the vehicle rental name #3648</li> <li>2022-01-03: Add support for VehicleParking entities</li> <li>2022-04-27: Read the headsign for frequency-only patterns correctly #4122</li> <li>2022-08-23: Remove patterns and add route gtfsTypes to stop layer #4404</li> <li>2022-10-11: Added layer for VehicleParkingGroups #4510</li> <li>2022-10-14: Add separate layers for vehicle rental place types #4516</li> <li>2022-10-19 #4529:</li> <li>Translatable fields are now translated based on accept-language header</li> <li>Added DigitransitRealtime for vehicle rental stations</li> <li>Changed old vehicle parking mapper to be Stadtnavi</li> <li>Added a new Digitransit vehicle parking mapper with no real-time information and less fields</li> <li>2024-01-22: Make <code>basePath</code> configurable #5627</li> </ul>"},{"location":"sandbox/ParkAndRideApi/","title":"Park and Ride API","text":""},{"location":"sandbox/ParkAndRideApi/#contact-info","title":"Contact Info","text":"<ul> <li>Evan Siroky, IBI Group, USA</li> </ul>"},{"location":"sandbox/ParkAndRideApi/#changelog","title":"Changelog","text":"<ul> <li>Initial version of the Park and Ride API. (February 2021)</li> </ul>"},{"location":"sandbox/ParkAndRideApi/#documentation","title":"Documentation","text":"<p>This adds a new API endpoint for fetching Park and Rides included in the current graph. It is possible to search using a bounding box and/or proximity of Park and Rides to nearby transit stops.</p>"},{"location":"sandbox/ReportApi/","title":"Report API","text":"<p>The report API is a collection of reports generated as CSV files. The main use-case is to download data for manual analyzes and verification. The CSV files should not be used as a service by another programs, the report can be changed at any time - without any notice.</p> <p>Feel free to add more reports and to add your organization to the contact info list.</p>"},{"location":"sandbox/ReportApi/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> <li>Leonard Ehrenfried, Germany, mail@leonard.io</li> </ul>"},{"location":"sandbox/ReportApi/#changelog","title":"Changelog","text":"<ul> <li>2021-05-19: Initial version of the report API. Support listing all transfers as a CSV text file.</li> <li>2021-07-19: Add report that exports the bicycle safety factors as CSV and an interactive HTML   table view.</li> </ul>"},{"location":"sandbox/ReportApi/#documentation","title":"Documentation","text":"<p>This module mounts an endpoint for generating reports under <code>otp/report</code>. Available reports:</p> <ul> <li>/otp/report/transfers.csv</li> <li>/otp/report/graph.json   Detailed numbers of transit and street entities in the graph</li> <li>/otp/report/bicycle-safety.html:   Interactive viewer of the rules that determine how bicycle safety factors are calculated.</li> <li>/otp/report/bicycle-safety.csv: Raw CSV   data for the bicycle safety report.<ul> <li>Norwegian version</li> <li>German version</li> <li>UK version</li> <li>Finnish version</li> </ul> </li> <li>/otp/report/transit/group/priorities:   List all transit groups used for transit-group-priority (Competition neutral planning).   </li> </ul>"},{"location":"sandbox/ReportApi/#configuration","title":"Configuration","text":"<p>The report API is turned off by default. To turn it on enable the <code>ReportApi</code> feature.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"ReportApi\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/RideHailing/","title":"Ride hailing services","text":"<p>This sandbox feature allows you to use ride hailing services like Uber.</p>"},{"location":"sandbox/RideHailing/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/RideHailing/#configuration","title":"Configuration","text":"<p>In order enable this feature, add a new section <code>rideHailingServices</code> in <code>router-config.json</code>.</p> <p>The supported ride-hailing providers are listed below.</p>"},{"location":"sandbox/RideHailing/#uber","title":"Uber","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"uber-car-hailing\" <code>enum</code> The type of the service. Required 2.3 clientId <code>string</code> OAuth client id to access the API. Required 2.3 clientSecret <code>string</code> OAuth client secret to access the API. Required 2.3 wheelchairAccessibleProductId <code>string</code> The id of the requested wheelchair-accessible product ID. Required 2.3 bannedProductIds <code>string[]</code> The IDs of those product ids that should not be used for estimates. Optional 2.3"},{"location":"sandbox/RideHailing/#details","title":"Details","text":""},{"location":"sandbox/RideHailing/#rideHailingServices_0_wheelchairAccessibleProductId","title":"wheelchairAccessibleProductId","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /rideHailingServices/[0] </p> <p>The id of the requested wheelchair-accessible product ID.</p> <p>See <code>bannedProductIds</code> for a list of product IDs.</p>"},{"location":"sandbox/RideHailing/#rideHailingServices_0_bannedProductIds","title":"bannedProductIds","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /rideHailingServices/[0] </p> <p>The IDs of those product ids that should not be used for estimates.</p> <p>See the current list of Uber product ids.</p>"},{"location":"sandbox/RideHailing/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"rideHailingServices\" : [\n    {\n      \"type\" : \"uber-car-hailing\",\n      \"clientId\" : \"secret-id\",\n      \"clientSecret\" : \"very-secret\",\n      \"wheelchairAccessibleProductId\" : \"545de0c4-659f-49c6-be65-0d5e448dffd5\",\n      \"bannedProductIds\" : [\n        \"1196d0dd-423b-4a81-a1d8-615367d3a365\",\n        \"f58761e5-8dd5-4940-a472-872f1236c596\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriAzureUpdater/","title":"Siri Azure Updater","text":"<p>It is sandbox extension developed by Sk\u00e5netrafiken that allows OTP to fetch Siri ET &amp; SX messages through Azure Service Bus. IT also OTP to download historical data from en HTTP endpoint on startup.</p>"},{"location":"sandbox/SiriAzureUpdater/#contact-info","title":"Contact Info","text":"<p>Sk\u00e5netrafiken, Sweden developer.otp@skanetrafiken.se</p>"},{"location":"sandbox/SiriAzureUpdater/#changelog","title":"Changelog","text":"<ul> <li>Added configuration for turning off stop arrival time match feature. </li> <li>Initial version (April 2022)</li> <li>Minor changes in logging (November 2022)</li> <li>Retry fetch from history endpoint if it failed (February 2023)</li> <li>Solve a bug in SiriAzureETUpdater and improve error logging (March 2023)</li> </ul>"},{"location":"sandbox/SiriAzureUpdater/#documentation","title":"Documentation","text":"<p>Documentation available here.</p>"},{"location":"sandbox/SiriAzureUpdater/#configuration","title":"Configuration","text":"<p>See example configuration in <code>examples/skanetrafiken/router-config.json</code>.</p>"},{"location":"sandbox/SiriUpdater/","title":"Siri Updater","text":"<p>Support for consuming SIRI ET and SX messages. The updater is developed to support the Nordic SIRI profile which is a subset of the SIRI specification.</p>"},{"location":"sandbox/SiriUpdater/#contact-info","title":"Contact Info","text":"<ul> <li>Lasse Tyrihjell, Entur, Norway</li> </ul>"},{"location":"sandbox/SiriUpdater/#documentation","title":"Documentation","text":"<p>This updater consumes SIRI real time information. It is developed by Entur and supports the Nordic Profile for SIRI. It should be possible to develop it further to support a broader set of the SIRI specification.</p> <p>For more documentation goto the Entur Real-Time Data documentation and the Norwegian SIRI profile .</p>"},{"location":"sandbox/SiriUpdater/#configuration","title":"Configuration","text":"<p>To enable the SIRI updater you need to add it to the updaters section of the <code>router-config.json</code>.</p>"},{"location":"sandbox/SiriUpdater/#siri-et-via-https","title":"Siri-ET via HTTPS","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"siri-et-updater\" <code>enum</code> The type of the updater. Required 1.5 blockReadinessUntilInitialized <code>boolean</code> Whether catching up with the updates should block the readiness check from returning a 'ready' result. Optional <code>false</code> 2.0 feedId <code>string</code> The ID of the feed to apply the updates to. Required 2.0 frequency <code>duration</code> How often the updates should be retrieved. Optional <code>\"PT1M\"</code> 2.0 fuzzyTripMatching <code>boolean</code> If the fuzzy trip matcher should be used to match trips. Optional <code>false</code> 2.0 previewInterval <code>duration</code> TODO Optional 2.0 requestorRef <code>string</code> The requester reference. Optional 2.0 timeout <code>duration</code> The HTTP timeout to download the updates. Optional <code>\"PT15S\"</code> 2.0 url <code>string</code> The URL to send the HTTP requests to. Required 2.0 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/SiriUpdater/#parameter-details","title":"Parameter details","text":""},{"location":"sandbox/SiriUpdater/#u__8__url","title":"url","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[8] </p> <p>The URL to send the HTTP requests to.</p> <p>Use the file protocol to set a directory for reading updates from a directory. The file loader will look for xml files: '*.xml' in the configured directory. The files are renamed by the loader when processed:</p> <p> a.xml \u00a0 \u279e \u00a0 a.xml.inProgress \u00a0 \u279e \u00a0 a.xml.ok \u00a0 or \u00a0 a.xml.failed</p>"},{"location":"sandbox/SiriUpdater/#u__8__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[8] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/SiriUpdater/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"siri-et-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Authorization\" : \"Some-Token\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriUpdater/#siri-sx-via-https","title":"Siri-SX via HTTPS","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"siri-sx-updater\" <code>enum</code> The type of the updater. Required 1.5 blockReadinessUntilInitialized <code>boolean</code> Whether catching up with the updates should block the readiness check from returning a 'ready' result. Optional <code>false</code> 2.0 earlyStart <code>duration</code> This value is subtracted from the actual validity defined in the message. Optional <code>\"PT0S\"</code> 2.0 feedId <code>string</code> The ID of the feed to apply the updates to. Required 2.0 frequency <code>duration</code> How often the updates should be retrieved. Optional <code>\"PT1M\"</code> 2.0 requestorRef <code>string</code> The requester reference. Optional 2.0 timeout <code>duration</code> The HTTP timeout to download the updates. Optional <code>\"PT15S\"</code> 2.0 url <code>string</code> The URL to send the HTTP requests to. Supports http/https and file protocol. Required 2.0 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/SiriUpdater/#parameter-details_1","title":"Parameter details","text":""},{"location":"sandbox/SiriUpdater/#u__9__earlyStart","title":"earlyStart","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /updaters/[9] </p> <p>This value is subtracted from the actual validity defined in the message.</p> <p>Normally the planned departure time is used, so setting this to 10s will cause the SX-message to be included in trip-results 10 seconds before the the planned departure time.</p>"},{"location":"sandbox/SiriUpdater/#u__9__url","title":"url","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[9] </p> <p>The URL to send the HTTP requests to. Supports http/https and file protocol.</p> <p>Use the file protocol to set a directory for reading updates from a directory. The file loader will look for xml files: '*.xml' in the configured directory. The files are renamed by the loader when processed:</p> <p> a.xml \u00a0 \u279e \u00a0 a.xml.inProgress \u00a0 \u279e \u00a0 a.xml.ok \u00a0 or \u00a0 a.xml.failed</p>"},{"location":"sandbox/SiriUpdater/#u__9__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[9] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/SiriUpdater/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"siri-sx-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Key\" : \"Value\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriUpdater/#changelog","title":"Changelog","text":"<ul> <li>Initial version of SIRI updater (October 2019)</li> <li>Include situations with no or no handled entity selectors with Unknown EntitySelector (December   2021, https://github.com/opentripplanner/OpenTripPlanner/pull/3780)</li> </ul>"},{"location":"sandbox/SmooveBikeRental/","title":"HSL Smoove Bike Rental Updater Support - OTP Sandbox Extension","text":""},{"location":"sandbox/SmooveBikeRental/#contact-info","title":"Contact Info","text":"<ul> <li>Digitransit team, HSL, Helsinki, Finland</li> </ul>"},{"location":"sandbox/SmooveBikeRental/#changelog","title":"Changelog","text":"<ul> <li>Move this functonality into a sandbox</li> <li>Add allowOverloading through updater config to the stations and isRenting, isReturning and   capacity from the data to stations (October   2021, https://github.com/opentripplanner/OpenTripPlanner/pull/3632)</li> <li>Rename <code>allowOverloading</code> to <code>overloadingAllowed</code></li> </ul>"},{"location":"sandbox/SmooveBikeRental/#documentation","title":"Documentation","text":"<p>TODO</p>"},{"location":"sandbox/SmooveBikeRental/#configuration","title":"Configuration","text":"<p>An example updater configuration:</p> <pre><code>{\n    \"type\": \"bike-rental\",\n    \"sourceType\": \"smoove\",\n    \"network\": \"smoove-network-1\",\n    \"url\": \"https://helsinki-fi.smoove.pro/api-public/stations\",\n    \"frequency\": 10,\n    \"overloadingAllowed\": true\n}\n</code></pre> <p><code>network</code> (optional) allows defining custom network id</p> <p><code>overloadingAllowed</code> (optional) defines if the stations in the network allow overloading (ignoring available spaces)</p>"},{"location":"sandbox/StopConsolidation/","title":"Stop Consolidation","text":""},{"location":"sandbox/StopConsolidation/#stop-consolidation","title":"Stop consolidation","text":""},{"location":"sandbox/StopConsolidation/#contact-info","title":"Contact Info","text":"<ul> <li>Jon Campbell, Arcadis, USA</li> </ul>"},{"location":"sandbox/StopConsolidation/#feature-explanation","title":"Feature explanation","text":"<p>This sandbox feature allows you to \"combine\" equivalent stops from across several feeds into a single, consolidated one. </p> <p>It is achieved by defining a \"primary\" stop and one or more \"secondary\" stops. During the graph build all trip patterns are modified so that the secondary ones are swapped out for their primary equivalent.</p>"},{"location":"sandbox/StopConsolidation/#effects","title":"Effects","text":"<p>This has the following consequences </p> <ul> <li>When you query the departures for a primary stop you see a consolidated view of all the equivalent departures.</li> <li>When transferring at a consolidated stop you no longer get instructions like \"walk 5 meters to stop X\"</li> </ul> <p>Downsides</p> <p>However, this feature has also severe downsides:</p> <ul> <li>It makes real-time trip updates referencing a stop id much more complicated and in many cases    impossible to resolve.    You can only reference a stop by its sequence, which only works in GTFS-RT, not Siri.</li> <li>Fare calculation and transfers are unlikely to work as expected.</li> </ul>"},{"location":"sandbox/StopConsolidation/#configuration","title":"Configuration","text":"<p>To enable this feature you need to add a file to OTP's working directory and configure its name like this:</p> <pre><code>// build-config.json\n{\n  \"stopConsolidationFile\" : \"consolidated-stops.csv\"\n}\n</code></pre> <p>The additional config file must look like the following:</p> <pre><code>stop_group_id,feed_id,stop_id,is_primary\n1,pierce,1705867009,0\n1,kcm,10225,1\n2,pierce,1569,0\n2,commtrans,473,0\n2,kcm,1040,1\n</code></pre> <p>The column names mean the following:</p> <ul> <li><code>stop_group_id</code>: id to group several rows in the file together</li> <li><code>feed_id</code>: feed id of the stop</li> <li><code>stop_id</code>: id of the stop</li> <li><code>is_primary</code>: whether the row represents a primary stop, <code>1</code> means yes and <code>0</code> means no</li> </ul>"},{"location":"sandbox/TravelTime/","title":"Travel Time (Isochrone &amp; Surface) API","text":""},{"location":"sandbox/TravelTime/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/TravelTime/#changelog","title":"Changelog","text":"<ul> <li>2022-05-09 Initial implementation</li> </ul>"},{"location":"sandbox/TravelTime/#documentation","title":"Documentation","text":"<p>The API produces a snapshot of travel time form a single place to places around it. The results can be fetched either as a set of isochrones or a raster map.</p>"},{"location":"sandbox/TravelTime/#configuration","title":"Configuration","text":"<p>The feature must be enabled in otp-config.json as follows:</p> <pre><code>// otp-config.json\n{\n    \"otpFeatures\" : {\n        \"SandboxAPITravelTime\" : true\n    }\n}\n</code></pre>"},{"location":"sandbox/TravelTime/#api-parameters","title":"API parameters","text":"<ul> <li><code>location</code> Origin of the search, can be either <code>latitude,longitude</code> or a stop id</li> <li><code>time</code> Departure time as a ISO-8601 time and date (example <code>2023-04-24T15:40:12+02:00</code>). The default value is the current time.</li> <li><code>cutoff</code> The maximum travel duration as a ISO-8601 duration. The <code>PT</code> can be dropped to simplify the value.    This parameter can be given multiple times to include multiple isochrones in a single request.   The default value is one hour.</li> <li><code>modes</code> A list of travel modes. WALK is not implemented, use <code>WALK, TRANSIT</code> instead.</li> <li><code>arriveBy</code> Set to <code>false</code> when searching from the location and <code>true</code> when searching to the    location</li> </ul>"},{"location":"sandbox/TravelTime/#isochrone-api","title":"Isochrone API","text":"<p><code>/otp/traveltime/isochrone</code></p> <p>Results is the travel time boundaries at the <code>cutoff</code> travel time.</p>"},{"location":"sandbox/TravelTime/#travel-time-surface-api","title":"Travel time surface API","text":"<p><code>/otp/traveltime/surface</code></p> <p>The travel time as a GeoTIFF raster file. The file has a single 32-bit int band, which contains the  travel time in seconds.</p>"},{"location":"sandbox/TravelTime/#example-request","title":"Example Request","text":"<pre><code>http://localhost:8080/otp/traveltime/isochrone?batch=true&amp;location=52.499959,13.388803&amp;time=2023-04-12T10:19:03%2B02:00&amp;modes=WALK,TRANSIT&amp;arriveBy=false&amp;cutoff=30M17S\n</code></pre>"},{"location":"sandbox/VehicleParking/","title":"Vehicle Parking Updaters","text":""},{"location":"sandbox/VehicleParking/#contact-info","title":"Contact Info","text":"<ul> <li>For HSL Park and Ride updater: Digitransit team, HSL, Helsinki, Finland</li> <li>For Bikely updater: Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/VehicleParking/#documentation","title":"Documentation","text":"<p>This sandbox contains vehicle parking updaters. Unlike for some other sandbox features, this is not enabled/disabled through <code>otp-config.json</code> but from <code>router-config.json</code> updaters.</p> <p>Currently contains the following updaters:</p> <ul> <li>HSL Park and Ride</li> <li>ParkAPI</li> <li>Bikely</li> </ul>"},{"location":"sandbox/VehicleParking/#configuration","title":"Configuration","text":"<p>These sandboxed vehicle parking updaters can be enabled by editing the <code>updaters</code> section in the <code>router-config.json</code> according to the following examples.</p> <p>All updaters have the following parameters in common:</p> <ul> <li><code>type</code>: this needs to be <code>\"vehicle-parking\"</code></li> <li><code>feedId</code>: this is used as a \"prefix\" for park ids, entrance ids and sometimes also for tags.</li> </ul>"},{"location":"sandbox/VehicleParking/#hsl-park-and-ride","title":"HSL Park and Ride","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 facilitiesFrequencySec <code>integer</code> How often the facilities should be updated. Optional <code>3600</code> 2.2 facilitiesUrl <code>string</code> URL of the facilities. Optional 2.2 feedId <code>string</code> The name of the data source. Required 2.2 hubsUrl <code>string</code> Hubs URL Optional 2.2 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 timeZone <code>time-zone</code> The time zone of the feed. Optional 2.2 utilizationsFrequencySec <code>integer</code> How often the utilization should be updated. Optional <code>600</code> 2.2 utilizationsUrl <code>string</code> URL of the utilization data. Optional 2.2"},{"location":"sandbox/VehicleParking/#details","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__2__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[2] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__2__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[2]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__2__timeZone","title":"timeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[2] </p> <p>The time zone of the feed.</p> <p>Used for converting abstract opening hours into concrete points in time.</p>"},{"location":"sandbox/VehicleParking/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"hsl-park\",\n      \"feedId\" : \"hslpark\",\n      \"timeZone\" : \"Europe/Helsinki\",\n      \"facilitiesFrequencySec\" : 3600,\n      \"facilitiesUrl\" : \"https://p.hsl.fi/api/v1/facilities.json?limit=-1\",\n      \"utilizationsFrequencySec\" : 600,\n      \"utilizationsUrl\" : \"https://p.hsl.fi/api/v1/utilizations.json?limit=-1\",\n      \"hubsUrl\" : \"https://p.hsl.fi/api/v1/hubs.json?limit=-1\"\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#parkapi","title":"ParkAPI","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> The name of the data source. Required 2.2 frequency <code>duration</code> How often to update the source. Optional <code>\"PT1M\"</code> 2.2 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 timeZone <code>time-zone</code> The time zone of the feed. Optional 2.2 url <code>string</code> URL of the resource. Optional 2.2 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.2 tags <code>string[]</code> Tags to add to the parking lots. Optional 2.2"},{"location":"sandbox/VehicleParking/#details_1","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__3__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[3] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__3__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[3]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__3__timeZone","title":"timeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>The time zone of the feed.</p> <p>Used for converting abstract opening hours into concrete points in time.</p>"},{"location":"sandbox/VehicleParking/#u__3__headers","title":"headers","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleParking/#u__3__tags","title":"tags","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>Tags to add to the parking lots.</p>"},{"location":"sandbox/VehicleParking/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"park-api\",\n      \"feedId\" : \"parkapi\",\n      \"timeZone\" : \"Europe/Berlin\",\n      \"frequency\" : \"10m\",\n      \"url\" : \"https://foo.bar\",\n      \"headers\" : {\n        \"Cache-Control\" : \"max-age=604800\"\n      },\n      \"tags\" : [\n        \"source:parkapi\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#bikely","title":"Bikely","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> The name of the data source. Required 2.2 frequency <code>duration</code> How often to update the source. Optional <code>\"PT1M\"</code> 2.3 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 url <code>string</code> URL of the locations endpoint. Optional 2.3 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/VehicleParking/#details_2","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__4__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[4] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__4__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[4]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__4__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[4] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleParking/#example-configuration_2","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"feedId\" : \"bikely\",\n      \"sourceType\" : \"bikely\",\n      \"url\" : \"https://api.safebikely.com/api/v1/s/locations\",\n      \"headers\" : {\n        \"X-Bikely-Token\" : \"${BIKELY_TOKEN}\",\n        \"Authorization\" : \"${BIKELY_AUTHORIZATION}\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#changelog","title":"Changelog","text":"<ul> <li>Create initial sandbox implementation (January 2022, #3796)</li> <li>Add timeZone parameter to hsl and parkapi updaters (September 2022, #4427)</li> <li>Added support for HSL parking hubs (October 2022, #4510)</li> <li>Add Bikely updater (November 2022, #4589)</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/","title":"Vehicle Rental Service Directory API support.","text":"<p>This adds support for the GBFS service directory endpoint component located at  https://github.com/entur/lamassu. OTP uses the service directory to lookup and connect to all GBFS endpoints registered in the directory. This simplifies the management of the GBFS endpoints, since multiple services/components like OTP can connect to the directory and get the necessary configuration from it.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/#changelog","title":"Changelog","text":"<ul> <li>Initial implementation of bike share updater API support</li> <li>Make json tag names configurable #3447</li> <li>Enable GBFS geofencing with VehicleRentalServiceDirectory #5324</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/#configuration","title":"Configuration","text":"<p>To enable this you need to specify a url for the <code>vehicleRentalServiceDirectory</code> in the <code>router-config.json</code></p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#parameter-summary","title":"Parameter Summary","text":"Config Parameter Type Summary Req./Opt. Default Value Since language <code>string</code> Language code. Optional 2.1 sourcesName <code>string</code> Json tag name for updater sources. Optional <code>\"systems\"</code> 2.1 updaterNetworkName <code>string</code> Json tag name for the network name for each source. Optional <code>\"id\"</code> 2.1 updaterUrlName <code>string</code> Json tag name for endpoint urls for each source. Optional <code>\"url\"</code> 2.1 url <code>uri</code> Endpoint for the VehicleRentalServiceDirectory Required 2.1 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.1 networks <code>object[]</code> List all networks to include. Use \"network\": \"default-network\" to set defaults. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0geofencingZones <code>boolean</code> Enables geofencingZones for the given network Optional <code>false</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0network <code>string</code> The network name Required 2.4"},{"location":"sandbox/VehicleRentalServiceDirectory/#parameter-details","title":"Parameter Details","text":""},{"location":"sandbox/VehicleRentalServiceDirectory/#vehicleRentalServiceDirectory_headers","title":"headers","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /vehicleRentalServiceDirectory </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#vehicleRentalServiceDirectory_networks","title":"networks","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /vehicleRentalServiceDirectory </p> <p>List all networks to include. Use \"network\": \"default-network\" to set defaults.</p> <p>If no default network exists only the listed networks are used. Configure a network with name \"default-network\" to include all unlisted networks. If not present, all unlisted networks are dropped. Note! The values in the \"default-network\" are not used to set missing field values in networks listed.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#example","title":"Example","text":"<pre><code>// router-config.json\n{\n  \"vehicleRentalServiceDirectory\" : {\n    \"url\" : \"https://example.com\",\n    \"sourcesName\" : \"systems\",\n    \"updaterUrlName\" : \"url\",\n    \"updaterNetworkName\" : \"id\",\n    \"headers\" : {\n      \"ET-Client-Name\" : \"otp\"\n    },\n    \"networks\" : [\n      {\n        \"network\" : \"oslo-by-sykkel\",\n        \"geofencingZones\" : true\n      }\n    ]\n  }\n}\n</code></pre>"},{"location":"sandbox/VehicleToStopHeuristics/","title":"Vehicle-to-Stop heuristics - OTP Sandbox Extension","text":""},{"location":"sandbox/VehicleToStopHeuristics/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried (mail@leonard.io)</li> </ul>"},{"location":"sandbox/VehicleToStopHeuristics/#changelog","title":"Changelog","text":"<ul> <li>Create initial   implementation #3906</li> </ul>"},{"location":"sandbox/VehicleToStopHeuristics/#documentation","title":"Documentation","text":"<p>This feature is meant to improve the performance and result quality for routing requests where a vehicle (car, bike, scooter) is ridden to a stop where transit is boarded.</p> <p>Before this feature existed a search for nearby stops was executed finding all candidate stops for boarding transit. For walking this yields a low number of stops but when driving a car this can easily mean to an entire city of stops, since the default was a drive of 45 minutes.</p> <p>Having a very long driving time has several problems:</p> <ul> <li>the access search itself is comparatively slow</li> <li>having many candidate stops slows down the transit search as many routes have to be checked</li> <li>often the quickest route would be to drive almost all the way to the destination and board transit   for a single stop</li> </ul> <p>We did not want to lower the maximum access time since in rural regions 45 minutes might be a useful maximum, but we want it to scale with the density of well-connected stops.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#vehicle-to-stop-heuristic","title":"Vehicle-to-stop heuristic","text":"<p>In order to improve the Park+Ride and Bike+Ride results we reduced the number of candidate stops with the following heuristic:</p> <ol> <li>When a stop is encountered check which routes depart from it</li> <li>Each route adds to an \"importance score\"</li> <li>Modes which are fast (RAIL, SUBWAY, FERRY) have a higher score than for example BUS</li> <li>Once a maximum score is reached, the search is complete</li> </ol> <p>The code for this is located in <code>VehicleToStopSkipEdgeStrategy.java</code>.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#bicycle-on-transit-heuristic","title":"Bicycle-on-transit heuristic","text":"<p>This heuristic works slightly differently in that it doesn't assign a score but simply stops the access search when a certain number of routes were encountered that allow you to take your bike onto transit.</p> <p>The code for this is located in <code>BikeToStopSkipEdgeStrategy.java</code>.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#configuration","title":"Configuration","text":"<p>Enable the feature by adding it to the <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"VehicleToStopHeuristics\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/VehicleToStopHeuristics/#collaborators-wanted","title":"Collaborators wanted","text":"<p>Since the current settings, scores and weights are hardcoded in the source code we are looking for collaborators that can help to make it more adaptable for different environments.</p> <p>These are some the goals for the future:</p> <ul> <li>make the scores that are assigned for routes of a certain mode configurable in JSON</li> <li>pre-calculate stop importance scores during the graph build</li> </ul> <p>If you want to help making this feature more flexible, please contact Leonard Ehrenfried or use the regular channels of communication outlined in CONTRIBUTING.md</p>"},{"location":"sandbox/transferanalyzer/","title":"Direct transfer analyzer module","text":""},{"location":"sandbox/transferanalyzer/#contact-info","title":"Contact Info","text":"<ul> <li>Gard Mellemstrand, Entur, Norway</li> </ul>"},{"location":"sandbox/transferanalyzer/#changelog","title":"Changelog","text":""},{"location":"sandbox/transferanalyzer/#may-20th-2019","title":"May 20th 2019","text":"<ul> <li>Added the direct transfer analyzer module (May 2019)</li> </ul>"},{"location":"sandbox/transferanalyzer/#documentation","title":"Documentation","text":"<p>Module used for analyzing the transfers between nearby stops generated by routing via OSM data. It generates lists of both unusually long and unroutable transfers. These lists can typically be used to improve the quality of OSM data for transfer purposes.</p> <p>See javadoc in DirectTransferAnalyzer class</p>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":""},{"location":"#opentripplanner-2","title":"OpenTripPlanner 2","text":"<p>OpenTripPlanner (OTP) is an open source multi-modal trip planner, focusing on travel by scheduled public transportation in combination with bicycling, walking, and mobility services including bike share and ride hailing. Its server component runs on any platform with a Java virtual machine (including Linux, Mac, and Windows). It exposes GraphQL APIs that can be accessed by various clients including open source Javascript components and native mobile applications. It builds its representation of the transportation network from open data in open standard file formats (primarily GTFS and OpenStreetMap). It applies real-time updates and alerts with immediate visibility to clients, finding itineraries that account for disruptions and service changes. OTP is released under the LGPL license. As of 2020, the codebase has been in active development for over ten years, and is relied upon by transportation authorities and travel planning applications in deployments around the world.</p> <p>You are currently reading the documentation for OpenTripPlanner 2, the second major version of OTP.</p>"},{"location":"#versions-of-this-documentation","title":"Versions of this documentation","text":"<p>Several versions of this documentation are built and published automatically for different branches of OTP. Each of these has a different stable URL, and you may switch between these versions using the selector in the upper left of the published documentation.</p> <p>Releases</p> <ul> <li>Latest - Version 2.4.0 (the git master branch)</li> <li>v2.3.0 - Version 2.3</li> <li>v2.2.0 - Version 2.2</li> <li>v2.1.0 - Version 2.1</li> <li>v2.0.0 - Version 2.0</li> <li>v1.5.0 - Stable 1.x release</li> </ul> <p>Snapshot</p> <ul> <li>dev-2.x - OTP 2 active development</li> </ul>"},{"location":"#audience","title":"Audience","text":"<p>The end users of OTP are the millions of people who rely on it to help plan their daily travel, often without even knowing they are using OTP. As an infrastructure component, installation and configuration of OTP tends to be somewhat technical and essentially invisible to those end users. This documentation is intended for people who wish to perform such deployments of OTP without necessarily diving into the internal details of the software.</p> <p>For members of the OTP community interested in software development, additional documentation detailing algorithms, data structures etc. is available as markdown files within the source code packages. It can be read in your IDE or when browsing the source tree on Github. See OTP Architecture.</p>"},{"location":"#quick-start","title":"Quick Start","text":"<p>We encourage you to read the introductory sections of this documentation to familiarize yourself with OpenTripPlanner use cases and configuration. But if you want to get started right away running your own OTP instance, the best place to start is the Basic Tutorial page.</p>"},{"location":"#getting-help","title":"Getting help","text":"<p>The fastest way to get help is to use our Gitter chat room where most of the core developers are. You can also send questions and comments to the mailing list or file bug reports via the Github issue tracker.  Note that the issue tracker is not intended for support questions or discussions. Please use the chat or the mailing list instead.</p>"},{"location":"#financial-and-in-kind-support","title":"Financial and In-Kind Support","text":"<p>OpenTripPlanner is a member project of Software Freedom Conservancy, a 501(c)(3) organization incorporated in New York, and donations made to it are fully tax-deductible to the extent permitted by law. Donations can be made by credit card, wire transfer or paper check. Please contact accounting@sfconservancy.org for instructions.</p> <p>OTP development is primarily carried out by full-time software engineers employed by transportation authorities and consultancies. Even with funding, it can be difficult to engage staff who have the specialized skill set required. Therefore, one of the best ways to support OTP is to allocate software development staff at your organization with transportation domain knowledge to participate in weekly development meetings and contribute to this effort. This also builds connections between organizations favoring open source collaboration.</p>"},{"location":"Accessibility/","title":"Accessibility","text":""},{"location":"Accessibility/#preamble","title":"Preamble","text":"<p>GTFS and Netex define accessibility primarily in terms of binary access for wheelchair users: it's either on or off. Whilst it is the desire of the OTP developers to broaden the scope of accessibility the lack of data limits us to use this definition in the implementation and in this document.</p>"},{"location":"Accessibility/#unknown-data","title":"Unknown data","text":"<p>Many agencies have the same problem: data on wheelchair-accessibility is, if it exists at all, patchy. If you only included trips and stops that are explicitly set to be wheelchair-accessible rather than unknown, it would be hard to get any result at all. For this reason OTP allows you to configure which sort of unknown information should be taken into account.</p>"},{"location":"Accessibility/#configuration","title":"Configuration","text":"<p>If you want to allow trips and stops of unknown wheelchair-accessibility then add the following to <code>router-config.json</code>:</p> <pre><code>{\n  \"routingDefaults\": {\n    \"wheelchairAccessibility\": {\n      \"trip\": {\n        \"onlyConsiderAccessible\": false,\n        \"unknownCost\": 600,\n        \"inaccessibleCost\": 3600\n      },\n      \"stop\": {\n        \"onlyConsiderAccessible\": false,\n        \"unknownCost\": 600,\n        \"inaccessibleCost\": 3600\n      },\n      \"elevator\": {\n        \"onlyConsiderAccessible\": false\n      },\n      \"inaccessibleStreetReluctance\": 25,\n      \"maxSlope\": 0.08333,\n      \"slopeExceededReluctance\": 50,\n      \"stairsReluctance\": 25\n    }\n  },\n  \"updaters\": []\n}\n</code></pre> <p>The parameters for <code>stop</code>, <code>trip</code> and <code>elevator</code> mean the following:</p> name default <code>onlyConsiderAccessible</code> Whether to exclude unknown accessibility and inaccessible stops/trips/elevators in the search. <code>true</code> <code>unknownCost</code> The cost to add if an entity has unknown wheelchair accessibility 600 <code>inaccessibleCost</code> The cost to add if an entity is known to be inaccessible 3600 <p>Note: Unless your accessibility data coverage is complete you will receive much better results by setting <code>onlyConsiderAccessible=false</code>, because otherwise you receive barely any results.</p> <p>Other parameters are:</p> <ul> <li><code>inaccessibleStreetReluctance</code>: if a street is marked as wheelchair-inaccessible this is the   penalty that is applied for wheelchair users. This should be quite high so that those are only   chosen as a very last resort. default: 25</li> <li><code>maxSlope</code>: the maximum slope that a wheelchair user can use without incurring routing penalties (   leading to those ways being avoided). default: 0.083 (8.3 %)</li> <li><code>slopeExceededReluctance</code>: how steep should the cost increase when you exceed the maximum slope.   By default, every percent over the limit doubles the cost of the traversal, so if the regular cost   is 100, being 1 percent over the limit will lead to a cost of 200, 2 percent over will lead to 400   and so on.   If you want an even steeper increase then set a value higher than 1. If you want it shallower use   a value between 0 and 1. To disable the penalty set a value below 0. default: 1</li> <li><code>stairsReluctance</code>: how much should a wheelchair user avoid stairs. This should be quite high so   that they are used only as a last resort. default: 25</li> </ul>"},{"location":"Accessibility/#accessible-transfers","title":"Accessible transfers","text":"<p>By default OTP only pre-calculates transfers between stops for able-bodied walkers. If they have no obstacles wheelchair users can use them, too, but there won't be guaranteed to be one.</p> <p>If you want OTP to also pre-generate wheelchair-accessible transfers use the following configuration in <code>build-config.json</code>:</p> <pre><code>{\n  \"transferRequests\": [\n    {\n      \"modes\": \"WALK\"\n    },\n    {\n      \"modes\": \"WALK\",\n      \"wheelchairAccessibility\": {\n        \"enabled\": true\n      }\n    }\n  ]\n}\n</code></pre> <p>This results in OTP calculating an accessible transfer if the default one is found to be inaccessible to wheelchair users.</p>"},{"location":"Accessibility/#example","title":"Example","text":"<p>A full configuration example is available at <code>/docs/examples</code></p>"},{"location":"Basic-Tutorial/","title":"OpenTripPlanner Basic Tutorial","text":"<p>This page should allow you to set up and test your own OTP2 server. If all goes well it should only take a few minutes!</p>"},{"location":"Basic-Tutorial/#get-java","title":"Get Java","text":"<p>As a Java program, OTP must be run within a Java virtual machine (JVM), which is provided as part of the Java runtime (JRE) or Java development kit (JDK). OTP2 is compatible with Java 21 or later. We recommend running on Java 21 rather than a later version, as it is a long-term support release. Run <code>java -version</code> to check that you have version 21 or newer of the JVM installed. If you do not, you will need to install a recent OpenJDK or Oracle Java package for your operating system.</p>"},{"location":"Basic-Tutorial/#get-otp","title":"Get OTP","text":"<p>OpenTripPlanner is written in Java and distributed as a single runnable JAR file. This is a \"shaded\" JAR containing all other libraries needed for OTP to work, and is available from the Maven Central repository. You will be able to go to the OTP directory at Maven Central, navigate to the directory of releases, and download the file with <code>shaded.jar</code> suffix .</p> <p>You may also want to get your own copy of the OTP source code and build a bleeding edge development JAR from scratch, especially if you plan to do some development yourself. In that case, check out the branch <code>dev-2.x</code>.</p>"},{"location":"Basic-Tutorial/#get-some-data","title":"Get some data","text":""},{"location":"Basic-Tutorial/#gtfs-for-transit-schedules-and-stops","title":"GTFS for Transit Schedules and Stops","text":"<p>First you'll need GTFS data to build a transit network. There's an excellent description of the GTFS format here. Transport agencies throughout the world provide GTFS schedules to the public. Transitland has a registry of feeds and TransitFeeds also provides an extensive catalog. The best option is often to simply fetch the data directly from a transit operator or agency. If you know of a feed you want to work with, download it and put it in an empty directory you have created for your OTP instance such as <code>/home/username/otp</code> on Linux, <code>/Users/username/otp</code> on MacOS, or <code>C:\\Users\\username\\otp</code> on Windows. For OTP2 to detect a GTFS file, its name must end in <code>.zip</code> and must contain the letters 'gtfs'. We often use the convention of saving GTFS files with names ending in <code>.gtfs.zip</code> which meets both these criteria, reflecting the fact that a GTFS feed is just a ZIP file containing a specific set of files. If you don't have a particular feed in mind, the one for Portland, Oregon's TriMet agency is a good option. It is available at this URL. This is a moderate-sized input of good quality (TriMet initiated OTP development and helped develop the GTFS format). On Linux, this could be done on the command line as follows:</p> <pre><code>$ cd /home/username\n$ mkdir otp\n$ cd otp\n$ wget \"http://developer.trimet.org/schedule/gtfs.zip\" -O trimet.gtfs.zip\n</code></pre>"},{"location":"Basic-Tutorial/#osm-for-streets","title":"OSM for Streets","text":"<p>You'll also need OpenStreetMap data to build a road network for walking, cycling, and driving. OpenStreetMap is a global collaborative map database that rivals or surpasses the quality of commercial maps in many locations. Several services extract smaller geographic regions from this database. Interline Technologies maintains a collection of extracts updated daily for urban areas around the world . Geofabrik provides extracts for larger areas like countries or states, from which you can prepare your own smaller bounding-box extracts using Osmosis , osmconvert, or (our favorite) Osmium-Tool. There is also Protomaps which can create custom extracts  for any region of the world with an easy to use drag and drop interface. OSM data can be delivered as XML or in the more compact binary PBF format. OpenTripPlanner consumes only PBF because it's smaller and more efficient.</p> <p>Download OSM PBF data for the same geographic region as your GTFS feed, and place this PBF file in the same directory you created for the OSM data. If you are using the TriMet GTFS feed, you could download the Geofabrik extract for the US state of Oregon , then further trim that to just the TriMet service area using the bounding box switch of one of the above tools. On Linux or MacOS you could do that as follows:</p> <pre><code>$ cd /home/username\n$ wget http://download.geofabrik.de/north-america/us/oregon-latest.osm.pbf\n$ osmconvert oregon-latest.osm.pbf -b=-123.043,45.246,-122.276,45.652 --complete-ways -o=portland.pbf\n$ mv portland.pbf otp\n</code></pre> <p>We find this tool useful for determining the geographic coordinates of bounding boxes. The CSV option in that tool produces exactly the format expected by the <code>osmconvert -b</code> switch. The <code>--complete-ways</code> switch is important to handle roads that cross outside your bounding box.</p> <p>If you have extracted a smaller PBF file from a larger region, be sure to put only your extract (not the original larger file) in the directory with your GTFS data. Otherwise OTP will try to load both the original file and the extract in a later step. See the page on preparing OSM data for additional information and example commands for cropping and filtering OSM data.</p>"},{"location":"Basic-Tutorial/#starting-otp","title":"Starting OTP","text":"<p>A typical command to start OTP looks like <code>java -Xmx2G -jar otp.shaded.jar &lt;options&gt;</code>. The <code>-Xmx</code> parameter sets the limit on how much memory OTP is allowed to consume. GTFS and OSM data sets are often very large, and OTP is relatively memory-hungry. You will need at least 1GB of memory when working with the Portland TriMet data set, and several gigabytes for larger inputs. Here is more information about the system requirements. If you have sufficient memory in your computer, set this to a couple of gigabytes (e.g. <code>-Xmx2G</code>). Java uses a garbage collection approach to memory management, which requires some \"breathing room\" to efficiently operate. Without sufficient free memory OTP can grind to a halt. VisualVM is a good way to inspect Java memory usage, especially with the VisualGC plugin.</p>"},{"location":"Basic-Tutorial/#building-graphs","title":"Building Graphs","text":"<p>There are two main phases to preparing and deploying an OTP server. The first is to analyze the GTFS, OSM and any other inputs (such as elevation data) and build a representation of the transportation network. Following mathematical terminology we call this a 'graph', and refer to this phase as \"graph building\". The second phase is to start a server that provides trip planning and other API services for this graph.</p> <p>It is possible to save the graph to a file on disk after the first phase, then load the graph from the file in the second phase. This allows restarting the server or starting multiple instances of the server without repeating the often time-consuming process of building the graph. It is also possible to split the graph building process into separate OSM and GTFS stages for similar reasons: to allow reusing results from slow processes, such as applying elevation data to streets. These different options are controlled with command line switches, and will be described in more detail below and in other tutorials.</p>"},{"location":"Basic-Tutorial/#simple-one-step-server","title":"Simple One-step Server","text":"<p>The simplest way to use OTP is to build a graph in a single step and start a server immediately, without saving it to disk. The command to do so is:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --build --serve /home/username/otp\n</code></pre> <p>where <code>/home/username/otp</code> should be the directory where you put your configuration and input files.</p> <p>If you're using the Portland input data, the graph build operation should take about one minute to complete, and then you'll see a <code>Grizzly server running</code> message. At this point you have an OpenTripPlanner server running locally and can open http://localhost:8080/ in a web browser. You should be presented with a Javascript client application that will interact with your local OpenTripPlanner instance.</p> <p>This map-based user interface is in fact sending HTTP GET requests to the OTP server running on your local machine. It can be informative to watch the HTTP requests and responses being generated using the developer tools in your web browser. OTP's built-in web server will run by default on port 8080. If by any chance some other software is already using that port number, you can specify a different port number with a switch <code>--port 8801</code>.</p>"},{"location":"Basic-Tutorial/#saving-a-graph","title":"Saving a Graph","text":"<p>If you want speed up the process of repeatedly starting up a server with the same graph, you can build a graph from street and transit data then save it to a file using the <code>--build</code> and <code>--save</code> command line parameters together. If for example your current working directory (<code>.</code>) contains the input files and the OTP JAR file, you can use this command:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --build --save .\n</code></pre> <p>This will produce a file called <code>graph.obj</code> in the same directory as the inputs. The server can then be started later using the <code>--load</code> parameter, and will read this file instead of building the graph from scratch:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --load .\n</code></pre> <p>Another reason to perform these two phases separately is that the building process loads the entire GTFS and OSM data sets into memory, so can require significantly more memory than just running a server. Accordingly, you may want to perform the build on one machine (e.g. a throw-away cloud instance with more memory or compute capacity), then copy the resulting graph file to one or more smaller machines to serve the API.</p>"},{"location":"Basic-Tutorial/#layering-gtfs-onto-osm","title":"Layering GTFS onto OSM","text":"<p>Building the street graph (especially with elevation data) can take a long time. It is common for transit data to change more frequently than street data, so it can be convenient to build the street graph once, and then layer transit data on top of the streets to make the final graph.</p> <p>Again assuming the input files and OTP JAR file are in the current working directory, you can build a street graph with OSM and elevation data only (ignoring transit input files) with this command:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --buildStreet .\n</code></pre> <p>Then, to build a graph layering transit data on top of the saved street graph (built using the previous command):</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --loadStreet --save .\n</code></pre> <p>Finally, the server can be started using the <code>--load</code> parameter:</p> <pre><code>$ java -Xmx2G -jar otp-2.4.0-shaded.jar --load .\n</code></pre>"},{"location":"Basic-Tutorial/#command-line-switches","title":"Command Line Switches","text":"<p>The flow diagram below summarizes all the command line switches used in the above examples, and how they control which actions are taken when OTP starts up.</p> <p></p> <p>You must use at least one of the required parameters: <code>--load</code>, <code>--loadStreet</code>, <code>--build</code> , <code>--buildStreet</code>. A required parameter may imply other parameters when the flow allows for no other choice. For example, <code>--load</code> implies <code>--serve</code>, so <code>--serve</code> is not necessary and has no additional effect when used together with <code>--load</code>.</p> <p>You can run the OTP .jar file with the <code>--help</code> option for a full list of command line parameters.</p>"},{"location":"Basic-Tutorial/#exploring-the-api","title":"Exploring the API","text":"<p>If you want to learn how to use OTP's API's, check out the GraphQL tutorial.</p>"},{"location":"Bibliography/","title":"Routing Bibliography","text":"<p>This is a list of articles, dissertations, and books that have inspired and informed both the existing OTP routing engine and some ongoing experiments.</p> <p>OTP1 uses a single time-dependent (as opposed to time-expanded) graph that contains both street and transit networks. Walk-only and bicycle-only trips are generally planned using the A-star algorithm with a Euclidean heuristic. Walk+Transit or Bike+Transit trips are planned using A-star with the Tung-Chew heuristic (i.e. a graph grown backward from the destination providing a lower bound on aggregate weight) for queue ordering. For speed reasons we are performing single-variable generalized cost optimization, which is not ideal. We should be performing Pareto optimization on at least two variables (generalized cost and time).</p> <p>OTP2 splits the search into three segments: access from the origin to transit stops, egress from transit stops to the destination, and transit service connecting the two. For the transit segment, OTP2 uses the Multi-criteria Range Raptor algorithm. For the access and egress searches it uses the same approach as OTP1. Both splitting the search into three parts and use of a table-scanning algorithm like Raptor improve OTP2's performance significantly while increasing result quality by producing true Pareto-optimal sets of results.</p>"},{"location":"Bibliography/#algorithms-used-in-otp2-but-not-otp1","title":"Algorithms used in OTP2 but not OTP1","text":"<ul> <li> <p>Delling, Pajor, Werneck. Round-Based Public Transit Routing (2012)   This is a tabular approach to routing in public transit networks that does not use an (   explicit) graph. It is simpler and can outperform classic graph algorithms.   http://research.microsoft.com/pubs/156567/raptor_alenex.pdf</p> </li> <li> <p>Delling, Dibbelt, and Pajor. Fast and Exact Public Transit Routing with Restricted Pareto Sets (   2019)   Describes the heuristic used in OTP2 to eliminate options early when they are known to become   non-optimal before they reach the destination.   https://epubs.siam.org/doi/pdf/10.1137/1.9781611975499.5</p> </li> </ul>"},{"location":"Bibliography/#techniques-used-in-or-influencing-otp1-and-otp2","title":"Techniques used in or influencing OTP1 and OTP2","text":""},{"location":"Bibliography/#general-background","title":"General Background","text":"<ul> <li> <p>Bast, Hannah. Car or public transport -- two worlds. (2009)   Explains how car routing is different from schedule-based public transport routing.   http://www.mpi-inf.mpg.de/~bast/papers/car_or_public_transport.pdf</p> </li> <li> <p>Delling, Daniel. Engineering and augmenting route planning algorithms. (2009, dissertation)   Overview, including time-dependent and Pareto shortest paths.   http://i11www.ira.uka.de/extra/publications/d-earpa-09.pdf</p> </li> <li> <p>Delling, Sanders, Schultes, and Wagner. Engineering Route-Planning Algorithms. (2009)   Overview.   http://i11www.ira.uka.de/extra/publications/dssw-erpa-09.pdf</p> </li> </ul>"},{"location":"Bibliography/#path-search-speedup-techniques","title":"Path Search Speedup Techniques","text":"<ul> <li> <p>Delling and Wagner. Time-Dependent Route Planning. (2009)   Overview.   http://i11www.iti.uni-karlsruhe.de/extra/publications/dw-tdrp-09.pdf</p> </li> <li> <p>Delling and Wagner. Landmark-Based Routing in Dynamic Graphs. (2008)   http://i11www.ira.uka.de/extra/publications/dw-lbrdg-07.pdf</p> </li> <li> <p>Bauer, Delling, Sanders, Schultes, and Wagner. Combining Hierarchical and Goal-Directed Speed-Up   Techniques for Dijkstra\u2019s Algorithm. (2008)   http://algo2.iti.kit.edu/download/bdsssw-chgds-10.pdf</p> </li> <li> <p>Bauer and Delling. SHARC: Fast and Robust Unidirectional Routing. (2009)   SH ortcuts + ARC flags. Can be combined with ALT.   http://www.siam.org/proceedings/alenex/2008/alx08_02bauerr.pdf</p> </li> <li> <p>Delling, Daniel. Time-Dependent SHARC-Routing. (2008)   http://i11www.iti.uni-karlsruhe.de/extra/publications/d-tdsr-09.pdf</p> </li> <li> <p>Goldberg, Kaplan, and Werneck. Reach for A\u2217: Efficient Point-to-Point Shortest Path Algorithms.    (2005)    http://avglab.com/andrew/pub/msr-tr-2005-132.pdf</p> </li> </ul>"},{"location":"Bibliography/#multi-objective-pareto-shortest-paths","title":"Multi-objective Pareto Shortest Paths","text":"<ul> <li> <p>Das and Dennis. Drawbacks of minimizing weighted sums of objectives for Pareto set generation in   multicriteria optimization problems. (1997)</p> </li> <li> <p>M\u00fcller-Hannemann and Schnee. Finding All Attractive Train Connections by Multi-criteria Pareto   Search. (2007)   Deutsche Bahn information system. Does not account for on-street travel.</p> </li> <li> <p>Mandow &amp; P\u00e9rez de la Cruz. A New Approach to Multiobjective A Search. (2005)   NAMOA http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.8780&amp;rep=rep1&amp;type=pdf</p> </li> <li> <p>Mandow &amp; P\u00e9rez de la Cruz. Multiobjective A search with consistent heuristics. (2008)   NAMOA</p> </li> <li> <p>Machuca, Mandow and P\u00e9rez de la Cruz. Evaluation of Heuristic Functions for Bicriterion Shortest   Path Problems. (2009)   Evaluates heuristics from Tung &amp; Chew (1992) versus lexicographical ordering of priority   queue.   http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.160.4715&amp;rep=rep1&amp;type=pdf</p> </li> <li> <p>Perny and Spanjaard. Near Admissible Algorithms for Multiobjective Search. (2009)   Discusses relaxed Pareto dominance (Epsilon-dominance) and its use in Multi-objective A*. This   a scheme for approximating the entire pareto-optimal solution set that allows time and space   complexity polynomial in the number of nodes.   http://www-desir.lip6.fr/publications/pub_1052_1_ECAI08.pdf</p> </li> <li> <p>Tung and Chew. A multicriteria Pareto-optimal path algorithm. (1992)</p> </li> <li> <p>Delling and Wagner. Pareto Paths with SHARC. (2009)   http://i11www.iti.uni-karlsruhe.de/extra/publications/dw-pps-09.pdf</p> </li> </ul>"},{"location":"Bibliography/#resource-constrained-routing","title":"Resource-constrained Routing","text":"<ul> <li> <p>Dumitrescu &amp; Boland. Improved Preprocessing, Labeling and Scaling Algorithms for the   Weight-Constrained Shortest Path Problem. (2003)   Comparison of scaling and label-setting methods.</p> </li> <li> <p>Ziegelmann, Mark. Constrained Shortest Paths and Related Problems. (2001, dissertation)   http://scidok.sulb.uni-saarland.de/volltexte/2004/251/pdf/MarkZiegelmann_ProfDrKurtMehlhorn.pdf</p> </li> </ul>"},{"location":"Bibliography/#contraction-and-transfer-patterns","title":"Contraction and Transfer Patterns","text":"<ul> <li> <p>Geisberger, Robert. Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road   Networks. (2008, dissertation)   http://algo2.iti.kit.edu/documents/routeplanning/geisberger_dipl.pdf</p> </li> <li> <p>Geisberger, Robert. Contraction of Timetable Networks with Realistic Tranfers (2010)   Introduces the \"Station Model Graph\".   http://algo2.iti.kit.edu/download/time_table_ch.pdf</p> </li> <li> <p>Bast, Carlsson, Eigenwillig, Geisberger Harrelson, Raychev, and Viger. Fast Routing in Very Large   Public Transportation Networks Using Transfer Patterns. (2010)   http://ad.informatik.uni-freiburg.de/files/transferpatterns.pdf/at_download/file</p> </li> </ul>"},{"location":"Bibliography/#timetable-based-routing","title":"Timetable-based routing","text":"<ul> <li>Schulz, Frank. Timetable Information and Shortest Paths. (2005, dissertation)   Excellent reference.   http://d-nb.info/1001586921/34</li> </ul>"},{"location":"Bibliography/#alt-and-metric-embeddings","title":"ALT and Metric Embeddings","text":"<ul> <li> <p>Goldberg and Werneck. Computing Point-to-Point Shortest Paths from External Memory. (2005)   Introduced the ALT algorithm.   http://www.cs.princeton.edu/courses/archive/spring06/cos423/Handouts/GW05.pdf</p> </li> <li> <p>Linial, London, and Rabinovich. The Geometry of Graphs and Some of its Algorithmic Applications. (   1995)   http://pdf.aminer.org/000/798/423/the_geometry_of_graphs_and_some_of_its_algorithmic_applications.pdf</p> </li> <li> <p>Hjaltason and Samet. Contractive Embedding Methods for Similarity Searching in Metric Spaces. (   2000)   http://www.cs.umd.edu/~hjs/pubs/metricpruning.pdf</p> </li> <li> <p>Potamias, Bonchi, Castillo, and Gionis. Fast Shortest Path Distance Estimation in Large   Networks. (2009)   Briefly discusses the connection between landmark routing and more general research on metric   embeddings.   http://dcommon.bu.edu/xmlui/bitstream/handle/2144/1727/2009-004-shortest-distance-estimation.pdf</p> </li> </ul>"},{"location":"Bibliography/#calibration-and-implementation-details","title":"Calibration and Implementation Details","text":"<ul> <li> <p>Wardman, Mark. Public Transport Values of Time. (2004)   http://eprints.whiterose.ac.uk/2062/1/ITS37_WP564_uploadable.pdf</p> </li> <li> <p>A.M. El-Geneidy, K.J. Krizek, M.J. Iacono. Predicting bicycle travel speeds along different   facilities using GPS data: a proof of concept model. (2007)Proceedings of the 86th Annual   Meeting of the Transportation Research Board, Compendium of Papers, TRB, Washington, D.C., USA (   CD-ROM)</p> </li> <li> <p>Chen, Chowdhury, Roche, Ramachandran, Tong. Priority Queues and Dijkstra\u2019s Algorithm.   Summary: Despite better theoretical complexity for Fibonacci heaps, it is often as good or   better to use a binary heap as a priority queue when doing path searches.   http://www.cs.utexas.edu/users/shaikat/papers/TR-07-54.pdf</p> </li> </ul>"},{"location":"Bibliography/#post-dijkstra-public-transit-routing","title":"Post-Dijkstra Public Transit Routing","text":"<ul> <li> <p>Dibbelt, Pajor, Strasser, Wagner. Intriguingly Simple and Fast Transit Routing (2013).   Introduces the Connection Scan Algorithm (CSA).   http://www.ecompass-project.eu/sites/default/files/ECOMPASS-TR-021.pdf</p> </li> <li> <p>Delling, Katz, and Pajor. Parallel computation of best connections in public transportation   networks (2012).   \"In this work, we present a novel algorithm for the one-to-all profile-search problem in   public transportation networks. It answers the question for all fastest connections between a   given station S and any other station at any time of the day in a single query... two interesting   questions arise for time-dependent route planning: compute the best connection for a given   departure time and the computation of all best connections during a given time interval (e. g., a   whole day). The former is called a time-query, while the latter is called a pro\ufb01le-query.\"   http://www.ecompass-project.eu/sites/default/files/ECOMPASS-TR-021.pdf</p> </li> </ul>"},{"location":"BoardingLocations/","title":"Boarding locations","text":"<p>It is often the case that the coordinates of stops are relatively far away from where the passengers are expected to the wait for the vehicle.</p> <p>A good example of this is Buckhead subway station in Atlanta.</p> <p></p> <p>There the coordinates of the stop in GTFS are located near Peachtree Road so OTP would instruct  passengers to wait on the street rather than walking down the stairs to the platform.</p>"},{"location":"BoardingLocations/#osm-tagging","title":"OSM tagging","text":"<p>We can correct the waiting location for the passenger by adding some tags to OSM which help OTP decide to correct the location. In general, you should familiarise yourself with the OSM wiki page on public transport.</p> <p>You can add cross-references to a stop's id or code on all OSM entities (nodes, ways, relations) which have one of the following tag combinations:</p> <ul> <li><code>public_transport=platform</code></li> <li><code>highway=bus_stop</code></li> <li><code>railway=tram_stop</code></li> <li><code>railway=station</code></li> <li><code>railway=halt</code></li> <li><code>amenity=bus_station</code></li> <li><code>amenity=ferry_terminal</code></li> </ul>"},{"location":"BoardingLocations/#notes","title":"Notes","text":"<ul> <li><code>public_transport=stop_location</code> and <code>railway=stop</code> are explicitly not on the list as they denote   the place where the train stops, not the waiting area.</li> <li>The <code>railway</code> key is deprecated (even though still widespread) and you should use <code>public_transport</code>    instead.</li> <li>OTP does not process isolated nodes, but only nodes, which are part of routable ways. Therefore, adding a single ,  isloated boarding location node to OSM has no effect. There is an exception, though: isolated nodes, which are members of <code>public_transport=stop_area</code> relation, will be considered and automatically linked with the street graph. For more information, check the stop area documentation.</li> </ul>"},{"location":"BoardingLocations/#cross-referencing","title":"Cross-referencing","text":"<p>In order to tell OTP how to link up the OSM entities to the stops you need to add a <code>ref</code> tag whose value is the stop's id or code. </p> <p>However, tagging conventions vary from location to location so other tags can be configured, too.</p> <p>For example, there is a country-wide stop reference system in Germany called IFOPT and therefore if you want to use it to match stops (example platform),  add the following to <code>build-config.json</code>:</p> <pre><code>{\n  \"boardingLocationTags\": [\"ref\", \"ref:IFOPT\"]\n}\n</code></pre>"},{"location":"BoardingLocations/#multiple-stops-on-the-same-platform","title":"Multiple stops on the same platform","text":"<p>Some stations have a middle platform with a stop on either side of it. In such a case, you can  simply add two or more references separated by a semicolon, as seen in this example.</p>"},{"location":"BuildConfiguration/","title":"Build","text":""},{"location":"BuildConfiguration/#graph-build-configuration","title":"Graph Build Configuration","text":"<p>This table lists all the JSON properties that can be defined in a <code>build-config.json</code> file. These will be stored in the graph itself, and affect any server that subsequently loads that graph. Sections follow that describe particular settings in more depth.</p>"},{"location":"BuildConfiguration/#parameters-overview","title":"Parameters Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since areaVisibility <code>boolean</code> Perform visibility calculations. Optional <code>false</code> 1.5 buildReportDir <code>uri</code> URI to the directory where the graph build report should be written to. Optional 2.0 configVersion <code>string</code> Deployment version of the build-config.json. Optional 2.1 dataImportReport <code>boolean</code> Generate nice HTML report of Graph errors/warnings Optional <code>false</code> 2.0 distanceBetweenElevationSamples <code>double</code> The distance between elevation samples in meters. Optional <code>10.0</code> 2.0 embedRouterConfig <code>boolean</code> Embed the Router config in the graph, which allows it to be sent to a server fully configured over the wire. Optional <code>true</code> 2.0 graph <code>uri</code> URI to the graph object file for reading and writing. Optional 2.0 gsCredentials <code>string</code> Local file system path to Google Cloud Platform service accounts credentials file. Optional 2.0 includeEllipsoidToGeoidDifference <code>boolean</code> Include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge. Optional <code>false</code> 2.0 maxAreaNodes <code>integer</code> Visibility calculations for an area will not be done if there are more nodes than this limit. Optional <code>150</code> 2.1 maxDataImportIssuesPerFile <code>integer</code> When to split the import report. Optional <code>1000</code> 2.0 maxElevationPropagationMeters <code>integer</code> The maximum distance to propagate elevation to vertices which have no elevation. Optional <code>2000</code> 1.5 maxStopToShapeSnapDistance <code>double</code> Maximum distance between route shapes and their stops. Optional <code>150.0</code> 2.1 maxTransferDuration <code>duration</code> Transfers up to this duration with the default walk speed value will be pre-calculated and included in the Graph. Optional <code>\"PT30M\"</code> 2.1 multiThreadElevationCalculations <code>boolean</code> Configuring multi-threading during elevation calculations. Optional <code>false</code> 2.0 osmCacheDataInMem <code>boolean</code> If OSM data should be cached in memory during processing. Optional <code>false</code> 2.0 osmNaming <code>string</code> A custom OSM namer to use. Optional 2.0 platformEntriesLinking <code>boolean</code> Link unconnected entries to public transport platforms. Optional <code>false</code> 2.0 readCachedElevations <code>boolean</code> Whether to read cached elevation data. Optional <code>true</code> 2.0 staticBikeParkAndRide <code>boolean</code> Whether we should create bike P+R stations from OSM data. Optional <code>false</code> 1.5 staticParkAndRide <code>boolean</code> Whether we should create car P+R stations from OSM data. Optional <code>true</code> 1.5 stopConsolidationFile <code>string</code> Name of the CSV-formatted file in the build directory which contains the configuration for stop consolidation. Optional 2.5 streetGraph <code>uri</code> URI to the street graph object file for reading and writing. Optional 2.0 subwayAccessTime <code>double</code> Minutes necessary to reach stops served by trips on routes of route_type=1 (subway) from the street. Optional <code>2.0</code> 1.5 transitModelTimeZone <code>time-zone</code> Time zone for the graph. Optional 2.2 transitServiceEnd <code>duration</code> Limit the import of transit services to the given end date. Optional <code>\"P3Y\"</code> 2.0 transitServiceStart <code>duration</code> Limit the import of transit services to the given START date. Optional <code>\"-P1Y\"</code> 2.0 writeCachedElevations <code>boolean</code> Reusing elevation data from previous builds Optional <code>false</code> 2.0 boardingLocationTags <code>string[]</code> What OSM tags should be looked on for the source of matching stops to platforms and stops. Optional 2.2 dataOverlay <code>object</code> Config for the DataOverlay Sandbox module Optional 2.2 dem <code>object[]</code> Specify parameters for DEM extracts. Optional 2.2 elevationUnitMultiplier <code>double</code> Specify a multiplier to convert elevation units from source to meters. Overrides the value specified in <code>demDefaults</code>. Optional <code>1.0</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 demDefaults <code>object</code> Default properties for DEM extracts. Optional 2.3 elevationUnitMultiplier <code>double</code> Specify a multiplier to convert elevation units from source to meters. Optional <code>1.0</code> 2.3 elevationBucket <code>object</code> Used to download NED elevation tiles from the given AWS S3 bucket. Optional na emissions <code>object</code> Emissions configuration. Optional 2.5 fares <code>object</code> Fare configuration. Optional 2.0 gtfsDefaults <code>object</code> The gtfsDefaults section allows you to specify default properties for GTFS files. Optional 2.3 \u00a0\u00a0\u00a0blockBasedInterlining <code>boolean</code> Whether to create stay-seated transfers in between two trips with the same block id. Optional <code>true</code> 2.3 discardMinTransferTimes <code>boolean</code> Should minimum transfer times in GTFS files be discarded. Optional <code>false</code> 2.3 \u00a0\u00a0\u00a0maxInterlineDistance <code>integer</code> Maximal distance between stops in meters that will connect consecutive trips that are made with same vehicle. Optional <code>200</code> 2.3 \u00a0\u00a0\u00a0removeRepeatedStops <code>boolean</code> Should consecutive identical stops be merged into one stop time entry. Optional <code>true</code> 2.3 stationTransferPreference <code>enum</code> Should there be some preference or aversion for transfers at stops that are part of a station. Optional <code>\"allowed\"</code> 2.3 islandPruning <code>object</code> Settings for fixing street graph connectivity errors Optional 2.3 adaptivePruningDistance <code>integer</code> Search distance for analyzing islands in pruning. Optional <code>250</code> 2.3 adaptivePruningFactor <code>double</code> Defines how much pruning thresholds grow maximally by distance. Optional <code>50.0</code> 2.3 islandWithStopsMaxSize <code>integer</code> When a graph island with stops in it should be pruned. Optional <code>2</code> 2.3 islandWithoutStopsMaxSize <code>integer</code> When a graph island without stops should be pruned. Optional <code>10</code> 2.3 localFileNamePatterns <code>object</code> Patterns for matching OTP file types in the base directory Optional 2.0 dem <code>regexp</code> Pattern for matching elevation DEM files. Optional <code>\"(?i)\\.tiff?$\"</code> 2.0 gtfs <code>regexp</code> Patterns for matching GTFS zip-files or directories. Optional <code>\"(?i)gtfs\"</code> 2.0 netex <code>regexp</code> Patterns for matching NeTEx zip files or directories. Optional <code>\"(?i)netex\"</code> 2.0 osm <code>regexp</code> Pattern for matching Open Street Map input files. Optional <code>\"(?i)(\\.pbf\u00a6\\.osm\u00a6\\.osm\\.xml)$\"</code> 2.0 netexDefaults <code>object</code> The netexDefaults section allows you to specify default properties for NeTEx files. Optional 2.2 \u00a0\u00a0\u00a0feedId <code>string</code> This field is used to identify the specific NeTEx feed. It is used instead of the feed_id field in GTFS file feed_info.txt. Optional <code>\"NETEX\"</code> 2.2 groupFilePattern <code>regexp</code> Pattern for matching group NeTEx files. Optional <code>\"(\\w{3})-.*\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0ignoreFareFrame <code>boolean</code> Ignore contents of the FareFrame Optional <code>false</code> 2.3 ignoreFilePattern <code>regexp</code> Pattern for matching ignored files in a NeTEx bundle. Optional <code>\"$^\"</code> 2.0 \u00a0\u00a0\u00a0noTransfersOnIsolatedStops <code>boolean</code> Whether we should allow transfers to and from StopPlaces marked with LimitedUse.ISOLATED Optional <code>false</code> 2.2 sharedFilePattern <code>regexp</code> Pattern for matching shared NeTEx files in a NeTEx bundle. Optional <code>\"shared-data\\.xml\"</code> 2.0 sharedGroupFilePattern <code>regexp</code> Pattern for matching shared group NeTEx files in a NeTEx bundle. Optional <code>\"(\\w{3})-.*-shared\\.xml\"</code> 2.0 ferryIdsNotAllowedForBicycle <code>string[]</code> List ferries which do not allow bikes. Optional 2.0 osm <code>object[]</code> Configure properties for a given OpenStreetMap feed. Optional 2.2 osmTagMapping <code>enum</code> The named set of mapping rules applied when parsing OSM tags. Overrides the value specified in <code>osmDefaults</code>. Optional <code>\"default\"</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0timeZone <code>time-zone</code> The timezone used to resolve opening hours in OSM data. Overrides the value specified in <code>osmDefaults</code>. Optional 2.2 osmDefaults <code>object</code> Default properties for OpenStreetMap feeds. Optional 2.2 osmTagMapping <code>enum</code> The named set of mapping rules applied when parsing OSM tags. Optional <code>\"default\"</code> 2.2 \u00a0\u00a0\u00a0timeZone <code>time-zone</code> The timezone used to resolve opening hours in OSM data. Optional 2.2 transferRequests <code>object[]</code> Routing requests to use for pre-calculating stop-to-stop transfers. Optional 2.1 transitFeeds <code>object[]</code> Scan for transit data files Optional 2.2 \u00a0\u00a0\u00a0{ object } <code>object</code> Nested object in array. The object type is determined by the parameters. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"gtfs\" <code>enum</code> The feed input format. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0blockBasedInterlining <code>boolean</code> Whether to create stay-seated transfers in between two trips with the same block id. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>true</code> 2.3 discardMinTransferTimes <code>boolean</code> Should minimum transfer times in GTFS files be discarded. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>false</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0feedId <code>string</code> The unique ID for this feed. This overrides any feed ID defined within the feed itself. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0maxInterlineDistance <code>integer</code> Maximal distance between stops in meters that will connect consecutive trips that are made with same vehicle. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>200</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0removeRepeatedStops <code>boolean</code> Should consecutive identical stops be merged into one stop time entry. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>true</code> 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 stationTransferPreference <code>enum</code> Should there be some preference or aversion for transfers at stops that are part of a station. Overrides the value specified in <code>gtfsDefaults</code>. Optional <code>\"allowed\"</code> 2.3 \u00a0\u00a0\u00a0{ object } <code>object</code> Nested object in array. The object type is determined by the parameters. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"netex\" <code>enum</code> The feed input format. Required 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0feedId <code>string</code> This field is used to identify the specific NeTEx feed. It is used instead of the feed_id field in GTFS file feed_info.txt. Required 2.2 groupFilePattern <code>regexp</code> Pattern for matching group NeTEx files. Optional <code>\"(\\w{3})-.*\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ignoreFareFrame <code>boolean</code> Ignore contents of the FareFrame Optional <code>false</code> 2.3 ignoreFilePattern <code>regexp</code> Pattern for matching ignored files in a NeTEx bundle. Optional <code>\"$^\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0noTransfersOnIsolatedStops <code>boolean</code> Whether we should allow transfers to and from StopPlaces marked with LimitedUse.ISOLATED Optional <code>false</code> 2.2 sharedFilePattern <code>regexp</code> Pattern for matching shared NeTEx files in a NeTEx bundle. Optional <code>\"shared-data\\.xml\"</code> 2.0 sharedGroupFilePattern <code>regexp</code> Pattern for matching shared group NeTEx files in a NeTEx bundle. Optional <code>\"(\\w{3})-.*-shared\\.xml\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0source <code>uri</code> The unique URI pointing to the data file. Required 2.2 ferryIdsNotAllowedForBicycle <code>string[]</code> List ferries which do not allow bikes. Optional 2.0"},{"location":"BuildConfiguration/#specifying-uris","title":"Specifying URIs","text":"<p>As a general rule, references to data files are specified as absolute URIs and must start with the  protocol name.   </p> <p>Example</p> <p>Local files: <code>\"file:///Users/kelvin/otp/streetGraph.obj\"</code> HTTPS resources: <code>\"https://download.geofabrik.de/europe/norway-latest.osm.pbf\"</code> Google Cloud Storage files: <code>\"gs://otp-test-bucket/a/b/graph.obj\"</code> </p> <p>Alternatively if a relative URI can be provided, it is interpreted as a path relative to the base directory.</p> <p>Example</p> <p>File relative to the base directory (inside the base directory): <code>streetGraph.obj</code>  File relative to the base directory (outside the base directory): <code>../street-graphs/streetGraph.obj</code></p>"},{"location":"BuildConfiguration/#example-with-multiple-data-sources","title":"Example With Multiple Data Sources","text":"<p>For example, this configuration could be used to load GTFS and OSM inputs from Google Cloud Storage:</p> <pre><code>// build-config.json\n{\n  \"osm\": [\n    {\n      \"source\": \"gs://bucket-name/streets.pbf\"\n    }\n  ],\n  \"transitFeeds\": [\n    {\n      \"type\": \"netex\",\n      \"source\": \"gs://bucket-name/transit1.zip\"\n    },\n    {\n      \"type\": \"gtfs\",\n      \"source\": \"gs://bucket-name/transit2.zip\"\n    }\n  ]\n}\n</code></pre> <p>The Google Storage system will inherit the permissions of the server it's running on within Google Cloud. It is also possible to supply credentials in this configuration file (see example below).</p> <p>Note that when files are specified with URIs in this configuration, the file types do not need to be inferred from the file names, so these GTFS files can have any names - there is no requirement that they have the letters \"gtfs\" in them.</p> <p>The default behavior of scanning the base directory for inputs is overridden independently for each file type. So in the above configuration, GTFS and OSM will be loaded from Google Cloud Storage, but OTP2 will still scan the base directory for all other types such as DEM files. Supplying an empty array for a particular file type will ensure that no inputs of that type are loaded, including by local directory scanning.</p>"},{"location":"BuildConfiguration/#limit-transit-service-period","title":"Limit the transit service period","text":"<p>The properties <code>transitServiceStart</code> and <code>transitServiceEnd</code> can be used to limit the service dates. This affects both GTFS service calendars and dates. The service calendar is reduced and dates outside the period are dropped. OTP2 will compute a transit schedule for every day for which it can find at least one trip running. On the other hand, OTP will waste resources if a service end date is unbounded or very large (<code>9999-12-31</code>). To avoid this, limit the OTP service period. Also, if you provide a service with multiple feeds they may have different service end dates. To avoid inconsistent results, the period can be limited, so all feeds have data for the entire period. The default is to use a period of 1 year before, and 3 years after the day the graph is built. Limiting the period will not improve the search performance, but OTP will build faster and load faster in most cases.</p> <p>The <code>transitServiceStart</code> and <code>transitServiceEnd</code> parameters are set using an absolute date like <code>2020-12-31</code> or a period like <code>P1Y6M5D</code> relative to the graph build date. Negative periods is used to specify dates in the past. The period is computed using the system time-zone, not the feed time-zone. Also, remember that the service day might be more than 24 hours. So be sure to include enough slack to account for the this. Setting the limits too wide have very little impact and is in general better than trying to be exact. The period and date format follow the ISO 8601 standard.</p> <p>Example</p> <pre><code>// build-config.json\n{\n  // Include 3 months of history\n  \"transitServiceStart\" : \"-P3M\",\n  // Include 1 year 6 month and 5 days of scheduled data in the future \n  \"transitServiceEnd\" : \"P1Y6M5D\"\n}\n</code></pre>"},{"location":"BuildConfiguration/#openstreetmaposm-configuration","title":"OpenStreetMap(OSM) configuration","text":"<p>It is possible to adjust how OSM data is interpreted by OpenTripPlanner when building the road part of the routing graph.</p>"},{"location":"BuildConfiguration/#osm-tag-mapping","title":"OSM tag mapping","text":"<p>OSM tags have different meanings in different countries, and how the roads in a particular country or region are tagged affects routing. As an example roads tagged with `highway=trunk are (mainly) walkable in Norway, but forbidden in some other countries. This might lead to OTP being unable to snap stops to these roads, or by giving you poor routing results for walking and biking. You can adjust which road types that are accessible by foot, car &amp; bicycle as well as speed limits, suitability for biking and walking. It's possible to define \"safety\" values for cycling and walking which are used in routing.</p> <p>To add your own OSM tag mapping have a look at <code>org.opentripplanner.graph_builder.module.osm.tagmapping.NorwayTagMapper</code> and <code>org.opentripplanner.graph_builder.module.osm.tagmapping.DefaultMapper</code> as examples.  If you choose to mainly rely on the default rules, make sure you add your own rules first before applying the default ones. The mechanism is that for any two identical tags, OTP will use the first one.</p> <pre><code>// build-config.json\n{\n  \"osm\": [\n    {\n      \"source\": \"gs://marduk-dev/osm/oslo_norway.osm-160816.pbf\",\n      \"osmTagMapping\": \"norway\"\n    }\n  ]\n}\n</code></pre>"},{"location":"BuildConfiguration/#custom-naming","title":"Custom naming","text":"<p>You can define a custom naming scheme for elements drawn from OSM by defining an <code>osmNaming</code> field in <code>build-config.json</code>, such as:</p> <pre><code>// build-config.json\n{\n  \"osmNaming\": \"portland\"\n}\n</code></pre> <p>There is currently only one custom naming module called <code>portland</code> (which has no parameters).</p>"},{"location":"BuildConfiguration/#elevation-data","title":"Elevation data","text":"<p>OpenTripPlanner can \"drape\" the OSM street network over a digital elevation model (DEM). This allows OTP to draw an elevation profile for the on-street portion of itineraries, and helps provide better routing for bicyclists. It even helps avoid hills for walking itineraries. DEMs are usually supplied as rasters (regular grids of numbers) stored in image formats such as GeoTIFF.</p>"},{"location":"BuildConfiguration/#geoid-difference","title":"Geoid Difference","text":"<p>Some elevation data sets are relative to mean sea level. At a global scale sea level is represented as a surface called the geoid, which is irregular in shape due to local gravitational anomalies. On the other hand, GPS elevations are reported relative to the WGS84 spheroid, a perfectly smooth mathematical surface approximating the geoid. In cases where the two elevation definitions are mixed, it may be necessary to adjust elevation values to avoid confusing users with things like negative elevation values in places clearly above sea level. See issue #2301 for detailed discussion of this.</p> <p>OTP allows you to adjust the elevation values reported in API responses in two ways. The first way is to store ellipsoid (GPS) elevation values internally, but apply a single geoid difference value in the OTP client where appropriate to display elevations above sea level. This ellipsoid to geoid difference is returned in each trip plan response in the ElevationMetadata field. Using a single value can be sufficient for smaller OTP deployments, but might result in incorrect values at the edges of larger OTP deployments. If your OTP instance uses this, it is recommended to set a default request value in the <code>router-config.json</code> file as follows:</p> <pre><code>// router-config.json\n{\n    \"routingDefaults\": {\n        \"geoidElevation\": true   \n    }\n}\n</code></pre> <p>The second way is to precompute these geoid difference values at a more granular level and store all elevations internally relative to the geoid (sea level). Elevations returned in the API responses will then not need to be adjusted to match end users' intuitive understanding of elevation. In order to speed up calculations, these geoid difference values are calculated and cached using only 2 significant digits of GPS coordinates. This is more than enough detail for most regions of the world and should result in less than one meter of vertical error even in areas that have the largest geoid irregularities. To enable this, include the following in the <code>build-config.json</code> file:</p> <pre><code>// build-config.json\n{\n  \"includeEllipsoidToGeoidDifference\": true\n}\n</code></pre> <p>If the geoid difference values are precomputed, be careful to not set the routing resource value of <code>geoidElevation</code> to true in order to avoid having the graph-wide geoid added again to all elevation values in the relevant street edges in responses.</p>"},{"location":"BuildConfiguration/#other-raster-elevation-data","title":"Other raster elevation data","text":"<p>For other parts of the world you will need a GeoTIFF file containing the elevation data. These are often available from national geographic surveys, or you can always fall back on the worldwide Space Shuttle Radar Topography Mission (SRTM) data. This not particularly high resolution (roughly 30 meters horizontally) but it can give acceptable results.</p> <p>Simply place the elevation data file in the directory with the other graph builder inputs, alongside the GTFS and OSM data. Make sure the file has a <code>.tiff</code> or <code>.tif</code> extension, and the graph builder should detect its presence and apply the elevation data to the streets.</p> <p>OTP should automatically handle DEM GeoTIFFs in most common projections. You may want to check for elevation-related error messages during the graph build process to make sure OTP has properly discovered the projection. If you are using a DEM in unprojected coordinates make sure that the axis order is (longitude, latitude) rather than (latitude, longitude). Unfortunately there is no reliable standard for WGS84 axis order, so OTP uses the same axis order as the above-mentioned SRTM data,  which is also the default for the popular Proj4 library.</p> <p>DEM files(USGS DEM) is not supported by OTP, but can be converted to GeoTIFF with tools like GDAL. Use <code>gdal_merge.py -o merged.tiff *.dem</code> to merge a set of <code>dem</code> files into one <code>tif</code> file.</p> <p>See Interline PlanetUtils for a set of scripts to download, merge, and resample  Mapzen/Amazon Terrain Tiles.</p>"},{"location":"BuildConfiguration/#elevation-unit-conversion","title":"Elevation unit conversion","text":"<p>By default, OTP expects the elevation data to use metres. However, by setting  <code>elevationUnitMultiplier</code> in <code>build-config.json</code>, it is possible to define a multiplier that  converts the elevation values from some other unit to metres.</p> <pre><code>// build-config.json\n{\n  \"dem\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.dem.tif\",\n      // Correct conversion multiplier when source data uses decimetres instead of metres\n      \"elevationUnitMultiplier\": 0.1\n    }\n  ]\n}\n</code></pre>"},{"location":"BuildConfiguration/#elevation-data-calculation-optimizations","title":"Elevation Data Calculation Optimizations","text":"<p>Calculating elevations on all StreetEdges can take a dramatically long time. In a very large graph build for multiple Northeast US states, the time it took to download the elevation data and calculate all the elevations took roughly 1.5 hours.</p> <p>If you are using cloud computing for your OTP instances, it is recommended to create prebuilt images that contain the elevation data you need. This will save time because all the data won't need to be downloaded.</p> <p>However, the bulk of the time will still be spent calculating elevations for the street edges. Therefore, a further optimization can be done to calculate and save the elevation data during  a  graph build and then save it for future use.</p>"},{"location":"BuildConfiguration/#reusing-elevation-data-from-previous-builds","title":"Reusing elevation data from previous builds","text":"<p>In order to write out the precalculated elevation data, add this to your <code>build-config.json</code> file:</p> <p><pre><code>// build-config.json\n{  \n  \"writeCachedElevations\": true\n}\n</code></pre> See writeCachedElevations for details.</p>"},{"location":"BuildConfiguration/#parameter-details","title":"Parameter Details","text":""},{"location":"BuildConfiguration/#areaVisibility","title":"areaVisibility","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Perform visibility calculations.</p> <p>If this is <code>true</code> OTP attempts to calculate a path straight through an OSM area using the shortest way rather than around the edge of it. (These calculations can be time consuming).</p>"},{"location":"BuildConfiguration/#buildReportDir","title":"buildReportDir","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the directory where the graph build report should be written to.</p> <p>The html report is written into this directory. If the directory exist, any existing files are deleted. If it does not exist, it is created.</p>"},{"location":"BuildConfiguration/#configVersion","title":"configVersion","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Deployment version of the build-config.json.</p> <p>The config-version is a parameter which each OTP deployment may set to be able to query the OTP server and verify that it uses the correct version of the config. The version should be injected into the config in the (continuous) deployment pipeline. How this is done, is up to the deployment.</p> <p>The config-version has no effect on OTP, and is provided as is on the API. There is no syntax or format check on the version and it can be any string.</p> <p>Be aware that OTP uses the config embedded in the loaded graph if no new config is provided.</p>"},{"location":"BuildConfiguration/#dataImportReport","title":"dataImportReport","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Generate nice HTML report of Graph errors/warnings</p> <p>The reports are stored in the same location as the graph.</p>"},{"location":"BuildConfiguration/#distanceBetweenElevationSamples","title":"distanceBetweenElevationSamples","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10.0</code> Path: / </p> <p>The distance between elevation samples in meters.</p> <p>The default is the approximate resolution of 1/3 arc-second NED data. This should not be smaller than the horizontal resolution of the height data used.</p>"},{"location":"BuildConfiguration/#graph","title":"graph","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the graph object file for reading and writing.</p> <p>The file is created or overwritten if OTP saves the graph to the file.</p>"},{"location":"BuildConfiguration/#gsCredentials","title":"gsCredentials","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Local file system path to Google Cloud Platform service accounts credentials file.</p> <p>The credentials is used to access GCS urls. When using GCS from outside of Google Cloud you need to provide a path the the service credentials. Environment variables in the path are resolved.</p> <p>This is a path to a file on the local file system, not an URI.</p>"},{"location":"BuildConfiguration/#includeEllipsoidToGeoidDifference","title":"includeEllipsoidToGeoidDifference","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge.</p> <p>When set to true (it is false by default), the elevation module will include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge in the graph.</p> <p>NOTE: if this is set to true for graph building, make sure to not set the value of <code>RoutingResource#geoidElevation</code> to true otherwise OTP will add this geoid value again to all of the elevation values in the street edges.</p>"},{"location":"BuildConfiguration/#maxDataImportIssuesPerFile","title":"maxDataImportIssuesPerFile","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1000</code> Path: / </p> <p>When to split the import report.</p> <p>If the number of issues is larger then <code>maxDataImportIssuesPerFile</code>, then the files will   be split in multiple files. Since browsers have problems opening large HTML files.</p>"},{"location":"BuildConfiguration/#maxStopToShapeSnapDistance","title":"maxStopToShapeSnapDistance","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>150.0</code> Path: / </p> <p>Maximum distance between route shapes and their stops.</p> <p>This field is used for mapping routes geometry shapes. It determines max distance between shape points and their stop sequence. If mapper cannot find any stops within this radius it will default to simple stop-to-stop geometry instead.</p>"},{"location":"BuildConfiguration/#multiThreadElevationCalculations","title":"multiThreadElevationCalculations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Configuring multi-threading during elevation calculations.</p> <p>For unknown reasons that seem to depend on data and machine settings, it might be faster   to use a single processor. If multi-threading is activated, parallel streams will be used   to calculate the elevations.</p>"},{"location":"BuildConfiguration/#osmCacheDataInMem","title":"osmCacheDataInMem","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>If OSM data should be cached in memory during processing.</p> <p>When loading OSM data, the input is streamed 3 times - one phase for processing RELATIONS, one for WAYS and last one for NODES. Instead of reading the data source 3 times it might be faster to cache the entire osm file im memory. The trade off is of course that OTP might use more memory while loading osm data. You can use this parameter to choose what is best for your deployment depending on your infrastructure. Set the parameter to <code>true</code> to cache the data, and to <code>false</code> to read the stream from the source each time.</p>"},{"location":"BuildConfiguration/#readCachedElevations","title":"readCachedElevations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>true</code> Path: / </p> <p>Whether to read cached elevation data.</p> <p>When set to true, the elevation module will attempt to read this file in order to reuse calculations of elevation data for various coordinate sequences instead of recalculating them all over again.</p>"},{"location":"BuildConfiguration/#streetGraph","title":"streetGraph","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>uri</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>URI to the street graph object file for reading and writing.</p> <p>The file is created or overwritten if OTP saves the graph to the file</p>"},{"location":"BuildConfiguration/#subwayAccessTime","title":"subwayAccessTime","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: / </p> <p>Minutes necessary to reach stops served by trips on routes of route_type=1 (subway) from the street.</p> <p>Note! The preferred way to do this is to update the OSM data. See In-station navigation.</p> <p>The ride locations for some modes of transport such as subways can be slow to reach from the street. When planning a trip, we need to allow additional time to reach these locations to properly inform the passenger. For example, this helps avoid suggesting short bus rides between two subway rides as a way to improve travel time. You can specify how long it takes to reach a subway platform.</p> <p>This setting does not generalize to other modes like airplanes because you often need much longer time to check in to a flight (2-3 hours for international flights) than to alight and exit the airport (perhaps 1 hour). Use <code>boardSlackForMode</code> and <code>alightSlackForMode</code> for this.</p>"},{"location":"BuildConfiguration/#transitModelTimeZone","title":"transitModelTimeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Time zone for the graph.</p> <p>This is used to store the timetables in the transit model, and to interpret times in incoming requests.</p>"},{"location":"BuildConfiguration/#transitServiceEnd","title":"transitServiceEnd","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"P3Y\"</code> Path: / </p> <p>Limit the import of transit services to the given end date.</p> <p>See Limit the transit service period for an introduction.</p> <p>The date is inclusive. If set, any transit service on a day AFTER the given date is dropped and will not be part of the graph. Use an absolute date or a period relative to the date the graph is build(BUILD_DAY).</p> <p>Use an empty string to make it unbounded.</p>"},{"location":"BuildConfiguration/#transitServiceStart","title":"transitServiceStart","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"-P1Y\"</code> Path: / </p> <p>Limit the import of transit services to the given START date.</p> <p>See Limit the transit service period for an introduction.</p> <p>The date is inclusive. If set, any transit service on a day BEFORE the given date is dropped and will not be part of the graph. Use an absolute date or a period relative to the date the graph is build(BUILD_DAY).</p> <p>Use an empty string to make unbounded.</p>"},{"location":"BuildConfiguration/#writeCachedElevations","title":"writeCachedElevations","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: / </p> <p>Reusing elevation data from previous builds</p> <p>When set to true, the elevation module will create a file cache for calculated elevation data. Subsequent graph builds can reuse the data in this file.</p> <p>After building the graph, a file called <code>cached_elevations.obj</code> will be written to the cache directory. By default, this file is not written during graph builds. There is also a graph build parameter called <code>readCachedElevations</code> which is set to <code>true</code> by default.</p> <p>In graph builds, the elevation module will attempt to read the <code>cached_elevations.obj</code> file from the cache directory. The cache directory defaults to <code>/var/otp/cache</code>, but this can be overridden via the CLI argument <code>--cache &lt;directory&gt;</code>. For the same graph build for multiple Northeast US states, the time it took with using this pre-downloaded and precalculated data became roughly 9 minutes.</p> <p>The cached data is a lookup table where the coordinate sequences of respective street edges are used as keys for calculated data. It is assumed that all of the other input data except for the OpenStreetMap data remains the same between graph builds. Therefore, if the underlying elevation data is changed, or different configuration values for <code>elevationUnitMultiplier</code> or <code>includeEllipsoidToGeoidDifference</code> are used, then this data becomes invalid and all elevation data should be recalculated. Over time, various edits to OpenStreetMap will cause this cached data to become stale and not include new OSM ways. Therefore, periodic update of this cached data is recommended.</p>"},{"location":"BuildConfiguration/#boardingLocationTags","title":"boardingLocationTags","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>What OSM tags should be looked on for the source of matching stops to platforms and stops.</p> <p>Detailed documentation</p>"},{"location":"BuildConfiguration/#dem","title":"dem","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Specify parameters for DEM extracts.</p> <p>The dem section allows you to override the default behavior of scanning for elevation files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p> <p>If not specified OTP will fall back to auto-detection based on the directory provided on the command line.</p>"},{"location":"BuildConfiguration/#dem_0_elevationUnitMultiplier","title":"elevationUnitMultiplier","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /dem/[0] </p> <p>Specify a multiplier to convert elevation units from source to meters. Overrides the value specified in <code>demDefaults</code>.</p> <p>Unit conversion multiplier for elevation values. No conversion needed if the elevation values are defined in meters in the source data. If, for example, decimetres are used in the source data, this should be set to 0.1.</p>"},{"location":"BuildConfiguration/#demDefaults_elevationUnitMultiplier","title":"elevationUnitMultiplier","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /demDefaults </p> <p>Specify a multiplier to convert elevation units from source to meters.</p> <p>Unit conversion multiplier for elevation values. No conversion needed if the elevation values are defined in meters in the source data. If, for example, decimetres are used in the source data, this should be set to 0.1.</p>"},{"location":"BuildConfiguration/#elevationBucket","title":"elevationBucket","text":"<p>Since version: <code>na</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Used to download NED elevation tiles from the given AWS S3 bucket.</p> <p>In the United States, a high resolution National Elevation Dataset is available for the entire territory. It used to be possible for OTP to download NED tiles on the fly from a rather complex USGS SOAP service. This process was somewhat unreliable and would greatly slow down the graph building process. In any case the service has since been replaced. But the USGS would also deliver the whole dataset in bulk if you sent them a hard drive. We did this many years back and uploaded the entire data set to Amazon AWS S3. OpenTripPlanner contains another module that can automatically fetch data in this format from any Amazon S3 copy of the bulk data.</p> <p>This <code>ned13</code> bucket is still available on S3 under a \"requester pays\" policy. As long as you specify valid AWS account credentials you should be able to download tiles, and any bandwidth costs will be billed to your AWS account.</p> <p>Once the tiles are downloaded for a particular geographic area, OTP will keep them in local cache for the next graph build operation. You should add the <code>--cache &lt;directory&gt;</code> command line parameter to specify your NED tile cache location.</p>"},{"location":"BuildConfiguration/#gd_discardMinTransferTimes","title":"discardMinTransferTimes","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /gtfsDefaults </p> <p>Should minimum transfer times in GTFS files be discarded.</p> <p>This is useful eg. when the minimum transfer time is only set for ticketing purposes, but we want to calculate the transfers always from OSM data.</p>"},{"location":"BuildConfiguration/#gd_stationTransferPreference","title":"stationTransferPreference","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"allowed\"</code> Path: /gtfsDefaults  Enum values: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Should there be some preference or aversion for transfers at stops that are part of a station.</p> <p>This parameter sets the generic level of preference. What is the actual cost can be changed with the <code>stopTransferCost</code> parameter in the router configuration.</p>"},{"location":"BuildConfiguration/#islandPruning_adaptivePruningDistance","title":"adaptivePruningDistance","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>250</code> Path: /islandPruning </p> <p>Search distance for analyzing islands in pruning.</p> <p>The distance after which disconnected sub graph is considered as real island in pruning heuristics.</p>"},{"location":"BuildConfiguration/#islandPruning_adaptivePruningFactor","title":"adaptivePruningFactor","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>50.0</code> Path: /islandPruning </p> <p>Defines how much pruning thresholds grow maximally by distance.</p> <p>Expands the pruning thresholds as the distance of an island from the rest of the graph gets smaller. Even fairly large disconnected sub graphs should be removed if they are badly entangled with other graph.</p>"},{"location":"BuildConfiguration/#islandPruning_islandWithStopsMaxSize","title":"islandWithStopsMaxSize","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2</code> Path: /islandPruning </p> <p>When a graph island with stops in it should be pruned.</p> <p>This field indicates the pruning threshold for islands with stops. Any such island under this edge count will be pruned.</p>"},{"location":"BuildConfiguration/#islandPruning_islandWithoutStopsMaxSize","title":"islandWithoutStopsMaxSize","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10</code> Path: /islandPruning </p> <p>When a graph island without stops should be pruned.</p> <p>This field indicates the pruning threshold for islands without stops. Any such island under this edge count will be pruned.</p>"},{"location":"BuildConfiguration/#localFileNamePatterns","title":"localFileNamePatterns","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Patterns for matching OTP file types in the base directory</p> <p>When scanning the base directory for inputs, each file's name is checked against patterns to detect what kind of file it is.</p> <p>OTP1 used to peek inside ZIP files and read the CSV tables to guess if a ZIP was indeed GTFS. Now that we support remote input files (cloud storage or arbitrary URLs) not all data sources allow seeking within files to guess what they are. Therefore, like all other file types GTFS is now detected from a filename pattern. It is not sufficient to look for the <code>.zip</code> extension because Netex data is also often supplied in a ZIP file.</p>"},{"location":"BuildConfiguration/#lfp_dem","title":"dem","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)\\.tiff?$\"</code> Path: /localFileNamePatterns </p> <p>Pattern for matching elevation DEM files.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_gtfs","title":"gtfs","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)gtfs\"</code> Path: /localFileNamePatterns </p> <p>Patterns for matching GTFS zip-files or directories.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_netex","title":"netex","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)netex\"</code> Path: /localFileNamePatterns </p> <p>Patterns for matching NeTEx zip files or directories.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#lfp_osm","title":"osm","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(?i)(\\.pbf|\\.osm|\\.osm\\.xml)$\"</code> Path: /localFileNamePatterns </p> <p>Pattern for matching Open Street Map input files.</p> <p>If the filename contains the given pattern it is considered a match. Any legal Java Regular expression is allowed.</p>"},{"location":"BuildConfiguration/#nd_groupFilePattern","title":"groupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching group NeTEx files.</p> <p>This field is used to match group files in the module file(zip file entries). group files are loaded right the after shared group files are loaded. Files are grouped together by the first group pattern in the regular expression. The pattern <code>\"(\\w{3})-.*\\.xml\"</code> matches <code>\"RUT-Line-208-Hagalia-Nevlunghavn.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#nd_ignoreFilePattern","title":"ignoreFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"$^\"</code> Path: /netexDefaults </p> <p>Pattern for matching ignored files in a NeTEx bundle.</p> <p>This field is used to exclude matching files in the module file(zip file entries). The ignored files are not loaded.</p>"},{"location":"BuildConfiguration/#nd_sharedFilePattern","title":"sharedFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"shared-data\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching shared NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared files(zip file entries) in the module file. Shared files are loaded first. Then the rest of the files are grouped and loaded.</p> <p>The pattern <code>\"shared-data.xml\"</code> matches <code>\"shared-data.xml\"</code></p> <p>File names are matched in the following order - and treated accordingly to the first match:</p> <ul> <li><code>ignoreFilePattern</code></li> <li><code>sharedFilePattern</code></li> <li><code>sharedGroupFilePattern</code></li> <li><code>groupFilePattern</code></li> </ul>"},{"location":"BuildConfiguration/#nd_sharedGroupFilePattern","title":"sharedGroupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*-shared\\.xml\"</code> Path: /netexDefaults </p> <p>Pattern for matching shared group NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared group files in the module file(zip file entries). Typically this is used to group all files from one agency together.</p> <p>Shared group files are loaded after shared files, but before the matching group files. Each group of files are loaded as a unit, followed by next group.</p> <p>Files are grouped together by the first group pattern in the regular expression.</p> <p>The pattern <code>\"(\\w{3})-.*-shared\\.xml\"</code> matches <code>\"RUT-shared.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#nd_ferryIdsNotAllowedForBicycle","title":"ferryIdsNotAllowedForBicycle","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /netexDefaults </p> <p>List ferries which do not allow bikes.</p> <p>Bicycles are allowed on most ferries however the Nordic profile doesn't contain a place where bicycle conveyance can be defined.</p> <p>For this reason we allow bicycles on ferries by default and allow to override the rare case where this is not the case.</p>"},{"location":"BuildConfiguration/#osm","title":"osm","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configure properties for a given OpenStreetMap feed.</p> <p>The osm section of build-config.json allows you to override the default behavior of scanning for OpenStreetMap files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p>"},{"location":"BuildConfiguration/#osm_0_osmTagMapping","title":"osmTagMapping","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"default\"</code> Path: /osm/[0]  Enum values: <code>default</code> | <code>norway</code> | <code>uk</code> | <code>finland</code> | <code>germany</code> | <code>atlanta</code> | <code>houston</code> | <code>portland</code> | <code>constant-speed-finland</code></p> <p>The named set of mapping rules applied when parsing OSM tags. Overrides the value specified in <code>osmDefaults</code>.</p>"},{"location":"BuildConfiguration/#od_osmTagMapping","title":"osmTagMapping","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"default\"</code> Path: /osmDefaults  Enum values: <code>default</code> | <code>norway</code> | <code>uk</code> | <code>finland</code> | <code>germany</code> | <code>atlanta</code> | <code>houston</code> | <code>portland</code> | <code>constant-speed-finland</code></p> <p>The named set of mapping rules applied when parsing OSM tags.</p>"},{"location":"BuildConfiguration/#transitFeeds","title":"transitFeeds","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Scan for transit data files</p> <p>The transitFeeds section of <code>build-config.json</code> allows you to override the default behavior of scanning for transit data files in the base directory. You can specify data located outside the local filesystem (including cloud storage services) or at various different locations around the local filesystem.</p> <p>When a feed of a particular type (<code>netex</code> or <code>gtfs</code>) is specified in the transitFeeds section, auto-scanning in the base directory for this feed type will be disabled.</p>"},{"location":"BuildConfiguration/#tf_0_discardMinTransferTimes","title":"discardMinTransferTimes","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /transitFeeds/[0] </p> <p>Should minimum transfer times in GTFS files be discarded. Overrides the value specified in <code>gtfsDefaults</code>.</p> <p>This is useful eg. when the minimum transfer time is only set for ticketing purposes, but we want to calculate the transfers always from OSM data.</p>"},{"location":"BuildConfiguration/#tf_0_stationTransferPreference","title":"stationTransferPreference","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"allowed\"</code> Path: /transitFeeds/[0]  Enum values: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Should there be some preference or aversion for transfers at stops that are part of a station. Overrides the value specified in <code>gtfsDefaults</code>.</p> <p>This parameter sets the generic level of preference. What is the actual cost can be changed with the <code>stopTransferCost</code> parameter in the router configuration.</p>"},{"location":"BuildConfiguration/#tf_1_groupFilePattern","title":"groupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching group NeTEx files.</p> <p>This field is used to match group files in the module file(zip file entries). group files are loaded right the after shared group files are loaded. Files are grouped together by the first group pattern in the regular expression. The pattern <code>\"(\\w{3})-.*\\.xml\"</code> matches <code>\"RUT-Line-208-Hagalia-Nevlunghavn.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#tf_1_ignoreFilePattern","title":"ignoreFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"$^\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching ignored files in a NeTEx bundle.</p> <p>This field is used to exclude matching files in the module file(zip file entries). The ignored files are not loaded.</p>"},{"location":"BuildConfiguration/#tf_1_sharedFilePattern","title":"sharedFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"shared-data\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching shared NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared files(zip file entries) in the module file. Shared files are loaded first. Then the rest of the files are grouped and loaded.</p> <p>The pattern <code>\"shared-data.xml\"</code> matches <code>\"shared-data.xml\"</code></p> <p>File names are matched in the following order - and treated accordingly to the first match:</p> <ul> <li><code>ignoreFilePattern</code></li> <li><code>sharedFilePattern</code></li> <li><code>sharedGroupFilePattern</code></li> <li><code>groupFilePattern</code></li> </ul>"},{"location":"BuildConfiguration/#tf_1_sharedGroupFilePattern","title":"sharedGroupFilePattern","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>regexp</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"(\\w{3})-.*-shared\\.xml\"</code> Path: /transitFeeds/[1] </p> <p>Pattern for matching shared group NeTEx files in a NeTEx bundle.</p> <p>This field is used to match shared group files in the module file(zip file entries). Typically this is used to group all files from one agency together.</p> <p>Shared group files are loaded after shared files, but before the matching group files. Each group of files are loaded as a unit, followed by next group.</p> <p>Files are grouped together by the first group pattern in the regular expression.</p> <p>The pattern <code>\"(\\w{3})-.*-shared\\.xml\"</code> matches <code>\"RUT-shared.xml\"</code> with group <code>\"RUT\"</code>.</p>"},{"location":"BuildConfiguration/#tf_1_ferryIdsNotAllowedForBicycle","title":"ferryIdsNotAllowedForBicycle","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transitFeeds/[1] </p> <p>List ferries which do not allow bikes.</p> <p>Bicycles are allowed on most ferries however the Nordic profile doesn't contain a place where bicycle conveyance can be defined.</p> <p>For this reason we allow bicycles on ferries by default and allow to override the rare case where this is not the case.</p>"},{"location":"BuildConfiguration/#build-config-example","title":"Build Config Example","text":"<pre><code>// build-config.json\n{\n  \"transitServiceStart\" : \"-P3M\",\n  \"transitServiceEnd\" : \"P1Y\",\n  \"osmCacheDataInMem\" : true,\n  \"localFileNamePatterns\" : {\n    \"osm\" : \"(i?)\\\\.osm\\\\.pbf$\",\n    \"dem\" : \"(i?)\\\\.dem\\\\.tiff?$\",\n    \"gtfs\" : \"(?i)gtfs\",\n    \"netex\" : \"(?i)netex\"\n  },\n  \"osmDefaults\" : {\n    \"timeZone\" : \"Europe/Rome\",\n    \"osmTagMapping\" : \"default\"\n  },\n  \"osm\" : [\n    {\n      \"source\" : \"gs://my-bucket/otp-work-dir/norway.osm.pbf\",\n      \"timeZone\" : \"Europe/Oslo\",\n      \"osmTagMapping\" : \"norway\"\n    }\n  ],\n  \"demDefaults\" : {\n    \"elevationUnitMultiplier\" : 1.0\n  },\n  \"dem\" : [\n    {\n      \"source\" : \"gs://my-bucket/otp-work-dir/norway.dem.tiff\",\n      \"elevationUnitMultiplier\" : 2.5\n    }\n  ],\n  \"netexDefaults\" : {\n    \"feedId\" : \"EN\",\n    \"sharedFilePattern\" : \"_stops.xml\",\n    \"sharedGroupFilePattern\" : \"_(\\\\w{3})_shared_data.xml\",\n    \"groupFilePattern\" : \"(\\\\w{3})_.*\\\\.xml\",\n    \"ignoreFilePattern\" : \"(temp|tmp)\",\n    \"ferryIdsNotAllowedForBicycle\" : [\n      \"RUT:B107\",\n      \"RUT:B209\"\n    ]\n  },\n  \"gtfsDefaults\" : {\n    \"stationTransferPreference\" : \"recommended\",\n    \"removeRepeatedStops\" : true,\n    \"discardMinTransferTimes\" : false,\n    \"blockBasedInterlining\" : true,\n    \"maxInterlineDistance\" : 200\n  },\n  \"islandPruning\" : {\n    \"islandWithStopsMaxSize\" : 2,\n    \"islandWithoutStopsMaxSize\" : 10,\n    \"adaptivePruningFactor\" : 50.0,\n    \"adaptivePruningDistance\" : 250\n  },\n  \"transitFeeds\" : [\n    {\n      \"type\" : \"gtfs\",\n      \"feedId\" : \"SE\",\n      \"source\" : \"https://skanetrafiken.se/download/sweden.gtfs.zip\"\n    },\n    {\n      \"type\" : \"netex\",\n      \"feedId\" : \"NO\",\n      \"source\" : \"gs://BUCKET/OTP_GCS_WORK_DIR/norway-netex.obj\",\n      \"sharedFilePattern\" : \"_stops.xml\",\n      \"sharedGroupFilePattern\" : \"_(\\\\w{3})_shared_data.xml\",\n      \"groupFilePattern\" : \"(\\\\w{3})_.*\\\\.xml\",\n      \"ignoreFilePattern\" : \"(temp|tmp)\"\n    }\n  ],\n  \"transferRequests\" : [\n    {\n      \"modes\" : \"WALK\"\n    },\n    {\n      \"modes\" : \"WALK\",\n      \"wheelchairAccessibility\" : {\n        \"enabled\" : true\n      }\n    }\n  ],\n  \"stopConsolidationFile\" : \"consolidated-stops.csv\",\n  \"emissions\" : {\n    \"carAvgCo2PerKm\" : 170,\n    \"carAvgOccupancy\" : 1.3\n  }\n}\n</code></pre>"},{"location":"Changelog/","title":"Changelog","text":"<p>The changelog lists most feature changes between each release. The list is automatically created based on merged pull requests. Search GitHub issues and pull requests for smaller issues.</p>"},{"location":"Changelog/#250-under-development","title":"2.5.0 (under development)","text":"<ul> <li>Gracefully handle nullable fields in TransitAlert #5349</li> <li>Remove transit with higher cost than best on-street itinerary filter #5222</li> <li>Remove banDiscouragedCycling and banDiscouragedWalking #5341</li> <li>Fix rental scooter access #5361</li> <li>De-duplicate stops returned by <code>stopsByRadius</code> #5366</li> <li>Fix value mapping for bikesAllowed in GTFS GraphQL API #5368</li> <li>Apply correct traversal permissions to barrier vertex #5369</li> <li>Move GTFS GraphQL API out of the sandbox #5339</li> <li>Transmodel GraphQL API for pass-through searches #5320</li> <li>Fix check for OSM relation members not being present in the extract #5379</li> <li>Add a configurable limit for the search window #5293</li> <li>Fix fare calculation for combined interlined legs #5408</li> <li>Fix board slack list mapping in Transmodel API #5420</li> <li>Fix flexible quay querying in Transmodel API #5417</li> <li>Add validation for missing calls in SIRI update #5403</li> <li>Import Occupancy Status from GTFS-RT Vehicle Positions #5372</li> <li>Add Roadmap epic template #5413</li> <li>Allow multiple zones in an unscheduled flex trip #5376</li> <li>Filter out null, empty and blank elements when mapping feed-scoped ids #5428</li> <li>Validate stop id in Transit leg reference #5440</li> <li>Add available types and spaces to <code>VehicleRentalStation</code> #5425</li> <li>Make vehicleRentalStation query optionally accept id without feed #5411</li> <li>Add stricter validation for flex areas #5457</li> <li>Remove HTTPS handling and its documentation #5439</li> <li>Add support for DSJ in transit leg reference #5455</li> <li>Ignore negative travel-times in Raptor #5443</li> <li>Fix sort order bug in optimized transfers #5446</li> <li>Siri file loader #5460</li> <li>Calculate CO\u2082 emissions of itineraries #5278</li> <li>Update NeTEx Java Model 2.0.15 #5466</li> <li>Migrate to Java 21 #5421</li> <li>Add Roadmap setup docs #5468</li> <li>Interpolate increasing stop times for GTFS-RT cancelled trips #5348</li> <li>Remove itineraries outside the search window in arriveBy search #5433</li> <li>Add back walk-reluctance in Transmodel API #5471</li> <li>Make <code>feedId</code> required for real-time updaters #5502</li> <li>Fix serialization of <code>AtomicInteger</code> #5508</li> <li>Improve linking of fixed stops used by flex trips #5503</li> <li>Keep min transfer filter is not local to group-by-filters #5436</li> <li>Add paging deduplication when cropping #5458</li> <li>Consolidate equivalent stops from several feeds  #5429</li> <li>Check transport mode when mapping GroupStops #5518</li> <li>Cleanup trip times - Part A #5437</li> <li>Transfer cost limit #5516</li> <li>Fix missed trip when arrive-by search-window is off by one minute #5520</li> <li>Transit group priority - Part 1 #4999</li> <li>Remove <code>matchBusRoutesToStreets</code> #5523</li> <li>Rename realtime to real-time in docs #5535</li> <li>Add same submode in alternative legs filter #5548</li> <li>Fix issue where stop points are sometimes added twice to index #5552</li> <li>Improve shutdown logic #5514</li> <li>Create TripOnServiceDate for new siri realtime servicejourneys #5542</li> <li>New debug client #5334</li> <li>Improve paging - avoid duplicates and missed itineraries when paging #5551</li> <li>Create own parking preferences for bike and car in the internal model #5521</li> <li>Make Transmodel GraphQl API an official OTP API #5573</li> <li>Add option to include stations in <code>nearest</code> search #5390</li> <li>GTFS Flex spec update: separate columns for <code>location_id</code>, <code>location_group_id</code> #5564</li> <li>Report NO_TRANSIT_CONNECTION when search-window is set. #5570</li> <li>Transit priority  - part 3 #5583</li> <li>Fix preference cost comparisons #5586</li> <li>Report and throw away trip-times which fail sanity check #5587</li> <li>Consider escalator edges in island pruning #5591</li> <li>Create own rental preferences for bike and car in the internal model #5562</li> <li>Adding situation-version to TransmodelGraphQL API #5592</li> <li>Move REST API into sandbox #5580</li> <li>Fix high walk reluctance leading to zero egress results for rental searches #5605</li> <li>Remove GTFS-RT websocket updater #5604</li> <li>Add stop layer to new Debug UI #5602</li> <li>Use fallback timezone if no transit data is loaded #4652</li> <li>Add new path for GTFS GraphQL API, remove batch feature #5581</li> <li>Restructure walk/bicycle/car preferences in router-config.json #5582</li> <li>Revert REST API spelling change of real-time #5629</li> <li>Remove <code>FareComponent</code> #5613</li> <li>Add AreaStop layer to new debug frontend #5636</li> <li>Allow configuration of vector tiles base path #5627</li> <li>Change Transmodel API path to <code>/otp/transmodel/v3</code> #5637</li> <li>Add flexibleArea to GroupStop Quays #5625 </li> </ul>"},{"location":"Changelog/#240-2023-09-13","title":"2.4.0 (2023-09-13)","text":""},{"location":"Changelog/#notable-changes","title":"Notable Changes","text":"<ul> <li>Improved support for Fares V2 #4917 #5227 </li> <li>Improved error and timeout handling #5047 #5092 #5121 #5114 #5133 #5130 #5192</li> <li>Enable GTFS GraphQL API by default, remove the word \"legacy\" from its name and documentation #5202</li> <li>Access and egress penalty on time and cost #5180</li> <li>Improve support for GBFS geofencing zones #5201</li> <li>Reduce memory consumption by 5-8% #5223</li> <li>Stop count limit for access/egress routing and new accessEgress configuration object #5214</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request","title":"Detailed changes by Pull Request","text":"<ul> <li>Generate static documentation for GTFS GraphQL API #5069</li> <li>Create a valid area even when it has too many vertices #5019</li> <li>Constant speed street routing #5057</li> <li>Remove dead build configuration parameter (extraEdgesStopPlatformLink) #5080</li> <li>Configure HTTP WebServer Transaction timeouts #5047</li> <li>Improve Graph updaters shutdown #5092</li> <li>Fix flex timeshift #5063</li> <li>Merge norway traversal calculator into default #5106</li> <li>Use correct GTFS sequence number in vehicle position matcher #5090</li> <li>OSM: Break out of processing a malformed level map #5096</li> <li>Handle JsonParseException #5121</li> <li>Do not enforce API processing timeout for parallel routing #5114</li> <li>Rename bikeRental options to vehicleRental #5089</li> <li>Fare sandbox cleanup, remove MultipleFareService #5100</li> <li>Add validation of NeTEx timetabled passing times #5081</li> <li>Return WALKING_BETTER_THAN_TRANSIT only on a fully walking leg #5091</li> <li>Handle CoercingParseValueException #5133</li> <li>Remove broken Jersey tracing configuration #5142</li> <li>Graceful timeout error handling #5130</li> <li>Log http request headers - like correlationId #5131</li> <li>Fix vertex removal race condition #5141</li> <li>Comment out replacing DSJ-ID from planned data with ID from real-time-data #5140</li> <li>Remove San Francisco and vehicle rental fare calculators #5145</li> <li>Remove batch query from Transmodel API #5147</li> <li>Fix nullable absolute direction in GTFS GraphQL API #5159</li> <li>Fix error in flex validation #5161</li> <li>Check service dates instead of service ids for block id transfers #5162</li> <li>Add support for mapping NeTEx operating day in operating period #5167</li> <li>Validate to/from in routing request #5164</li> <li>Changing default value for earlyStartSec #5165</li> <li>Add GTFS stop sequence to GTFS GraphQL API #5153</li> <li>Remove walk leg in a stay seated transfer #5135</li> <li>Validate distinct from/to temporary vertices #5181</li> <li>Add support for NeTEx taxi mode #5183</li> <li>Fix bike triangle in Transmodel API #5179</li> <li>Bug fixes in stop area relation processing #5166</li> <li>Allow underscores in GTFS feed IDs #5191</li> <li>Area vertex linking improvements #5209</li> <li>Allow multiple FlexibleAreas in a FlexibleStopPlace #4922</li> <li>Prevent NPE in vehicle position matching #5212</li> <li>Empty stop_headsign will fall back to trip_headsign #5205</li> <li>Treat escalator differently from stairs, add escalator reluctance #5046</li> <li>Flex build time and memory optimization for large zones #5233</li> <li>Fix pathway traversal time calculation when none is supplied #5242</li> <li>Add check for null value of serviceCodesRunning in TripPatternForDateMapper #5239</li> <li>Improve error handling in TransmodelGraph #5192</li> <li>Fix filtering by submode #5261</li> <li>Add leg.headsign to GTFS GraphQL API #5290</li> <li>Return client error for invalid Transmodel query JSON format #5277</li> <li>Validate missing intermediate location in via requests #5253</li> <li>Support Fares v2 FareMedium and update spec implementation #5227</li> <li>Improve walk step narrative for entering/exiting stations and signposted pathways #5285</li> <li>Fix walk board cost comparison and add escalatorReluctance to hash #5310</li> <li>Remove pathway id from REST API #5303</li> <li>Remove Winkki street note updater #5305</li> <li>Extend stop area relation linking to include bus stop and platform nodes #5319</li> <li>Add access/egress penalty transmodel api #5268</li> </ul>"},{"location":"Changelog/#230-2023-04-24","title":"2.3.0 (2023-04-24)","text":""},{"location":"Changelog/#notable-changes_1","title":"Notable Changes","text":"<ul> <li>The performance for trip search of large networks (&gt; 100k stops) is improved</li> <li>Run only a single heuristics request (instead of two) #4537</li> <li>Parse NeTEx fare zones from a FareFrame #4563</li> <li>Initial implementation of via search #4554</li> <li>Relaunched documentation theme #4575</li> <li>Add carpool and taxi modes #4641</li> <li>New filter API #4657</li> <li>Adaptive street graph island pruning #4688</li> <li>Experimental support for GBFS geofencing zones #4741</li> <li>Update GBFS support to v2.3 #4809</li> <li>Improve support for EPIP NeTex profile #4863</li> <li>Uber ride hailing #4979</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_1","title":"Detailed changes by Pull Request","text":"<ul> <li>Refactoring SIRI StopConditions from TransitAlert to EntitySelector #4196</li> <li>Add cost of egress leg to the cost of the last transit leg if transit leg arrives at destination #4547</li> <li>Add fallback for missing operator name #4588</li> <li>Add performance test for Switzerland #4576</li> <li>Fix interchange generation when identical consecutive stops are filtered #4586</li> <li>Add alerts to leg when reading in a leg reference #4595</li> <li>Remove KML bike parking updater #4602</li> <li>Add stationTransferPreference option for GTFS feeds #4599</li> <li>Fix osmDefaults so they are used if something is not set in source #4635</li> <li>Add demDefaults #4637</li> <li>Add vector tile layer in debug client for AreaStops #4565</li> <li>Prevent bicycles from using stairs #4614</li> <li>Bugfix for interchanges that start and end from the same stop #4597</li> <li>Add option to define gtfsDefaults and move some parameters from root to gtfs config #4624</li> <li>Fix: forBoarding and forAlighting on cancelled calls in transmodel api #4639</li> <li>Make maxFlexTripDuration configurable #4642</li> <li>Extract separate conditions for \"and\", \"greater than\", \"less than\" during OSM tag mapping, add Portland tag mapping #4593</li> <li>Better fallback in shape geometry processing #4617</li> <li>Fix batch queries in HSL graphql API #4663</li> <li>Add filter for minimum bike parking distance #4626</li> <li>Add limits for flex access/egress walking #4655</li> <li>Make Prometheus endpoint take Accept header into account #4674</li> <li>Add entrances to parking lots that are unconnected in OSM #4666</li> <li>Include crossing=traffic_signals and use it for walking/cycling penalty on crossings #4574</li> <li>Replace surface=cobblestone:flattened with surface=set as a mixin spec in default OsmTagMapper #4683</li> <li>Remove NYC fare service #4694</li> <li>Upgrade dependencies to take new spelling of GTFS Flex's 'drop off' into account #4693</li> <li>Configuration of additional HTTP headers for GTFS-RT updaters #4684</li> <li>Automatic Java dependency upgrades #4704</li> <li>GTFS-RT extension to add completely new routes #4667</li> <li>Add validation on NeTEx flexible area import #4765</li> <li>Do not return a leg from a leg reference, if trip does not exist on date #4758</li> <li>Fix direct transfer analyzer #4767</li> <li>Refactor data import issue reporting #4777</li> <li>Add support for deleted trips &amp; including real-time cancellations in trip search #4759</li> <li>Fix TPoint generation for real-time generated patterns #4787</li> <li>Improve resiliency of the Transmodel API #4806</li> <li>Use TripPatterns for filtering #4820</li> <li>Remove all edges from stop vertex in island pruning #4846</li> <li>Filter functionality for GroupOfLines/GroupOfRoutes in TransmodelAPI #4812</li> <li>Mapping for maxAccessEgressDurationPerMode in Transmodel API #4829</li> <li>Use headsign from the original pattern in a real-time added pattern if the stop sequence is unchanged #4845</li> <li>Remove RouteMatcher #4821</li> <li>Improve boarding location linking on platforms #4852</li> <li>Always check allowed modes in VehicleRentalEdge #4810</li> <li>Include cancelled stops when including cancelled trips in trip search #4851</li> <li>Unpreferred vehicle parking tags #4873</li> <li>Ignore UnrestrictedPublicTransportAreas that do not contain regular stops #4919</li> <li>Validate missing transit data before building transit graph #4930</li> <li>Use durations for Raptor search window configuration #4926</li> <li>Add graph build issue statistics to metrics endpoint #4869</li> <li>Add documentation about system requirements and suggestions #4937</li> <li>Fix initial A* state of car rental #4934</li> <li>Remove check for (now optional) ENV-variable for GCP Authentication #4966</li> <li>Improved walking routes when walking starts or ends in an area #4936</li> <li>Remove unconnected walking areas from graph #4981</li> <li>Filter out duplicate-like legs in alternative legs #4868</li> <li>Fix timeshifting of Flex ~ Walk ~ Flex paths in Raptor #4952</li> <li>Validate the number of service links mapped to a JourneyPattern #4963</li> <li>Make sure the default streetRoutingTimeout is used #4998</li> <li>Validate service date for SCHEDULED updates #4861</li> <li>Fix quay duplicates overwriting stop index #4964</li> <li>Allow OTP to start when unexpected enum values are encountered in config #4983</li> <li>Add filename to graph report #4984</li> <li>Support for second criteria in McRaptor #4996</li> <li>Initialize RAPTOR stop-to-stop transfers on server startup #4977</li> <li>Fix bugs related to DST and service date #5004</li> <li>Fix validation of running period for NeTEx flexible lines #5007</li> <li>JSON logging #5023</li> <li>Add allowOverloading parameter to GBFS updaters and fix use of it in routing #5024</li> <li>Fix precedence rules for NeTEx flexible line booking information #5021</li> <li>Fix transferCacheRequests when custom streetRoutingTimeout is set #5039</li> </ul>"},{"location":"Changelog/#220-2022-11-01","title":"2.2.0 (2022-11-01)","text":""},{"location":"Changelog/#notable-changes_2","title":"Notable Changes","text":"<ul> <li>The performance for trip search is improved by ~20-30% </li> <li>Support for GTFS-RT Vehicle Positions #3981</li> <li>Support for NeTex DatedServiceJourneys #3889</li> <li>Cost-based wheelchair-accessible routing #4045</li> <li>Improve stop linking by taking OSM platform polygons into account #4116</li> <li>Provide an OCI container image on DockerHub #4168</li> <li>Re-add block-based interlining #4264</li> <li>Add walk safety to street routing #4328</li> <li>Experimental support for GTFS Fares V2 #4338</li> <li>Document JVM configuration options #4492</li> <li>Support for HTTPS datasource for Graph Building #4482</li> <li>Metrics for real-time trip updaters #4471</li> <li>Configuration Documentation generated programmatically #4478</li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_2","title":"Detailed changes by Pull Request","text":"<ul> <li>NeTEx mapping for WheelChairBoarding #3945</li> <li>OTP support for NeTEx GroupOfLines #3928</li> <li>Implement trip banning #3953</li> <li>Improve performance of Park+Ride, Bike+Ride and Bike+Transit #3906</li> <li>Re-add GraphCoherencyCheckerModule #3985</li> <li>Modify TripPattern logic for updating stop-to-stop geometry #3988</li> <li>Read translations from GTFS and Netex sources for stop names #3808</li> <li>Update to Java 17 and Kryo 5 #3994</li> <li>Remove optimize=TRANSFERS #4004</li> <li>Enable GBFS floating vehicles by default #4012</li> <li>Don't try to repair trips with negative dwell or driving times, drop them instead #4019</li> <li>Add support for SKIPPED stop time updates in SCHEDULED update handling #3960</li> <li>Elevation handling improvements #4033</li> <li>NeTEx mapping of WheelchairBoarding from ServiceJourney to Trip #4043</li> <li>Add GBFS form factors to GraphQL API #4062</li> <li>Add Geocoder API for debug client searches #4068</li> <li>Consider Wheelchair boarding/alightning when routing from or to directly to a stop #4046</li> <li>Add an implementation for fetching alternative legs #4071</li> <li>Allow single SIRI-situations to fail without affecting others #4083</li> <li>Fix problem with submode filter #4093</li> <li>Make maxWheelchairSlope not a hard cut-off, but apply a cost instead #4088</li> <li>Expose Leg.serviceDate in trip end-point #4096</li> <li>Enable overriding maxDirectStreetDuration per mode #4104</li> <li>Preserve language in SIRI/GTFS-RT alert messages #4117</li> <li>Use board/alight cost only for transits #4079</li> <li>Improve SIRI real-time performance by reducing stopPattern duplicates #4038</li> <li>Siri updaters for Azure ServiceBus #4106</li> <li>Fallback to recorded/expected arrival/departure time if other one is missing in SIRI-ET #4055</li> <li>Allow overriding GBFS system_id with configuration #4147</li> <li>Fix error with transfer-slack and GTFS minTransferTime #4120</li> <li>Use actual distance for walk distance in StreetEdge #4125</li> <li>Don't indicate stop has been updated when NO_DATA is defined #3962</li> <li>Implement nearby searches for car and bicycle parking #4165</li> <li>Do not link cars to stop vertices in routing #4166</li> <li>Add Siri real-time occupancy info #4180</li> <li>Add gtfs stop description translations #4158</li> <li>Add option to discard min transfer times #4195</li> <li>Use negative delay from first stop in a GTFS RT update in previous stop times when required #4035</li> <li>OTP2 no longer crashes on invalid GTFS stop time sequences #4205</li> <li>Cost-based wheelchair accessibility routing for streets #4163</li> <li>Expose SIRI ET PredictionInaccurate in Transmodel-API #4217</li> <li>Do not apply walkable area processing to open platform geometries #4225</li> <li>Add field 'routingErrors' to GTFS GraphQLAPI #4253</li> <li>Configure idempotent upload to Google Cloud Storage #4269</li> <li>Add support to unprefer certain routes #4238</li> <li>Fix inconsistent mapping of NeTEx quay publicCode #4282</li> <li>Take street legs into account when applying the similar legs filter #4280</li> <li>Make graph time zone configurable #4281</li> <li>Support real-time updated wheelchair accessibility for trips #4255</li> <li>Include waiting time at beginning and end in TransitGeneralizedCostFilter #4188</li> <li>Allow filtering out of time-shifted itineraries with same routes and stops #4298</li> <li>Remove unmaintained custom fare calculators for NYC, Seattle, SF Bay Area, Netherlands #4273</li> <li>Return meaningful error if origin and destination are the same #4364</li> <li>Allow configuring maxAccessEgressDuration, searchWindow, timetableView #4377</li> <li>Add custom bike rental data updater (vilkku) as an extension #4381</li> <li>Flex: when optimizing paths preserve egress transfers #4378</li> <li>Skip opening hours if no time-zone configured #4372</li> <li>Digitransit stop vector layer updates #4404</li> <li>Re-enable copying of submode to trip from route #4407</li> <li>Configure each transit feed properties individually  #4399</li> <li>Account for boarding restrictions when calculating direct transfers #4421</li> <li>Configure the import of OSM extracts individually #4419</li> <li>Configure the import of elevation data individually #4423</li> <li>Return typed errors from real-time updates, prepare for real-time statistics #4424</li> <li>Add feature switch for matching ET messages on stops #4347</li> <li>Make safety defaults customizable for walking and cycling #4438</li> <li>Fix block-based interlining when importing several GTFS feeds #4468</li> <li>Do not remove patterns with non-running DatedServiceJourneys #4474</li> <li>Discard direct walking results if direct mode is flex #4476</li> <li>Implement free transfers in GTFS Fares V2 #4460</li> <li>Read and expose time zone in NeTEx/Transmodel API #4480</li> <li>Remove filtering of flex patterns in NeTEX import #4493</li> <li>Make walk and bicycle safety defaults adjustable based on speed limits on ways #4484</li> <li>Enable fuzzyTripMatching in other SIRI-ET updaters #4495</li> <li>Add support for importing zip datasets containing large entries #4508</li> <li>Add feature toggle for turning off the debug client #4512</li> <li>Add 'exact match' specifier for way property sets #4505</li> <li>Remove unnecessary sourceType attribute from GTFS-RT configuration  #4525</li> <li>Do not allow boarding/alighting at GroupStops in RAPTOR #4534</li> <li>Read the feed id from the agency when storing agencies #4536</li> </ul>"},{"location":"Changelog/#210-2022-03-17","title":"2.1.0 (2022-03-17)","text":""},{"location":"Changelog/#notable-changes_3","title":"Notable Changes","text":"<ul> <li>GBFS 2.2 is supported including \"form factors\" (bike, scooter, car) and floating vehicles (with no fixed station)</li> <li>Constrained Transfers (Netex interchanges / GTFS <code>transfers.txt</code>)</li> <li>Transfers for bicycle and wheelchair users distinct from walking paths</li> <li>Support for GTFS-Flex v2</li> <li>Support for frequency-based trips (GTFS <code>frequencies.txt</code>, does not exist in Netex)</li> <li>Many 1.5 features not fully implemented in 2.0 have been reintroduced</li> <li>Improved result quality relative to both 1.5 and 2.0: filtering of itineraries and selection of transfer points between routes</li> <li>Car and bicycle parking has been combined into vehicle parking (enhanced with real-time details like remaining parking spaces)</li> <li>New system for paging of routing results via cursor token</li> <li>Response times should be roughly stable since 2.0. Performance much improved over OTP1 for long searches, may be somewhat slower for short searches. Extremely depdendent on data set used, so test on your specific data.</li> <li>System integration tests for ongoing performance measurement </li> </ul>"},{"location":"Changelog/#detailed-changes-by-pull-request_3","title":"Detailed changes by Pull Request","text":"<ul> <li>Fix NullPointerException when a Real-Time update do not match an existing TripPattern #3284</li> <li>Support for versioning the configuration files #3282</li> <li>Prioritize \"direct\" routes over transfers in group-filters #3309</li> <li>Remove poor transit results for short trips, when walking is better #3331</li> <li>GTFS Trips will by default not allow bikes if no explicit value is set #3359.</li> <li>Improve the dynamic search window calculation. The configuration parameters <code>minTransitTimeCoefficient</code> and <code>minWaitTimeCoefficient</code> replace the old <code>minTripTimeCoefficient</code> parameter. #3366 </li> <li>Allow loops caused by turn restriction in street routes #3399</li> <li>Apply turn restrictions when splitting edges. #3414</li> <li>Add separate no-thru handling for bicycles #3410</li> <li>Add German way property set #3359</li> <li>Process OSM bicycle routes correctly #3359</li> <li>Avoid turns across traffic on bicycles #3359</li> <li>Remove request parameter <code>driveOnRight</code> and derive information from way property set #3359</li> <li>Add basic support for routing using floating bikes #3370</li> <li>Optimize which stops are used for transfers, using generalized-cost, wait-time and transfer priority. Partially implements #2788</li> <li>Support for stay-seated and guaranteed transfers #3193</li> <li>Fix reading of cached elevation files #3455</li> <li>Added BikeRentalWithMostlyWalking filter #3446</li> <li>Import GTFS-Flex v2 Flexible trips #3453</li> <li>Add support for arriving at the destination with rented bicycles #3459</li> <li>Allow IntersectionTraversalCostModel to be specified in the WayPropertySet #3472</li> <li>Fix for traveling back in time when optimize transfers #3491</li> <li>Transit reluctance per transit mode #3440</li> <li>Allow the removal of P+R results consisting only of driving of walking #3515</li> <li>Allow http headers to be specified for bike rental updaters #3533</li> <li>Per-mode reluctance parameters are added so that itineraries with multiple modes may have varying reluctances. #3501</li> <li>Add <code>maxAreaNodes</code> configuration parameter for changing an area visibility calculation limit (https://github.com/opentripplanner/OpenTripPlanner/issues/3534)</li> <li>Add maxAccessEgressDurationSecondsForMode to RoutingRequest #3560</li> <li>Add bicycle safety report to report API #3563</li> <li>Optimize Transfers performance issue #3513</li> <li>Don't allow bicycle loops in A* #3574</li> <li>Cancel individual stop on StopPattern instead of TripTimes #3575</li> <li>Do not allow bicycle traversal on ways tagged with mtb:scale #3578</li> <li>Changes to the StopTimes call #3576</li> <li>Fix bug in optimize transfer service decorating path #3587</li> <li>Remove non-GBFS bicycle rental updaters #3562</li> <li>Remove possibility to import vehicle rental stations from OSM, make vehicle rental stations feed scoped #3601</li> <li>When importing Netex, allow bicycles on ferries by default #3596</li> <li>Safely catch some elevation interpolation exceptions #3412</li> <li>Route not found in some conditions with boarding/alighting restrictions #3621</li> <li>Load additional data from GBFS and expose it #3610</li> <li>Allow transfers to use customizable request options #3324</li> <li>Check boarding and alighting permissions in TransferGenerator #3641</li> <li>Stoptimes should return tripId on the REST API. #3589</li> <li>Handle non-symmetric transfers in RAPTOR #3634.</li> <li>Order RAPTOR input data so that plans are deterministic #3580</li> <li>Cost on transfer in Raptor #3617</li> <li>Allow for combined NeTEx and GTFS data sources #3650</li> <li>Generalized graph connectivity pruning #3426</li> <li>Stop linking to area/platform edges obeys area boundaries and traverse modes #3201</li> <li>Add service day mapping to REST API #3659</li> <li>Generalized cost on transfer in Raptor #3629</li> <li>Add two new filters for use within grouping filter #3638</li> <li>Correct usage of boardSlackForMode / alightSlackForMode #3693</li> <li>Do not parse pass-through information in GBFS mappers #3709</li> <li>Vehicle rental updates #3632</li> <li>add trolleybus &amp; monorail support #3658</li> <li>Do not create zero length StreetEdges #3716</li> <li>Add pickup and dropoff booking info to REST API #3710</li> <li>Use the whole duration of the filtered transit data for the raptor heuristic search #3664</li> <li>Performance improvement for flex access/egress searches #3661</li> <li>Add new routing errors for cases where all itineraries were filtered by post-processing #3628</li> <li>Fix combination of flex access and constrained transfer #3726</li> <li>Merge B+R and P+R functionality into vehicle parking #3480</li> <li>Add cost to maximize wait-time and avoid back-travel in optimize transfers #3654</li> <li>Calculate fares from itineraries not Raptor paths, calculate flex fares #3743</li> <li>Logging first time instance reports it is ready to use #3733</li> <li>Allow limiting the used vehicle rentals and parkings #3746</li> <li>Add support for car and scooter rental modes #3706</li> <li>Extra stop priority cost in optimized transfer service #3731</li> <li>Remove old visibility graph library from walkable area builder #3753</li> <li>Update GtfsRealtime and include severity, effect and cause from GTFS RT #3747</li> <li>Handle miscellaneous service as BUS instead of crashing build #3755</li> <li>Update all timers to micrometer instances #3744</li> <li>Bugfix: ClassCastException when planning flex routes #3762</li> <li>Add mode from parent StopPlace for Quays in Netex mapper #3751</li> <li>Minor performance improvements #3767</li> <li>Parallelise computing of trip pattern geometries #3766</li> <li>Add flex stop to TripTimes, return geometries in GraphQL API #3757</li> <li>Fix checking allowed boarding/alighting for unscheduled flex trips #3782</li> <li>Calculating number of days to use in StopTimes-request #3742</li> <li>Walkable area builder improvements #3765</li> <li>Remove hardcoded alighting/boarding on first/last stop #3784</li> <li>Add support for include-file-directive in config files. #3771</li> <li>Remove build parameter 'useTransfersTxt' #3791</li> <li>Add cursor-based paging #3759</li> <li>Data overlay sandbox feature #3760</li> <li>Add support for sandboxed real-time vehicle parking updaters #3796</li> <li>Add reading and exposing of Netex submodes #3793</li> <li>Fix: Account for wait-time in no-wait Raptor strategy  #3798</li> <li>Read in flex window from Netex feeds #3800</li> <li>Fix NPE when routing on a graph without transit data. #3804</li> <li>Read leg mode from trip, instead of route #3819</li> <li>Use API mapping in snapshot tests #3823</li> <li>Store stop indices in leg and use them to simplify logic in TripTimeShortHelper #3820</li> <li>Include all trips in <code>stopTimesForStop</code> #3817</li> <li>Store all alerts and add support for route_type and direction_id selectors #3780</li> <li>Remove outdated real-time-update from TimetableSnapshot #3770</li> <li>Contributing Guide #3769</li> <li>OTP support for NeTEx branding #3829</li> <li>Not allowed transfers and support for GTFS transfer points #3792</li> <li>Simple implementation of horizontally moving elevators (Elevator way) #3750</li> <li>fix: Avoid mixed path separators on Windows in Park API test #3845</li> <li>Filter out elevator ways that are also implicit areas #3850</li> <li>Dynamically compute additional search days #3824</li> <li>Mode &amp; submode filter for NeTEx Service Journeys #3844</li> <li>Return correct heuristic values, when constrained transfers is turned on #3841</li> <li>Adjust search window dynamically to fit the number of itineraries #3828</li> <li>Implement minimum transfer time from GTFS transfers.txt #3830</li> <li>Fix number format exception for elevator duration parsing OSM data #3871</li> <li>Include generalizedCost in the optimized transfers wait-time cost #3864</li> <li>Expose maxStopToShapeSnapDistance as build-config.json parameter #3874</li> <li>Implement in-seat transfers per GTFS draft #3831</li> <li>Add stairsTimeFactor to StreetEdge #3832</li> <li>Make sure we keep the itinerary with the least number of transfers when grouping the itineraries #3833</li> <li>Don't expect every pattern in a route to have the specified stop with constrained transfers #3868</li> <li>Add support for creating constrained transfers from real-time generated patterns #3878</li> <li>Account for stay seated transfers when calculating the number of transfers #3888</li> <li>Add Hungarian translation #3861</li> <li>Add support for \"via\" in NeTEx headsigns #3883</li> <li>NeTEx mapping to StopTime.timepoint #3898</li> <li>Optimize RAPTOR trip search by pre-calculating arrival/departure time arrays #3919</li> <li>Make turn restrictions faster and thread-safe by moving them into StreetEdge #3899</li> <li>Add routing using frequency trips #3916</li> <li>Remove ET real-time override code #3912</li> <li>Allow traversal of pathways without traversal time, distance or steps #3910</li> </ul>"},{"location":"Changelog/#200-2020-11-27","title":"2.0.0 (2020-11-27)","text":"<ul> <li>Sandbox for experimental features #2745</li> <li>Bugfix for Missing platforms for stops in GTFS import causes a NPE #2804</li> <li>Remove extra Djikstra implementations</li> <li>Remove redundant LineStrings in order to save memory #2795</li> <li>NeTEx import support #2769</li> <li>New Transit search algorithm, Raptor, replaces the AStar for all transit searches.</li> <li>Added NeTEx notices #2824</li> <li>Make transfers and access/egress use effectiveWalkDistance to take slopes into account #2857</li> <li>Add MultiModalStation and GroupOfStations to OTP model and added these to the NeTEx import #2813</li> <li>Combined OSM loaders, removing several rarely used ones #2878</li> <li>New Java Code Style (part of #2755)</li> <li>Cleanup and rename Graph Builder Annotations, now Data Import Issues #2871</li> <li>Bugfix for graph building crashing on unsupported modes #2899</li> <li>Add command line parameter for building partial graphs #2583</li> <li>Refactor GenericLocation/AStar/RoutingContext to allow multiple start vertices #2887 </li> <li>New Transit search algorithm, Raptor, replaces the AStar for all transit searches. </li> <li>Update only the relevant parts of the TransitLayer each time an update is applied #2918</li> <li>Ability to switch off the fare service#2912.</li> <li>Limit the transit service period#2925.</li> <li>Removed unwanted cost added for wait time between access and transit with RangeRaptor #2927</li> <li>Dynamic search parameters, calculate raptor search-window when needed. #2931</li> <li>Support for next/previous paging trip search results #2941</li> <li>Fix mismatch in duration for walk legs, resulting in negative wait times #2955</li> <li>NeTEx import now supports ServiceLinks #2951</li> <li>Also check TripPatterns added by real-time when showing stoptimes for stop #2954</li> <li>Copy geometries from previous TripPattern when real-time updates result in a TripPattern being replaced #2987</li> <li>Support for the Norwegian language.</li> <li>Update pathways support to official GTFS specification #2923</li> <li>Support for XML (de-)serialization is REMOVED from the REST API #3031</li> <li>Refactor how to specify access/egress/direct/transit modes in the internal model and the Transmodel API #3011</li> <li>Make agency id feed scoped #3035</li> <li>Refactor kiss and ride to a more general car pickup mode #3063</li> <li>Map NeTEx publicCode to OTP tripShortName and NeTEx private code to OTP internalPlanningCode #3088</li> <li>Add MQTT transport for the GTFS-RT trip update updater #3094</li> <li>Add FinlandWayPropertySetSource #3096</li> <li>Map NeTEx publicCode to OTP tripShortName and NeTEx private code to OTP internalPlanningCode #3088</li> <li>Reading and writing files(CONFIG, GRAPH, DEM, OSM, GTFS, NETEX, DATA_IMPORT_ISSUES) is changed. All files, except configuration files, are read from a data source. We support Google Cloud Storage and the local file system data sources for now, but plan to add at least support for AWS S3 #2891</li> <li>Remove AlertPatcher #3134</li> <li>Update DebugOutput to match new routing phases of OTP2 #3109</li> <li>Filter transit itineraries with relative high cost #3157</li> <li>Fix issue with colliding TripPattern ids after modifications form real-time updaters #3202</li> <li>Fix: The updater config type is unknown: gtfs-http #3195</li> <li>Fix: Problem building and loading the GTFS file in San Fransisco Bay Area #3195</li> <li>Fix: The <code>BusRouteStreetMatcher</code> and <code>TransitToTaggedStopsModule</code> graph builder modules are not run if the graph is build in two steps, and add progress tracker to BusRouteStreetMatcher. #3195</li> <li>Improvement: Insert project information like Maven version number into configuration files. #3254 </li> <li>Added pathway FeedScopedId as the route text to trip plan responses. #3287</li> </ul>"},{"location":"Changelog/#ported-over-from-14-and-15","title":"Ported over from 1.4 and 1.5","text":"<ul> <li>Add application/x-protobuf to accepted protobuf content-types #2839</li> <li>Make OTP run on Java 11 #2812</li> <li>Fixes surefire test failure during build #2816</li> <li>Disable linking from already linked stops #2372</li> <li>Add Way Property Set for the UK #2818</li> <li>Remove Open Traffic prototype code #2698</li> <li>Docs: improve configuration documentation</li> <li>Update onebusaway-gtfs to latest version from OBA project #2636</li> <li>Remove the coupling to OneBusAway GTFS within OTP's internal model by creating new classes replacing the external classes #2494</li> <li>Allow itineraries in response to be sorted by duration #2593</li> <li>Fix reverse optimization bug #2653, #2411</li> <li>increase GTFS-real-time feeds size limit from 64MB to 2G #2738</li> <li>Fix XML response serialization #2685</li> <li>Refactor InterleavedBidirectionalHeuristic #2671</li> <li>Add \"Accept\" headers to GTFS-RT HTTP requests #2796</li> <li>Fix minor test failure against BANO geocoder #2798</li> <li>Fix frequency bounds checking #2540</li> <li>Remove dependency on Conveyal jackson2-geojson</li> <li>Changed calculation of slope costs #2579</li> <li>Replace Java built in serialization with faster Kryo #2681</li> <li>Support OSM highway=razed tag #2660</li> <li>Add bicimad bike rental updater #2503</li> <li>Add Smoove citybikes updater #2515</li> <li>Allow big GTFS-real-time feeds by increasing protobuf size limit to 2G #2739</li> <li>Cannot transfer between stops at exactly the same location #2371</li> <li>Improve documentation for <code>mode</code> routing parameter #2809</li> <li>Switched to single license file, removing all OTP and OBA file license headers</li> </ul>"},{"location":"Changelog/#13-2018-08-03","title":"1.3 (2018-08-03)","text":"<ul> <li>Fix stop linking to only one edge of platform #2472</li> <li>Log and allow changing number of HTTP handler threads</li> <li>Update Dutch base fare from 89 to 90 cents #2608</li> <li>Add Dutch fare service #2571</li> <li>Revise unit tests to use less memory</li> <li>Run all graph updater setup methods sequentially #2545</li> <li>Allow vehicle rental systems with cars (stopgap parameter on bike rental)</li> <li>Bump R5 version to get newer gtfs-lib and FST serialization</li> <li>Move stopClusterMode parameter from routing config to build config #2558</li> <li>Update encrypted Maven artifact signing key (it expired)</li> <li>Clean up logging</li> <li>Remove/update deprecated HTTPClient, add missing SSL ciphers #2451</li> <li>Make maxTransfer options configurable through scripting API #2507</li> <li>Fix scripts when entity IDs contain colons #2474</li> <li>Add HTML report for stops more than 20m from linked road #2460</li> <li>Update fares in NycFareServiceImpl #2466</li> <li>Compact legs NPE fix #2449 #2490</li> <li>Docs: elevation data configuration, USGS DEM files</li> <li>Docs: Update list of deployments</li> <li>Docs: API, list of deployments, usage stats and tutorials</li> <li>Docs: Update leadership committee listing following Boston Summit</li> <li>Docs: Update OTP logo (Thanks Kate Chanba!)</li> </ul>"},{"location":"Changelog/#12-2017-09-18","title":"1.2 (2017-09-18)","text":"<ul> <li>Add support for consuming GBFS bike-rental availability feeds. #2458</li> <li>Add GBFS configuration example</li> <li>Add flag for including requested start/end time in maxHours in planner API. #2457</li> <li>Add maxTransferDistance graph builder parameter</li> <li>Add option for filtering non-pickup stops in TransitIndex stop times functions. #2377</li> <li>Support foot/bicycle=discouraged OSM tag. #2415</li> <li>Improve linking of transit platforms to connecting access ways. #2422 / #2428</li> <li>Fix bug when building graph with parent station transfers. #2404 / #2410</li> <li>Fix bugs in park and ride search. #2424</li> <li>Support different stop ID formats in field trip module</li> <li>Update URL in BANO geocoding module. #2438 / #2439</li> <li>Add more debug information related to trips matching using GTFS-RT feed. #2432</li> <li>Update default PATH_NOT_FOUND message to new wording developed w/ TriMet. #2355</li> <li>Update Travis build configuration to not attempt GPG operations. #2441</li> <li>Fix javadoc URL in scripting documentation. #2437</li> <li>Automatically link to GitHub issues in Changelog. #2426</li> <li>Expose FeedInfo objects in the Index API #2456</li> <li>Changes to Puget Sound region fare calculation #2484</li> <li>Fix coordinatates when clustering by parent station #2447</li> <li>Allow setting OSM Way Properties from build-config.json #2389</li> <li>Optionally compact (\"reverse-optimize\") results with complete reverse search #2449</li> <li>Add updater for urbaninfrastructure city bikes #2448</li> <li>Miscellaneous documentation updates</li> </ul>"},{"location":"Changelog/#11-2017-03-16","title":"1.1 (2017-03-16)","text":"<ul> <li>Deploy to Sonatype OSSRH and Maven Central</li> <li>Documentation updates including repo links</li> <li>New router-config stopClusterMode: clustering by parent station or geography #2364</li> <li>Spanish and Portuguese UI Translations</li> <li>In TimeSurface API, serialize travel times to every point when detail=true</li> <li>Make OSM highway=corridor pedestrian routable</li> <li>Fix GraphIndex.stopTimesForStop to search on the request day rather than now</li> <li>Update GraphQL to latest version and improve support for complex arguments #2367</li> <li>Add support for operationName to the graphql endpoint</li> <li>Fix findClosestStopsByWalking, properly set RoutingContext</li> <li>Fixed major routing problem where dead-end SimpleTransfers blocked walking paths #2414</li> <li>Created Github issue template</li> <li>Avoid negative elevation figures: Compute ellipsoid-geoid offset and optionally apply to elevation calculations #2301</li> <li>Fix VCub bike share updater using new API variable names.</li> <li>Fix spurious different-day warning #2399</li> <li>Shutdown hook to gracefully shut down Grizzly #2384</li> <li>Added headsign attribute for stoptimes in GraphQL #2224</li> <li>Allow Cars on highway=*;bicycle=designated #2374</li> <li>Expose PruneFloatingIslands parameters in build-config.json</li> <li>Lazy initialization of stop clusters where needed</li> <li>Include Agency/Route branding in responses</li> <li>Include turn-by-turn walking directions for transfer legs #1707</li> <li>Output error when edge lengths are negative, and set them to 1mm</li> <li>Add disableAlertFiltering API flag #2351</li> <li>Do not show arrival times at terminal stops in stop time viewer #2357</li> <li>Index API now returns stop information URL, enabling hyperlinks in trip viewer #2352</li> <li>Remove all unused model classes for index API #1301</li> <li>Apply an interlining fix from 0.10 branch</li> <li>Allow quoted search phrases in the Lucene search #2279</li> <li>Re-implement maxHours filter #2332</li> <li>Properly set wheelchairAccessible on area edges</li> <li>Fixed file URL in test #2339</li> <li>Add details field to fares, listing which legs each fare applies to #1699</li> </ul>"},{"location":"Changelog/#10-2016-09-09","title":"1.0 (2016-09-09)","text":"<ul> <li>Fix problem with missing embedded router-configs.</li> <li>Check whether trips have been banned when applying in-seat transfers (interlining).</li> <li>Load embedded config for existing graphs on disk.</li> <li>Apply max walk distance to transfers, not just initial and final walk.</li> <li>Remove Conveyal tiles from client (which was getting expensive), add free Carto/MapZen tiles.</li> <li>Fixed headsigns: in itineraries, headsign for a leg used to always be the last stop.</li> <li>Updated default map tile sets in the client because Mapquest is no longer gratis.</li> <li>Fix problem with empty list ??? #1873</li> <li>Rewrite of intermediate places handling in GraphPathFinder. Original request is cloned for each intermediate path.</li> <li>Routes in GraphQL API Change \"type\" to \"mode\" and add \"type\" as route type to Route for GraphQL</li> <li>Add effective end date to alerts (from HSL).</li> <li>Rutebanken Citybike bike share.</li> <li>Correct TPEG transport modes TPEG 401 and 402 to be \"subway\".</li> <li>Ignore exceptions caused by errors in OSM linear rings.</li> <li>Updated to version 2.18 of Jersey to fix hanging threads in Grizzly.</li> <li>Removed confusing \"Busish\" and \"Trainish\" pseudo-modes.</li> <li>FareService for Seattle: allow specifying fares in GTFS instead of hard-coding them in Java. Senior/youth fare prices are given in an extra column in fare attributes. Per-trip fares are taken into consideration when calculating fares in this region.</li> <li>Update new linker to link to transitStops if no streets are found.</li> <li>Show the name supplied in the request for the origin/destination points in the response.</li> <li>Throw a trivialPath exception if start/end point are on the same edge.</li> <li>Switch to only use the new SimpleStreetLinker, even for search start and end points. Completely removed old linker classes. Changes for proper handling of wheelchairs and bicycles at start and end points.</li> <li>Properly handle null timetableSnapshots when there is no real-time data.</li> </ul>"},{"location":"Changelog/#020-2016-06-10","title":"0.20 (2016-06-10)","text":"<ul> <li>Re-enabled Enunciate, which works properly with OTP now. This means we have auto-generated API docs.</li> <li>Make headsign and block ID visible in the Stop Viewer.</li> <li>NYC fare service: filter out non-NYC agencies.</li> <li>Optionally log all requests to a file.</li> <li>Make max distance for in-seat transfers (interlining) configurable. Previously it was hardcoded at 200m.</li> <li>Polish translation for web client.</li> <li>Introduced bikeShareId in trip plans (separate from stopIds).</li> <li>Support for ShareBike bike rental system in Oslo, Drammen, Trondheim, Milan, Barcelona and Mexico City among others.</li> <li>Changed default waitAtBeginningFactor and timeouts.</li> <li>Show alert in client when itinerary departure date differs from search date.</li> <li>Exposed realtimeState in GraphQL responses.</li> <li>Fixed a routerConfig NullPointerException.</li> <li>Support for San Francisco bike share from leoromanovsky.</li> <li>GraphQL API for most transit data from hannesj.</li> <li>Disallow shortcuts through multiple StationStopEdges.</li> <li>Add support for airplanes (from HSL)</li> <li>Major simplification and correction of the longDistance heuristic, removed obsolete runState.options.heuristicWeight.</li> <li>Return default OSM level for ways that are not found.</li> <li>Profile routing: use earliest arrival objective function on-street, properly handle TrivialPathExceptions.</li> <li>Fixed ID matching when applying AlertPatches.</li> <li>Fixed banning of agencies in multi agency feeds.</li> <li>More coherent handling of feed IDs as scope for GTFS IDs.</li> <li>Added transit service start and end timestamps to BuildInfo.</li> <li>Handle embeded router configuration for POSTed graphs and zips for building.</li> <li>Simplified router-config handling.</li> <li>Properly lazy-initialize profile routing stopClusters. Added stop clusters to the Index API.</li> <li>Completely removed the ill-advised path parser system, which was too clever for its own good.</li> <li>Sort itineraries by total travel time rather than in-transit time.</li> <li>Rental bikes: allow loading generic KML.</li> <li>Removed the experimental TransportNetwork classes, which shared no code with the rest of OTP and    were duplicated in the R5 project. There are still some elements that can be cleaned out when only   R5 is used by Conveyal's analysis system. The broker code in OTP is now able to start up R5    workers for Analyst.</li> <li>Use the Conveyal fork of the OBA GTFS loader, so that we can add our own extensions to GTFS.</li> <li>Updated docs to offer Conveyal Maven repo as a place to get prebuilt OTP.</li> </ul>"},{"location":"Changelog/#0190-2016-05-25","title":"0.19.0 (2016-05-25)","text":""},{"location":"Changelog/#0180-2015-05-29","title":"0.18.0 (2015-05-29)","text":"<ul> <li>Ability to load elevation from projected GeoTIFF</li> <li>Clarified axis order for unprojected GeoTIFFs</li> <li>Stop viewer and car distance fixed in client</li> <li>Server-side localization improvements</li> <li>Proper names for intersections</li> <li>JSON config for loading bikeshare and park and ride lots from OSM</li> <li>More ways to fetch isochrones</li> <li>Fixed frequency-based routing in repeated RAPTOR</li> <li>Calculate graph envelope at build time not runtime</li> <li>Fixed slow excessive HashGrid search</li> <li>Readthedocs documentation updates</li> </ul>"},{"location":"Changelog/#0170-2015-05-14","title":"0.17.0 (2015-05-14)","text":"<ul> <li>Allow fetching arrivals/departures over a particular time window</li> <li>Completely new spatial analysis implementation: repeated RAPTOR search at every minute in a departure time window</li> <li>More reproducible spatial analysis results across similar graphs, thanks to more consistent splitting of streets etc.</li> <li>Sigmoidal accessibility metric rolloff (rather than hard-edged cutoff)</li> <li>Correction of equirectangular projection used in spatial analysis</li> <li>Improved, simplified, deterministic linking of stops into the street network</li> </ul>"},{"location":"Changelog/#0160-2015-05-07","title":"0.16.0 (2015-05-07)","text":"<ul> <li>Several improvements to OSM tag based traversal permissions</li> <li>Scripting documentation</li> <li>Accept TIFF files whose names end in .tiff not .tif</li> <li>Store distances (not times) in Analyst Samples to allow variable walk speed</li> <li>Fixed bug in graph auto-scanning</li> <li>Fixed client-side bug in first and last itinerary buttons</li> <li>OTP startup scripts no longer use wildcards</li> <li>Transit, bike rental, and parking linking done in one module</li> <li>Elevation tiles for the US can be fetched from Amazon S3</li> <li>Bumped language level to Java 8 (lambda functions, method references, collection streams)</li> </ul>"},{"location":"Changelog/#0150-2015-04-14","title":"0.15.0 (2015-04-14)","text":"<ul> <li>Fare module for Seattle</li> <li>JSON fare module and OSM street naming configuration</li> <li>Significant improvements to speed and result quality of Profile Routing</li> <li>Support for added and modified GTFS-RT trips (thanks Jaap Koelewijn of DAT Mobility and Plannerstack)</li> <li>Detailed edge lists in profile routing responses (for Transitive.js)</li> <li>Support for multiple access modes including bike rental in profile routing</li> <li>Fixes to graph reloading via web API</li> <li>Improved comments in code and documentation of PointSets</li> <li>Pulled MapDB GTFS loader out into a separate repo</li> <li>Working artifact version was 0.15.0-SNAPSHOT instead of 1.0.0-SNAPSHOT (anticipating frequent point releases)</li> </ul>"},{"location":"Changelog/#0140-2015-03-28","title":"0.14.0 (2015-03-28)","text":"<ul> <li>JSON configuration of graph building and routers</li> <li>Began moving documentation (including this changelog) into the OTP repo and rewriting it page by   page. It is built statically from Markdown using mkdocs and published on readthedocs.</li> <li>Street edge lists and bike rental station IDs in profile routing results (allows better rendering)</li> <li>Improved correctness of profile routing</li> <li>Qualified modes including rented bikes work in profile routing</li> <li>Simplification of qualified mode sets</li> <li>Elevation models are loaded from TIFFs in graph directory</li> <li>Tiles for differences between TimeSurfaces</li> <li>Restructured relationship between Routers and Graphs</li> <li>Various changes enabling use of Analyst features in a cluster computing environment.</li> <li>Removed several single-implementation interfaces, factories, services and other superfluous abstractions</li> <li>Various client fixes related to the transit index API</li> <li>Revised nearby stops logic and transfer generation to eliminate useless transfer edges</li> <li>New Index API endpoints for geometries, transfers etc.</li> <li>Isochrone generation fixes</li> <li>Default mode of operation is now \u201clong distance mode\u201d</li> <li>Process for finding alternative routes is now based on banning trips and retrying, while reusing the heuristic</li> <li>Optimization objective functions are swappable, and have been simplified and corrected</li> <li>All client Javascript librariess are now pulled from a CDN</li> <li>Dutch BAG and French BANO geocoders</li> <li>Bus to street matching improvements</li> <li>Complete MapDB based GTFS and OSM loader libraries (will become separate projects, not yet   connected to OTP graph builder)</li> <li>API documentation generation working again</li> <li>Disable some time consuming graph building steps by default</li> <li>Finnish and Swedish translations</li> <li>Subway-specific JSON configuration options (street to platform time)</li> <li>Real-time fetch / streaming configurable via JSON</li> <li>Stairs reluctance is much higher when carrying a bike</li> <li>Graph visualizer routing progress animates when a search is triggered via the web API</li> <li>Assume WGS84 (spherical distance calculations) everywhere</li> <li>Removed custom motor vehicle (which was unmaintained and not documented)</li> <li>Ability to poll for bike rental locations only once at startup</li> <li>Stoptimes are fetched for a specific service day in index API</li> <li>Bicycle triangle support in profile routing</li> <li>Proper handling of multiple access modes with different speeds in profile routing</li> <li>Command line option to output OTP's version</li> </ul>"},{"location":"Changelog/#0130-2014-12-05","title":"0.13.0 (2014-12-05)","text":"<ul> <li>Detect apparent errors in GTFS interlining</li> <li>Long distance mode: use a pure weight-based state comparison, and use trip-banning retrying logic   to get multiple paths. This compromises correctness somewhat but brings search times back within   reason for large regional graphs. Also, we create significantly less SimpleTransfers.</li> <li>Progress on GTFS reading and writing library (not yet used by OTP).</li> <li>Bug fixes for tiny street edges, time zones.</li> <li>Deployment of artifacts to maven.conveyal.com via S3.</li> <li>Handle park and ride lots that have roads running through them, but don't share nodes with those roads.</li> </ul>"},{"location":"Changelog/#0121-2014-11-17","title":"0.12.1 (2014-11-17)","text":"<ul> <li>Fixed threading problem caused by graph visualization instrumentation #1611</li> <li>Fixed 'unconnected areas' infinite loop #1605</li> </ul>"},{"location":"Changelog/#0120-2014-11-11","title":"0.12.0 (2014-11-11)","text":"<ul> <li>Graph building from zipball of data sent over the wire</li> <li>OTP-specific GTFS loader library with error checking and recovery</li> <li>Bike and car park and ride improvements</li> <li>Stable hash codes for stop patterns and trips</li> <li>Bicycle safety and wheelchair access tile generators</li> <li>Newer versions of Grizzly, Jackson, and Enunciate (documentation generation now works)</li> <li>Redesigned HashGrid spatial index</li> <li>Significant reduction in graph size in memory and on disk</li> <li>Improved internationalization</li> <li>Ability to pause and step search in graph visualizer</li> <li>Additional graph visualizer modes for spotting overbranching</li> <li>Movement toward 1.0 web services API</li> <li>Kiss and Ride</li> <li>Complete removal of Spring</li> <li>Complete removal of Lombok</li> <li>CORS replaces JSONP</li> <li>Pointset classes for dealing with one-to-many calculations and accessibility calculations</li> <li>Experimental \"Profile routing\" which enumerates reasonable route combinations over a time range rather than exact itineraries</li> <li>Single-module Maven build (complete elimination of submodules)</li> <li>Alternate Gradle build script</li> <li>full internationalization of the map-based web client</li> <li>basic Lucene-based built-in geocoder</li> </ul>"},{"location":"Changelog/#0110-2014-03-24","title":"0.11.0 (2014-03-24)","text":"<ul> <li>Built-in HTTP server layer, making it possible to distribute OTP as a standalone JAR</li> <li>\"Long-distance\" mode for large graphs, including bidirectional goal direction heuristic.</li> <li>Simplified Maven project structure with less submodules</li> <li>GTFS-RT trip update support, including streaming incremental data, which directly affects route optimization</li> </ul>"},{"location":"Changelog/#0100-2014-03-18","title":"0.10.0 (2014-03-18)","text":"<p>This release was made to consolidate all the development that had occurred with a 0.9.x-SNAPSHOT Maven version. The changes were very significant and it was not appropriate to tag them as a minor bugfix release after the 0.9 tag. Though this release was performed at the same time as 0.11.0, it represents a much earlier stage in the development of OTP.</p>"},{"location":"Changelog/#070-2012-04-29","title":"0.7.0 (2012-04-29)","text":"<ul> <li>Bike rental support (thanks Laurent Gr\u00e9goire)</li> <li>Real-time bike rental availability feed support</li> <li>Updated to new version of One Bus Away GTFS/CSV, fixing timezone and string interning issues (thanks Brian Ferris)</li> <li>Bugfixes in area routing, OSM loading, nonexistant NED tiles, route short names</li> <li>Dutch and French language updates</li> <li>Catch negative edge weights due to broken GTFS</li> <li>Significant (10-20%) speedup by moving a field into StateData (thanks Laurent Gr\u00e9goire)</li> </ul>"},{"location":"Changelog/#060-2012-04-25","title":"0.6.0 (2012-04-25)","text":"<ul> <li>area routing</li> <li>more lenient parsing of times</li> <li>new directions icon set with SVG sources (thanks Laurent G)</li> </ul>"},{"location":"Changelog/#054-2012-04-06","title":"0.5.4 (2012-04-06)","text":"<ul> <li>catch 0 divisors in NED builder, preventing NaN propagation to edge lengths</li> <li>avoid repeated insertion of edges into edge lists, which are now threadsafe edge sets</li> <li>identity equality for edges</li> <li>bounding box check in UnifiedCoverage (speed up NED loading)</li> <li>Dutch API messages</li> <li>elevation override fix</li> <li>less verbose graph builder (be sure to check graphbuilder annotation summary)</li> <li>replacement streets given names</li> <li>geocoder bug fix (thanks Laurent Gregoire)</li> <li>git commit IDs included in MavenVersion, allowing clearer OTP/Graph version mismatch warnings</li> <li>fix problems with immediate reboarding and unexpected edges in itinerary builder</li> <li>favicon (thanks Joel Haasnoot)</li> <li>Legs in API response have TripId (for real-time information)</li> <li>Polish locale (thanks \u0141ukasz Witkowski)</li> <li>transfers.txt can define station paths, entry costs for stations</li> <li>allow loading a base graph into graphbuilder instead of starting from scratch</li> </ul>"},{"location":"Changelog/#053-2012-03-23","title":"0.5.3 (2012-03-23)","text":"<ul> <li>GTFS loader now loads feeds one-at-a-time, allowing per-feed configuration</li> <li>half-written graph files are now deleted on graph build error</li> <li>DST issue OTP-side fixes, tests adjusted to use timezones</li> <li>updated French translation</li> <li>fixed problem with loop ways in OSM</li> <li>graph coherency checking</li> <li>improved OSM floor number handling</li> <li>handle units in ele tags</li> <li>ferry icons (thanks Joel Haasnoot)</li> <li>mapbox streets tile layer is now the default</li> <li>complete Dutch translation</li> </ul>"},{"location":"Changelog/#052-2012-03-20","title":"0.5.2 (2012-03-20)","text":"<ul> <li>hop speed/distance checks, duplicate shape point filtering, etc.</li> </ul>"},{"location":"Changelog/#051-2012-03-16","title":"0.5.1 (2012-03-16)","text":"<ul> <li>more transit index features</li> <li>default agencyIDs now determined on a per-feed basis</li> <li>fixed fare overflow problem</li> <li>fixed bug in loop road turn conversion</li> <li>additional graphbuilder warnings and annotations</li> <li>fixed a batch of bugs found by fixbugs</li> </ul>"},{"location":"Changelog/#050-2012-03-09","title":"0.5.0 (2012-03-09)","text":"<ul> <li>stop codes, zones, and agency names in planner responses</li> <li>encapsulation of edge list modifications</li> <li>expanded edge and vertex type hierarchy</li> <li>use mapquest OSM server by default</li> <li>Turkish locale (thanks Hasan Tayyar Be\u015fik)</li> <li>German and Italian locales (thanks Gerardo Carrieri)</li> <li>bookmarkable trip URLs (thanks Matt Conway)</li> <li>elevator and OSM level support (thanks Matt Conway)</li> <li>BART/Muni fare service</li> <li>release and javadoc/apidoc publishing automation</li> <li>graph versioning based on Maven artifact version</li> <li>API for browsing graph internals</li> <li>improved stop linking</li> <li>optional island removal graphbuilder step</li> <li>and of course, lots of bugfixes</li> </ul>"},{"location":"Changelog/#044-2012-02-06","title":"0.4.4 (2012-02-06)","text":"<p>Release in anticipation of upcoming merges.</p>"},{"location":"Codestyle/","title":"Codestyle","text":"<p>We use the following code conventions for Java and JavaScript.</p>"},{"location":"Codestyle/#java","title":"Java","text":"<p>The OpenTripPlanner Java code style is revised in OTP v2.2. We use the Prettier Java as is. Maven is setup to run <code>prettier-maven-plugin</code>. A check is run in the CI build, which fails the build preventing merging a PR if the code-style is incorrect.</p> <p>There is two ways to format the code before checkin it in. You may run a normal build with maven - it takes a bit of time, but reformat the entire codebase. Only code you have changed should be formatted, since the existing code is already formatted. The second way is to set up prettier and run it manually or hick it into your IDE, so it runs every time a file is changed.</p>"},{"location":"Codestyle/#how-to-run-prittier-with-maven","title":"How to run Prittier with Maven","text":"<p>Format all code is done in the validate phase (run before test, package, install)</p> <pre><code>% mvn test\n</code></pre> <p>To skip the prettier formating use profile <code>prettierSkip</code>:</p> <pre><code>% mvn test -P prettierSkip\n</code></pre> <p>The check for formatting errors use profile <code>prettierCheck</code>:</p> <pre><code>% mvn test -P prettierSkip\n</code></pre> <p>The check is run by the CI server and will fail the build if the code is incorrectly formatted.</p>"},{"location":"Codestyle/#intellj-and-code-style-formatting","title":"IntellJ and Code Style Formatting","text":"<p>You should use the prettier Maven plugin to reformat the code or run prettier with Node(faster).</p> <p>The prettier does NOT format the doc and markdown files, only Java code. So, for other files you should use the project code-style. It is automatically imported when you first open the project. But, if you have set a custom code-style in your settings (as we used until OTP v2.1), then you need to change to the Project Code Style. Open the <code>Preferences</code> from the menu and select _ Editor &gt; Code Style_. Then select Project in the _Scheme drop down.</p>"},{"location":"Codestyle/#run-prettier-maven-plugin-as-an-external-tool-in-intellij","title":"Run Prettier Maven Plugin as an external tool in IntelliJ","text":"<p>You can run the Prettier Maven plugin as an external tool in IntelliJ. Set it up as an <code>External tool</code> and assign a key-shortcut to the tool execution.</p> <p></p> <pre><code>Name:              Prettier Format Current File\nProgram:           mvn\nArguments:         prettier:write -Dprettier.inputGlobs=$FilePathRelativeToProjectRoot$\nWorking Directory: $ProjectFileDir$\n</code></pre> <p>Tip!  Add a unused key shortcut to execute the external tool, then you can use the old  short-cut to format other file types.</p>"},{"location":"Codestyle/#install-file-watchers-plugin-in-intellij","title":"Install File Watchers Plugin in IntelliJ","text":"<p>You can also configure IntelliJ to run the prettier every time IntelliJ save a Java file. But, if you are editing the file at the same time you will get a warning that the file in memory and the file on disk both changed - and asked to select one of them.</p> <ol> <li>In the menyopen Prefernces... and select Plugins.</li> <li>Search for \"File Watchers\" in Marketplace</li> <li>Run Install</li> </ol>"},{"location":"Codestyle/#configure-file-watcher","title":"Configure File Watcher","text":"<p>You can run Prettier on every file save in Intellij using the File Watcher plugin. There is several ways to set it up. Below is hwo to configure it using Maven to run the formatter. The Maven way work without any installation of other components, but might be a bit slow. So, you might want to install prettier-java in your shell and run it instead.</p> <pre><code>Name:              Format files with Prettier\nFile type:         Java\nScope:             Project Files\nProgram:           mvn\nArguments:         prettier:write -Dprettier.inputGlobs=$FilePathRelativeToProjectRoot$\nWorking Directory: $ProjectFileDir$\n</code></pre>"},{"location":"Codestyle/#other-ides","title":"Other IDEs","text":"<p>We do not have support for other IDEs at the moment. If you use another editor and make one please feel free to share it.</p>"},{"location":"Codestyle/#sorting-class-members","title":"Sorting Class Members","text":"<p>Some of the classes in OTP have a lot of fields and methods. Keeping members sorted reduce the merge conflicts. Adding fields and methods to the end of the list will cause merge conflicts more often than inserting methods and fields in an ordered list. Fields and methods can be sorted in \"feature\" sections or alphabetically, but stick to it and respect it when adding new methods and fields.</p> <p>The provided formatter will group class members in this order:</p> <ol> <li>Getter and Setter methods are kept together</li> <li>Overridden methods are kept together</li> <li>Dependent methods are sorted in a breadth-first order.</li> <li>Members are sorted like this:<ol> <li><code>static</code> <code>final</code> fields</li> <li><code>static</code> fields</li> <li><code>static</code> initializer</li> <li><code>final</code> fields</li> <li>fields</li> <li>class initializer (avoid using it)</li> <li>Constructor</li> <li><code>static</code> methods</li> <li><code>static</code> getter and setters</li> <li>methods</li> <li>getter and setters</li> <li>enums</li> <li>interfaces</li> <li><code>static</code> classes</li> <li>classes</li> </ol> </li> <li>Each section of members are sorted by visibility:<ol> <li>\u00b4public\u00b4</li> <li>package private</li> <li>\u00b4protected\u00b4</li> <li>\u00b4private\u00b4</li> </ol> </li> </ol>"},{"location":"Codestyle/#javadoc-guidlines","title":"JavaDoc Guidlines","text":"<p>What to put in Javadoc:</p> <ul> <li>On methods:<ul> <li>Side effects on instance state (is it a pure function)</li> <li>Contract of the method<ul> <li>Input domain for which the logic is designed</li> <li>Range of outputs produced from valid inputs</li> <li>Is behavior undefined or will fail when conditions are not met</li> <li>Are null values allowed as inputs</li> <li>Will null values occur as outputs (what do they mean)</li> </ul> </li> <li>Invariants that hold if the preconditions are met</li> <li>Concurrency<ul> <li>Is method thread-safe</li> <li>Usage constraints for multi-threaded use</li> </ul> </li> </ul> </li> <li>On classes:<ul> <li>Initialization and teardown process</li> <li>Can instance be reused for multiple operations, or should it be discarded</li> <li>Is it immutable or should anything be treated as immutable</li> <li>Is it a utility class of static methods that should not be instantiated</li> </ul> </li> </ul>"},{"location":"Codestyle/#javascript","title":"JavaScript","text":"<p>As of #206, we follow Crockford's JavaScript code conventions. Further guidelines include:</p> <ul> <li>All .js source files should contain one class only</li> <li>Capitalize the class name, as well as the source file name (a la Java)</li> <li>Include the namespace definition in each and every file: <code>otp.namespace(\"otp.configure\");</code></li> <li>Include a class comment. For example,</li> </ul> <pre><code>/**\n * Configure Class\n *\n * Purpose is to allow a generic configuration object to be read via AJAX/JSON, and inserted into an\n * Ext Store\n * The implementation is TriMet route map specific...but replacing ConfigureStore object (or member\n * variables) with another implementation, will give this widget flexibility for other uses beyond\n * the iMap.\n *\n * @class\n */\n</code></pre> <p>Note: There is still a lot of code following other style conventions, but please adhere to consistent style when you write new code, and help clean up and reformat code as you refactor.</p>"},{"location":"Configuration/","title":"Introduction","text":""},{"location":"Configuration/#configuring-opentripplanner","title":"Configuring OpenTripPlanner","text":""},{"location":"Configuration/#base-directory","title":"Base Directory","text":"<p>On the OTP2 command line you must always specify a single directory after all the switches. This tells OTP2 where to look for any configuration files. By default OTP will also scan this directory for input files to build a graph (GTFS, OSM, elevation, and base street graphs) or the <code>graph.obj</code> file to load when starting a server.</p> <p>A typical OTP2 directory for a New York City graph might include the following:</p> <pre><code>otp-config.json\nbuild-config.json\nrouter-config.json\nnew-york-city-no-buildings.osm.pbf\nnyc-elevation.tiff\nlong-island-rail-road.gtfs.zip\nmta-new-york-city-transit.gtfs.zip\nport-authority-of-new-york-new-jersey.gtfs.zip\ngraph.obj\n</code></pre> <p>You could have more than one of these directories if you are building separate graphs for separate regions. Each one should contain one or more GTFS feeds, a PBF OpenStreetMap file, some JSON configuration files, and any output files such as <code>graph.obj</code>. For convenience, especially if you work with only one graph at a time, you may want to place your OTP2 JAR file in this same directory. Note that file types are detected through a case-insensitive combination of file extension and words within the file name. GTFS file names must end in <code>.zip</code> and contain the letters <code>gtfs</code>, and OSM files must end in <code>.pbf</code>.</p> <p>It is also possible to provide a list of input files in the configuration, which will override the default behavior of scanning the base directory for input files. Scanning is overridden independently for each file type, and can point to remote cloud storage with arbitrary URIs. See the storage section for further details.</p>"},{"location":"Configuration/#three-scopes-of-configuration","title":"Three Scopes of Configuration","text":"<p>OTP is configured via three configuration JSON files which are read from the directory specified on its command line. We try to provide sensible defaults for every option, so all three of these files are optional, as are all the options within each file. Each configuration file corresponds to options that are relevant at a particular phase of OTP usage.</p> <p>Options and parameters that are taken into account during the graph building process will be \"baked into\" the graph, and cannot be changed later in a running server. These are specified in <code>build-config.json</code>. Other details of OTP operation can be modified without rebuilding the graph. These run-time configuration options are found in <code>router-config.json</code>. Finally, <code>otp-config.json</code> contains simple switches that enable or disable system-wide features.</p>"},{"location":"Configuration/#configuration-types","title":"Configuration types","text":"<p>The OTP configuration files use the JSON file format. OTP allows comments and unquoted field names in the JSON configuration files to be more human-friendly. OTP supports all the basic JSON types: nested objects <code>{...}</code>, arrays <code>[]</code>, numbers <code>789.0</code> and boolean <code>true</code> or <code>false</code>. In addition to these basic types some configuration parameters are parsed with some restrictions. In the documentation below we will refer to the following types:</p> Type Description Examples <code>boolean</code> This is the Boolean JSON type <code>true</code>, <code>false</code> <code>string</code> This is the String JSON type. <code>\"This is a string!\"</code> <code>double</code> A decimal floating point number. 64 bit. <code>3.15</code> <code>integer</code> A decimal integer number. 32 bit. <code>1</code>, <code>-7</code>, <code>2100</code> <code>long</code> A decimal integer number. 64 bit. <code>-1234567890</code> <code>enum</code> A fixed set of string literals. <code>\"RAIL\"</code>, <code>\"BUS\"</code> <code>enum-map</code> List of key/value pairs, where the key is a enum and the value can be any given type. <code>{ \"RAIL: 1.2, \"BUS\": 2.3 }</code> <code>enum-set</code> List of enum string values <code>[ \"RAIL\", \"TRAM\" ]</code> <code>locale</code> <code>Language[\\_country[\\_variant]]</code>. A Locale object represents a specific geographical, political, or cultural region. For more information see the Java Locale. <code>\"en_US\"</code>, <code>\"nn_NO\"</code> <code>date</code> Local date. The format is YYYY-MM-DD (ISO-8601). <code>\"2020-09-21\"</code> <code>date-or-period</code> A local date, or a period relative to today. The local date has the format <code>YYYY-MM-DD</code> and the period has the format <code>PnYnMnD</code> or <code>-PnYnMnD</code> where <code>n</code> is a integer number. <code>\"P1Y\"</code>, <code>\"-P3M2D\"</code>, <code>\"P1D\"</code> <code>duration</code> A duration is a amount of time. The format is <code>PnDTnHnMnS</code> or <code>nDnHnMnS</code> where <code>n</code> is a  integer number. The <code>D</code>(days), <code>H</code>(hours), <code>M</code>(minutes) and <code>S</code>(seconds) are not case sensitive. <code>\"3h\"</code>, <code>\"2m\"</code>, <code>\"1d5h2m3s\"</code>, <code>\"-P2dT-1s\"</code> <code>regexp</code> A regular expression pattern used to match a sting. <code>\"$^\"</code>, <code>\"gtfs\"</code>, <code>\"\\w{3})-.*\\.xml\"</code> <code>uri</code> An URI path to a resource like a file or a URL. Relative URIs are resolved relative to the OTP base path. <code>\"http://foo.bar/\"</code>, <code>\"file:///Users/jon/local/file\"</code>, <code>\"graph.obj\"</code> <code>time-zone</code> Time-Zone ID <code>\"UTC\"</code>, <code>\"Europe/Paris\"</code>, <code>\"-05:00\"</code> <code>feed-scoped-id</code> FeedScopedId <code>\"NO:1001\"</code>, <code>\"1:101\"</code> <code>cost-linear-function</code> A cost-linear-function used to calculate a cost from another cost or time/duration.    Given a function of time:   <code>f(t) = a + b * t</code>   then <code>a</code> is the constant time part, <code>b</code> is the time-coefficient, and <code>t</code> is the variable.   If <code>a=0s</code> and <code>b=0.0</code>, then the cost is always <code>0</code>(zero).    Examples: <code>0s + 2.5t</code>, <code>10m + 0t</code> and <code>1h5m59s + 9.9t</code>    The <code>constant</code> must be 0 or a positive number or duration. The unit is seconds unless   specified using the duration format. A duration is automatically converted to a cost.   The <code>coefficient</code> must be in range: [0.0, 100.0] <code>time-penalty</code> A time-penalty is used to add a penalty to the duration/arrival-time/departure-time for   a path. It will be invisible to the end user, but used during the routing when comparing   stop-arrival/paths.    Given a function of time:   <code>f(t) = a + b * t</code>   then <code>a</code> is the constant time part, <code>b</code> is the time-coefficient, and <code>t</code> is the variable.   If <code>a=0s</code> and <code>b=0.0</code>, then the cost is always <code>0</code>(zero).    Examples: <code>0s + 2.5t</code>, <code>10m + 0 x</code> and <code>1h5m59s + 9.9t</code>    The <code>constant</code> must be 0 or a positive number(seconds) or a duration.   The <code>coefficient</code> must be in range: [0.0, 100.0] <code>map</code> List of key/value pairs, where the key is a string and the value can be any given type. <code>{ \"one\": 1.2, \"two\": 2.3 }</code> <code>object</code> Config object containing nested elements <code>\"walk\": { \"speed\": 1.3, \"reluctance\": 5 }</code> <code>array</code> Config object containing an array/list of elements <code>\"array\": [ 1, 2, 3 ]</code>"},{"location":"Configuration/#system-environment-and-project-information-substitution","title":"System environment and project information substitution","text":"<p>OTP supports injecting system environment variables and project information parameters into the configuration. A pattern like <code>${VAR_NAME}</code> in a configuration file is substituted with an environment variable with name <code>VAR_NAME</code>. The substitution is done BEFORE the JSON is parsed, so both json keys and values are subject to substitution. This is useful if you want OTPs version number to be part of the graph-file-name, or you want to inject credentials in a cloud based deployment.</p> <pre><code>{\n    \"gsCredentials\": \"${GCS_SERVICE_CREDENTIALS}\",\n    \"graph\": \"file:///var/otp/graph-${otp.serialization.version.id}.obj\"\n}\n</code></pre> <p>In the example above the environment variable <code>GCS_SERVICE_CREDENTIALS</code> on the local machine where OTP is deployed is injected into the config. Also, the OTP serialization version id is injected.</p> <p>The project information variables available are:</p> <ul> <li><code>maven.version</code></li> <li><code>maven.version.short</code></li> <li><code>maven.version.major</code></li> <li><code>maven.version.minor</code></li> <li><code>maven.version.patch</code></li> <li><code>maven.version.qualifier</code></li> <li><code>git.branch</code></li> <li><code>git.commit</code></li> <li><code>git.commit.timestamp</code></li> <li><code>graph.file.header</code></li> <li><code>otp.serialization.version.id</code></li> </ul>"},{"location":"Configuration/#config-version","title":"Config version","text":"<p>All three configuration files have an optional <code>configVersion</code> property. The property can be used to version the configuration in a deployment pipeline. The <code>configVersion</code> is not used by OTP in any way, but is logged at startup and is available as part of the server-info data in the REST API. The intended usage is to be able to check which version of the configuration the graph was build with and which version the router uses. In an deployment with many OTP instances it can be useful to ask an instance about the version, instead of tracking the deployment pipeline backwards to find the version used. How you inject a version into the configuration file is up to you, but you can do it in your build-pipeline, at deployment time or use system environment variable substitution.</p>"},{"location":"Configuration/#otp-serialization-version-id-and-graphobj-file-header","title":"OTP Serialization version id and Graph.obj file header","text":"<p>OTP has a OTP Serialization Version Id maintained in the pom.xml_ file. OTP stores the id in the serialized Graph.obj file header, allowing OTP to check for compatibility issues when loading the graph. The header info is available to configuration substitution:</p> <ul> <li><code>${graph.file.header}</code> Will expand to: <code>OpenTripPlannerGraph;0000007;</code></li> <li><code>${otp.serialization.version.id}</code> Will expand to: <code>7</code></li> </ul> <p>The intended usage is to be able to have a graph build pipeline that \"knows\" the matching graph and OTP planner instance. For example, you may build new graphs for every OTP serialization version id in use by the planning OTP instances you have deployed and plan to deploy. This way you can roll forward and backward new OTP instances without worrying about building new graphs.</p> <p>There are various ways to access this information. To get the <code>Graph.obj</code> serialization version id you can run the following bash command:</p> <ul> <li><code>head -c 29 Graph.obj ==&gt;  OpenTripPlannerGraph;0000007;</code> (file header)</li> <li><code>head -c 28 Graph.obj | tail -c 7 ==&gt;  0000007</code>  (version id)</li> </ul> <p>The Maven pom.xml, the META-INF/MANIFEST.MF, the OTP command line(<code>--serializationVersionId</code>),  log start-up messages and all OTP APIs can be used to get the OTP Serialization Version Id.</p>"},{"location":"Configuration/#include-file-directive","title":"Include file directive","text":"<p>It is possible to inject the contents of another file into a configuration file. This makes it possible to keep parts of the configuration in separate files. To include the contents of a file, use <code>${includeFile:FILE_NAME}</code>. The <code>FILE_NAME</code> must be the name of a file in the configuration directory. Relative paths are not supported.</p> <p>To allow both files (the configuration file and the injected file) to be valid JSON files, a special case is supported. If the include file directive is quoted, then the quotes are removed, if the  text inserted is valid JSON (starts with <code>{</code> and ends with <code>}</code>). </p> <p>Variable substitution is performed on configuration file after the include file directive; Hence variable substitution is also performed on the text in the injected file.</p> <p>Here is an example including variable substitution, assuming version 2.4.0 of OTP:</p> <pre><code>// build-config.json\n{\n  \"transitFeeds\" : \"${includeFile:transit.json}\"\n} \n</code></pre> <pre><code>// transit.json\n[\n  {\n  \"source\": \"netex-v${maven.version.short}.obj\"\n}\n]\n</code></pre> <p>The result will look like this:</p> <pre><code>{\n      \"transitFeeds\": [\n        {\n          \"source\": \"netex-v2.4.0.obj\"\n        }\n      ]\n} \n</code></pre>"},{"location":"Configuration/#system-wide-configuration","title":"System-wide Configuration","text":"<p>Using the file <code>otp-config.json</code> you can enable or disable different APIs and experimental Sandbox Extensions. By default, all supported APIs are enabled and all sandbox features are disabled. So for most OTP2 use cases it is not necessary to create this file. Features that can be toggled in this file are generally only affect the routing phase of OTP2 usage, but for consistency all such \"feature flags\", even those that would affect graph building, are managed in this one file. </p>"},{"location":"Configuration/#otp-features","title":"OTP Features","text":"<p>Here is a list of all features which can be toggled on/off and their default values.</p> Feature Description Enabled by default Sandbox <code>APIBikeRental</code> Enable the bike rental endpoint. \u2713\ufe0f <code>APIServerInfo</code> Enable the server info endpoint. \u2713\ufe0f <code>APIUpdaterStatus</code> Enable endpoint for graph updaters status. \u2713\ufe0f <code>ConsiderPatternsForDirectTransfers</code> Enable limiting transfers so that there is only a single transfer to each pattern. \u2713\ufe0f <code>DebugUi</code> Enable the debug GraphQL client and web UI and located at the root of the web server as well as the debug map tiles it uses. Be aware that the map tiles are not a stable API and can change without notice. Use the vector tiles feature if you want a stable map tiles API. \u2713\ufe0f <code>FloatingBike</code> Enable floating bike routing. \u2713\ufe0f <code>GtfsGraphQlApi</code> Enable the GTFS GraphQL API. \u2713\ufe0f <code>GtfsGraphQlApiRentalStationFuzzyMatching</code> Does vehicleRentalStation query also allow ids that are not feed scoped. <code>MinimumTransferTimeIsDefinitive</code> If the minimum transfer time is a lower bound (default) or the definitive time for the transfer. Set this to <code>true</code> if you want to set a transfer time lower than what OTP derives from OSM data. <code>OptimizeTransfers</code> OTP will inspect all itineraries found and optimize where (which stops) the transfer will happen. Waiting time, priority and guaranteed transfers are taken into account. \u2713\ufe0f <code>ParallelRouting</code> Enable performing parts of the trip planning in parallel. <code>TransferConstraints</code> Enforce transfers to happen according to the transfers.txt (GTFS) and Interchanges (NeTEx). Turning this off will increase the routing performance a little. \u2713\ufe0f <code>TransmodelGraphQlApi</code> Enable the Transmodel (NeTEx) GraphQL API. \u2713\ufe0f \u2713\ufe0f <code>ActuatorAPI</code> Endpoint for actuators (service health status). \u2713\ufe0f <code>AsyncGraphQLFetchers</code> Whether the @async annotation in the GraphQL schema should lead to the fetch being executed asynchronously. This allows batch or alias queries to run in parallel at the cost of consuming extra threads. <code>Co2Emissions</code> Enable the emissions sandbox module. \u2713\ufe0f <code>DataOverlay</code> Enable usage of data overlay when calculating costs for the street network. \u2713\ufe0f <code>FaresV2</code> Enable import of GTFS-Fares v2 data. \u2713\ufe0f <code>FlexRouting</code> Enable FLEX routing. \u2713\ufe0f <code>GoogleCloudStorage</code> Enable Google Cloud Storage integration. \u2713\ufe0f <code>LegacyRestApi</code> Enable legacy REST API. This API will be removed in the future. \u2713\ufe0f \u2713\ufe0f <code>RealtimeResolver</code> When routing with ignoreRealtimeUpdates=true, add an extra step which populates results with real-time data \u2713\ufe0f <code>ReportApi</code> Enable the report API. \u2713\ufe0f <code>RestAPIPassInDefaultConfigAsJson</code> Enable a default RouteRequest to be passed in as JSON on the REST API - FOR DEBUGGING ONLY! <code>SandboxAPIGeocoder</code> Enable the Geocoder API. \u2713\ufe0f <code>SandboxAPIMapboxVectorTilesApi</code> Enable Mapbox vector tiles API. \u2713\ufe0f <code>SandboxAPIParkAndRideApi</code> Enable park-and-ride endpoint. \u2713\ufe0f <code>SandboxAPITravelTime</code> Enable the isochrone/travel time surface API. \u2713\ufe0f <code>TransferAnalyzer</code> Analyze transfers during graph build. \u2713\ufe0f <code>VehicleToStopHeuristics</code> Enable improved heuristic for park-and-ride queries. \u2713\ufe0f <p>Example</p> <pre><code>// otp-config.json\n{\n    \"otpFeatures\" : {\n        \"APIBikeRental\" : false,\n        \"ActuatorAPI\" : true\n    }\n}\n</code></pre>"},{"location":"Configuration/#jvm-configuration","title":"JVM configuration","text":"<p>This section contains general recommendations for tuning the JVM in a production environment. It focuses mainly on garbage collection configuration and memory settings. See Garbage Collector Tuning for general information on garbage collection. See Large Pages in Java and  Transparent Huge Pages for general information on large memory pages.</p>"},{"location":"Configuration/#otp-server","title":"OTP server","text":"<p>The OTP server processes concurrent routing requests in real time. The main optimization goal for the OTP server is minimizing response time.</p>"},{"location":"Configuration/#garbage-collector","title":"Garbage collector","text":"<ul> <li>The G1 garbage collector (default since Java 9) offers a good compromise between low latency (i.e. low GC pause time) and GC overhead.</li> <li>If latency spikes are an issue, the ZGC garbage collector is an alternative. It produces in general more overhead than G1.  </li> </ul>"},{"location":"Configuration/#memory-settings","title":"Memory settings","text":"<ul> <li>Using Large Memory Pages can reduce pressure on the TLB cache and increase performance.  </li> <li>It is in general not recommended to use large memory page in Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>) for latency-sensitive applications, since memory is allocated on-demand and this can induce latency spikes if the memory is fragmented.   Thus TLBFS mode (<code>-XX:+UseHugeTLBFS</code>) should be the first choice.</li> <li>If TLBFS mode is not an option,  Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>) can be used instead, with additional provisions to mitigate the risk of latency spikes: The physical memory can be committed upfront, at JVM startup time. This can be done by forcing a fixed heap size and pre-touching the memory. Example: <code>-Xms18g -Xmx18g -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch</code> </li> </ul>"},{"location":"Configuration/#graph-builder","title":"Graph Builder","text":"<p>The Graph Builder is the non-interactive mode used to build street graphs and transit graphs.    The main optimization goal for the Graph Builder is minimizing total build time.  </p>"},{"location":"Configuration/#garbage-collector_1","title":"Garbage collector","text":"<ul> <li>In theory, the Parallel garbage collector offers the best throughput. In practice, it can be challenging to optimize the Parallel GC to build both a street graph and a transit graph, the memory usage patterns being different. </li> <li>The G1 garbage collector provides in general a good compromise.  </li> </ul>"},{"location":"Configuration/#memory-settings_1","title":"Memory settings","text":"<ul> <li>Using Large Memory Pages can reduce pressure on the TLB cache and increase performance.  </li> <li>Since latency is not an issue, Large Memory Pages can be used indifferently in TLBFS mode (<code>-XX:+UseHugeTLBFS</code>) or Transparent Huge Page mode (<code>-XX:+UseTransparentHugePages</code>)</li> </ul>"},{"location":"Container-Image/","title":"Container image","text":"<p>The CI pipeline deploys container images for runtimes like Docker, Kubernetes or Podman to  Dockerhub.</p> <p>The image assumes you use a volume to mount the input data (GTFS/NeTex, OSM) and config files into  <code>/var/opentripplanner/</code>. When serving a graph it's also expected to be in this directory.</p>"},{"location":"Container-Image/#quick-start","title":"Quick start","text":"<p>Let's use the image to build a graph in Berlin.</p> <pre><code># create directory for data and config\nmkdir berlin\n# download OSM\ncurl -L https://download.geofabrik.de/europe/germany/berlin-latest.osm.pbf -o berlin/osm.pbf  \n# download GTFS\ncurl -L https://vbb.de/vbbgtfs -o berlin/vbb-gtfs.zip\n# build graph and save it onto the host system via the volume\ndocker run --rm -v \"$(pwd)/berlin:/var/opentripplanner\" docker.io/opentripplanner/opentripplanner:latest --build --save \n# load and serve graph\ndocker run -it --rm -p 8080:8080 -v \"$(pwd)/berlin:/var/opentripplanner\" docker.io/opentripplanner/opentripplanner:latest --load --serve\n</code></pre> <p>Now open http://localhost:8080 to see your running OTP instance.</p>"},{"location":"Container-Image/#additional-notes","title":"Additional notes","text":"<p>Make sure to include the word \"gtfs\" when naming the gtfs files that you want to use for OTP. Otherwise, graph build will fail.</p> <p>If you want to set JVM options you can use the environment variable <code>JAVA_TOOL_OPTIONS</code>, so a full example to add to your docker command is <code>-e JAVA_TOOL_OPTIONS='-Xmx4g'</code>. </p>"},{"location":"Data-Sources/","title":"Data Sources","text":""},{"location":"Data-Sources/#input-formats","title":"Input Formats","text":"<p>At the core of OpenTripPlanner is a library of Java code that finds efficient paths through multi-modal transportation networks built from OpenStreetMap and GTFS data. It can also receive GTFS-RT (real-time) data.</p> <p>In addition to GTFS, OTP can also load data in the Nordic Profile of Netex, the EU-standard transit data interchange format. The upcoming EU-wide profile was heavily influenced by the Nordic Profile and uses the same schema, so eventual support for the full EU profile is a possibility.</p> <p>GTFS and Netex data are converted into OTP's own internal model which is a superset of both. It is therefore possible to mix Netex and GTFS data, and potentially even data from other sources.</p>"},{"location":"Deployments/","title":"OpenTripPlanner Deployments Worldwide","text":""},{"location":"Deployments/#official-production","title":"Official Production","text":"<p>The following are known deployments of OTP in a government- or agency-sponsored production capacity:</p> <ul> <li>Norway (nationwide) Since November 2017, the national integrated ticketing agency Entur has   prodvided a national journey planner which consumes schedule data in the EU   standard NeTEx format with SIRI real-time updates. Entur has contributed greatly to the OTP2 effort   and primarily uses OTP2 in production, handling peak loads in excess of 20 requests per second.    Most regional agencies in Norway, like Ruter, Oslo area uses OTP as a service provided by Entur.</li> <li>Finland (nationwide) The Helsinki Regional Transport Authority,   the Finnish Transport Agency, and   other Finnish cities have collaborated to   create Digitransit, providing OTP-based trip planners, APIs, open   data, Docker containers and open source code. Each member organisation runs its own instance of a   shared codebase and deployment environment. Their source code is   available on Github, including   a new custom UI. This system also has a strong   real-time component.</li> <li>Finland Intercity The Finnish intercity coach   service Matkahuolto   has developed a trip planner in partnership with Kyyti.</li> <li>Sk\u00e5ne, Sweden, the JourneyPlanner and mobile app for the regional transit agency Sk\u00e5netrafiken   uses OTP2 with the nordic profile of NeTEx and SIRI for real-time updates.</li> <li>Northern Colorado</li> <li>Philadelphia and surrounding areas</li> <li>Portland, Oregon TriMet is the agency that originally started the OpenTripPlanner project.   Their Regional Trip Planner is based on OTP and provides about 40,000   trip plans on a typical weekday.</li> <li>New York City</li> <li>New York State The State Department of   Transportation's transit trip planner provides itineraries   for public transit systems throughout the state in a single unified OTP instance.</li> <li>Los Angeles, California The new metro.net trip planner.</li> <li>Atlanta, Georgia The Metropolitan Atlanta Rapid Transit Authority's (   MARTA) trip planner and the Atlanta region's transit   information hub https://atlrides.com/ both use OTP to power their website trip   planners.</li> <li>Boston, Massachusetts   The Massachusetts Bay Transportation Authority trip planner.</li> <li>Seattle, Washington The Sound Transit Trip Planner   is based on OTP. OTP also powers the trip planning feature of   the OneBusAway native apps in the Puget Sound region. Technical details   are here   .</li> <li>Ride Metro Houston</li> <li>Tampa, Florida Hillsoborough Area Regional Transit uses an OpenTripPlanner server to power the   trip planning feature of the OneBusAway native apps in their region.   Technical details   are here   .</li> <li>Piemonte Region, Italy and the City of   Torino built on OpenTripPlanner   by 5T.</li> <li>Valencia, Spain from the Municipal   Transport Company of Valencia S.A.U.</li> <li>Grenoble, France from SMTC, Grenoble Alpes m\u00e9tropole, l'\u00c9tat   Fran\u00e7ais, the Rh\u00f4ne-alpes region, the Is\u00e8re council and the City of Grenoble.</li> <li>Rennes, France where the STAR network provides an OTP client   for iOS   , Android, Windows Phone   et Web.</li> <li>Alen\u00e7on, France integrated urban and school bus   network planner from R\u00e9unir Alen\u00e7on.</li> <li>Pozna\u0144, Poland from Urban Transport Authority of Pozna\u0144 (ZTM   Poznan).</li> <li>Trento Province, Italy</li> <li>ViaggiaTrento   and ViaggiaRovereto   were implemented as part of the SmartCampus Project, a research   project founded by TrentoRise, UNITN,   and FBK.</li> <li>University of South Florida (Tampa, Florida). The USF Maps App is a   responsive web application for that helps university students, staff, and visitors find their way   around the campus using multiple modes of transportation, including the USF Bull Runner campus   shuttle, Share-A-Bull bike share, and pedestrian pathways.   Open-sourced on Github.</li> <li>Lower Saxony, Germany The VBN transportation authority offers an OTP instance as alternative to the Hafas passenger information system.</li> <li>Leipzig, Germany As of summer 2020 Leipzig Move has been using   OpenTripPlanner.</li> </ul>"},{"location":"Deployments/#independent-production","title":"Independent Production","text":"<p>The following OTP-based services are presented as production-quality deployments, but are not backed by an official transportation authority or government. OTP is also known to be used on the back end of several popular multi-city mobile trip planning applications.</p> <ul> <li>The Netherlands (nationwide) Plannerstack Foundation provides   national scale trip planning APIs using OTP and other open source trip planners, based   on OpenOV's extremely detailed open data including minutely real-time   updates for every vehicle in the country.</li> <li>OTP Android   by CUTR-USF and Vreixo Gonz\u00e1lez can find itineraries on many different OTP servers via a service   discovery mechanism.</li> <li>ViviBus Bologna Bologna, Italy.</li> </ul>"},{"location":"Developers-Guide/","title":"Developers Guide","text":""},{"location":"Developers-Guide/#quick-setup","title":"Quick setup","text":"<p>A Quick guide to setting up the OpenTripPlanner project.</p> <p>You need Git, Maven and Java(JDK) and an IDE installed on your computer. Your IDE might have JDK and Maven embedded, if so you may skip step 3.</p> <ol> <li>Clone OpenTripPlanner from GitHub.</li> <li>Checkout the desired branch <code>git checkout dev-2.x</code></li> <li>Run <code>mvn package</code>- this will download all dependencies, build the project and run tests.</li> <li>Open the project in your IDE.</li> </ol>"},{"location":"Developers-Guide/#working-on-otp-in-an-ide","title":"Working on OTP in an IDE","text":"<p>Most people writing or modifying OTP code use an Integrated Development Environment (IDE). Some of the most popular IDEs for Java development are IntelliJ IDEA, Eclipse, and NetBeans. All three of these environments are good for working on OTP. IntelliJ is used by most OTP developers, and the only IDE we support with a code style formatter. You may choose another IDE, but Maven and Git integration is a plus since OTP is under Git version control and build with Maven.</p> <p>Many of the Core OTP developers use IntelliJ IDEA. It is an excellent IDE, and in my experience is quicker and more stable than the competition. IntelliJ IDEA is a commercial product, but there is an open source \"community edition\" that is completely sufficient for working on OTP.</p> <p>Rather than using the version control support in my IDE, I usually find it more straightforward to clone the OTP GitHub repository manually (on the command line or using some other Git interface tool), then import the resulting local OTP repository into my IDE as a Maven project. The IDE should then take care of fetching all the libraries OTP depends on, based on the Maven project description (POM file) in the base of the OTP repository. This step can take a long time because it involves downloading a lot of JAR files.</p> <p>When running your local copy of the OTP source within an IDE, all command line switches and configuration options will be identical to the ones used when running the OTP JAR from the command line (as described in the OpenTripPlanner Basic Tutorial and configuration reference). The only difference is that you need to manually specify the main class. When you run a JAR from the command line, the JVM automatically knows which class contains the entry point into the program (the <code>main</code> function), but in IDEs you must create a \"run configuration\".</p> <p>Both IntelliJ and Eclipse have \"run\" menus, from which you can select an option to edit the run configurations. You want to create a configuration for a Java Application, specifying the main class <code>org.opentripplanner.standalone.OTPMain</code>. Unlike on the command line, the arguments to the JVM and to the main class you are running are specified separately. In the field for the VM options you'll want to put your maximum memory parameter (<code>-Xmx2G</code>, or whatever limit you want to place on JVM memory usage). The rest of the parameters to OTP itself will go in a different field with a name like \"program arguments\".</p>"},{"location":"Developers-Guide/#contributing-to-the-project","title":"Contributing to the project","text":"<p>OpenTripPlanner is a community based open source project, and we welcome all who wish to contribute. There are several ways to get involved:</p> <ul> <li> <p>Join the Gitter chat room and the    user mailing list.</p> </li> <li> <p>Fix typos and improve the documentation within the <code>/docs</code> directory of the project (details   below).</p> </li> <li> <p>File a bug or new feature request.</p> </li> <li> <p>Create pull requests citing the relevant issue.</p> </li> <li> <p>Join developer meetings hosted twice a week. Check the specific times and URLs    on this page</p> </li> </ul>"},{"location":"Developers-Guide/#branches-and-branch-protection","title":"Branches and Branch Protection","text":"<p>As of August 2022, we work on OTP 2.x and are using a Git branching model derived from  Gitflow. All development will occur on the <code>dev-2.x</code> branch. Only release commits setting the Maven artifact version to a non-snapshot number should be pushed to the <code>master</code> branch of OTP. All other changes to master should result  from fast-forward merges of a Github pull request from the <code>dev-2.x</code> branch. In turn, all changes  to <code>dev-2.x</code> should result from a fast-forward merge of a Github pull request for a single feature,  fix, or other change. These pull requests are subject to code review. We require two pull request  approvals from developers part of the OTP Review Team. These developers act on behalf of the  leadership committee members. The reviewers should be from two different organizations. We also  have validation rules ensuring that the code compiles and all tests pass before pull requests can  be merged.</p> <p>The <code>dev-1.x</code> exist for patching OTP version 1.x, but with few people to do the reviews, very few PRs are accepted. We recommend getting in touch with the community before you spend time on making  a PR.</p>"},{"location":"Developers-Guide/#issues","title":"Issues","text":"<p>If no ticket exists for the feature or bug your code implements or fixes, you should create a new ticket prior to checking in, or ideally even prior to your development work since this provides a place to carry out implementation discussions (in the comments). The created issue should be referenced in a pull request. For really minor and uncontroversial pull requests, it is ok to not create an issue.</p>"},{"location":"Developers-Guide/#unit-tests-using-real-osm-data","title":"Unit tests using real OSM data","text":"<p>Sometimes it is useful to build a graph from actual OSM or GTFS data. Since building these graphs in a test can be quite slow they will be accepted in pull requests only if they conform to certain standards:</p> <ol> <li> <p>Use the smallest possible regional extract - the OSM file should not contain more than a few    hundred ways. Use <code>osmium-extract</code> to cut down a larger OSM file into a tiny subset of it.</p> </li> <li> <p>Strip out any unneeded information by using the <code>osmium filter-tags</code> as describe    in Preparing OSM</p> </li> </ol>"},{"location":"Developers-Guide/#code-comments","title":"Code Comments","text":"<p>As a matter of policy, all new methods, classes, and fields should include comments explaining what they are for and any other pertinent information. For Java code, the comments should use the JavaDoc conventions. It is best to provide comments that not only explain what you did but also why you did it while providing some context. Please avoid including trivial Javadoc or the empty Javadoc stubs added by IDEs, such as <code>@param</code> annotations with no description.</p>"},{"location":"Developers-Guide/#itinerary-and-api-snapshot-tests","title":"Itinerary and API Snapshot Tests","text":"<p>To test the itinerary generation, and the API there are snapshot test which save the result of the requests as <code>*.snap</code> JSON-like files. These are stored in git so that it is possible to compare to the expected result when running the tests.</p> <p>If the snapshots need to be recreated than running <code>mvn clean -Pclean-test-snapshots</code> will remove the existing <code>*.snap</code> files so that the next time the tests are run the snapshots will be recreated. The updated files may be committed after checking that the changes in the files are expected.</p>"},{"location":"Developers-Guide/#documentation","title":"Documentation","text":"<p>OTP documentation is included directly in the OpenTripPlanner repository. This allows version control to be applied to documentation as well as program source code. All pull requests that change how OTP is used or configured should include changes to the documentation alongside code modifications.</p> <p>The documentation files are in Markdown format and are in the <code>/docs</code> directory under the root of the project. On every push to the <code>dev-2.x</code> branch the documentation will be rebuilt and deployed as static pages to our subdomain of Github Pages.  MkDocs is a Python program and should run on any major platform.  See http://www.mkdocs.org/ for information on how to install it and  how to generate a live local preview of the documentation while you're writing it.</p> <p>In short:</p> <pre><code>$ pip install -r docs/requirements.txt\n$ mkdocs serve\n</code></pre> <p>The OTP GTFS GraphQL API documentation is available online at </p> <p>https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/</p> <p>You can also use the interactive GraphQL API client that is built into every instance at</p> <p>http://localhost:8080/graphiql</p>"},{"location":"Developers-Guide/#debug-layers","title":"Debug layers","text":"<p>Adding new renderer is very easy. You just need to create new class (preferably in <code>org.opentripplanner.inspector</code> package) which implements EdgeVertexRenderer. It is best if class name ends with Rendered. To implement this interface you need to write three functions <code>renderEdge</code>, <code>renderVertex</code> and <code>getName</code>. Both render functions accepts <code>EdgeVisualAttributes</code> object in which label of edge/vertex and color can be set. And both return <code>true</code> if edge/vertex should be rendered and <code>false</code> otherwise. <code>getName</code> function should return short descriptive name of the class and will be shown in layer chooser.</p> <p>For examples how to write renderers you can look into example renderers which are all in <code>org.opentripplanner.inspector</code> package.</p> <p>After your class is written you only need to add it to TileRenderManager:</p> <pre><code>//This is how Wheelchair renderer is added\nrenderers.put(\"wheelchair\", new EdgeVertexTileRenderer(new WheelchairEdgeRenderer()));\n</code></pre> <p><code>wheelchair</code> is internal layer key and should consist of a-zA-Z and -.</p> <p>By default all the tiles have cache headers to cache them for one hour. This can become problematic if you are changing renderers a lot. To disable this change <code>GraphInspectorTileResource</code>:</p> <pre><code>//This lines\nCacheControl cc = new CacheControl();\ncc.setMaxAge(3600);\ncc.setNoCache(false);\n\n//to this:\nCacheControl cc = new CacheControl();\ncc.setNoCache(true);\n</code></pre>"},{"location":"Developers-Guide/#date-format","title":"Date format","text":"<p>Please use only ISO 8601 date format (YYYY-MM-DD) in documentation, comments, and throughout the project. This avoids the ambiguity that can result from differing local interpretations of date formats like 02/01/12.</p>"},{"location":"Developers-Guide/#code-style","title":"Code style","text":"<p>The OTP code style is described on a separate style guide page.</p>"},{"location":"Developers-Guide/#code-conventions-and-architecture","title":"Code conventions and architecture","text":"<p>The architecture  and code conventions are only available on GitHub, not in the project documentation. These documents contain relative  links to code so, they are a bit easier to maintain that way. The target audience is also active  OTP developers that have the code checked out locally.</p>"},{"location":"Developers-Guide/#continuous-integration","title":"Continuous Integration","text":"<p>The OpenTripPlanner project uses the Github actions continuous integration system . Any time a change is pushed to the main OpenTripPlanner repository on GitHub or to an open pull request, Github actions will compile and test the new code, providing feedback on the stability of the build.</p>"},{"location":"Developers-Guide/#changelog-workflow","title":"Changelog workflow","text":"<p>The changelog file is generated from the pull-request(PR) title using the changelog workflow . The workflow runs after the PR is merged, and it changes, commits and pushes the Changelog.md. A secret personal access token is used to bypass the \"Require PR with 2 approvals\" rule. To exclude a PR from the changelog add the label <code>skip changelog</code> to the PR.</p>"},{"location":"Developers-Guide/#how-to-update-the-changelog_token","title":"How-to update the CHANGELOG_TOKEN","text":"<p>The <code>CHANGELOG_TOKEN</code> is used by the changelog workflow. It contains a Personal Access Token. The token must be generated by a Repository Owner and have the following rights (Settings / Developer settings / Personal access tokens):</p> <p></p>"},{"location":"Developers-Guide/#release-process","title":"Release Process","text":"<p>New releases can be found on GitHub.  Releases are performed off the master branch, and are tagged with git annotated tags.</p> <p>OpenTripPlanner is currently configured such that builds including releases upload JAR files to GitHub Packages. This is not the most convenient place for end users to find and download the files. Therefore we also attach a stand-alone \"shaded\" JAR to the GitHub tag/release page, and have historically also uploaded Maven artifacts to Maven Central including compiled and source code JARs as well as the \"shaded\" JAR containing all dependencies, allowing stand-alone usage. This release process is handled by the Sonatype Nexus Staging plugin, which is no longer configured in the OpenTripPlanner POM. This step currently requires making a few significant manual modifications to the POM.</p> <p>We no longer trigger deployment of artifacts to Maven Central or deployment of REST API documentation to AWS automatically in our build scripts (GitHub Actions). These steps are prone to failure and require storing a lot of infrequently used secret information in the repo and environment variables on GitHub. Our releases are currently not very frequent so we just carry out these steps manually by following the checklist. We aim to make a release every 6 months.</p> <p>Use the Release Checklist to perform the release.</p>"},{"location":"Getting-OTP/","title":"Getting OpenTripPlanner","text":""},{"location":"Getting-OTP/#pre-built-jars","title":"Pre-built JARs","text":"<p>OpenTripPlanner is distributed as a single stand-alone runnable JAR file. We create a tag and release page on GitHub for each release version, and also deploy them to the Maven Central repository. You can go to the release pages on GitHub or the OTP directory at Maven Central, navigate to the highest version number, and download the file whose name ends with <code>shaded.jar</code>.</p> <p>Note that version numbers like <code>v2.1.0-rc1</code> or <code>v2.4.0-SNAPSHOT</code> refer to development builds _ before_ the release version <code>v2.4.0</code>. The existence of a build <code>vX.Y.Z-SNAPSHOT</code> does not mean that <code>vX.Y.Z</code> has been released yet.</p> <p>We use the Github Actions CI system to build OTP every time a change is made. You can find the JARs resulting from those builds in the Github Packages repository . It can be harder to find the specific version you're looking for here, so we recommend using the release pages or Maven Central as described above.</p>"},{"location":"Getting-OTP/#building-from-source","title":"Building from Source","text":"<p>You may also choose to build OTP from its source code. If you will be modifying OTP you will need to know how to rebuild it (though your IDE may take care of this build cycle for you). If you have the right software installed, building OTP locally from its source code is not particularly difficult. You should only need the following software:</p> <ul> <li> <p>Git, a version control system</p> </li> <li> <p>Java Development Kit, preferably version 21</p> </li> <li> <p>Maven, a build and dependency management system</p> </li> </ul> <p>You will also need a reliable internet connection so Maven can fetch all of OTP's dependencies (the libraries it uses).</p> <p>Once you have these packages installed, create and/or switch to the directory where you will keep your Git repositories and make a local copy of the OTP source code:</p> <pre><code>mkdir git\ncd git\ngit clone git@github.com:opentripplanner/OpenTripPlanner.git\n</code></pre> <p>Then change to the newly cloned OpenTripPlanner repository directory and start a build:</p> <pre><code>cd OpenTripPlanner\nmvn clean package\n</code></pre> <p>Maven should then be able to download all the libraries and other dependencies necessary to compile OTP. If all goes well you should see a success message like the following:</p> <pre><code>[INFO] ------------------------------------------------------------------------\n[INFO] BUILD SUCCESS\n[INFO] ------------------------------------------------------------------------\n[INFO] Total time: 42.164s\n[INFO] Finished at: Tue Feb 18 19:35:48 CET 2014\n[INFO] Final Memory: 88M/695M\n[INFO] ------------------------------------------------------------------------\n</code></pre> <p>This build process should produce a JAR file called <code>otp-x.y.z-shaded.jar</code> in the <code>target/</code> directory which contains all the compiled OTP classes and their dependencies (the external libraries they use). The shell script called 'otp' in the root of the cloned repository will start the main class of that JAR file under a Java virtual machine, so after the Maven build completes you should be able to run <code>./otp --help</code> and see an OTP help message including command line options. Due to the way Maven works, this script is not executable by default, so you will need to do <code>chmod u+x ./otp</code> before you run it to mark it as executable.</p> <p>The words \"clean package\" are the build steps you want to run. You're telling maven to clean up any extraneous junk in the directory, then perform all the build steps, including compilation, up to and including \"package\", which bundles the compiled program into a single JAR file for distribution.</p> <p>If you have just cloned OTP you will be working with the default \"master\" branch, where most active development occurs. This is not the most stable or deployment-ready code available. To avoid newly minted bugs or undocumented behavior, you can use Git to check out a specific release (tag or branch) of OTP to work with. The Maven build also includes many time-consuming integration tests. When working with a stable release of OTP, you may want to turn them off by adding the switch: <code>-DskipTests</code>.</p> <p>For example, you could do the following:</p> <pre><code>cd OpenTripPlanner\ngit checkout v2.4.0\ngit clean -df\nmvn clean package -DskipTests\n</code></pre> <p>Please note that the build process creates two distinct versions of the OTP JAR file. The one ending in <code>-shaded.jar</code> is much bigger because it contains copies of all the external libraries that OTP uses. It serves as a stand-alone runnable distribution of OTP. The one with a version number but without the word <code>shaded</code> contains only OTP itself, without any external dependencies. This JAR is useful when OTP is included as a component in some other project, where we want the dependency management system to gather all the external libraries automatically.</p>"},{"location":"Getting-OTP/#maven-repository","title":"Maven Repository","text":"<p>OpenTripPlanner is a Maven project. Maven is a combined build and dependency management system: it fetches all the external libraries that OTP uses, runs all the commands to compile the OTP source code into runnable form, performs tests, and can then deploy the final \"artifact\" (the runnable JAR file) to the Maven repository, from which it can be automatically included in other Java projects.</p> <p>This repository is machine-readable (by Maven or other build systems) and also provides human readable directory listings via HTTP. You can fetch an OTP JAR from this repository by constructing the proper URL for the release you want. For example, release 2.4.0 will be found at <code>https://repo1.maven.org/maven2/org/opentripplanner/otp/2.4.0/otp-2.4.0-shaded.jar</code>.</p> <p>To make use of OTP in another Maven project, you must specify it as a dependency in that project's <code>pom.xml</code>:</p> <pre><code>&lt;dependency&gt;\n  &lt;groupId&gt;org.opentripplanner&lt;/groupId&gt;\n  &lt;artifactId&gt;otp&lt;/artifactId&gt;\n  &lt;version&gt;2.4.0&lt;/version&gt;\n&lt;/dependency&gt;\n</code></pre>"},{"location":"Governance/","title":"Project Governance","text":"<p>OpenTripPlanner is a member project of the Software Freedom Conservancy. Development of OpenTripPlanner is managed by a Project Leadership Committee (PLC) which makes decisions by simple majority vote. The current members of this committee are (in alphabetical order):</p> Name Affiliation Sean Barbeau University of South Florida Sheldon Brown Cambridge Systematics Andrew Byrd Conveyal Thomas Craig CALACT ITS4US Drew Dara-Abrams Interline David Emory IBI Group Thomas Gran Entur (Norway) Tuukka Hastrup Transpordiamet (Estonia) Joel Lappalainan Digitransit (Finland) Frank Purcell TriMet (Portland, Oregon) David Turner ex-OpenPlans Anders Varmy Skanetrafiken Leonard Ehrenfried Independent contractor <p>The PLC holds a quarterly video conference on the first Tuesday of June, September, December, and March. An agenda is prepared as a collaborative document in advance of each quarterly meeting. These meetings are held at 8AM US Pacific time to accommodate members in the US Pacific, US Eastern, and Central European time zones.</p> <p>We take care to avoid a governance system that is too conceptual or process-heavy. The main goal is to have regular agenda-driven meetings that yield clear decisions and action items assigned to specific people. The committee should ideally be composed of active, professional contributors to the OpenTripPlanner project, including representatives of organizations that host official public deployments of OTP.</p> <p>We enfore a policy on the review and merging of new changes to the OTP system, guided by a roadmap maintained by the committee. All changes must be reviewed and approved by at least two people from two different organizations. The list of approved reviewers is the PLC Github group, visible here https://github.com/orgs/opentripplanner/teams/plc/members</p>"},{"location":"History/","title":"OpenTripPlanner Project History","text":""},{"location":"History/#opentripplanner-1","title":"OpenTripPlanner 1","text":"<p>OpenTripPlanner was seeded by Portland, Oregon's transit agency TriMet with a Regional Travel Options grant and opened with a 3-day Kick-Off Workshop in July of 2009 bringing together transit agencies and the authors of the major open source transit passenger information software of the day: David Emory of FivePoints, Brian Ferris of OneBusAway, and Brandon Martin-Anderson of Graphserver. From 2009 through 2012, development was coordinated by New York nonprofit OpenPlans. In 2011 a second workshop was held to mark the end of the first phase of development. TriMet's 2009-2011 OTP Final Report summarizes progress at that point.</p> <p>The project has since grown to encompass a global community of users and developers. By early 2013, OpenTripPlanner had become the primary trip planning software used by TriMet in the Portland regional trip planner and was backing several popular mobile applications. Public-facing OpenTripPlanner instances were available in at least ten countries throughout the world. At this point the OpenPlans transportation software team became the independent consultancy Conveyal. The original OpenTripPlanner development team from OpenPlans still actively participates in programming, design, and community coordination via the mailing list and their roles on the OTP Project Leadership Committee.</p> <p>In summer of 2013, the OpenTripPlanner project was accepted for membership in the Software Freedom Conservancy (SFC). SFC handles the legal and financial details common to many open source projects.</p> <p>In 2013-2014 OpenTripPlanner was a focal point in the Dutch Transport Ministry's Beter Benutten Multimodale Reisinformatie (Better Utilization: Multimodal Travel Information) project which encouraged investment in trip planning platforms and services. Five companies worked together to improve OpenTripPlanner performance in large regional transport networks and add support for streaming real-time data, making itineraries reflect service modifications and delays only seconds after vehicles report their positions. Another consortium embarked on a full rewrite of the trip planning core called RRRR (or R4), a proof of concept validating extremely efficient routing techniques and serving as an early prototype for OTP2.</p> <p>In the fall of 2014, Arlington, Virginia launched a new commute planning site for the Washington, DC metropolitan area, depending on OpenTripPlanner to weigh the costs and benefits of various travel options. In 2015 the New York State department of transportation's 511 transit trip planner began using OTP to provide itineraries for public transit systems throughout the state from a single unified OTP instance. Starting in early 2016, the regional transport authorities of Helsinki, Finland (HSL) and Oslo, Norway (Ruter) began using a completely open source passenger information system based on OpenTripPlanner. National-scale OpenTripPlanner instances were also created in Finland and Norway.</p> <p>After seven years of hard work and almost 10,000 commits from over 100 contributors around the world, OTP version 1.0 was released on 9 September 2016.</p>"},{"location":"History/#opentripplanner-2","title":"OpenTripPlanner 2","text":"<p>The OTP community has a long history with round-based routing algorithms. FivePoints, one of the predecessor projects to OTP, used a round-based method several years before the now-familiar Raptor algorithm was published in an influential paper . OpenPlans carried out experiments with routing innovations like Raptor and contraction hierarchies as they emerged in the academic literature. Research and development work on OTP scalability has focused on round-based tabular approaches since the MMRI pre-commercial procurement projects of 2013-2014. Conveyal built its high-performance transportation network analysis system around its R5 router. So in strategy discussions, the expected technical direction was clear.</p> <p>In the second quarter of 2018, Ruter and Entur took the lead on finally integrating a new round-based transit routing engine inspired by R5 into OTP. They also began adding support for importing EU-standard Netex data, making it possible for passenger information services in Europe to achieve regulatory compliance with a fully open source software stack. In June 2018, at the first OTP international summit hosted by Cambridge Systematics in Boston, the project leadership committee officially approved this roadmap toward OTP2.</p> <p>In April of 2019, the second OTP international summit was hosted by Entur in Oslo. Encouraged by the crowd of participants from across the Nordic countries and North America, work on OTP2 continued unabated through 2019, 2020, and 2021 with twice-weekly videoconferences bringing together software developers from across the world. Videos of the full April 2019 OTP summit and the October 2019 OTP webinar are available.</p> <p>OTP2 went into feature freeze in September 2020, and the 2.0 release occurred at the end of November 2020. OTP2 is now seeing production use for a subset of requests in several national-scale trip planners. The project leadership committee is exploring the creation of an OTP1 working group to ensure follow-up maintenance of the final version of OTP1.</p>"},{"location":"In-Station-Navigation/","title":"In-station navigation","text":"<p>OTP offers a variety of ways to produce precise walking instructions for walking inside a station or between transit stops.</p>"},{"location":"In-Station-Navigation/#osm-generated-navigation","title":"OSM generated navigation","text":"<p>In the most common case, the walking instructions for reaching a transit stop are generated from the available OSM data. For this reason it is important that the coordinate of the stop is as close as  possible to where the passenger is expected to wait for the vehicle, not where the vehicle will stop.</p> <p>It is therefore a good idea to place the stop coordinates at a bus shelter or railway platform rather than at the middle of the road or the railway tracks.</p> <p>Of course you also want the data in OSM as precise as possible: data for railway platforms, stairs, tunnels and other infrastructure help OTP to generate good walking instructions.</p>"},{"location":"In-Station-Navigation/#example-exiting-a-railway-platform","title":"Example: exiting a railway platform","text":"<p>The train arrives in a railway station in Stuttgart (green line), the passenger alights and is instructed (grey line) to walk along the platform, up the stairs and across a bridge to continue to  their final destination.</p> <p></p>"},{"location":"In-Station-Navigation/#boarding-locations","title":"Boarding locations","text":"<p>If your stop coordinates are not very well-placed, OTP may direct passengers to the wrong waiting location or offer incorrect transfer paths and time. As this a common problem and stop coordinates  can be hard to change due to upstream systems, OTP offers a  way to derive the waiting coordinates from OSM data.</p> <p>Even if your stop coordinates are good, some stations are underground and to get correct walking  instructions it's required to use this feature so that correct instructions for using entrances and stairs are generated.</p>"},{"location":"In-Station-Navigation/#example-walking-downstairs-to-underground-stations","title":"Example: walking downstairs to underground stations","text":"<p>This shows an underground subway station in Stuttgart which can only be reached by using entrances at either end walking down to the platform via a series of stairs and walkways. OTP can only generate these detailed instructions because the platform has a tag <code>ref:IFOPT</code> which identifies it in the German national stop register.</p> <p></p>"},{"location":"In-Station-Navigation/#gtfs-pathways","title":"GTFS pathways","text":"<p>If your GTFS input file contains pathways this will override the OSM-generated instructions. It is therefore important that the pathways contain as much precision as possible.</p> <p>One advantage that pathways offer is the possibility to add information like \"follow signs for X\" which OTP adds to the textual turn-by-turn instructions.</p>"},{"location":"In-Station-Navigation/#example-transferring-at-sudkreuz","title":"Example: Transferring at S\u00fcdkreuz","text":"<p>Here the pathways don't offer a lot of precision: In a railway hub in Berlin  there are suboptimal instructions on how to move from one platform to another because the pathways  only contain rudimentary information about how to move inside the station. (The red lines represent  train lines with the grey line showing the walking path.)</p> <p></p>"},{"location":"In-Station-Navigation/#transfers","title":"Transfers","text":"<p>The above precedence rules of </p> <ul> <li>GTFS pathways, if it exists</li> <li>then OSM data </li> </ul> <p>also apply when computing transfers from one stop to another.</p>"},{"location":"In-Station-Navigation/#example-transferring-from-tram-to-rail-at-oslo-central","title":"Example: transferring from tram to rail at Oslo Central","text":"<p>Here the passenger arrives in a local tram (blue line) near the main station in Oslo. They are  instructed (grey line) to walk into the station right onto the correct platform and leave on a long-distance train (red line).</p> <p></p>"},{"location":"In-Station-Navigation/#example-transferring-between-platforms-at-oslo-central","title":"Example: transferring between platforms at Oslo Central","text":"<p>This example instructs the passenger to get off a train, then walking down the stairs and via a tunnel to another platform.</p> <p></p>"},{"location":"In-Station-Navigation/#transfer-time","title":"Transfer time","text":"<p>The routing engine calculates the time to move from one stop to another by how long it thinks the walking takes based on the navigation instructions outlined above. So, if OTP thinks that it takes 5 minutes to walk from platform 1 to platform 8, then the routing algorithm will not suggest a transit connection that departs less than 5 minutes after arriving at platform 1.</p> <p>However, how fast the passenger is assumed to walk is controllable through the walk speed parameter. This can be configured per installation or passed as an API call parameter.</p> <p>The parameters <code>alightSlack</code>, <code>transferSlack</code>  and <code>boardSlack</code> also allow you to define extra buffer time for transferring.</p> <p>GTFS minimum transfer times  are also supported but generally not advised. It is preferable to micromap your stations and improve the stop coordinates rather than force specific transfer times by adding this data.</p>"},{"location":"In-Station-Navigation/#common-data-errors","title":"Common data errors","text":"<ul> <li>Stop coordinates not where passengers are expected to board</li> <li>All stops/platforms in a railway station having the same coordinates</li> <li>OSM platforms not connected to the street network</li> </ul>"},{"location":"IslandPruning/","title":"Street graph pruning","text":"<p>A street graph created from OpenStreetMap data has sections which cannot be reached with some or all traverse modes. For example, true geographic islands are usually disconnected from the main graph. The street network of such islands should be kept so that routing within the island or continuing from a ferry stop on it works as expected. Even a tiny street network connected to a ferry stop improves routing to an island a lot, because coordinate based itinerary searches find something to project onto.</p> <p> Removing a small subgraph from an island causes poor routing. A ferry stop on the island links directly to mainland.</p> <p>Disconnected parts can also represent a strictly forbidden area, such as connections within an industrial unit, roads of a military base or another region which cannot and should not be accessed when using door to door routing of a public transit journey planner. Existence of such graph sections is harmful, because start and end points of an itinerary search request may accidentally get projected to such a private pathway. As a result, a user does not receive any itineraries and gets no explanation for the routing problem.</p> <p>In most cases, connectivity problems are caused by incorrect modeling of OSM data. The number of such errors is usually very large, and the problem cannot be solved by simply fixing OSM data as soon as errors are detected - the OSM street network in Finland contains over 10 000 detected walk connectivity issues! An algorithmic solution is needed to address a problem of such magnitude.</p> <p> A typical error: bus platforms are not connected to the street network at all</p> <p>A simple and efficient solution is to detect harmful disconnected parts and remove them from the street graph. Routing then uses the properly connected part of the graph and finds itineraries. As a side effect, the start point of an itinerary search which departs from the removed graph projects at the border of it, which usually is good enough. Transfers may include strange teleportation and unexpected walking, as public transit stops may link to somewhat remote streets, but at least transfers will work.</p> <p> A disconnected railway platform breaks routing. Traveler is guided to take a round trip around the country although there is one hour direct train connection.</p>"},{"location":"IslandPruning/#access-restriction-islands","title":"Access restriction islands","text":"<p>One common reason for OSM connectivity problems is access tagging. It is perfectly OK to tag a front yard of a private residence using <code>access=private</code> or <code>access=destination</code> tags, so that strangers are not guided to travel through the private area. Routing will still use the private streets if a trip starts or ends there - only pass through traversal gets prohibited. However, sometimes OSM contributors try to block the traffic by tagging only entrance segments of streets leading to a restricted area. Unfortunately this totally prevents access to the interior part of the network, because OTP interprets it as pass through traffic. Pruning handles such problems by converting streets behind an access restriction to have the same access properties.</p> <p> Some regular (gray colored) streets are blocked behind access restricted (red colored) connections. Walk routing to them fails because it would be considered as pass through traffic. The image on the right shows that pruning added walk nothrough restricition to those streets, and routing works again.</p>"},{"location":"IslandPruning/#pruning-algorithm","title":"Pruning algorithm","text":"<p>Pruning analyses the three traverse modes - walk, bike and car - separately. For example, a resting area by a motorway may include some walking paths, but the only way to get there is to use car. Therefore, it represents a disconnected 'island' when considering the walk mode. Pruning does not erase disconnected graph geometry as long as it can be reached using any of the traverse modes. Instead, pruning removes traversal permission for each disconnected mode from the island.</p> <p>Pruning uses four parameters and some heuristics to decide if a disconnected sub graph is a real island to be retained, or a harmful data error:</p> <ul> <li><code>islandWithStopsMaxSize</code> defines the threshold for graph islands, which include public transit stops. All stop islands which have less graph edges than this get pruned. Default value is 2.  </li> <li><code>islandWithoutStopsMaxSize</code> defines the threshold for graph islands, which do not have public transit stops. All stopless islands which have less edges than this get pruned. Defaults to 10.  </li> <li><code>adaptivePruningFactor</code> defines the maximal value for a distance based multiplier for the two thresholds defined above (default value 20).  </li> <li><code>adaptivePruningDistance</code> defines the search radius as meters when estimating distance between graphs (default value 250).  </li> </ul> <p>Pruning thresholds are increased adaptively so that if the distance between an examined sub graph and the other graph is zero, the threshold is multiplied by a full adaptivePruningFactor value. The idea is that if a sub graph is closely entangled with another graph, it is likely to be a harmful modeling error, not a remote place like a true geographic island. If the distance is more than <code>adaptivePruningDistance</code>, the actual nominal threshold values will be used. So, adaptiveness prunes much larger disconnected graphs in places where they have potential to cause routing errors.</p> <p>Adaptive pruning can be disabled by setting adaptivePruningFactor to 1. Constant pruning thresholds will then be applied.</p> <p>Pruning also examines the transport modes of graph islands with stops. If land transportation modes are not found (only ferry or no modes at all), the graph is retained. Unknown mode is accepted for island status, because ferry lines often operate only during warm seasons.</p>"},{"location":"IslandPruning/#some-examples","title":"Some examples","text":"<p> A disconnected small graph should be preserved, if it is located on a real island.</p> <p> A street section has tags which prevent traversal on it, and OTP has removed it from the graph. Some isolated streets remain left, and a public transit stop gets linked to them. Routing cannot use the stop unless traveler is leaving from or going to the small isolated sub graph. Isolated streets cannot be reached by walking either. After pruning, the stop is projected to the main graph. Transfers at the stop work fine. Itineraries can guide traveler quite close to the removed streets.</p> <p> The platform structure of a bus station is disconnected from the other graph. Most bus traffic of a medium size city becomes unusable. Despite of the complexity of the sub graph (54 edges and 21 stops), it must be removed in pruning, so that stops get linked to reachable and well connected streets.</p>"},{"location":"IslandPruning/#issue-reports","title":"Issue reports","text":"<p>Pruning creates a <code>GraphIsland</code> issue every time it prunes a sub graph. Issues may show up as duplicates, because pruning is run for each traverse mode.</p> <p>A <code>PrunedStopIsland</code> issue is added for every pruned graph island which has stops linked to it. Such islands are particularly harmful, because they are places where public transit transfers take place and hence are frequently used. Pruned stop island issues should be studied frequently and underlying OSM errors fixed, especially if the island has many stops and edges (i.e it is most likely a public transit station, see station island example above).</p>"},{"location":"Localization/","title":"Localization","text":"<p>NOTE: This documentation pertains to the client included in the main OTP repository. THIS BUILT-IN OTP CLIENT IS PROVIDED FOR TEST AND DEBUGGING PURPOSES. IT IS NOT MEANT FOR PRODUCTION USE.</p> <p>This page contains instructions for both developers and translators on how to make the OTP interface usable by people who speak different languages. Developers will need to take certain steps to mark translatable strings within the source code. Translators will need to edit specific files within the project to create or revise the translation for their language.</p> <p>In OTP we use gettext for localization, for the following reasons:</p> <ul> <li>Plural suport</li> <li>Context support</li> <li>Automatic extraction of translatable strings from source code</li> <li>Translator comments   support</li> <li>Source references (we can see where each translated string is used in the source code)</li> </ul> <p>In the Javascript UI the i18next library is used.</p> <p>Three types of files are used in the OTP localization process:</p> <ul> <li>The <code>.pot</code> file is the message template. It is a starting point for creating new <code>.po</code> files.</li> <li><code>.po</code> files are created and edited by translators based on the <code>.pot</code> file.</li> <li><code>.json</code> files are generated from the <code>.po</code> files for each language.</li> <li><code>.js</code> files are localization configuration files which specify units and time/date formats.</li> </ul> <p>Only the <code>.po</code> and <code>.js</code> files are directly edited. The <code>.pot</code> file is created from an automated analysis of annotated source code. The <code>.json</code> files are also automatically generated as an easy way for the Javascript UI to consume the contents of the <code>.po</code> files.</p> <p>All translation files are in the directory <code>/src/client/i18n</code>.</p>"},{"location":"Localization/#for-software-developers-adding-new-strings","title":"For Software Developers: Adding New Strings","text":"<p>When you add a string to Javascript source that will be seen by the end user, wherever that string is referenced you should surround it with a call to a special function. The name of the function depends on what kind of string it is:</p> <ul> <li>basic string: <code>_tr('string', parameters)</code></li> <li>basic string with context: <code>ngettext('context', 'string')</code></li> <li>string with plural: <code>ngettext('singular', 'plural', quantity)</code></li> <li>string with plural and context: <code>npgettext('context', 'singular', 'plural', quantity)</code></li> </ul> <p>For more detail, see Sprintf parameters.</p> <p>A \"context\" is any string (preferably short and without whitespace) that is used to disambiguate the translation of the main string. It is used when developers get input from translators that some string should be translated in different ways in different parts of the program. Each of those distinct places will be assigned a different context string.</p> <p>When you add strings to the source code, if you think that translators might not understand how the string is used or what parameters it requires, add translator comments like this:</p> <pre><code>//TRANSLATORS: Start: location at [time date] (Used in print itinerary  \n//when do you start your trip)                                          \nhtml += '&lt;h3&gt;' + _tr('Start: %s at %s', this.getStartLocationStr(), this.getStartTimeStr()) + '&lt;/h3&gt;';\n</code></pre> <p>Translator comments must always start with <code>TRANSLATORS:</code> and must be in the line immediately before translated string. Otherwise they won't be extracted together with the string.</p>"},{"location":"Localization/#examples","title":"Examples:","text":""},{"location":"Localization/#basic-translated-string","title":"Basic translated string","text":"<pre><code>//TRANSLATORS: Board Public transit route name (agency name     \n//Stop ID ) start time                                          \nhtml += '&lt;li&gt;&lt;b&gt;' + _tr('Board') + '&lt;/b&gt;: ' + leg.from.name + ' (' + leg.from.stopId.agencyId + ' Stop ID #' +\n\n//With named sprintf parameters (our preferred option)\n\n//TRANSLATORS: Start: location at [time date] (Used in print itinerary  \n//when do you start your trip)                                          \nhtml += '&lt;h3&gt;' + _tr('Start: %(location)s at %(time_date)s', {\n    'location': this.getStartLocationStr(),\n    'time_date': this.getStartTimeStr()\n}) + '&lt;/h3&gt;';\n\n//With positional sprintf parameters (to be avoided because word order changes between languages)\nhtml += '&lt;h3&gt;' + _tr('End: %1$s at %2$s', this.getEndLocationStr(), this.getEndTimeStr()) + '&lt;/h3&gt;';\n</code></pre>"},{"location":"Localization/#normal-string-with-context","title":"Normal string with context","text":"<pre><code> if (leg.headsign) html += pgettext(\"bus_direction\", \" to \") + leg.headsign;\n\n//same string could be different translation\n//TRANSLATORS: [distance] to [name of destination]              \nhtml += \" \" + otp.util.Itin.distanceString(leg.distance) + pgettext(\"direction\", \" to \") + leg.to.name;\n</code></pre>"},{"location":"Localization/#plural-strings","title":"Plural strings","text":"<pre><code>//TRANSLATORS: widget title                                             \nthis.setTitle(ngettext(\"%d Itinerary Returned\", \"%d Itineraries Returned\", this.itineraries.length));\n</code></pre> <p>If you add new strings to the source code, it is good practice to also update the translation template and the translations but it is not mandatory (these can be updated later). It is also recommended to include \"i18n string change\" in the commit message.</p>"},{"location":"Localization/#updating-translations","title":"Updating translations","text":"<p>Translations are updated with the help of Babel and i18next-conv (xgettext doesn't yet have great Javascript support).</p> <p>Babel is used to extract strings from the Javascript source code into the shared <code>.POT</code> translation template, and also for updating the existing <code>.PO</code> language translations when new strings are introduced in the template. i18next-conv is used to convert the <code>.PO</code> translation files for the individual languages to <code>.json</code> files which are used by the Javascript translation library.</p>"},{"location":"Localization/#installing-babel","title":"Installing Babel","text":"<p>You can install it from your operating system's package repository (if available) or you can use virtualenv.</p> <ol> <li>Install virtualenv (This depends on your operating system)</li> <li>Create virtualenv with name .venv in directory where src and other files resides (Root    OpenTripPlanner directory). <code>virtualenv2 .venv</code>(python 2) or <code>python3 -m venv .venv</code> (python 3)</li> <li>Use virtualenv <code>source .venv/bin/activate</code></li> <li>Install babel <code>pip install babel</code></li> </ol> <p>If you didn't install babel from virtualenv in root OpenTripPlanner directory you have to add path to babel in Makefile. change <code>PYBABEL</code> variable to path to pybabel.</p>"},{"location":"Localization/#installing-i18next-conv","title":"Installing i18next-conv","text":"<p>i18next-conv requires nodejs.</p> <p>Once you have NodeJS installed, use <code>npm install i18next-conv</code> to install i18next-conv in the same directory where you created virtualenv.</p>"},{"location":"Localization/#updating-the-pot-template","title":"Updating the <code>.pot</code> Template","text":"<p>In the root of the OTP repo, run <code>make</code>. The commands in the <code>Makefile</code> will extract the translatable strings from the Javascript files and update the translation template <code>messages.pot</code>, as well as the <code>.po</code> translation files for all the different languages.</p> <p>Once this is done, you can translate the new strings in the <code>.po</code> files. After saving the updated <code>.po</code> file, run <code>make update_js</code> to transform to PO files into <code>.json</code>, which is used at runtime by the Javascript translation library. After you rebuild OTP, all new strings should be visible in the UI.</p>"},{"location":"Localization/#for-translators-creating-new-translations","title":"For Translators: Creating New Translations","text":"<p>The following can get a bit technical. If you want to do a translation but don't want to / know how to install all this software, post to the Gitter chat room  stating what language you want to translate, and someone will make you a corresponding <code>.po</code> file.</p>"},{"location":"Localization/#creating-a-new-translation-file","title":"Creating a New Translation File","text":"<p>New <code>.po</code> files are created from the <code>.pot</code> template with the help of <code>msginit</code>, which is run like this: <code>msginit init -l &lt;LAN&gt; -i messages.pot -o &lt;LAN&gt;.po</code>, where <code>&lt;LAN&gt;</code> is a culture code. New <code>.po</code>files can also be created with the help of <code>Poedit</code>. All translation files should be placed in the directory <code>/src/client/i18n</code>.</p> <p>Please use the ISO language code as the culture code (e.g. <code>fr.po</code> for French). We will append country codes in the following limited circumstances:</p> <ul> <li>British versus US English (<code>en_GB.po</code> and <code>en_US.po</code>)</li> <li>Brazilian Portuguese <code>pt_BR.po</code>, as opposed to <code>pt.po</code> for European Portuguese</li> <li>Chinese: <code>zh_TW.po</code> for traditional characters as used in e.g. Taiwan and Hong Kong,   and <code>zh_CN.po</code> for simplified characters as used in mainland China, Singapore, etc.</li> </ul> <p>These conventions are based on the Launchpad Translation page.</p> <p>In Linux you can see the culture codes for all the locales you have installed with the command <code>locale -a</code>. A list of culture codes is also availible here .</p>"},{"location":"Localization/#performing-the-translation","title":"Performing the Translation","text":""},{"location":"Localization/#configuration","title":"Configuration","text":"<p>Copy the locale configuration script <code>English.js</code> from <code>/src/client/js/otp/locale</code> to <code>YourLanguage.js</code> and customize it to your language. Change the name, units, locale_short and datepicker_locale_short values. Translate infoWidgets and localize the time/date formats.</p> <p>Then take the following steps:</p> <ul> <li>Add the culture code to the <code>LANGS</code> variable in the Makefile`</li> <li>Add the new <code>YourLanguage.js</code> to the locales variable in <code>/src/client/js/otp/config.js</code></li> <li>Add a new datepicker translation to <code>/src/client/js/lib/jquery-ui/i18n</code></li> <li>Load the new datepicker translation and <code>YourLanguage.js</code> in <code>/src/client/index.html</code></li> </ul>"},{"location":"Localization/#translating-strings","title":"Translating Strings","text":"<p>For translating the strings themselves, you can use any program that supports gettext files. You can in theory use any text editor, but programs or plugins purpose-built for translating are recommended. Most of them support checking parameter correctness, translation memory, web translating services etc. to make the task easier.</p> <p>Here are some such programs (all free and open source):</p> <ul> <li>Poedit For Linux, Windows, and Mac. Use a version newer then 1.5. This is   the recommended choice for getting started with localization. It supports translation memory and   file context.</li> <li>Web Poedit Usable from within a web browser, you don't have to   install or register</li> <li>Gted A plugin for the Eclipse IDE.</li> <li>Lokalize Runs under KDE on Linux, has some Windows support.   Supports translation memory and file context.</li> <li>Virtaal For Linux, Windows, and beta for Mac.   Supports Google and Microsoft web translation and other translation memory services.</li> </ul> <p>All these programs support setting a string to \"fuzzy\", marking that it needs review etc. in case you translate something but aren't sure of it's correctness. Sometimes those flags are set automatically if the original string was changed and translators must check if the translation is still correct.</p>"},{"location":"Localization/#caveats","title":"Caveats","text":"<p>Be careful when translating that the translated strings have the same format as the original. If spaces appear at the start or end of the strings, they must also appear in the translation. The order of unnamed (positional) parameters may change depending on the target language. You can also leave parameter out of the translation if it is irrelevant in the target language.</p>"},{"location":"Logging/","title":"Logging","text":"<p>OTP uses logback and slj4j as a logging framework. Logging is configured in the <code>logback.xml</code> file inside the OTP jar file. See these frameworks for more documentation on log configuration.</p> <p>For developers, starting OTP using the <code>InteractiveOtpMain</code> is an easy way to configure debug logging.</p> <p>Some loggers useful for debugging.</p> <ul> <li><code>TRANSFERS_EXPORT</code>: Dump transfers to transfers-debug.csv file.</li> <li><code>DATA_IMPORT_ISSUES</code>: Write issues to debug lag as well as to the issue report.</li> <li><code>org.opentripplanner.raptor.RaptorService</code>: Debug Raptor request and response</li> </ul>"},{"location":"Logging/#format","title":"Format","text":"<p>By default, OTP logs in plain text to the console. However, it is possible to also log in JSON format.</p> <p>To enable it, set the Java property <code>otp.logging.format</code> to one of these values:</p> <ul> <li><code>plain</code>: regular plain text logging (default, no need to configure it)</li> <li><code>json</code>: Logstash-encoded JSON format understood by many log ingestion tools (Datadog, Loggly, Loki...)</li> </ul>"},{"location":"Logging/#complete-example","title":"Complete example","text":"<pre><code>java -Dotp.logging.format=json -jar otp.jar --load --serve data\n</code></pre>"},{"location":"Logging/#further-customization","title":"Further customization","text":"<p>If you want to customize the exact log output even further you can use your own logback configuration  by starting OTP with the following parameter:</p> <pre><code>java -Dlogback.configurationFile=/path/to/logback.xml -jar otp.jar --load --serve data\n</code></pre> <p>For example, Entur has their own custom log format configured as follows:</p> <pre><code>&lt;!-- Entur's custom log format  --&gt;\n&lt;appender name=\"entur\" class=\"ch.qos.logback.core.ConsoleAppender\"&gt;\n  &lt;encoder class=\"net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder\"&gt;\n     &lt;providers&gt;\n        &lt;!-- provides the timestamp &lt;timestamp/&gt; --&gt;\n        &lt;!-- provides the version &lt;version/&gt; --&gt;\n        &lt;!-- provides the fields in the configured pattern --&gt;\n        &lt;pattern&gt;\n           &lt;!-- the pattern that defines what to include --&gt;\n           &lt;pattern&gt;\n           {\n             \"serviceContext\": {\n               \"service\": \"otp2\"\n             },\n             \"message\": \"%message\\n%ex{full}\",\n             \"severity\": \"%level\",\n             \"reportLocation\": {\n               \"filePath\": \"%logger\",\n               \"lineNumber\": \"%line\",\n               \"functionName\": \"%method\"\n              }\n            }\n            &lt;/pattern&gt;\n        &lt;/pattern&gt;\n     &lt;/providers&gt;\n  &lt;/encoder&gt;\n&lt;/appender&gt;\n</code></pre>"},{"location":"Netex-Norway/","title":"Using European Data Standards","text":""},{"location":"Netex-Norway/#building-with-netex-data","title":"Building with Netex Data","text":"<p>One important new feature of OTP2 is the ability to load Netex data. Netex is a European specification for transit data exchange, comparable in purpose to GTFS but broader in scope. An EU directive aims to have all EU countries sharing Netex data by the end of 2019.</p> <p>Different countries are currently using different incompatible \"profiles\" of Netex, but an effort is underway to converge on a single European standard profile. This is based in large part on the Norwegian profile, and Norway's national passenger information and ticketing agency Entur has contributed the OTP2 Netex loading code. Therefore if you'd like to try loading Netex data, Norway is a good place to start.</p> <p>The Norwegian Netex data can be downloaded from the Entur developer pages. There is a column of Netex download links partway down the page, and the first row is for all of Norway.</p> <p>Full OSM data for Norway can be downloaded from the Geofabrik Norway downloads page. Get the <code>norway-latest.osm.pbf</code> file, which can then be filtered to remove buildings and other unused data before loading into OTP using a command like the one below. This filtering step can be skipped if you don't have the necessary Osmium tools installed.</p> <p><code>osmium tags-filter norway-latest.osm.pbf w/highway w/public_transport=platform w/railway=platform w/park_ride=yes r/type=restriction -o norway-filtered.osm.pbf -f pbf,add_metadata=false,pbf_dense_nodes=true</code></p> <p>Be sure to move the original unfiltered file out of your graph inputs directory (or rename it with a suffix like <code>norway-latest.osm.pbf.ignore</code>) otherwise OTP2 will try to include both the filtered and unfiltered OSM data in your graph.</p> <p>The <code>build-config.json</code> for a Norwegian graph using Netex data looks like this:</p> <pre><code>{\n  \"areaVisibility\": true,\n  \"platformEntriesLinking\": true,\n  \"islandWithoutStopsMaxSize\": 5,\n  \"islandWithStopsMaxSize\": 5,\n  \"dataImportReport\": true,\n  \"netexDefaults\" : {\n    \"moduleFilePattern\" : \".*-netex\\\\.zip\",\n    \"sharedFilePattern\": \"_stops.xml\",\n    \"sharedGroupFilePattern\": \"_(\\\\w{3})(_flexible)?_shared_data.xml\",\n    \"groupFilePattern\": \"(\\\\w{3})_.*\\\\.xml\",\n    \"feedId\": \"EN\",\n    \"ferryIdsNotAllowedForBicycle\": [\n      \"NYC:Line:1\",\n      \"NYC:Line:012fc5c4-131b-4dfc-8160-4e49136e531a\",\n      \"NYC:Line:8bfef12a-ac98-4376-8a2a-eb5a336d107b\"\n    ]\n  },\n  \"osm\": [\n    {\n      \"source\": \"norway-latest.osm.pbf\",\n      \"osmTagMapping\": \"norway\",\n      \"timeZone\": \"Europe/Oslo\"\n    }\n    ]\n}\n</code></pre> <p>Note the special section specifying how to find Netex XML files within the single ZIP archive you downloaded.</p> <p>Once you have the graph inputs (the OSM PBF file, the Netex ZIP file, and the <code>build-config.json</code>) saved together in a directory, you can instruct OTP2 to build a graph from these inputs:</p> <p><code>java -Xmx10G otp2.jar --build --save /path/to/graph/inputs</code></p> <p>This should produce a file <code>graph.obj</code> in the same directory as your inputs. Building this Norway graph takes approximately 16 minutes (without elevation data, as configured above), and can be done within 10GB of heap memory (JVM switch <code>-Xmx10G</code>). Increasing that to 12 or 14GB might speed it up a bit if you have the space. The Graph file it produces is just under 600MB. The server will take about 30 seconds to load this Graph and start up, and will consume about 4GB of heap memory under light use.</p> <p>You can then start up an OTP server with a command like this:</p> <p><code>java -Xmx6G otp2.jar --load /path/to/graph</code></p> <p>Once the server is started up, go to <code>http://localhost:8080</code> in a browser to try out your server using OTP's built in testing web client. Try some long trips like Oslo to Bergen and see if you can get long distance trains and flights as alternatives. You might need to increase the walking limit above its very low default value.</p>"},{"location":"Netex-Norway/#adding-siri-real-time-data","title":"Adding SIRI Real-time Data","text":"<p>Another important feature in OTP2 is the ability to use SIRI real-time data. Within the EU data standards, SIRI is analogous to GTFS-RT: a way to apply real-time updates on top of schedule data. While technically a distinct specification from Netex, both Netex and SIRI use the Transmodel vocabulary, allowing SIRI messages to reference entities in Netex schedule data. Like GTFS-RT, SIRI is consumed by OTP2 using \"graph updaters\" which are configured in the <code>router-config.json</code> file, which is placed in the same directory as the <code>graph.obj</code> file and loaded at server startup.</p> <pre><code>{\n    \"updaters\": [\n        {\n            \"type\": \"siri-sx-updater\",\n            \"frequency\": \"1m\",\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-sx\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"siri-et-updater\",\n            \"frequency\": \"20s\",\n            \"previewIntervalMinutes\": 180,\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-et\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"siri-vm-updater\",\n            \"frequency\": \"1m\",\n            \"url\": \"https://api.example.com/siri\",\n            \"feedId\": \"siri-vm\",\n            \"blockReadinessUntilInitialized\": true\n        },\n        {\n            \"type\": \"raptor-transit-layer\",\n            \"updateIntervalSeconds\": 20\n        }\n    ]\n}\n</code></pre> <p>The first three updaters fetch three different kinds of SIRI data:</p> <ul> <li>Situation Exchange (SX, text notices analogous to GTFS-RT Alerts)</li> <li>Estimated Timetable (ET, predicted arrival times analogous to GTFS-RT TripUpdates)</li> <li>Vehicle Monitoring (VM, location and status of vehicles analogous to GTFS-RT VehiclePositions)</li> </ul> <p>These updaters can handle differential updates, but they use a polling approach rather than the message-oriented streaming approach of the GTFS-RT Websocket updater. The server keeps track of clients, sending only the things that have changed since the last polling operation.</p> <p>Note that between these SIRI updaters and the GTFS-RT Websocket updater, we now have both polling and streaming examples of GTFS-RT \"incrementality\" semantics, so should be able to finalize that part of the specification.</p> <p>The final updater regularly performs a copy of the real-time data into a format suitable for use by OTP2's new Raptor router. Without this updater the real-time data will be received and cataloged, but not visible to the router.</p>"},{"location":"Preparing-OSM/","title":"Preparing OSM Data","text":""},{"location":"Preparing-OSM/#cropping-osm-data","title":"Cropping OSM data","text":"<p>Services producing automated extracts of OSM data like Geofabrik or Interline Extracts are limited to predefined areas. You'll often need to download an extract for a country or region larger than your true analysis area, then cut it down to size.</p> <p>Excessively large OSM data can lead to significant increases in computation time and complexity, both while building the graph and handling trip planning requests. You may want to crop the OSM data if they cover an area significantly larger than your transit network. Several command line tools are able to perform these cropping operations: Osmosis is a multi-platform Java tool that works on Windows, Linux, and MacOS but is relatively slow, OSMConvert is a fast tool pre-built for Windows and Linux and available on MacOS and Linux distributions as part of <code>osmctools</code> package. Osmium-Tool is a personal favorite that is extremely fast but only straightforward to install on Linux and MacOS platforms. Below are some example crop commands for these different tools:</p> <p>Osmosis: <code>osmosis --rb input.osm.pbf --bounding-box left=4.34 right=5.84 bottom=43.10 top=43.97 --wb cropped.osm.pbf</code></p> <p>OsmConvert: <code>osmconvert input.osm.pbf -b=-77.255859375,38.77764022307335,-76.81365966796875,39.02345139405933 --complete-ways -o=cropped.osm.pbf</code></p> <p>Osmium: <code>osmium extract --strategy complete_ways --bbox 2.25,48.81,2.42,48.91 input.osm.pbf -o cropped.osm.pbf</code></p> <p>The latter two commands expect bounding boxes to be specified in the format <code>min_lon,min_lat,max_lon,max_lat</code>. We frequently find bounding boxes using the convenient Klokantech bounding box tool. Selecting the \"CSV\" format in the lower left will give exactly the format expected by these tools.</p>"},{"location":"Preparing-OSM/#filtering-osm-data","title":"Filtering OSM data","text":"<p>The OSM database contains a lot of other data besides the roads, paths, and public transportation platform data we need for accessibility analysis. As of this writing, according to TagInfo 59% of the ways in OSM are buildings, and only 23% are roads or paths. Buildings frequently have more complex shapes than roads, and objects like waterways or political boundaries can be very large in size. It has been jokingly said that OSM should be renamed \"OpenBuildingMap\" rather than \"OpenStreetMap\".</p> <p>Removing unneeded data will reduce file sizes, facilitating copying or moving files around and reducing the size of project backups and archives. It may also speed up the processing stage where the OSM data is converted into a routable street network. Several command line tools exist to filter OSM data. Command line tools for this purpose include Osmosis and Osmium-Tool. Osmium-Tool is extremely fast but is only straightforward to install on Linux and MacOS platforms. Osmosis is often slower at filtering but will also work on Windows as it's a multi-platform Java application. OSMFilter cannot work with PBF format files so we rarely use it. Below are some example commands for retaining only OSM data useful for accessibility analysis. Here are some example commands:</p> <p>Osmosis: <code>osmosis --rb input.osm.pbf --tf reject-ways building=* --tf reject-ways waterway=* --tf reject-ways landuse=* --tf reject-ways natural=* --used-node --wb filtered.osm.pbf</code></p> <p>Osmium-Tool: <code>osmium tags-filter input.osm.pbf w/highway wa/public_transport=platform wa/railway=platform w/park_ride=yes r/type=restriction r/type=route -o filtered.osm.pbf -f pbf,add_metadata=false</code></p>"},{"location":"Presentations/","title":"Presentations related to OpenTripPlanner","text":""},{"location":"Presentations/#presentations-in-english","title":"Presentations in English","text":"<ul> <li>OpenTripPlanner past, present and the future. FOSDEM. Hannes Junnila. February, 2023</li> <li>OpenTripPlanner 2.2 webinar. Thomas Gran, Hannes Junnila and Leonard Ehrenfried. October, 2022</li> <li>Use of OpenTripPlanner in Norway. Andreas Tryti, Andrew Byrd and Brede Dammen. March, 2021</li> <li>OTP Webinar at Entur. Thomas Gran, Andrew Byrd and Gard Mellemstrand. October, 2019</li> <li>Multiple presentations at the OTP Open Day. April, 2019</li> <li>Simulating Cities with OpenStreetMap and OpenTripPlanner. State of the Map US. Kevin Webb. April, 2014</li> <li>OpenTripPlanner: Recent Developments in Multimodal Routing with OSM. State of the Map US. David Emory. June, 2013</li> </ul>"},{"location":"Presentations/#presentations-in-german","title":"Presentations in German","text":"<ul> <li>\u00d6PNV und Fahrgemeinschaften intermodal mit dem OpenTripPlanner. FOSSGIS 2019. Holger Bruch. March, 2019</li> </ul>"},{"location":"Product-Overview/","title":"Product Overview","text":""},{"location":"Product-Overview/#opentripplanner-project","title":"OpenTripPlanner project","text":"<p>OpenTripPlanner is a group of open source software applications that help individuals and organizations  calculate and deliver multimodal trip plans based on OpenStreetMap (OSM) and other standardized data  sources (e.g. GTFS, GBFS, NeTEx).</p> <p>A community of dozens of individuals and organizations work on OpenTripPlanner collaboratively to  improve multimodal trip planning best practices and to make it easier for public transit agencies and  public transit riders to publish and access information about transit services.</p> <p>OpenTripPlanner deployments are locally managed in many different ways by many different types of organizations.  OpenTripPlanner consistently and dependably delivers multimodal trip plans to millions of riders  everyday in dozens of countries around the globe. The project is actively maintained by the community,  with more than 50 commits most weeks during 2022, and 20 different developers having made 50 or more  commits during the life of the project.</p>"},{"location":"Product-Overview/#what-exactly-is-otp","title":"What exactly is OTP?","text":"<p>The most commonly used OpenTripPlanner component is a server-side Java application that is primarily  designed to interpret and combine map, transit service, and other mobility data sets, providing API  endpoints that receive user origins and destinations and return trip plans to other applications  along with vector map tiles, stop departures, and other rider information.</p> <p>In other words, OTP is a backend application that can work with other frontend user interfaces. OTP  works with your website, mobile app, physical signage or other applications in order to provide  relevant customer information and meaningful trip plans to riders.</p> <p>There's no official OTP user interface, although the OpenTripPlanner ecosystem includes several user  interface projects (for example Digitransit and  OTP-react-redux).  How your OTP deployment looks is entirely up to you. </p>"},{"location":"Product-Overview/#what-otp-can-do-for-you","title":"What OTP can do for you","text":""},{"location":"Product-Overview/#transit-agencies","title":"Transit agencies","text":"<p>Transit agencies can use OTP as a backend for their public website/app trip planner or internal trip planner  for their customer service team.</p> <ul> <li>Fully customizable for use with any frontend</li> <li>High-performance trip planning</li> <li>Fully multimodal routing, including walking, biking, bikeshare, demand-responsive services in  combined trip plans rather than presented in alternative trip plans</li> <li>Support for real-time alerts, trip re-routing based on real-time delays and vehicle positions</li> <li>Multi-criteria cost calculation allows for dynamic user inputs and requests including  mode, time, transfers, and other preferences while delivering balanced results</li> <li>One OTP backend can power both a website and app for use by riders, along with a separate frontend  with a different configuration for use by a customer service team</li> <li>Active development by dozens of agencies means new features every year (see the OTP common roadmap here)</li> </ul>"},{"location":"Product-Overview/#regions-countries-and-private-entities","title":"Regions, countries, and private entities","text":"<p>Regional, provincial, or national governments, or any private entity, can set up a trip planner including multiple transit agencies.</p> <ul> <li>Highly scalable software for large regions</li> <li>Interagency fare calculation</li> <li>Integrates multiple modes including bikeshare and demand-response</li> <li>Can be provided as a service to agencies for use in their websites and apps</li> </ul>"},{"location":"Product-Overview/#researchers","title":"Researchers","text":"<p>While historically, OpenTripPlanner has often been used by researchers for the programmatic calculation  of large numbers of trip plans, this is no longer an intended use case of OTP. You are welcome to use  OTP for any purpose, but you may also find applications like r5 to  be more appropriate for these purposes.</p>"},{"location":"Product-Overview/#talk-to-an-expert-about-otp","title":"Talk to an expert about OTP","text":"<p>Everyone interested in OTP is welcome to post questions on the Gitter chat or OpenTripPlanner-users group.</p> <p>If you\u2019re looking for a conversation with an individual from a similar organizational type, you can  make that request and include some info about your organization on the forum linked above and a member  of the OTP community will connect with you.</p>"},{"location":"ReleaseChecklist/","title":"Release Checklist","text":"<p>This section serves as a checklist for the person performing releases. Note that much of this mimics the actions taken by the Maven release plugin. Based on past experience, the Maven release plugin can fail at various points in the process leaving the repo in a confusing state. Taking each action manually is more tedious, but keeps eyes on each step and is less prone to failure.</p> <ul> <li>Check that your local copy of the dev branch is up to date with no uncommitted changes<ul> <li><code>git status</code></li> <li><code>git checkout dev-2.x</code></li> <li><code>git clean -df</code></li> <li><code>git pull</code></li> </ul> </li> <li>Make sure the documentation is up to date<ul> <li>Check all links and references to the release and update to the target release version. Search   all files for with a regular expression: <code>2\\.[012]\\.0</code> and replace if appropriate with the new   version.</li> <li>In <code>docs/index.md</code> replace what is the latest version and add a new line for the previous one</li> </ul> </li> <li>Update <code>docs/Changelog.md</code><ul> <li>Lines should have been added or updated as each pull request was merged</li> <li>If you suspect any changes are not reflected in the Changelog, review the commit log and add   any missing items</li> <li>Update the header at the top of the list from <code>x.y.z-SNAPSHOT</code> to just <code>x.y.z (current date)</code></li> <li>Check in any changes, and push to GitHub</li> <li>It is important to finalize the documentation before tagging the release, to ensure the    published documentation is associated with the release tag </li> </ul> </li> <li>Update the variable MASTER_BRANCH_VERSION in <code>cibuild.yml</code><ul> <li>This tells the GH Action that pushes the documentation on master what the name of the    current version is.    For version 2.3.0 Leonard has already done it: Example commit</li> </ul> </li> <li>Verify that all dependencies in the POM are non-SNAPSHOT versions (e.g. with <code>grep</code>)</li> <li>Check on GH Actions that the build is currently passing</li> <li>Switch to the HEAD of master branch, and ensure it's up to date with no uncommitted changes<ul> <li><code>git checkout master</code></li> <li><code>git status</code></li> <li><code>git clean -df</code></li> <li><code>git pull</code></li> </ul> </li> <li>Merge the dev branch into master<ul> <li><code>git merge dev-2.x</code></li> </ul> </li> <li>Bump the SNAPSHOT version in the POM to the release version<ul> <li>Edit version in POM, removing SNAPSHOT and increasing version numbers as needed (following   semantic versioning)</li> <li><code>git add pom.xml</code></li> <li><code>git commit -m \"prepare release x.y.z\"</code></li> </ul> </li> <li>Run a test build of the release locally, without deploying it<ul> <li><code>mvn clean install -Prelease</code></li> <li>The <code>install</code> goal will sign the Maven artifacts so you need the GPG signing certificate set   up</li> <li>You can also use the <code>package</code> goal instead of the <code>install</code> goal to avoid signing if you   don't have the GPG certificate installed.</li> <li>All tests should pass</li> </ul> </li> <li>Finally, if everything looks good, tag and push this release to make it official<ul> <li><code>git tag -a vX.Y.Z -m \"release X.Y.Z\"</code></li> <li><code>git push origin vX.Y.Z</code></li> <li><code>git push origin master</code></li> <li>Note that only one commit may have a particular non-snapshot version in the POM (this is   the commit that should be tagged as the release)</li> <li>Go to the GitHub tags page and use   the <code>...</code> button to mark the new tag as a release.</li> <li>Give the release a name like <code>v2.2.0 (November 2022)</code></li> <li>Optionally add a very condensed version of the changelog in the description box, with only the   5-10 most significant changes that might affect someone's choice to upgrade.</li> <li>Attach the JAR files produced in <code>/target</code> to the GitHub release page you just created.</li> </ul> </li> <li>Check that the push triggered an Actions build and that it was uploaded to GHPR.<ul> <li>Currently, pushing the tag does not trigger deployment of release Maven artifacts, only GHPR   JARs.</li> </ul> </li> <li>Deploy the build artifacts to Maven Central and GitHub and Maven Central<ul> <li>This step can get complicated and requires you to have the GPG keys and Maven repo credentials   set up.</li> <li>Apply the changes recorded   in https://github.com/opentripplanner/OpenTripPlanner/tree/signed-deploy-to-central</li> <li>While still on the tag commit, run <code>mvn deploy -Prelease</code>.</li> </ul> </li> <li>Set up next development iteration<ul> <li>Add a new section header to <code>docs/Changelog.md</code> like <code>x.y+1.0-SNAPSHOT (in progress)</code></li> <li>Edit minor version in <code>pom.xml</code> to <code>x.y+1.0-SNAPSHOT</code></li> <li><code>git add pom.xml docs/Changelog.md</code></li> <li><code>git commit -m \"Prepare next development iteration x.y+1.0-SNAPSHOT\"</code></li> <li><code>git push</code></li> </ul> </li> <li>Check that Maven artifact appears on Maven Central<ul> <li>Directory listing of OTP releases on Maven Central</li> <li>It may take a while (half an hour) for releases to show up in the central repo after Travis   uploads the artifacts</li> </ul> </li> <li>Merge master back into dev (to sync up the Maven artifact version from the POM)<ul> <li><code>git checkout dev-2.x</code></li> <li><code>git merge master</code></li> <li><code>git push</code></li> </ul> </li> <li>Email the OTP dev and users mailing lists<ul> <li>Mention the new version number.</li> <li>Provide links to the new developer documentation.</li> <li>Provide links to the artifacts directory on Maven Central.</li> </ul> </li> <li>Prepare for the next release in GitHub by renaming the released milestone and creating a new   milestone for the next release. Then make sure all issues and PRs are tagged with the correct   milestone.<ul> <li>Close open PRs older than 2 years, make sure the milestone is set to <code>Rejected</code>.</li> <li>Rename the old milestone from <code>x.y (Next Release)</code> to <code>x.y</code>. All issues and PRs assigned to    this milestone are automatically updated.</li> <li>Create a new milestone: <code>x.y+1 (Next Release)</code></li> <li>All PullRequests SHOULD have a milestone (except some very old ones) <ul> <li>Assign all open PRs to this new milestone <code>x.y+1 (Next Release)</code>.</li> <li>Assign all closed PRs without a milestone in the release to the released milestone    <code>x.y</code>. Make sure NOT to include very old PRs or PRs merged after the release(if any).</li> </ul> </li> <li>Some issues have a milestone, but not all.<ul> <li>Move all open issues with the released milestone <code>x.y</code> to the next release    <code>x.y+1 (Next Release)</code>. </li> </ul> </li> </ul> </li> </ul>"},{"location":"ReleaseChecklist/#artifact-signing","title":"Artifact Signing","text":"<p>Maven release artifacts must be digitally signed to prove their origin. This is a safeguard against compromised code from a malicious third party being disguised as a trusted library.</p> <p>The OTP artifact signing key was created by Conveyal. We export only that signing subkey, with our company's main key blanked out. Therefore, even if someone managed to acquire the decrypted key file and the associated GPG passphrase, they would not have the main key. We could deactivate the signing key and create a new one, without the main key being compromised.</p> <p>When modified for Maven Central deployment, OpenTripPlanner's POM is set up to sign artifacts in the verify phase, which means signing will happen for the <code>install</code> and <code>deploy</code> targets, but not the <code>package</code> target. When performing a local test build, if you do <code>mvn clean install site</code> it will test the signing process. If you do not have the certificate installed, you can instead do <code>mvn clean package site</code> to bypass signing, but this provides less certainty that everything is set up correctly for the CI-driven final release.</p>"},{"location":"Roadmap/","title":"Roadmap","text":"<p>The OTP community uses a GitHub-hosted Roadmap to document all long-term feature requests for OpenTripPlanner. Unlike typical OTP Issues, the Roadmap outlines quarterly and yearly product-focused goals the community intends to propose for OTP, rather than short-term bug fixes or feature requests.</p> <p>Twice a year, product owners (POs) and developers will review and clean up the issues at the PO meetings. Product owner (PO) meetings are open to everyone interested in OTP and are held on the first Tuesday of each month at 7 AM US Pacific / 10 AM  US Eastern / 4PM CET. To join, please consult this calender. For other questions, please contact members in the Gitter chat or the user mailing list.</p> <p>To create an issue on the OTP Roadmap, follow these steps:</p> <ol> <li>Navigate to the OpenTripPlanner GitHub.</li> <li>Select the \"Projects\" tab.    </li> <li>Choose the \"Roadmap\" project.    </li> <li>To add an issue, click \"Add item\" under the \"Wish list\" column.  </li> <li>Click the \"+\" icon, then \"Create a new issue.\" </li> <li>Select the \"Roadmap Epic\" type by clicking \"Choose.\"    </li> <li> <p>Complete the required fields:</p> <ul> <li>What: Clearly state the desired changes or new features.</li> <li>Why: Clearly state the expected impact or outcome of these changes.</li> <li>When: Provide a timeline or timeframe for implementing these changes.</li> <li>Link issue(s) related to or part of yours.</li> <li>Use labels to indicate which organizations have an interest in this Roadmap issue or to classify the Issue.</li> </ul> <p></p> </li> </ol> <p>Then, click \"Create.\"</p> <p>This is what your completed Roadmap Issue should like: </p> <p>Discussions about the Issue within the corresponding Gitter chat are encouraged, along with participation in the OTP product owner (PO) or developer meetings.</p>"},{"location":"RouteRequest/","title":"Route Request","text":""},{"location":"RouteRequest/#route-request","title":"Route Request","text":"<p>The RouteRequest is the type for the routingDefaults in router-config.json  and in the transferRequests in build-config.json.</p> Config Parameter Type Summary Req./Opt. Default Value Since alightSlack <code>duration</code> The minimum extra time after exiting a public transport vehicle. Optional <code>\"PT0S\"</code> 2.0 arriveBy <code>boolean</code> Whether the trip should depart or arrive at the specified date and time. Optional <code>false</code> 2.0 boardSlack <code>duration</code> The boardSlack is the minimum extra time to board a public transport vehicle. Optional <code>\"PT0S\"</code> 2.0 drivingDirection <code>enum</code> The driving direction to use in the intersection traversal calculation Optional <code>\"right\"</code> 2.2 elevatorBoardCost <code>integer</code> What is the cost of boarding a elevator? Optional <code>90</code> 2.0 elevatorBoardTime <code>integer</code> How long does it take to get on an elevator, on average. Optional <code>90</code> 2.0 elevatorHopCost <code>integer</code> What is the cost of travelling one floor on an elevator? Optional <code>20</code> 2.0 elevatorHopTime <code>integer</code> How long does it take to advance one floor on an elevator? Optional <code>20</code> 2.0 geoidElevation <code>boolean</code> If true, the Graph's ellipsoidToGeoidDifference is applied to all elevations returned by this query. Optional <code>false</code> 2.0 ignoreRealtimeUpdates <code>boolean</code> When true, real-time updates are ignored during this search. Optional <code>false</code> 2.0 intersectionTraversalModel <code>enum</code> The model that computes the costs of turns. Optional <code>\"simple\"</code> 2.2 locale <code>locale</code> TODO Optional <code>\"en_US\"</code> 2.0 maxDirectStreetDuration <code>duration</code> This is the maximum duration for a direct street search for each mode. Optional <code>\"PT4H\"</code> 2.1 maxJourneyDuration <code>duration</code> The expected maximum time a journey can last across all possible journeys for the current deployment. Optional <code>\"PT24H\"</code> 2.1 modes <code>string</code> The set of access/egress/direct/transit modes to be used for the route search. Optional <code>\"TRANSIT,WALK\"</code> 2.0 nonpreferredTransferPenalty <code>integer</code> Penalty (in seconds) for using a non-preferred transfer. Optional <code>180</code> 2.0 numItineraries <code>integer</code> The maximum number of itineraries to return. Optional <code>50</code> 2.0 otherThanPreferredRoutesPenalty <code>integer</code> Penalty added for using every route that is not preferred if user set any route as preferred. Optional <code>300</code> 2.0 relaxTransitGroupPriority <code>string</code> The relax function for transit-group-priority Optional <code>\"0s + 1.00 t\"</code> 2.5 relaxTransitSearchGeneralizedCostAtDestination <code>double</code> Whether non-optimal transit paths at the destination should be returned Optional 2.3 searchWindow <code>duration</code> The duration of the search-window. Optional 2.0 streetRoutingTimeout <code>duration</code> The maximum time a street routing request is allowed to take before returning the results. Optional <code>\"PT5S\"</code> 2.2 transferPenalty <code>integer</code> An additional penalty added to boardings after the first. Optional <code>0</code> 2.0 transferSlack <code>integer</code> The extra time needed to make a safe transfer in seconds. Optional <code>120</code> 2.0 turnReluctance <code>double</code> Multiplicative factor on expected turning time. Optional <code>1.0</code> 2.0 unpreferredCost <code>cost-linear-function</code> A cost function used to calculate penalty for an unpreferred route. Optional <code>\"0s + 1.00 t\"</code> 2.2 waitReluctance <code>double</code> How much worse is waiting for a transit vehicle than being on a transit vehicle, as a multiplier. Optional <code>1.0</code> 2.0 accessEgress <code>object</code> Parameters for access and egress routing. Optional 2.4 maxDuration <code>duration</code> This is the maximum duration for access/egress for street searches. Optional <code>\"PT45M\"</code> 2.1 maxStopCount <code>integer</code> Maximal number of stops collected in access/egress routing Optional <code>500</code> 2.4 maxDurationForMode <code>enum map of duration</code> Limit access/egress per street mode. Optional 2.1 penalty <code>enum map of object</code> Penalty for access/egress by street mode. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0FLEXIBLE <code>object</code> NA Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0costFactor <code>double</code> A factor multiplied with the time-penalty to get the cost-penalty. Optional <code>0.0</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0timePenalty <code>time-penalty</code> Penalty added to the time of a path/leg. Optional <code>\"0s + 0.00 t\"</code> 2.4 alightSlackForMode <code>enum map of duration</code> How much extra time should be given when alighting a vehicle for each given mode. Optional 2.0 bicycle <code>object</code> Bicycle preferences. Optional 2.5 boardCost <code>integer</code> Prevents unnecessary transfers by adding a cost for boarding a transit vehicle. Optional <code>600</code> 2.0 optimization <code>enum</code> The set of characteristics that the user wants to optimize for. Optional <code>\"safe-streets\"</code> 2.0 \u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad cycling is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 \u00a0\u00a0\u00a0speed <code>double</code> Max bicycle speed along streets, in meters per second Optional <code>5.0</code> 2.0 \u00a0\u00a0\u00a0parking <code>object</code> Preferences for parking a vehicle. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0cost <code>integer</code> Cost to park a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>duration</code> Time to park a vehicle. Optional <code>\"PT1M\"</code> 2.0 unpreferredVehicleParkingTagCost <code>integer</code> What cost to add if a parking facility doesn't contain a preferred tag. Optional <code>300</code> 2.3 bannedVehicleParkingTags <code>string[]</code> Tags with which a vehicle parking will not be used. If empty, no tags are banned. Optional 2.1 preferredVehicleParkingTags <code>string[]</code> Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised. Optional 2.3 requiredVehicleParkingTags <code>string[]</code> Tags without which a vehicle parking will not be used. If empty, no tags are required. Optional 2.1 \u00a0\u00a0\u00a0rental <code>object</code> Vehicle rental options Optional 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowKeepingAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffCost <code>integer</code> Cost to drop-off a rented vehicle. Optional <code>30</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffTime <code>duration</code> Time to drop-off a rented vehicle. Optional <code>\"PT30S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0keepingAtDestinationCost <code>integer</code> The cost of arriving at the destination with the rented vehicle, to discourage doing so. Optional <code>0</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupCost <code>integer</code> Cost to rent a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupTime <code>duration</code> Time to rent a vehicle. Optional <code>\"PT1M\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0useAvailabilityInformation <code>boolean</code> Whether or not vehicle rental availability information will be used to plan vehicle rental trips. Optional <code>false</code> 2.0 allowedNetworks <code>string[]</code> The vehicle rental networks which may be used. If empty all networks may be used. Optional 2.1 bannedNetworks <code>string[]</code> The vehicle rental networks which may not be used. If empty, no networks are banned. Optional 2.1 triangle <code>object</code> Triangle optimization criteria. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flatness <code>double</code> Relative importance of flat terrain (range 0-1). Optional <code>0.0</code> 2.0 safety <code>double</code> Relative importance of safety (range 0-1). Optional <code>0.0</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>double</code> Relative importance of duration of travel (range 0-1). Optional <code>0.0</code> 2.0 \u00a0\u00a0\u00a0walk <code>object</code> Preferences for walking a vehicle. Optional 2.5 hopCost <code>integer</code> The cost of hopping on or off a vehicle. Optional <code>0</code> 2.0 hopTime <code>duration</code> The time it takes the user to hop on or off a vehicle. Optional <code>\"PT0S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad walking with a vehicle is, compared to being in transit for equal lengths of time. Optional <code>5.0</code> 2.1 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0speed <code>double</code> The user's vehicle walking speed in meters/second. Defaults to approximately 3 MPH. Optional <code>1.33</code> 2.1 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0stairsReluctance <code>double</code> How bad is it to walk the vehicle up/down a flight of stairs compared to taking a detour. Optional <code>10.0</code> 2.3 boardSlackForMode <code>enum map of duration</code> How much extra time should be given when boarding a vehicle for each given mode. Optional 2.0 car <code>object</code> Car preferences. Optional 2.5 \u00a0\u00a0\u00a0accelerationSpeed <code>double</code> The acceleration speed of an automobile, in meters per second per second. Optional <code>2.9</code> 2.0 \u00a0\u00a0\u00a0decelerationSpeed <code>double</code> The deceleration speed of an automobile, in meters per second per second. Optional <code>2.9</code> 2.0 \u00a0\u00a0\u00a0pickupCost <code>integer</code> Add a cost for car pickup changes when a pickup or drop off takes place Optional <code>120</code> 2.1 \u00a0\u00a0\u00a0pickupTime <code>duration</code> Add a time for car pickup changes when a pickup or drop off takes place Optional <code>\"PT1M\"</code> 2.1 \u00a0\u00a0\u00a0reluctance <code>double</code> A multiplier for how bad driving is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 \u00a0\u00a0\u00a0speed <code>double</code> Max car speed along streets, in meters per second Optional <code>40.0</code> 2.0 \u00a0\u00a0\u00a0parking <code>object</code> Preferences for parking a vehicle. Optional 2.5 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0cost <code>integer</code> Cost to park a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0time <code>duration</code> Time to park a vehicle. Optional <code>\"PT1M\"</code> 2.0 unpreferredVehicleParkingTagCost <code>integer</code> What cost to add if a parking facility doesn't contain a preferred tag. Optional <code>300</code> 2.3 bannedVehicleParkingTags <code>string[]</code> Tags with which a vehicle parking will not be used. If empty, no tags are banned. Optional 2.1 preferredVehicleParkingTags <code>string[]</code> Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised. Optional 2.3 requiredVehicleParkingTags <code>string[]</code> Tags without which a vehicle parking will not be used. If empty, no tags are required. Optional 2.1 \u00a0\u00a0\u00a0rental <code>object</code> Vehicle rental options Optional 2.3 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowKeepingAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffCost <code>integer</code> Cost to drop-off a rented vehicle. Optional <code>30</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0dropOffTime <code>duration</code> Time to drop-off a rented vehicle. Optional <code>\"PT30S\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0keepingAtDestinationCost <code>integer</code> The cost of arriving at the destination with the rented vehicle, to discourage doing so. Optional <code>0</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupCost <code>integer</code> Cost to rent a vehicle. Optional <code>120</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pickupTime <code>duration</code> Time to rent a vehicle. Optional <code>\"PT1M\"</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0useAvailabilityInformation <code>boolean</code> Whether or not vehicle rental availability information will be used to plan vehicle rental trips. Optional <code>false</code> 2.0 allowedNetworks <code>string[]</code> The vehicle rental networks which may be used. If empty all networks may be used. Optional 2.1 bannedNetworks <code>string[]</code> The vehicle rental networks which may not be used. If empty, no networks are banned. Optional 2.1 itineraryFilters <code>object</code> Configure itinerary filters that may modify itineraries, sort them, and filter away less preferable results. Optional 2.0 accessibilityScore <code>boolean</code> An experimental feature contributed by IBI which adds a sandbox accessibility score between 0 and 1 for each leg and itinerary. Optional <code>false</code> 2.2 bikeRentalDistanceRatio <code>double</code> Filter routes that consist of bike-rental and walking by the minimum fraction of the bike-rental leg using distance. Optional <code>0.0</code> 2.1 debug <code>enum</code> Enable this to attach a system notice to itineraries instead of removing them. This is very convenient when tuning the itinerary-filter-chain. Optional <code>\"off\"</code> 2.0 filterItinerariesWithSameFirstOrLastTrip <code>boolean</code> If more than one itinerary begins or ends with same trip, filter out one of those itineraries so that only one remains. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0groupSimilarityKeepOne <code>double</code> Pick ONE itinerary from each group after putting itineraries that are 85% similar together. Optional <code>0.85</code> 2.1 \u00a0\u00a0\u00a0groupSimilarityKeepThree <code>double</code> Reduce the number of itineraries to three itineraries by reducing each group of itineraries grouped by 68% similarity. Optional <code>0.68</code> 2.1 groupedOtherThanSameLegsMaxCostMultiplier <code>double</code> Filter grouped itineraries, where the non-grouped legs are more expensive than in the lowest cost one. Optional <code>2.0</code> 2.1 minBikeParkingDistance <code>double</code> Filter out bike park+ride results that have fewer meters of cycling than this value. Optional <code>0.0</code> 2.3 nonTransitGeneralizedCostLimit <code>cost-linear-function</code> The function define a max-limit for generalized-cost for non-transit itineraries. Optional <code>\"1h + 2.0 t\"</code> 2.1 parkAndRideDurationRatio <code>double</code> Filter P+R routes that consist of driving and walking by the minimum fraction of the driving using of time. Optional <code>0.0</code> 2.1 removeItinerariesWithSameRoutesAndStops <code>boolean</code> Set to true if you want to list only the first itinerary  which goes through the same stops and routes. Optional <code>false</code> 2.2 removeTransitWithHigherCostThanBestOnStreetOnly <code>cost-linear-function</code> Limit function for generalized-cost computed from street-only itineries applied to transit itineraries. Optional <code>\"1m + 1.30 t\"</code> 2.4 transitGeneralizedCostLimit <code>object</code> A relative limit for the generalized-cost for transit itineraries. Optional 2.1 costLimitFunction <code>cost-linear-function</code> The base function used by the filter. Optional <code>\"15m + 1.50 t\"</code> 2.2 intervalRelaxFactor <code>double</code> How much the filter should be relaxed for itineraries that do not overlap in time. Optional <code>0.4</code> 2.2 maxDirectStreetDurationForMode <code>enum map of duration</code> Limit direct route duration per street mode. Optional 2.2 transferOptimization <code>object</code> Optimize where a transfer between to trip happens. Optional 2.1 backTravelWaitTimeFactor <code>double</code> To reduce back-travel we favor waiting, this reduces the cost of waiting. Optional <code>1.0</code> 2.1 extraStopBoardAlightCostsFactor <code>double</code> Add an extra board- and alight-cost for prioritized stops. Optional <code>0.0</code> 2.1 minSafeWaitTimeFactor <code>double</code> Used to set a maximum wait-time cost, base on min-safe-transfer-time. Optional <code>5.0</code> 2.1 optimizeTransferWaitTime <code>boolean</code> This enables the transfer wait time optimization. Optional <code>true</code> 2.1 transitGroupPriority <code>object</code> Group transit patterns and give each group a mutual advantage in the Raptor search. Optional 2.5 transitReluctanceForMode <code>enum map of double</code> Transit reluctance for a given transport mode Optional 2.1 unpreferred <code>object</code> Parameters listing authorities or lines that preferably should not be used in trip patters. Optional 2.2 agencies <code>feed-scoped-id[]</code> The ids of the agencies that incur an extra cost when being used. Format: <code>FeedId:AgencyId</code> Optional 2.2 routes <code>feed-scoped-id[]</code> The ids of the routes that incur an extra cost when being used. Format: <code>FeedId:RouteId</code> Optional 2.2 walk <code>object</code> Walking preferences. Optional 2.5 \u00a0\u00a0\u00a0boardCost <code>integer</code> Prevents unnecessary transfers by adding a cost for boarding a vehicle. This is the cost that is used when boarding while walking. Optional <code>600</code> 2.0 \u00a0\u00a0\u00a0escalatorReluctance <code>double</code> A multiplier for how bad being in an escalator is compared to being in transit for equal lengths of time Optional <code>1.5</code> 2.4 reluctance <code>double</code> A multiplier for how bad walking is, compared to being in transit for equal lengths of time. Optional <code>2.0</code> 2.0 safetyFactor <code>double</code> Factor for how much the walk safety is considered in routing. Optional <code>1.0</code> 2.2 \u00a0\u00a0\u00a0speed <code>double</code> The user's walking speed in meters/second. Optional <code>1.33</code> 2.0 \u00a0\u00a0\u00a0stairsReluctance <code>double</code> Used instead of walkReluctance for stairs. Optional <code>2.0</code> 2.0 stairsTimeFactor <code>double</code> How much more time does it take to walk a flight of stairs compared to walking a similar horizontal length. Optional <code>3.0</code> 2.1 wheelchairAccessibility <code>object</code> See Wheelchair Accessibility Optional 2.2 \u00a0\u00a0\u00a0enabled <code>boolean</code> Enable wheelchair accessibility. Optional <code>false</code> 2.0 \u00a0\u00a0\u00a0inaccessibleStreetReluctance <code>double</code> The factor to multiply the cost of traversing a street edge that is not wheelchair-accessible. Optional <code>25.0</code> 2.2 maxSlope <code>double</code> The maximum slope as a fraction of 1. Optional <code>0.083</code> 2.0 slopeExceededReluctance <code>double</code> How much streets with high slope should be avoided. Optional <code>1.0</code> 2.2 stairsReluctance <code>double</code> How much stairs should be avoided. Optional <code>100.0</code> 2.2 \u00a0\u00a0\u00a0elevator <code>object</code> Configuration for when to use inaccessible elevators. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>false</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>20</code> 2.2 \u00a0\u00a0\u00a0stop <code>object</code> Configuration for when to use inaccessible stops. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>true</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>600</code> 2.2 \u00a0\u00a0\u00a0trip <code>object</code> Configuration for when to use inaccessible trips. Optional 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inaccessibleCost <code>integer</code> The cost to add when traversing an entity which is know to be inaccessible. Optional <code>3600</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0onlyConsiderAccessible <code>boolean</code> Whether to only use this entity if it is explicitly marked as wheelchair accessible. Optional <code>true</code> 2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0unknownCost <code>integer</code> The cost to add when traversing an entity with unknown accessibility information. Optional <code>600</code> 2.2"},{"location":"RouteRequest/#parameter-details","title":"Parameter Details","text":""},{"location":"RouteRequest/#rd_alightSlack","title":"alightSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults </p> <p>The minimum extra time after exiting a public transport vehicle.</p> <p>The slack is added to the time when going from the transit vehicle to the stop.</p>"},{"location":"RouteRequest/#rd_boardSlack","title":"boardSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults </p> <p>The boardSlack is the minimum extra time to board a public transport vehicle.</p> <p>The board time is added to the time when going from the stop (offboard) to onboard a transit vehicle.</p> <p>This is the same as the <code>transferSlack</code>, except that this also apply to to the first transit leg in the trip. This is the default value used, if not overridden by the <code>boardSlackList</code>.</p>"},{"location":"RouteRequest/#rd_drivingDirection","title":"drivingDirection","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"right\"</code> Path: /routingDefaults  Enum values: <code>right</code> | <code>left</code></p> <p>The driving direction to use in the intersection traversal calculation</p>"},{"location":"RouteRequest/#rd_intersectionTraversalModel","title":"intersectionTraversalModel","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"simple\"</code> Path: /routingDefaults  Enum values: <code>simple</code> | <code>constant</code></p> <p>The model that computes the costs of turns.</p>"},{"location":"RouteRequest/#rd_maxDirectStreetDuration","title":"maxDirectStreetDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT4H\"</code> Path: /routingDefaults </p> <p>This is the maximum duration for a direct street search for each mode.</p> <p>This is a performance limit and should therefore be set high. Results close to the limit are not guaranteed to be optimal. Use itinerary-filters to limit what is presented to the client. The duration can be set per mode(<code>maxDirectStreetDurationForMode</code>), because some street modes searches are much more resource intensive than others. A default value is applied if the mode specific value do not exist.\"</p>"},{"location":"RouteRequest/#rd_maxJourneyDuration","title":"maxJourneyDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT24H\"</code> Path: /routingDefaults </p> <p>The expected maximum time a journey can last across all possible journeys for the current deployment.</p> <p>Normally you would just do an estimate and add enough slack, so you are sure that there is no journeys that falls outside this window. The parameter is used find all possible dates for the journey and then search only the services which run on those dates. The duration must include access, egress, wait-time and transit time for the whole journey. It should also take low frequency days/periods like holidays into account. In other words, pick the two points within your area that has the worst connection and then try to travel on the worst possible day, and find the maximum journey duration. Using a value that is too high has the effect of including more patterns in the search, hence, making it a bit slower. Recommended values would be from 12 hours(small town/city), 1 day (region) to 2 days (country like Norway).\"</p>"},{"location":"RouteRequest/#rd_otherThanPreferredRoutesPenalty","title":"otherThanPreferredRoutesPenalty","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults </p> <p>Penalty added for using every route that is not preferred if user set any route as preferred.</p> <p>We return number of seconds that we are willing to wait for preferred route.</p>"},{"location":"RouteRequest/#rd_relaxTransitGroupPriority","title":"relaxTransitGroupPriority","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"0s + 1.00 t\"</code> Path: /routingDefaults </p> <p>The relax function for transit-group-priority</p> <p>A path is considered optimal if the generalized-cost is less than the generalized-cost of another path. If this parameter is set, the comparison is relaxed further if they belong to different transit groups.</p>"},{"location":"RouteRequest/#rd_relaxTransitSearchGeneralizedCostAtDestination","title":"relaxTransitSearchGeneralizedCostAtDestination","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Whether non-optimal transit paths at the destination should be returned</p> <p>Let c be the existing minimum pareto optimal generalized cost to beat. Then a trip with cost c' is accepted if the following is true: <code>c' &lt; Math.round(c * relaxRaptorCostCriteria)</code>.</p> <p>The parameter is optional. If not set a normal comparison is performed.</p> <p>Values equals or less than zero is not allowed. Values greater than 2.0 are not supported, due to performance reasons.</p>"},{"location":"RouteRequest/#rd_searchWindow","title":"searchWindow","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>The duration of the search-window.</p> <p>This is the time/duration in seconds from the earliest-departure-time(EDT) to the latest-departure-time(LDT). In case of a reverse search it will be the time from earliest to latest arrival time (LAT - EAT).</p> <p>All optimal travels that depart within the search window is guaranteed to be found.</p> <p>This is sometimes referred to as the Range Raptor Search Window - but could be used in a none Transit search as well; Hence this is named search-window and not raptor-search-window.</p> <p>This is normally dynamically calculated by the server. Use <code>null</code> to unset, and zero to do one Raptor iteration. The value is dynamically  assigned a suitable value, if not set. In a small to medium size operation you may use a fixed value, like 60 minutes. If you have a mixture of high frequency cities routes and  infrequent long distant journeys, the best option is normally to use the dynamic auto assignment. If not provided the value is resolved depending on the other input parameters, available transit options and realtime changes.</p> <p>There is no need to set this when going to the next/previous page. The OTP Server will increase/decrease the search-window when paging to match the requested number of itineraries.</p>"},{"location":"RouteRequest/#rd_streetRoutingTimeout","title":"streetRoutingTimeout","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT5S\"</code> Path: /routingDefaults </p> <p>The maximum time a street routing request is allowed to take before returning the results.</p> <p>The street search(AStar) aborts after this duration and any paths found are returned to the client. The street part of the routing may take a long time if searching very long distances. You can set the street routing timeout to avoid tying up server resources on pointless searches and ensure that your users receive a timely response. You can also limit the max duration. There are is also a 'apiProcessingTimeout'. Make sure the street timeout is less than the 'apiProcessingTimeout'.</p>"},{"location":"RouteRequest/#rd_transferPenalty","title":"transferPenalty","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /routingDefaults </p> <p>An additional penalty added to boardings after the first.</p> <p>The value is in OTP's internal weight units, which are roughly equivalent to seconds. Set this to a high value to discourage transfers. Of course, transfers that save significant time or walking will still be taken.</p>"},{"location":"RouteRequest/#rd_transferSlack","title":"transferSlack","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>120</code> Path: /routingDefaults </p> <p>The extra time needed to make a safe transfer in seconds.</p> <p>An expected transfer time in seconds that specifies the amount of time that must pass between exiting one public transport vehicle and boarding another. This time is in addition to time it might take to walk between stops plus <code>boardSlack</code> and <code>alightSlack</code>.</p>"},{"location":"RouteRequest/#rd_unpreferredCost","title":"unpreferredCost","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"0s + 1.00 t\"</code> Path: /routingDefaults </p> <p>A cost function used to calculate penalty for an unpreferred route.</p> <p>Function should return number of seconds that we are willing to wait for preferred route or for an unpreferred agency's departure. For example: <code>5m + 2.0 t</code></p>"},{"location":"RouteRequest/#rd_accessEgress_maxDuration","title":"maxDuration","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /routingDefaults/accessEgress </p> <p>This is the maximum duration for access/egress for street searches.</p> <p>This is a performance limit and should therefore be set high. Results close to the limit are not guaranteed to be optimal. Use itinerary-filters to limit what is presented to the client. The duration can be set per mode(<code>maxDurationForMode</code>), because some street modes searches are much more resource intensive than others. A default value is applied if the mode specific value do not exist.</p>"},{"location":"RouteRequest/#rd_accessEgress_maxStopCount","title":"maxStopCount","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>500</code> Path: /routingDefaults/accessEgress </p> <p>Maximal number of stops collected in access/egress routing</p> <p>Safety limit to prevent access to and egress from too many stops.</p>"},{"location":"RouteRequest/#rd_accessEgress_maxDurationForMode","title":"maxDurationForMode","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/accessEgress  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Limit access/egress per street mode.</p> <p>Override the settings in <code>maxDuration</code> for specific street modes. This is done because some street modes searches are much more resource intensive than others.</p>"},{"location":"RouteRequest/#rd_accessEgress_penalty","title":"penalty","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>enum map of object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/accessEgress  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Penalty for access/egress by street mode.</p> <p>Use this to add a time and cost penalty to an access/egress legs for a given street mode. This will favour other street-modes and transit. This has a performance penalty, since the search-window is increased with the same amount as the maximum penalty for the access legs used. In other cases where the access(CAR) is faster than transit the performance will be better.</p> <p>The default is no penalty, if not configured.</p> <p>Example: <code>\"car-to-park\" : { \"timePenalty\": \"10m + 1.5t\", \"costFactor\": 2.5 }</code></p> <p>Time penalty</p> <p>The <code>timePenalty</code> is used to add a penalty to the access/egress duration/time. The time including the penalty is used in the algorithm when comparing paths, but the actual duration is used when presented to the end user.</p> <p>Cost factor</p> <p>The <code>costFactor</code> is used to add an additional cost to the leg\u00b4s  generalized-cost. The time-penalty is multiplied with the cost-factor. A cost-factor of zero, gives no extra cost, while 1.0 will add the same amount to both time and cost.</p>"},{"location":"RouteRequest/#rd_alightSlackForMode","title":"alightSlackForMode","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>How much extra time should be given when alighting a vehicle for each given mode.</p> <p>Sometimes there is a need to configure a longer alighting times for specific modes, such as airplanes or ferries.</p>"},{"location":"RouteRequest/#rd_bicycle_boardCost","title":"boardCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>600</code> Path: /routingDefaults/bicycle </p> <p>Prevents unnecessary transfers by adding a cost for boarding a transit vehicle.</p> <p>This is the cost that is used when boarding while cycling. This is usually higher that walkBoardCost.</p>"},{"location":"RouteRequest/#rd_bicycle_optimization","title":"optimization","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"safe-streets\"</code> Path: /routingDefaults/bicycle  Enum values: <code>shortest-duration</code> | <code>safe-streets</code> | <code>flat-streets</code> | <code>safest-streets</code> | <code>triangle</code></p> <p>The set of characteristics that the user wants to optimize for.</p> <p>If the triangle optimization is used, it's enough to just define the triangle parameters</p>"},{"location":"RouteRequest/#rd_bicycle_parking_unpreferredVehicleParkingTagCost","title":"unpreferredVehicleParkingTagCost","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults/bicycle/parking </p> <p>What cost to add if a parking facility doesn't contain a preferred tag.</p> <p>See <code>preferredVehicleParkingTags</code>.</p>"},{"location":"RouteRequest/#rd_bicycle_parking_bannedVehicleParkingTags","title":"bannedVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Tags with which a vehicle parking will not be used. If empty, no tags are banned.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_parking_preferredVehicleParkingTags","title":"preferredVehicleParkingTags","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_parking_requiredVehicleParkingTags","title":"requiredVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/parking </p> <p>Tags without which a vehicle parking will not be used. If empty, no tags are required.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_bicycle_rental_allowedNetworks","title":"allowedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/rental </p> <p>The vehicle rental networks which may be used. If empty all networks may be used.</p>"},{"location":"RouteRequest/#rd_bicycle_rental_bannedNetworks","title":"bannedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle/rental </p> <p>The vehicle rental networks which may not be used. If empty, no networks are banned.</p>"},{"location":"RouteRequest/#rd_bicycle_triangle","title":"triangle","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/bicycle </p> <p>Triangle optimization criteria.</p> <p>Optimization type doesn't need to be defined if these values are defined.</p>"},{"location":"RouteRequest/#rd_bicycle_triangle_safety","title":"safety","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/bicycle/triangle </p> <p>Relative importance of safety (range 0-1).</p> <p>This factor can also include other concerns such as convenience and general cyclist preferences by taking into account road surface etc.</p>"},{"location":"RouteRequest/#rd_bicycle_walk_hopCost","title":"hopCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /routingDefaults/bicycle/walk </p> <p>The cost of hopping on or off a vehicle.</p> <p>There are different parameters for the cost of renting or parking a vehicle and this is not meant for controlling the cost of those events.</p>"},{"location":"RouteRequest/#rd_bicycle_walk_hopTime","title":"hopTime","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /routingDefaults/bicycle/walk </p> <p>The time it takes the user to hop on or off a vehicle.</p> <p>Time it takes to rent or park a vehicle have their own parameters and this is not meant for controlling the duration of those events.</p>"},{"location":"RouteRequest/#rd_boardSlackForMode","title":"boardSlackForMode","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>How much extra time should be given when boarding a vehicle for each given mode.</p> <p>Sometimes there is a need to configure a board times for specific modes, such as airplanes or ferries, where the check-in process needs to be done in good time before ride.</p>"},{"location":"RouteRequest/#rd_car_parking_unpreferredVehicleParkingTagCost","title":"unpreferredVehicleParkingTagCost","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>300</code> Path: /routingDefaults/car/parking </p> <p>What cost to add if a parking facility doesn't contain a preferred tag.</p> <p>See <code>preferredVehicleParkingTags</code>.</p>"},{"location":"RouteRequest/#rd_car_parking_bannedVehicleParkingTags","title":"bannedVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Tags with which a vehicle parking will not be used. If empty, no tags are banned.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_parking_preferredVehicleParkingTags","title":"preferredVehicleParkingTags","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Vehicle parking facilities that don't have one of these tags will receive an extra cost and will therefore be penalised.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_parking_requiredVehicleParkingTags","title":"requiredVehicleParkingTags","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/parking </p> <p>Tags without which a vehicle parking will not be used. If empty, no tags are required.</p> <p>Vehicle parking tags can originate from different places depending on the origin of the parking(OSM or RT feed).</p>"},{"location":"RouteRequest/#rd_car_rental_allowedNetworks","title":"allowedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/rental </p> <p>The vehicle rental networks which may be used. If empty all networks may be used.</p>"},{"location":"RouteRequest/#rd_car_rental_bannedNetworks","title":"bannedNetworks","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/car/rental </p> <p>The vehicle rental networks which may not be used. If empty, no networks are banned.</p>"},{"location":"RouteRequest/#rd_itineraryFilters","title":"itineraryFilters","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Configure itinerary filters that may modify itineraries, sort them, and filter away less preferable results.</p> <p>The purpose of the itinerary filter chain is to post process the result returned by the routing search. The filters may modify itineraries, sort them, and filter away less preferable results.</p> <p>OTP2 may produce numerous pareto-optimal results when using <code>time</code>, <code>number-of-transfers</code> and <code>generalized-cost</code> as criteria. Use the parameters listed here to reduce/filter the itineraries return by the search engine before returning the results to client. There is also a few mandatory non-configurable filters removing none optimal results. You may see these filters pop-up in the filter debugging.</p>"},{"location":"RouteRequest/#group-by-similarity-filters","title":"Group by similarity filters","text":"<p>The group-by-filter is a bit complex, but should be simple to use. Set <code>debug=true</code> and experiment with <code>searchWindow</code> and the three group-by parameters(<code>groupSimilarityKeepOne</code>, <code>groupSimilarityKeepThree</code> and <code>groupedOtherThanSameLegsMaxCostMultiplier</code>).</p> <p>The group-by-filter work by grouping itineraries together and then reducing the number of itineraries in each group, keeping the itinerary/itineraries with the best itinerary generalized-cost. The group-by function first pick all transit legs that account for more than N% of the itinerary based on distance traveled. This become the group-key. Two keys are the same if all legs in one of the keys also exist in the other. Note, one key may have a larger set of legs than the other, but they can still be the same. When comparing two legs we compare the <code>tripId</code> and make sure the legs overlap in place and time. Two legs are the same if both legs ride at least a common subsection of the same trip. The <code>keepOne</code> filter will keep ONE itinerary in each group. The <code>keepThree</code> keeps 3 itineraries for each group.</p> <p>The grouped itineraries can be further reduced by using <code>groupedOtherThanSameLegsMaxCostMultiplier</code>. This parameter filters out itineraries, where the legs that are not common for all the grouped itineraries have a much higher cost, than the lowest in the group. By default, it filters out itineraries that are at least double in cost for the non-grouped legs.</p>"},{"location":"RouteRequest/#rd_if_accessibilityScore","title":"accessibilityScore","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>An experimental feature contributed by IBI which adds a sandbox accessibility score between 0 and 1 for each leg and itinerary.</p> <p>This can be used by frontend developers to implement a simple traffic light UI.</p>"},{"location":"RouteRequest/#rd_if_bikeRentalDistanceRatio","title":"bikeRentalDistanceRatio","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter routes that consist of bike-rental and walking by the minimum fraction of the bike-rental leg using distance.</p> <p>This filters out results that consist of a long walk plus a relatively short bike rental leg. A value of <code>0.3</code> means that a minimum of 30% of the total distance must be spent on the bike in order for the result to be included.</p>"},{"location":"RouteRequest/#rd_if_debug","title":"debug","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"off\"</code> Path: /routingDefaults/itineraryFilters  Enum values: <code>off</code> | <code>list-all</code> | <code>limit-to-search-window</code> | <code>limit-to-num-of-itineraries</code></p> <p>Enable this to attach a system notice to itineraries instead of removing them. This is very convenient when tuning the itinerary-filter-chain.</p> <ul> <li><code>off</code> By default, the debug itinerary filters is turned off.</li> <li><code>list-all</code> List all itineraries, including all deleted itineraries.</li> <li><code>limit-to-search-window</code> Return all itineraries, including deleted ones, inside the actual search-window used    (the requested search-window may differ).</li> <li><code>limit-to-num-of-itineraries</code> Only return the requested number of itineraries, counting both actual and deleted ones.    The top <code>numItineraries</code> using the request sort order is returned. This does not work    with paging, itineraries after the limit, but inside the search-window are skipped when    moving to the next page.</li> </ul>"},{"location":"RouteRequest/#rd_if_filterItinerariesWithSameFirstOrLastTrip","title":"filterItinerariesWithSameFirstOrLastTrip","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>If more than one itinerary begins or ends with same trip, filter out one of those itineraries so that only one remains.</p> <p>Trips are considered equal if they have same id and same service day. Non-transit legs are skipped during comparison. Before filtering, trips are sorted by their generalized cost. The algorithm loops through the list from top to bottom. If an itinerary matches from any other itinerary from above, it is removed from list.</p>"},{"location":"RouteRequest/#rd_if_groupedOtherThanSameLegsMaxCostMultiplier","title":"groupedOtherThanSameLegsMaxCostMultiplier","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter grouped itineraries, where the non-grouped legs are more expensive than in the lowest cost one.</p> <p>Of the itineraries grouped to maximum of three itineraries, how much worse can the non-grouped legs be compared to the lowest cost. 2.0 means that they can be double the cost, and any itineraries having a higher cost will be filtered.</p>"},{"location":"RouteRequest/#rd_if_minBikeParkingDistance","title":"minBikeParkingDistance","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter out bike park+ride results that have fewer meters of cycling than this value.</p> <p>Useful if you want to exclude those routes which have only a few meters of cycling before parking the bike and taking public transport.</p>"},{"location":"RouteRequest/#rd_if_nonTransitGeneralizedCostLimit","title":"nonTransitGeneralizedCostLimit","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"1h + 2.0 t\"</code> Path: /routingDefaults/itineraryFilters </p> <p>The function define a max-limit for generalized-cost for non-transit itineraries.</p> <p>The max-limit is applied to itineraries with no transit legs, however all itineraries (including those with transit legs) are considered when calculating the minimum cost. The smallest generalized-cost value is used as input to the function. The function is used to calculate a max-limit. The max-limit is then used to filter non-transit itineraries by generalized-cost. Itineraries with a cost higher than the max-limit are dropped from the result set.</p> <p>For example if the function is <code>f(x) = 30m + 2.0 x</code> and the smallest cost is <code>30m = 1800s</code>, then all non-transit itineraries with a cost larger than <code>1800 + 2 * 5000 = 11 800</code> are dropped.</p>"},{"location":"RouteRequest/#rd_if_parkAndRideDurationRatio","title":"parkAndRideDurationRatio","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/itineraryFilters </p> <p>Filter P+R routes that consist of driving and walking by the minimum fraction of the driving using of time.</p> <p>This filters out results that consist of driving plus a very long walk leg at the end. A value of <code>0.3</code> means that a minimum of 30% of the total time must be spent in the car in order for the result to be included. However, if there is only a single result, it is never filtered.</p>"},{"location":"RouteRequest/#rd_if_removeItinerariesWithSameRoutesAndStops","title":"removeItinerariesWithSameRoutesAndStops","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /routingDefaults/itineraryFilters </p> <p>Set to true if you want to list only the first itinerary  which goes through the same stops and routes.</p> <p>Itineraries visiting the same set of stops and riding the exact same routes, departing later are removed from the result.</p>"},{"location":"RouteRequest/#rd_if_removeTransitWithHigherCostThanBestOnStreetOnly","title":"removeTransitWithHigherCostThanBestOnStreetOnly","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"1m + 1.30 t\"</code> Path: /routingDefaults/itineraryFilters </p> <p>Limit function for generalized-cost computed from street-only itineries applied to transit itineraries.</p> <p>The max-limit is applied to itineraries with transit legs, and only itineraries without transit legs are considered when calculating the minimum cost. The smallest generalized-cost value is used as input to the function. The function is used to calculate a max-limit. The max-limit is then used to filter transit itineraries by generalized-cost. Itineraries with a cost higher than the max-limit are dropped from the result set. Walking is handled with a different logic: if a transit itinerary has higher cost than a plain walk itinerary, it will be removed even if the cost limit function would keep it.</p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit","title":"transitGeneralizedCostLimit","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/itineraryFilters </p> <p>A relative limit for the generalized-cost for transit itineraries.</p> <p>The filter compares all itineraries against every other itinerary. If the generalized-cost plus a <code>transitGeneralizedCostLimit</code> is higher than the other generalized-cost, then the itinerary is dropped. The <code>transitGeneralizedCostLimit</code> is calculated using the <code>costLimitFunction</code> plus a relative cost for the distance in time between the itineraries. The relative cost is the <code>intervalRelaxFactor</code> multiplied with the interval in seconds. To set the <code>costLimitFunction</code> to be 1 hour plus 2 times cost use: <code>3600 + 2.0 x</code>. To set an absolute value(3000s) use: <code>3000 + 0x</code></p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit_costLimitFunction","title":"costLimitFunction","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>cost-linear-function</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"15m + 1.50 t\"</code> Path: /routingDefaults/itineraryFilters/transitGeneralizedCostLimit </p> <p>The base function used by the filter.</p> <p>This function calculates the threshold for the filter, when the itineraries have exactly the same arrival and departure times.</p>"},{"location":"RouteRequest/#rd_if_transitGeneralizedCostLimit_intervalRelaxFactor","title":"intervalRelaxFactor","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.4</code> Path: /routingDefaults/itineraryFilters/transitGeneralizedCostLimit </p> <p>How much the filter should be relaxed for itineraries that do not overlap in time.</p> <p>This value is used to increase the filter threshold for itineraries further away in time, compared to those, that have exactly the same arrival and departure times.</p> <p>The unit is cost unit per second of time difference.</p>"},{"location":"RouteRequest/#rd_maxDirectStreetDurationForMode","title":"maxDirectStreetDurationForMode","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum map of duration</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>not-set</code> | <code>walk</code> | <code>bike</code> | <code>bike-to-park</code> | <code>bike-rental</code> | <code>scooter-rental</code> | <code>car</code> | <code>car-to-park</code> | <code>car-pickup</code> | <code>car-rental</code> | <code>car-hailing</code> | <code>flexible</code></p> <p>Limit direct route duration per street mode.</p> <p>Override the settings in <code>maxDirectStreetDuration</code> for specific street modes. This is done because some street modes searches are much more resource intensive than others.</p>"},{"location":"RouteRequest/#rd_transferOptimization","title":"transferOptimization","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Optimize where a transfer between to trip happens. </p> <p>The main purpose of transfer optimization is to handle cases where it is possible to transfer between two routes at more than one point (pair of stops). The transfer optimization ensures that transfers occur at the best possible location. By post-processing all paths returned by the router, OTP can apply sophisticated calculations that are too slow or not algorithmically valid within Raptor. Transfers are optimized is done after the Raptor search and before the paths are passed to the itinerary-filter-chain.</p> <p>To toggle transfer optimization on or off use the OTPFeature <code>OptimizeTransfers</code> (default is on). You should leave this on unless there is a critical issue with it. The OTPFeature <code>GuaranteedTransfers</code> will toggle on and off the priority optimization (part of OptimizeTransfers).</p> <p>The optimized transfer service will try to, in order:</p> <ol> <li>Use transfer priority. This includes stay-seated and guaranteed transfers.</li> <li>Use the transfers with the best distribution of the wait-time, and avoid very short transfers.</li> <li>Avoid back-travel</li> <li>Boost stop-priority to select preferred and recommended stops.</li> </ol> <p>If two paths have the same transfer priority level, then we break the tie by looking at waiting times. The goal is to maximize the wait-time for each stop, avoiding situations where there is little time available to make the transfer. This is balanced with the generalized-cost. The cost is adjusted with a new cost for wait-time (optimized-wait-time-cost).</p> <p>The defaults should work fine, but if you have results with short wait-times dominating a better option or \"back-travel\", then try to increase the <code>minSafeWaitTimeFactor</code>, <code>backTravelWaitTimeFactor</code> and/or <code>extraStopBoardAlightCostsFactor</code>.</p> <p>For details on the logic/design see transfer optimization package documentation.</p>"},{"location":"RouteRequest/#rd_to_backTravelWaitTimeFactor","title":"backTravelWaitTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/transferOptimization </p> <p>To reduce back-travel we favor waiting, this reduces the cost of waiting.</p> <p>The wait time is used to prevent back-travel, the <code>backTravelWaitTimeFactor</code> is multiplied with the wait-time and subtracted from the optimized-transfer-cost.</p>"},{"location":"RouteRequest/#rd_to_extraStopBoardAlightCostsFactor","title":"extraStopBoardAlightCostsFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.0</code> Path: /routingDefaults/transferOptimization </p> <p>Add an extra board- and alight-cost for prioritized stops.</p> <p>A stopBoardAlightCosts is added to the generalized-cost during routing. But this cost cannot be too high, because that would add extra cost to the transfer, and favor other alternative paths. But, when optimizing transfers, we do not have to take other paths into consideration and can boost the stop-priority-cost to allow transfers to take place at a preferred stop. The cost added during routing is already added to the generalized-cost used as a base in the optimized transfer calculation. By setting this parameter to 0, no extra cost is added, by setting it to <code>1.0</code> the stop-cost is doubled. Stop priority is only supported by the NeTEx import, not GTFS.</p>"},{"location":"RouteRequest/#rd_to_minSafeWaitTimeFactor","title":"minSafeWaitTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>5.0</code> Path: /routingDefaults/transferOptimization </p> <p>Used to set a maximum wait-time cost, base on min-safe-transfer-time.</p> <p>This defines the maximum cost for the logarithmic function relative to the min-safe-transfer-time (t0) when wait time goes towards zero(0). f(0) = n * t0</p>"},{"location":"RouteRequest/#rd_to_optimizeTransferWaitTime","title":"optimizeTransferWaitTime","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>true</code> Path: /routingDefaults/transferOptimization </p> <p>This enables the transfer wait time optimization.</p> <p>If not enabled generalizedCost function is used to pick the optimal transfer point.</p>"},{"location":"RouteRequest/#rd_transitGroupPriority","title":"transitGroupPriority","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Group transit patterns and give each group a mutual advantage in the Raptor search.</p> <p>Use this to separate transit patterns into groups. Each group will be given a group-id. A path (multiple legs) will then have a set of group-ids based on the group-id from each leg. Hence, two paths with a different set of group-ids will BOTH be optimal unless the cost is worse than the relaxation specified in the <code>relaxTransitGroupPriority</code> parameter. This is only available in the TransmodelAPI for now.</p> <p>Unmatched patterns are put in the BASE priority-group.</p> <p>THIS IS STILL AN EXPERIMENTAL FEATURE - IT MAY CHANGE WITHOUT ANY NOTICE!</p>"},{"location":"RouteRequest/#rd_transitReluctanceForMode","title":"transitReluctanceForMode","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>enum map of double</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults  Enum keys: <code>rail</code> | <code>coach</code> | <code>subway</code> | <code>bus</code> | <code>tram</code> | <code>ferry</code> | <code>airplane</code> | <code>cable-car</code> | <code>gondola</code> | <code>funicular</code> | <code>trolleybus</code> | <code>monorail</code> | <code>carpool</code> | <code>taxi</code></p> <p>Transit reluctance for a given transport mode</p>"},{"location":"RouteRequest/#rd_unpreferred","title":"unpreferred","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults </p> <p>Parameters listing authorities or lines that preferably should not be used in trip patters.</p> <p>A cost is applied to boarding nonpreferred authorities or routes.</p> <p>The routing engine will add extra penalty - on the unpreferred routes and/or agencies using a cost function. The cost function (<code>unpreferredCost</code>) is defined as a linear function of the form <code>A + B x</code>, where <code>A</code> is a fixed cost (in seconds) and <code>B</code> is reluctance multiplier for transit leg travel time <code>x</code> (in seconds).</p>"},{"location":"RouteRequest/#rd_unpreferred_agencies","title":"agencies","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>feed-scoped-id[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/unpreferred </p> <p>The ids of the agencies that incur an extra cost when being used. Format: <code>FeedId:AgencyId</code></p> <p>How much cost is added is configured in <code>unpreferredCost</code>.</p>"},{"location":"RouteRequest/#rd_unpreferred_routes","title":"routes","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>feed-scoped-id[]</code> \u2219 Cardinality: <code>Optional</code> Path: /routingDefaults/unpreferred </p> <p>The ids of the routes that incur an extra cost when being used. Format: <code>FeedId:RouteId</code></p> <p>How much cost is added is configured in <code>unpreferredCost</code>.</p>"},{"location":"RouteRequest/#rd_walk_reluctance","title":"reluctance","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>2.0</code> Path: /routingDefaults/walk </p> <p>A multiplier for how bad walking is, compared to being in transit for equal lengths of time.</p> <p>Empirically, values between 2 and 4 seem to correspond well to the concept of not wanting to walk too much without asking for totally ridiculous itineraries, but this observation should in no way be taken as scientific or definitive. Your mileage may vary. See https://github.com/opentripplanner/OpenTripPlanner/issues/4090 for impact on performance with high values.</p>"},{"location":"RouteRequest/#rd_walk_safetyFactor","title":"safetyFactor","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/walk </p> <p>Factor for how much the walk safety is considered in routing.</p> <p>Value should be between 0 and 1. If the value is set to be 0, safety is ignored.</p>"},{"location":"RouteRequest/#rd_walk_stairsTimeFactor","title":"stairsTimeFactor","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>3.0</code> Path: /routingDefaults/walk </p> <p>How much more time does it take to walk a flight of stairs compared to walking a similar horizontal length.</p> <p>Default value is based on: Fujiyama, T., &amp; Tyler, N. (2010). Predicting the walking speed of pedestrians on stairs. Transportation Planning and Technology, 33(2), 177\u2013202.</p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_maxSlope","title":"maxSlope","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.083</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>The maximum slope as a fraction of 1.</p> <p>9 percent would be <code>0.09</code></p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_slopeExceededReluctance","title":"slopeExceededReluctance","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>1.0</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>How much streets with high slope should be avoided.</p> <p>What factor should be given to street edges, which are over the max slope. The penalty is not static but scales with how much you exceed the maximum slope. Set to negative to disable routing on too steep edges.</p>"},{"location":"RouteRequest/#rd_wheelchairAccessibility_stairsReluctance","title":"stairsReluctance","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>100.0</code> Path: /routingDefaults/wheelchairAccessibility </p> <p>How much stairs should be avoided.</p> <p>Stairs are not completely excluded for wheelchair users but severely punished. This value determines how much they are punished. This should be a very high value as you want to only include stairs as a last result.</p>"},{"location":"RouteRequest/#config-example","title":"Config Example","text":"<pre><code>// router-config.json\n{\n  \"routingDefaults\" : {\n    \"numItineraries\" : 12,\n    \"transferPenalty\" : 0,\n    \"turnReluctance\" : 1.0,\n    \"elevatorBoardTime\" : 90,\n    \"elevatorBoardCost\" : 90,\n    \"elevatorHopTime\" : 20,\n    \"elevatorHopCost\" : 20,\n    \"bicycle\" : {\n      \"speed\" : 5,\n      \"reluctance\" : 5.0,\n      \"boardCost\" : 600,\n      \"walk\" : {\n        \"reluctance\" : 10.0,\n        \"stairsReluctance\" : 150.0\n      },\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"1m\",\n        \"cost\" : 120\n      },\n      \"triangle\" : {\n        \"safety\" : 0.4,\n        \"flatness\" : 0.3,\n        \"time\" : 0.3\n      }\n    },\n    \"car\" : {\n      \"speed\" : 40,\n      \"reluctance\" : 10,\n      \"decelerationSpeed\" : 2.9,\n      \"accelerationSpeed\" : 2.9,\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"5m\",\n        \"cost\" : 600\n      }\n    },\n    \"walk\" : {\n      \"speed\" : 1.3,\n      \"reluctance\" : 4.0,\n      \"stairsReluctance\" : 1.65,\n      \"boardCost\" : 600,\n      \"escalatorReluctance\" : 1.5\n    },\n    \"waitReluctance\" : 1.0,\n    \"otherThanPreferredRoutesPenalty\" : 300,\n    \"transferSlack\" : 120,\n    \"boardSlackForMode\" : {\n      \"AIRPLANE\" : \"35m\"\n    },\n    \"alightSlackForMode\" : {\n      \"AIRPLANE\" : \"15m\"\n    },\n    \"transitReluctanceForMode\" : {\n      \"RAIL\" : 0.85\n    },\n    \"accessEgress\" : {\n      \"maxDuration\" : \"45m\",\n      \"maxDurationForMode\" : {\n        \"BIKE_RENTAL\" : \"20m\"\n      },\n      \"maxStopCount\" : 500,\n      \"penalty\" : {\n        \"FLEXIBLE\" : {\n          \"timePenalty\" : \"2m + 1.1t\",\n          \"costFactor\" : 1.7\n        }\n      }\n    },\n    \"itineraryFilters\" : {\n      \"transitGeneralizedCostLimit\" : {\n        \"costLimitFunction\" : \"15m + 1.5 x\",\n        \"intervalRelaxFactor\" : 0.4\n      },\n      \"nonTransitGeneralizedCostLimit\" : \"400 + 1.5x\",\n      \"removeTransitWithHigherCostThanBestOnStreetOnly\" : \"60 + 1.3x\",\n      \"bikeRentalDistanceRatio\" : 0.3,\n      \"accessibilityScore\" : true,\n      \"minBikeParkingDistance\" : 300,\n      \"debug\" : \"limit-to-search-window\"\n    },\n    \"ignoreRealtimeUpdates\" : false,\n    \"geoidElevation\" : false,\n    \"maxJourneyDuration\" : \"36h\",\n    \"unpreferred\" : {\n      \"agencies\" : [\n        \"HSL:123\"\n      ],\n      \"routes\" : [\n        \"HSL:456\"\n      ]\n    },\n    \"unpreferredCost\" : \"10m + 2.0 x\",\n    \"streetRoutingTimeout\" : \"5s\",\n    \"transferOptimization\" : {\n      \"optimizeTransferWaitTime\" : true,\n      \"minSafeWaitTimeFactor\" : 5.0,\n      \"backTravelWaitTimeFactor\" : 1.0,\n      \"extraStopBoardAlightCostsFactor\" : 8.0\n    },\n    \"wheelchairAccessibility\" : {\n      \"trip\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"stop\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"elevator\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 20,\n        \"inaccessibleCost\" : 3600\n      },\n      \"inaccessibleStreetReluctance\" : 25,\n      \"maxSlope\" : 0.083,\n      \"slopeExceededReluctance\" : 1,\n      \"stairsReluctance\" : 100\n    }\n  }\n}\n</code></pre>"},{"location":"RouterConfiguration/","title":"Router","text":""},{"location":"RouterConfiguration/#router-configuration","title":"Router configuration","text":"<p>This section covers all options that can be set for each router using the <code>router-config.json</code> file. These options can be applied by the OTP server without rebuilding the graph.</p>"},{"location":"RouterConfiguration/#configure-using-command-line-arguments","title":"Configure using command-line arguments","text":"<p>Certain settings can be provided on the command line, when starting OpenTripPlanner. See the <code>CommandLineParameters</code> class for a full list of arguments .</p>"},{"location":"RouterConfiguration/#routing-defaults","title":"Routing defaults","text":"<p>There are many trip planning options used in the OTP web API, and more exist internally that are not exposed via the API. You may want to change the default value for some of these parameters, i.e. the value which will be applied unless it is overridden in a web API request.</p> <p>A full list of them can be found in the RouteRequest.</p>"},{"location":"RouterConfiguration/#parameter-summary","title":"Parameter Summary","text":"Config Parameter Type Summary Req./Opt. Default Value Since configVersion <code>string</code> Deployment version of the router-config.json. Optional 2.1 flex <code>object</code> Configuration for flex routing. Optional 2.1 rideHailingServices <code>object[]</code> Configuration for interfaces to external ride hailing services like Uber. Optional 2.3 routingDefaults <code>object</code> The default parameters for the routing query. Optional 2.0 server <code>object</code> Configuration for router server. Optional 2.4 apiProcessingTimeout <code>duration</code> Maximum processing time for an API request Optional <code>\"PT-1S\"</code> 2.4 traceParameters <code>object[]</code> Trace OTP request using HTTP request/response parameter(s) combined with logging. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0generateIdIfMissing <code>boolean</code> If <code>true</code> a unique value is generated if no http request header is provided, or the value is missing. Optional <code>false</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0httpRequestHeader <code>string</code> The header-key to use when fetching the trace parameter value Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0httpResponseHeader <code>string</code> The header-key to use when saving the value back into the http response Optional 2.4 logKey <code>string</code> The log event key used. Optional 2.4 timetableUpdates <code>object</code> Global configuration for timetable updaters. Optional 2.2 maxSnapshotFrequency <code>duration</code> How long a snapshot should be cached. Optional <code>\"PT1S\"</code> 2.2 \u00a0\u00a0\u00a0purgeExpiredData <code>boolean</code> Should expired real-time data be purged from the graph. Apply to GTFS-RT and Siri updates. Optional <code>true</code> 2.2 transit <code>object</code> Configuration for transit searches with RAPTOR. Optional na iterationDepartureStepInSeconds <code>integer</code> Step for departure times between each RangeRaptor iterations. Optional <code>60</code> na maxNumberOfTransfers <code>integer</code> This parameter is used to allocate enough memory space for Raptor. Optional <code>12</code> na maxSearchWindow <code>duration</code> Upper limit of the request parameter searchWindow. Optional <code>\"PT24H\"</code> 2.4 scheduledTripBinarySearchThreshold <code>integer</code> This threshold is used to determine when to perform a binary trip schedule search. Optional <code>50</code> na searchThreadPoolSize <code>integer</code> Split a travel search in smaller jobs and run them in parallel to improve performance. Optional <code>0</code> na transferCacheMaxSize <code>integer</code> The maximum number of distinct transfers parameters to cache pre-calculated transfers for. Optional <code>25</code> na dynamicSearchWindow <code>object</code> The dynamic search window coefficients used to calculate the EDT, LAT and SW. Optional 2.1 maxWindow <code>duration</code> Upper limit for the search-window calculation. Optional <code>\"PT3H\"</code> 2.2 minTransitTimeCoefficient <code>double</code> The coefficient to multiply with <code>minTransitTime</code>. Optional <code>0.5</code> 2.1 minWaitTimeCoefficient <code>double</code> The coefficient to multiply with <code>minWaitTime</code>. Optional <code>0.5</code> 2.1 minWindow <code>duration</code> The constant minimum duration for a raptor-search-window. Optional <code>\"PT40M\"</code> 2.2 stepMinutes <code>integer</code> Used to set the steps the search-window is rounded to. Optional <code>10</code> 2.1 pagingSearchWindowAdjustments <code>duration[]</code> The provided array of durations is used to increase the search-window for the next/previous page. Optional na stopTransferCost <code>enum map of integer</code> Use this to set a stop transfer cost for the given transfer priority Optional 2.0 transferCacheRequests <code>object[]</code> Routing requests to use for pre-filling the stop-to-stop transfer cache. Optional 2.3 transmodelApi <code>object</code> Configuration for the Transmodel GraphQL API. Optional 2.1 hideFeedId <code>boolean</code> Hide the FeedId in all API output, and add it to input. Optional <code>false</code> na tracingHeaderTags <code>string[]</code> Used to group requests when monitoring OTP. Optional na updaters <code>object[]</code> Configuration for the updaters that import various types of data into OTP. Optional 1.5 vectorTiles <code>object</code> Vector tile configuration Optional na vehicleRentalServiceDirectory <code>object</code> Configuration for the vehicle rental service directory. Optional 2.0"},{"location":"RouterConfiguration/#parameter-details","title":"Parameter Details","text":""},{"location":"RouterConfiguration/#configVersion","title":"configVersion","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Deployment version of the router-config.json.</p> <p>The config-version is a parameter which each OTP deployment may set to be able to query the OTP server and verify that it uses the correct version of the config. The version should be injected into the config in the (continuous) deployment pipeline. How this is done, is up to the deployment.</p> <p>The config-version has no effect on OTP, and is provided as is on the API. There is no syntax or format check on the version and it can be any string.</p> <p>Be aware that OTP uses the config embedded in the loaded graph if no new config is provided.</p>"},{"location":"RouterConfiguration/#server","title":"server","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configuration for router server.</p> <p>These parameters are used to configure the router server. Many parameters are specific to a domain, these are set in the routing request.</p>"},{"location":"RouterConfiguration/#server_apiProcessingTimeout","title":"apiProcessingTimeout","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT-1S\"</code> Path: /server </p> <p>Maximum processing time for an API request</p> <p>This timeout limits the server-side processing time for a given API request. This does not include network latency nor waiting time in the HTTP server thread pool. The default value is <code>-1s</code>(no timeout). The timeout is applied to all APIs (REST, Transmodel &amp; GTFS GraphQL). The timeout is not enforced when the parallel routing OTP feature is in use.</p>"},{"location":"RouterConfiguration/#server_traceParameters","title":"traceParameters","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /server </p> <p>Trace OTP request using HTTP request/response parameter(s) combined with logging.</p> <p>OTP supports tracing user requests across log events and \"outside\" services. OTP can insert http-request-header parameters into all associated log events and into the http response. If the value is not present in the request, a unique value can be generated. The OTP generated value is a 6 characters long base 36[0-9a-z] character string.</p> <p>Use-case Correlation-ID</p> <p>A common use-case in a service oriented environment is to use a correlation-id to identify all log messages across multiple (micro-)services from the same user. This is done by setting the \"X-Correlation-ID\" http header in the http facade/gateway. Use the \"traceParameters\" to configure OTP to pick up the correlation id, insert it into the logs and return it. See the example below on how-to configure the \"server.traceParameters\" instance.</p>"},{"location":"RouterConfiguration/#server_traceParameters_0_logKey","title":"logKey","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /server/traceParameters/[0] </p> <p>The log event key used.</p> <p>OTP stores the key/value pair in the log MDC(Mapped Diagnostic Context). To use it you normally include the key in the log pattern like this: <code>%X{LOG-KEY}</code>. See your log framework for details. Only log4j and logback support this.</p>"},{"location":"RouterConfiguration/#timetableUpdates_maxSnapshotFrequency","title":"maxSnapshotFrequency","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT1S\"</code> Path: /timetableUpdates </p> <p>How long a snapshot should be cached.</p> <p>If a timetable snapshot is requested less than this number of milliseconds after the previous snapshot, then return the same instance. Throttles the potentially resource-consuming task of duplicating a TripPattern \u2192 Timetable map and indexing the new Timetables. Applies to GTFS-RT and Siri updates.</p>"},{"location":"RouterConfiguration/#transit","title":"transit","text":"<p>Since version: <code>na</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: / </p> <p>Configuration for transit searches with RAPTOR.</p> <p>Some of these parameters for tuning transit routing are only available through configuration and cannot be set in the routing request. These parameters work together with the default routing request and the actual routing request.</p>"},{"location":"RouterConfiguration/#transit_iterationDepartureStepInSeconds","title":"iterationDepartureStepInSeconds","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>60</code> Path: /transit </p> <p>Step for departure times between each RangeRaptor iterations.</p> <p>This is a performance optimization parameter. A transit network usually uses minute resolution for the timetables, so to match that, set this variable to 60 seconds. Setting it to less than 60 will not give better result, but degrade performance. Setting it to 120 seconds will improve performance, but you might get a slack of 60 seconds somewhere in the result.</p>"},{"location":"RouterConfiguration/#transit_maxNumberOfTransfers","title":"maxNumberOfTransfers","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>12</code> Path: /transit </p> <p>This parameter is used to allocate enough memory space for Raptor.</p> <p>Set it to the maximum number of transfers for any given itinerary expected to be found within the entire transit network. The memory overhead of setting this higher than the maximum number of transfers is very little so it is better to set it too high than to low.</p>"},{"location":"RouterConfiguration/#transit_maxSearchWindow","title":"maxSearchWindow","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT24H\"</code> Path: /transit </p> <p>Upper limit of the request parameter searchWindow.</p> <p>Maximum search window that can be set through the searchWindow API parameter. Due to the way timetable data are collected before a Raptor trip search, using a search window larger than 24 hours may lead to inconsistent search results. Limiting the search window prevents also potential performance issues. The recommended maximum value is 24 hours. This parameter does not restrict the maximum duration of a dynamic search window (use the parameter <code>transit.dynamicSearchWindow.maxWindow</code> to specify such a restriction).</p>"},{"location":"RouterConfiguration/#transit_scheduledTripBinarySearchThreshold","title":"scheduledTripBinarySearchThreshold","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>50</code> Path: /transit </p> <p>This threshold is used to determine when to perform a binary trip schedule search.</p> <p>This reduce the number of trips departure time lookups and comparisons. When testing with data from Entur and all of Norway as a Graph, the optimal value was about 50. If you calculate the departure time every time or want to fine tune the performance, changing this may improve the performance a few percents.</p>"},{"location":"RouterConfiguration/#transit_searchThreadPoolSize","title":"searchThreadPoolSize","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0</code> Path: /transit </p> <p>Split a travel search in smaller jobs and run them in parallel to improve performance.</p> <p>Use this parameter to set the total number of executable threads available across all searches. Multiple searches can run in parallel - this parameter have no effect with regard to that. If 0, no extra threads are started and the search is done in one thread.</p>"},{"location":"RouterConfiguration/#transit_transferCacheMaxSize","title":"transferCacheMaxSize","text":"<p>Since version: <code>na</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>25</code> Path: /transit </p> <p>The maximum number of distinct transfers parameters to cache pre-calculated transfers for.</p> <p>If too low, requests may be slower. If too high, more memory may be used then required.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow","title":"dynamicSearchWindow","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>object</code> \u2219 Cardinality: <code>Optional</code> Path: /transit </p> <p>The dynamic search window coefficients used to calculate the EDT, LAT and SW.</p> <p>The dynamic search window coefficients is used to calculate EDT(earliest-departure-time), LAT(latest-arrival-time) and SW(raptor-search-window) request parameters using heuristics. The heuristics perform a Raptor search (one-iteration) to find a trip which we use to find a lower bound for the travel duration time - the \"minTransitTime\". The heuristic search is used for other purposes too, and is very fast.</p> <p>At least the EDT or the LAT must be passed into Raptor to perform a Range Raptor search. If unknown/missing the parameters(EDT, LAT, DW) are dynamically calculated. The dynamic coefficients affect the performance and should be tuned to match the deployment.</p> <p>The request parameters are calculated like this:</p> <pre><code>    DW  = round_N(C + T * minTransitTime + W * minWaitTime)\n    LAT = EDT + DW + minTransitTime\n    EDT = LAT - (DW + minTransitTime)\n</code></pre> <p>The <code>round_N(...)</code> method rounds the input to the closest multiplication of N.</p> <p>The 3 coefficients above are:</p> <ul> <li><code>C</code> is parameter: <code>minWindow</code></li> <li><code>T</code> is parameter: <code>minTransitTimeCoefficient</code></li> <li><code>W</code> is parameter: <code>minWaitTimeCoefficient</code></li> <li><code>N</code> is parameter: <code>stepMinutes</code></li> </ul> <p>In addition there is an upper bound on the calculation of the search window: <code>maxWindow</code>.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_maxWindow","title":"maxWindow","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT3H\"</code> Path: /transit/dynamicSearchWindow </p> <p>Upper limit for the search-window calculation.</p> <p>Long search windows consumes a lot of resources and may take a long time. Use this parameter to tune the desired maximum search time.</p> <p>This is the parameter that affects the response time most, the downside is that a search is only guaranteed to be pareto-optimal within a search-window.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minTransitTimeCoefficient","title":"minTransitTimeCoefficient","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.5</code> Path: /transit/dynamicSearchWindow </p> <p>The coefficient to multiply with <code>minTransitTime</code>.</p> <p>Use a value between <code>0.0</code> and <code>3.0</code>. Using <code>0.0</code> will eliminate the <code>minTransitTime</code> from the dynamic raptor-search-window calculation.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minWaitTimeCoefficient","title":"minWaitTimeCoefficient","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.5</code> Path: /transit/dynamicSearchWindow </p> <p>The coefficient to multiply with <code>minWaitTime</code>.</p> <p>Use a value between <code>0.0</code> and <code>1.0</code>. Using <code>0.0</code> will eliminate the <code>minWaitTime</code> from the dynamic raptor-search-window calculation.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_minWindow","title":"minWindow","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT40M\"</code> Path: /transit/dynamicSearchWindow </p> <p>The constant minimum duration for a raptor-search-window. </p> <p>Use a value between 20 and 180 minutes in a normal deployment.</p>"},{"location":"RouterConfiguration/#transit_dynamicSearchWindow_stepMinutes","title":"stepMinutes","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>10</code> Path: /transit/dynamicSearchWindow </p> <p>Used to set the steps the search-window is rounded to.</p> <p>The search window is rounded off to the closest multiplication of <code>stepMinutes</code>. If <code>stepMinutes</code> = 10 minutes, the search-window can be 10, 20, 30 ... minutes. It the computed search-window is 5 minutes and 17 seconds it will be rounded up to 10 minutes.</p> <p>Use a value between <code>1</code> and <code>60</code>. This should be less than the <code>min-raptor-search-window</code> coefficient.</p>"},{"location":"RouterConfiguration/#transit_pagingSearchWindowAdjustments","title":"pagingSearchWindowAdjustments","text":"<p>Since version: <code>na</code> \u2219 Type: <code>duration[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transit </p> <p>The provided array of durations is used to increase the search-window for the next/previous page.</p> <p>The search window is expanded when the current page return few options. If ZERO result is returned the first duration in the list is used, if ONE result is returned then the second duration is used and so on. The duration is added to the existing search-window and inserted into the next and previous page cursor. See JavaDoc for TransitTuningParameters#pagingSearchWindowAdjustments\" + for more info.\"</p>"},{"location":"RouterConfiguration/#transit_stopTransferCost","title":"stopTransferCost","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>enum map of integer</code> \u2219 Cardinality: <code>Optional</code> Path: /transit  Enum keys: <code>discouraged</code> | <code>allowed</code> | <code>recommended</code> | <code>preferred</code></p> <p>Use this to set a stop transfer cost for the given transfer priority</p> <p>The cost is applied to boarding and alighting at all stops. All stops have a transfer cost priority set, the default is <code>allowed</code>. The <code>stopTransferCost</code> parameter is optional, but if listed all values must be set.</p> <p>If not set the <code>stopTransferCost</code> is ignored. This is only available for NeTEx imported Stops.</p> <p>The cost is a scalar, but is equivalent to the felt cost of riding a transit trip for 1 second.</p> Config key Description Type <code>discouraged</code> Use a very high cost like <code>72 000</code> to eliminate transfers at the stop if not the only option. int <code>allowed</code> Allowed, but not recommended. Use something like <code>150</code>. int <code>recommended</code> Use a small cost penalty like <code>60</code>. int <code>preferred</code> The best place to do transfers. Should be set to <code>0</code>(zero). int <p>Use values in a range from <code>0</code> to <code>100 000</code>. All key/value pairs are required if the <code>stopTransferCost</code> is listed.</p>"},{"location":"RouterConfiguration/#transit_transferCacheRequests","title":"transferCacheRequests","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transit \u2219 See: RouteRequest.md </p> <p>Routing requests to use for pre-filling the stop-to-stop transfer cache.</p> <p>If not set, the default behavior is to cache stop-to-stop transfers using the default route request (<code>routingDefaults</code>). Use this to change the default or specify more than one <code>RouteRequest</code>.</p> <p>Example</p> <pre><code>// router-config.json\n{\n  \"transit\": {\n    \"transferCacheRequests\": [\n      { \"modes\": \"WALK\"                                                     },\n      { \"modes\": \"WALK\",    \"wheelchairAccessibility\": { \"enabled\": true  } }\n    ]\n  }\n}\n</code></pre>"},{"location":"RouterConfiguration/#transmodelApi_hideFeedId","title":"hideFeedId","text":"<p>Since version: <code>na</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /transmodelApi </p> <p>Hide the FeedId in all API output, and add it to input.</p> <p>Only turn this feature on if you have unique ids across all feeds, without the feedId prefix.</p>"},{"location":"RouterConfiguration/#transmodelApi_tracingHeaderTags","title":"tracingHeaderTags","text":"<p>Since version: <code>na</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /transmodelApi </p> <p>Used to group requests when monitoring OTP.</p>"},{"location":"RouterConfiguration/#router-config-example","title":"Router Config Example","text":"<pre><code>// router-config.json\n{\n  \"configVersion\" : \"v2.4.0-EN000121\",\n  \"server\" : {\n    \"apiProcessingTimeout\" : \"7s\",\n    \"traceParameters\" : [\n      {\n        \"httpRequestHeader\" : \"X-Correlation-ID\",\n        \"httpResponseHeader\" : \"X-Correlation-ID\",\n        \"logKey\" : \"correlationId\",\n        \"generateIdIfMissing\" : true\n      }\n    ]\n  },\n  \"routingDefaults\" : {\n    \"numItineraries\" : 12,\n    \"transferPenalty\" : 0,\n    \"turnReluctance\" : 1.0,\n    \"elevatorBoardTime\" : 90,\n    \"elevatorBoardCost\" : 90,\n    \"elevatorHopTime\" : 20,\n    \"elevatorHopCost\" : 20,\n    \"bicycle\" : {\n      \"speed\" : 5,\n      \"reluctance\" : 5.0,\n      \"boardCost\" : 600,\n      \"walk\" : {\n        \"reluctance\" : 10.0,\n        \"stairsReluctance\" : 150.0\n      },\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"1m\",\n        \"cost\" : 120\n      },\n      \"triangle\" : {\n        \"safety\" : 0.4,\n        \"flatness\" : 0.3,\n        \"time\" : 0.3\n      }\n    },\n    \"car\" : {\n      \"speed\" : 40,\n      \"reluctance\" : 10,\n      \"decelerationSpeed\" : 2.9,\n      \"accelerationSpeed\" : 2.9,\n      \"rental\" : {\n        \"pickupCost\" : 120,\n        \"dropOffTime\" : \"30s\",\n        \"dropOffCost\" : 30\n      },\n      \"parking\" : {\n        \"time\" : \"5m\",\n        \"cost\" : 600\n      }\n    },\n    \"walk\" : {\n      \"speed\" : 1.3,\n      \"reluctance\" : 4.0,\n      \"stairsReluctance\" : 1.65,\n      \"boardCost\" : 600,\n      \"escalatorReluctance\" : 1.5\n    },\n    \"waitReluctance\" : 1.0,\n    \"otherThanPreferredRoutesPenalty\" : 300,\n    \"transferSlack\" : 120,\n    \"boardSlackForMode\" : {\n      \"AIRPLANE\" : \"35m\"\n    },\n    \"alightSlackForMode\" : {\n      \"AIRPLANE\" : \"15m\"\n    },\n    \"transitReluctanceForMode\" : {\n      \"RAIL\" : 0.85\n    },\n    \"accessEgress\" : {\n      \"maxDuration\" : \"45m\",\n      \"maxDurationForMode\" : {\n        \"BIKE_RENTAL\" : \"20m\"\n      },\n      \"maxStopCount\" : 500,\n      \"penalty\" : {\n        \"FLEXIBLE\" : {\n          \"timePenalty\" : \"2m + 1.1t\",\n          \"costFactor\" : 1.7\n        }\n      }\n    },\n    \"itineraryFilters\" : {\n      \"transitGeneralizedCostLimit\" : {\n        \"costLimitFunction\" : \"15m + 1.5 x\",\n        \"intervalRelaxFactor\" : 0.4\n      },\n      \"nonTransitGeneralizedCostLimit\" : \"400 + 1.5x\",\n      \"removeTransitWithHigherCostThanBestOnStreetOnly\" : \"60 + 1.3x\",\n      \"bikeRentalDistanceRatio\" : 0.3,\n      \"accessibilityScore\" : true,\n      \"minBikeParkingDistance\" : 300,\n      \"debug\" : \"limit-to-search-window\"\n    },\n    \"ignoreRealtimeUpdates\" : false,\n    \"geoidElevation\" : false,\n    \"maxJourneyDuration\" : \"36h\",\n    \"unpreferred\" : {\n      \"agencies\" : [\n        \"HSL:123\"\n      ],\n      \"routes\" : [\n        \"HSL:456\"\n      ]\n    },\n    \"unpreferredCost\" : \"10m + 2.0 x\",\n    \"streetRoutingTimeout\" : \"5s\",\n    \"transferOptimization\" : {\n      \"optimizeTransferWaitTime\" : true,\n      \"minSafeWaitTimeFactor\" : 5.0,\n      \"backTravelWaitTimeFactor\" : 1.0,\n      \"extraStopBoardAlightCostsFactor\" : 8.0\n    },\n    \"wheelchairAccessibility\" : {\n      \"trip\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"stop\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 600,\n        \"inaccessibleCost\" : 3600\n      },\n      \"elevator\" : {\n        \"onlyConsiderAccessible\" : false,\n        \"unknownCost\" : 20,\n        \"inaccessibleCost\" : 3600\n      },\n      \"inaccessibleStreetReluctance\" : 25,\n      \"maxSlope\" : 0.083,\n      \"slopeExceededReluctance\" : 1,\n      \"stairsReluctance\" : 100\n    }\n  },\n  \"flex\" : {\n    \"maxTransferDuration\" : \"5m\",\n    \"maxFlexTripDuration\" : \"45m\",\n    \"maxAccessWalkDuration\" : \"15m\",\n    \"maxEgressWalkDuration\" : \"15m\"\n  },\n  \"transit\" : {\n    \"maxNumberOfTransfers\" : 12,\n    \"dynamicSearchWindow\" : {\n      \"minTransitTimeCoefficient\" : 0.5,\n      \"minWaitTimeCoefficient\" : 0.5,\n      \"minWindow\" : \"1h\",\n      \"maxWindow\" : \"5h\"\n    },\n    \"stopTransferCost\" : {\n      \"DISCOURAGED\" : 1500,\n      \"ALLOWED\" : 75,\n      \"RECOMMENDED\" : 30,\n      \"PREFERRED\" : 0\n    },\n    \"transferCacheRequests\" : [\n      {\n        \"modes\" : \"WALK\"\n      },\n      {\n        \"modes\" : \"WALK\",\n        \"wheelchairAccessibility\" : {\n          \"enabled\" : true\n        }\n      }\n    ]\n  },\n  \"vehicleRentalServiceDirectory\" : {\n    \"url\" : \"https://entur.no/bikeRentalServiceDirectory\",\n    \"sourcesName\" : \"systems\",\n    \"updaterUrlName\" : \"url\",\n    \"updaterNetworkName\" : \"id\",\n    \"headers\" : {\n      \"ET-Client-Name\" : \"MY_ORG_CLIENT_NAME\"\n    }\n  },\n  \"transmodelApi\" : {\n    \"hideFeedId\" : true\n  },\n  \"vectorTiles\" : {\n    \"basePath\" : \"/otp_ct/vectorTiles\",\n    \"layers\" : [\n      {\n        \"name\" : \"stops\",\n        \"type\" : \"Stop\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"stations\",\n        \"type\" : \"Station\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 12,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"rentalPlaces\",\n        \"type\" : \"VehicleRental\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60,\n        \"expansionFactor\" : 0.25\n      },\n      {\n        \"name\" : \"rentalVehicle\",\n        \"type\" : \"VehicleRentalVehicle\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60\n      },\n      {\n        \"name\" : \"rentalStation\",\n        \"type\" : \"VehicleRentalStation\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 600\n      },\n      {\n        \"name\" : \"vehicleParking\",\n        \"type\" : \"VehicleParking\",\n        \"mapper\" : \"Digitransit\",\n        \"maxZoom\" : 20,\n        \"minZoom\" : 14,\n        \"cacheMaxSeconds\" : 60,\n        \"expansionFactor\" : 0.25\n      }\n    ]\n  },\n  \"timetableUpdates\" : {\n    \"purgeExpiredData\" : false,\n    \"maxSnapshotFrequency\" : \"2s\"\n  },\n  \"updaters\" : [\n    {\n      \"type\" : \"real-time-alerts\",\n      \"frequency\" : \"30s\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/FeedSpecAlerts/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Some-Header\" : \"A-Value\"\n      }\n    },\n    {\n      \"type\" : \"vehicle-rental\",\n      \"network\" : \"socialbicycles_coast\",\n      \"sourceType\" : \"gbfs\",\n      \"language\" : \"en\",\n      \"frequency\" : \"1m\",\n      \"allowKeepingRentedVehicleAtDestination\" : false,\n      \"geofencingZones\" : false,\n      \"url\" : \"http://coast.socialbicycles.com/opendata/gbfs.json\",\n      \"headers\" : {\n        \"Auth\" : \"&lt;any-token&gt;\",\n        \"&lt;key&gt;\" : \"&lt;value&gt;\"\n      }\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"hsl-park\",\n      \"feedId\" : \"hslpark\",\n      \"timeZone\" : \"Europe/Helsinki\",\n      \"facilitiesFrequencySec\" : 3600,\n      \"facilitiesUrl\" : \"https://p.hsl.fi/api/v1/facilities.json?limit=-1\",\n      \"utilizationsFrequencySec\" : 600,\n      \"utilizationsUrl\" : \"https://p.hsl.fi/api/v1/utilizations.json?limit=-1\",\n      \"hubsUrl\" : \"https://p.hsl.fi/api/v1/hubs.json?limit=-1\"\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"park-api\",\n      \"feedId\" : \"parkapi\",\n      \"timeZone\" : \"Europe/Berlin\",\n      \"frequency\" : \"10m\",\n      \"url\" : \"https://foo.bar\",\n      \"headers\" : {\n        \"Cache-Control\" : \"max-age=604800\"\n      },\n      \"tags\" : [\n        \"source:parkapi\"\n      ]\n    },\n    {\n      \"type\" : \"vehicle-parking\",\n      \"feedId\" : \"bikely\",\n      \"sourceType\" : \"bikely\",\n      \"url\" : \"https://api.safebikely.com/api/v1/s/locations\",\n      \"headers\" : {\n        \"X-Bikely-Token\" : \"${BIKELY_TOKEN}\",\n        \"Authorization\" : \"${BIKELY_AUTHORIZATION}\"\n      }\n    },\n    {\n      \"type\" : \"stop-time-updater\",\n      \"frequency\" : \"1m\",\n      \"backwardsDelayPropagationType\" : \"REQUIRED_NO_DATA\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/TripUpdate/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Authorization\" : \"A-Token\"\n      }\n    },\n    {\n      \"type\" : \"mqtt-gtfs-rt-updater\",\n      \"url\" : \"tcp://pred.rt.hsl.fi\",\n      \"topic\" : \"gtfsrt/v2/fi/hsl/tu\",\n      \"feedId\" : \"HSL\",\n      \"fuzzyTripMatching\" : true\n    },\n    {\n      \"type\" : \"vehicle-positions\",\n      \"url\" : \"https://s3.amazonaws.com/kcm-alerts-realtime-prod/vehiclepositions.pb\",\n      \"feedId\" : \"1\",\n      \"frequency\" : \"1m\",\n      \"headers\" : {\n        \"Header-Name\" : \"Header-Value\"\n      },\n      \"fuzzyTripMatching\" : false,\n      \"features\" : [\n        \"position\"\n      ]\n    },\n    {\n      \"type\" : \"siri-et-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Authorization\" : \"Some-Token\"\n      }\n    },\n    {\n      \"type\" : \"siri-sx-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Key\" : \"Value\"\n      }\n    },\n    {\n      \"type\" : \"siri-azure-sx-updater\",\n      \"topic\" : \"some_topic\",\n      \"servicebus-url\" : \"service_bus_url\",\n      \"feedId\" : \"feed_id\",\n      \"customMidnight\" : 4,\n      \"history\" : {\n        \"url\" : \"endpoint_url\",\n        \"fromDateTime\" : \"-P1D\",\n        \"toDateTime\" : \"P1D\",\n        \"timeout\" : 300000\n      }\n    }\n  ],\n  \"rideHailingServices\" : [\n    {\n      \"type\" : \"uber-car-hailing\",\n      \"clientId\" : \"secret-id\",\n      \"clientSecret\" : \"very-secret\",\n      \"wheelchairAccessibleProductId\" : \"545de0c4-659f-49c6-be65-0d5e448dffd5\",\n      \"bannedProductIds\" : [\n        \"1196d0dd-423b-4a81-a1d8-615367d3a365\",\n        \"f58761e5-8dd5-4940-a472-872f1236c596\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"RoutingModes/","title":"Routing modes","text":"<p>This page is intended as an exhaustive listing of what OTP's routing engine is capable of and  therefore documents internal names. Since OTP has multiple APIs where each works slightly differently, please consult your API documentation on how to select the appropriate mode.</p>"},{"location":"RoutingModes/#Street modes","title":"Street modes","text":"<p>Routing modes on streets, including walking, biking, driving, and car-sharing.</p>"},{"location":"RoutingModes/#BIKE","title":"BIKE","text":"<p>Cycling for the entirety of the route or taking a bicycle onto the public transport and cycling from the arrival station to the destination.</p>"},{"location":"RoutingModes/#BIKE_RENTAL","title":"BIKE_RENTAL","text":"<p>Taking a rented, shared-mobility bike for part or the entirety of the route.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#BIKE_TO_PARK","title":"BIKE_TO_PARK","text":"<p>Leaving the bicycle at the departure station and walking from the arrival station to the destination. This mode needs to be combined with at least one transit mode otherwise it behaves like an ordinary bicycle journey.</p> <p>Prerequisite: Bicycle parking stations present in the OSM file and visible to OTP by enabling the property <code>staticBikeParkAndRide</code> during graph build.</p>"},{"location":"RoutingModes/#CAR","title":"CAR","text":"<p>Driving your own car the entirety of the route. This can be combined with transit, where will return routes with a Kiss &amp; Ride component. This means that the car is not parked in a permanent parking area but rather the passenger is dropped off (for example, at an airport) and the driver continues driving the car away from the drop off location.</p>"},{"location":"RoutingModes/#CAR_HAILING","title":"CAR_HAILING","text":"<p>Using a car hailing app like Uber or Lyft to get to a train station or all the way to the destination.</p> <p>See the sandbox documentation on how to configure it.</p>"},{"location":"RoutingModes/#CAR_PICKUP","title":"CAR_PICKUP","text":"<p>Walking to a pickup point along the road, driving to a drop-off point along the road, and walking the rest of the way.  This can include various taxi-services or kiss &amp; ride.</p>"},{"location":"RoutingModes/#CAR_RENTAL","title":"CAR_RENTAL","text":"<p>Walk to a car rental point, drive to a car rental drop-off point and walk the rest of the way. This can include car rental at fixed locations or free-floating services.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#CAR_TO_PARK","title":"CAR_TO_PARK","text":"<p>Driving a car to the park-and-ride facilities near a station and taking publictransport. This mode needs to be combined with at least one transit mode otherwise, it behaves like an ordinary car journey. Prerequisite: Park-and-ride areas near the stations need to be present in the OSM input file.</p>"},{"location":"RoutingModes/#FLEXIBLE","title":"FLEXIBLE","text":"<p>Encompasses all types of on-demand and flexible transportation for example GTFS Flex or NeTEx Flexible Stop Places.</p>"},{"location":"RoutingModes/#SCOOTER_RENTAL","title":"SCOOTER_RENTAL","text":"<p>Walking to a scooter rental point, riding a scooter to a scooter rental drop-off point, and walking the rest of the way. This can include scooter rental at fixed locations or free-floating services.</p> <p>Prerequisite: Vehicle or station locations need to be added to OTP from dynamic data feeds. See Configuring GBFS on how to add one.</p>"},{"location":"RoutingModes/#WALK","title":"WALK","text":"<p>Walking some or all of the way of the route.</p>"},{"location":"RoutingModes/#Transit modes","title":"Transit modes","text":"<p>Routing modes for transit, including rail, bus, ferry, etc. Equivalent to GTFS <code>route_type</code> or to NeTEx TransportMode. </p>"},{"location":"RoutingModes/#AIRPLANE","title":"AIRPLANE","text":"<p>Taking an airplane</p>"},{"location":"RoutingModes/#BUS","title":"BUS","text":"<p>Used for short- and long-distance bus routes.</p>"},{"location":"RoutingModes/#CABLE_CAR","title":"CABLE_CAR","text":"<p>Used for street-level cable cars where the cable runs beneath the car.</p>"},{"location":"RoutingModes/#CARPOOL","title":"CARPOOL","text":"<p>Private car trips shared with others.</p> <p>This is currently not specified in GTFS so we use the mode type values 1550-1560 which are in the range of private taxis.</p>"},{"location":"RoutingModes/#COACH","title":"COACH","text":"<p>Used for long-distance bus routes.</p>"},{"location":"RoutingModes/#FERRY","title":"FERRY","text":"<p>Used for short- and long-distance boat service.</p>"},{"location":"RoutingModes/#FUNICULAR","title":"FUNICULAR","text":"<p>Used for any rail system that moves on steep inclines with a cable traction system.</p>"},{"location":"RoutingModes/#GONDOLA","title":"GONDOLA","text":"<p>Gondola or suspended cable car. Typically used for aerial cable cars where the car is suspended from the cable.</p>"},{"location":"RoutingModes/#MONORAIL","title":"MONORAIL","text":"<p>Used for any rail system that runs on a single rail.</p>"},{"location":"RoutingModes/#RAIL","title":"RAIL","text":"<p>Used for intercity or long-distance travel.</p>"},{"location":"RoutingModes/#SUBWAY","title":"SUBWAY","text":"<p>Subway or Metro, used for any underground rail system within a metropolitan area.</p>"},{"location":"RoutingModes/#TAXI","title":"TAXI","text":"<p>Using a taxi service</p>"},{"location":"RoutingModes/#TRAM","title":"TRAM","text":"<p>Tram, streetcar or light rail. Used for any light rail or street level system within a metropolitan area.</p>"},{"location":"RoutingModes/#TROLLEYBUS","title":"TROLLEYBUS","text":"<p>Used for trolleybus systems which draw power from overhead wires using poles on the roof of the vehicle.</p>"},{"location":"SandboxExtension/","title":"OTP Sandbox Extensions","text":"<ul> <li>The sandbox is a place to test and implement new \"experimental\" features.</li> <li>This should not be used for bug fixes and smaller changes.</li> <li>Consider forking if the feature is valuable to one deployment only.</li> </ul>"},{"location":"SandboxExtension/#available-extensions","title":"Available extensions","text":"<p>Here is a list of features implemented as OTP Sandbox Extensions. The Sandbox extensions are provided \"as is\".</p> <ul> <li>Google Cloud Storage - Enable Google Cloud Storage as a OTP Data Source</li> <li>Actuator API - API used to check the health status of the OTP instance.</li> <li>Geocoder API - Adds an API to search for stops and stations.</li> <li>Transfer analyser - Module used for analyzing the transfers between  nearby stops generated by routing via OSM data.</li> <li>SIRI Updater - Update OTP with real-time information from a Transmodel SIRI data source.</li> <li>SIRI Azure Updater - fetch SIRI real-time data through Azure Service Bus</li> <li>VehicleRentalServiceDirectory - GBFS service directory endpoint.</li> <li>Smoove Bike Rental Updator Support - Smoove Bike Rental Updator(HSL)</li> <li>Mapbox Vector Tiles API - Mapbox Vector Tiles API</li> <li>Flex Routing - Flexible transit routing for GTFS and Netex data sources</li> <li>Park and Ride API - Park and Ride API</li> <li>Data Overlay - StreetEdge grid data populating affecting the route planning</li> <li>Vehicle Parking - Vehicle Parking updaters</li> <li>Vehicle-to-stop heuristics - Speeding up Park+Ride, Bike+Ride and Bike+Transit searches</li> <li>Travel Time (Isochrone &amp; Surface) API - Travel Time API</li> <li>IBI accessibility score - IBI accessibility score</li> <li>Fares - Fare calculation</li> <li>Ride hailing - Ride hailing services like Uber</li> </ul>"},{"location":"SandboxExtension/#terminology","title":"Terminology","text":"<p>Main/core   -- All OTP code and additional files, NOT part of the sandbox. (<code>docs</code>, <code>src/main</code>, <code>src/test</code> and so on)</p> <p>Extensions -- All features implemented in the OTP Sandbox, provided with no guarantees. (<code>src/ext</code>, <code>src/ext-test</code>)</p>"},{"location":"SandboxExtension/#sandbox-goals","title":"Sandbox Goals","text":"<ul> <li>Reduce work for PR approval</li> <li>Allow experimental code to evolve (in a Sandbox)</li> <li>Encourage refactoring and creation of extension points in the main code.</li> <li>Increase visibility and cooperation of development of new features.</li> <li>Feature toggle<ul> <li>Sandbox features should use the OTPFeature to enable the code. Sandbox features are by   default off. To toggle features on/off se the configuration documentation.</li> </ul> </li> </ul>"},{"location":"SandboxExtension/#contract","title":"Contract","text":"<ul> <li>Give your feature a name: <code>&lt;extension name&gt;</code></li> <li>A new feature is isolated from the rest of the code by putting it in the directory <code>src/ext</code>. Java   code should have package prefix <code>org.opentripplanner.ext.&lt;extension name&gt;</code>. Unit tests should be   added in the test directory: <code>src/ext-test</code></li> <li>To integrate the new feature into OTP you may have to create new extension points in the main/core   code. Changes to the core OTP are subject to normal a review process.</li> <li>Create a readme file (<code>docs/sandbox/&lt;Extension Name&gt;.md</code> package including:<ul> <li>Extension Name</li> <li>Contact info</li> <li>Change log</li> <li>Documentation of the feature (optional)</li> </ul> </li> <li>List your extension in the Available extensions section and in the   mkdocs config file.</li> <li>Use feature toggling to enable a feature at runtime. The feature must be disabled by default. A   feature is toggled on using the config files.</li> <li>Only code modifying the main code(<code>src/main</code>, not <code>src/ext</code>) is reviewed. The current coding   standard apply to the extension code as well - but the code is not necessarily reviewed.</li> <li>There are no grantees - the authors of an extension can change its API any time they want.</li> <li>Anyone can request the feature to be merged into the main code. An approval from the PLC and a new   review is then required. The reviewers may request any changes, including API changes.</li> <li>If an extension is taken into the core/main OTP code, any API included may change, no BACKWARD   compatibility is guaranteed. I.e. the reviewers may require changes before it is merged.</li> <li>The feature submitters is responsible for maintaining and testing the extension code, but do not   need to provide any guarantees or support. If the extension is merged into the main code the   author will in fact need to provide support and maintenance.</li> <li>When someone at a later point in time want to change the main code the only thing they are   responsible for - with regard to the extension code - is:<ul> <li>that it compiles.</li> <li>that the unit tests run. If a test is not easy to fix, it can be tagged with @Ignore. If   ignored it would be polite to notify the author.</li> </ul> </li> <li>Changes to the main OTP API that cannot be toggled in must be clearly marked/tagged as part of   an experimental feature and documented - This code is subject to review.</li> <li>If a feature is old and not maintained it can be removed 1 month after notifying the submitter   (using contact info in README file).</li> <li>Introducing new dependencies needs approval. They are NOT approved if they are likely to be a   maintenance challenge (many transitive dependencies or potential conflicts with other   versions/libraries).</li> </ul>"},{"location":"StopAreas/","title":"Stop Areas","text":"<p>Public transit stations and stops can be modeled using a relation tagged with <code>public_transport=stop_area</code>. Description of such relations can be found from this OSM wiki page.</p> <p>OpenTripPlanner detects such relations and applies some special logic to them. Nodes, which are linked to street network, and are located within platform areas, are interpreted as connection points from the street network to the platform. OTP automatically links such points with the platform geometry in order to improve walk routing.</p> <p>For example, an elevator or stairs can connect a normal street to a railway platform above it. There is no need to add an explicit edge, which connects the entrance point with the actual geometry of the platform.</p> <p>An  example: Huopalahti railway station in Helsinki</p>"},{"location":"StopAreas/#instructions","title":"Instructions","text":"<ul> <li>Add platforms, which need special linking, as members of a <code>stop_area</code> tagged relation</li> <li>Set role=platform to these platform members</li> <li>Platforms must be also proper areas, tagged as routable highways and <code>area=yes</code>. Also a single tag <code>public_transport=platform</code> will do.</li> <li>Model required entrance points and stop linking points inside platform geometry and make them relation members, too.</li> <li>Entrances can be tagged using <code>railway=subway_entrance</code>, <code>highway=elevator</code>, <code>entrance=yes</code> or <code>entrance=main</code>.</li> <li>Stop linking points should be tagged as boarding locations, e.g. using the tag <code>public_transport=platform</code>.</li> <li>Connect entrance points to the street network. Stop linking points can have reference tags to instruct how to link them with public transit stops as instructed in the document about boarding locations.</li> <li>Platform and its entrance point must have the same <code>level</code> tag value. Also matching by default value zero is accepted.</li> <li>If <code>level</code> tag is not set, <code>layer</code> tag is also considered</li> </ul>"},{"location":"System-Requirements/","title":"System Requirements and Suggestions","text":""},{"location":"System-Requirements/#system-requirements","title":"System requirements","text":""},{"location":"System-Requirements/#memory","title":"Memory","text":"<p>OTP is relatively memory-hungry as it includes all the required data in memory. How much memory is required to build the graph for OTP, or to run the OTP server, depends on the used data sets (is OSM, elevation and/or transit data included?), on the size of the covered geographical area and the density of the transit and street network. The required memory can vary from less than one GB to more than 100 GB. For example, including all available data for Finland takes a bit over 10 GB but for Germany it requires 95 GB.</p>"},{"location":"System-Requirements/#processor","title":"Processor","text":"<p>Single thread performance is an important factor for OTP's performance. Additionally, OTP benefits from larger CPU cache as reading from memory can be a bottleneck.</p> <p>OTP's performance scales with the number of available CPU cores. OTP processes each request in a separate thread and usually one request doesn't utilize more than one thread, but with some requests and configurations, it's possible that multiple threads are used in parallel for a small part of a request or to process multiple queries within one request. How much parallel processing we utilize in requests might change in the future. Real-time updates also run in a separate thread. Therefore, to have a good performance, it makes sense to have multiple cores available. How OTP uses parallel processing also depends on the available cores (&lt;= 2 cores vs &gt;2 cores) in some cases. Therefore, load testing should be done against a machine that doesn't differ too much from production machines.</p> <p>Entur and the Digitransit project have found that the 3rd generation AMD processors have a slightly better performance for OTP2 than the Intel 3rd generation CPUs (and especially better than the 2nd generation CPUs).</p>"},{"location":"System-Requirements/#suggested-vm-types-in-cloud-service-providers","title":"Suggested VM types in cloud service providers","text":""},{"location":"System-Requirements/#azure","title":"Azure","text":"<p>For Azure, the Digitransit project did benchmarking of the available virtual machines types for OTP 2.3 in early 2023 and found that the <code>D2as \u2013 D96as v5</code> family had the best performance of the reasonable priced virtual machines types. These machines use the 3rd generation AMD EPYCTM 7763v (Milan) processor. The 3rd generation Intel machines had a slightly worse performance and a slightly higher cost. Digitransit chose to use the <code>D8as v5</code> machine as it had enough memory for running OTP in Finland and a reasonable number of vCPUs.</p>"},{"location":"System-Requirements/#google-cloud","title":"Google Cloud","text":"<p>Entur uses a scalable fleet of instances of type <code>c2d-standard-8</code>.</p>"},{"location":"Troubleshooting-Routing/","title":"Troubleshooting Routing","text":""},{"location":"Troubleshooting-Routing/#graph-builder-data-import-issues","title":"Graph Builder Data Import Issues","text":"<p>When you build a graph, OTP may encounter clearly incorrect or ambiguous data, or may detect less severe, but potentially problematic situations in the input data. Such problems should result in a \"Data Import Issue\" being generated. These issues are logged the the <code>DATA_IMPORT_ISSUES</code> console logger, depending on your need you might turn this logger on/off. At the end of the graph build process, OTP prints a summary of all the issues, like the following:</p> <pre><code> 11:35:57.515 INFO (Graph.java:970) Summary (number of each type of issues):\n 11:35:57.518 INFO (Graph.java:976)     TurnRestrictionBad - 560\n 11:35:57.518 INFO (Graph.java:976)     TurnRestrictionException - 15\n 11:35:57.518 INFO (Graph.java:976)     StopLinkedTooFar - 22\n 11:35:57.518 INFO (Graph.java:976)     HopSpeedSlow - 22\n 11:35:57.518 INFO (Graph.java:976)     Graphwide - 1\n 11:35:57.518 INFO (Graph.java:976)     GraphConnectivity - 407\n 11:35:57.519 INFO (Graph.java:976)     ParkAndRideUnlinked - 1\n 11:35:57.519 INFO (Graph.java:976)     StopNotLinkedForTransfers - 31\n 11:35:57.519 INFO (Graph.java:976)     NoFutureDates - 1\n</code></pre> <p>The full set of issues can be written out to an HTML report for closer inspection. To enable the creation of these (potentially voluminous) HTML reports, add <code>\"dataImportReport\" : true</code> to your graph builder JSON configuration.</p> <p>If the graph is saved to a file, these issues are saved with it and can be examined later. Currently the only tool for doing this is the \"Graph Visualizer\", which is not particularly well maintained and is intended for use by software developers familiar with OTP who can patch up the code as needed.</p>"},{"location":"Troubleshooting-Routing/#debug-layers","title":"Debug layers","text":"<p>OpenTripplanner has option to ease debugging problems with graph. Older option is graph visualizer. Which you can enable with <code>--visualize</code> parameter instead of <code>--server</code> when starting OTP. There you can see whole graph. You can click on edges and vertices and see the metadata. It is useful to see if street has expected options. And if connections are where they are expected.</p> <p>It can be hard to use on large graphs since, whole graph is displayed at once. And it can be hard to search for specific streets since only street graph is shown without the rest of information.</p> <p>Another option is to use debug layers, which shows extra layers on top of the normal debug UI map. If you want to see them you need to open the map layer selector on the top left hand side and choose the requested layer.</p> <p>Currently you can choose between:</p> <ul> <li>Wheelchair access (which colors street edges red if they don't allow wheelchair or green   otherwise)</li> <li>Bicycle safety (colors street edges based on   how good are for cycling [smaller is better])</li> <li>Traversal permissions (colors street edges based on what types of transit modes are allowed to   travel on them (Pedestrian, cycling, car are currently supported)) Traversal permissions layer   also draws links from transit stops/vehicle rentals and P+R to graph. And also draws transit   stops, vehicle rentals and P+R vertices with different color.</li> <li>No thru traffic - streets are colored if the edge has thru traffic restrictions (car and bicycle   = <code>red</code>, car only = <code>orange</code>, bicycle only = <code>blue</code>, and no-restriction = <code>light gray</code>)</li> </ul>"},{"location":"Troubleshooting-Routing/#interpretation-traversal-permissions-layer","title":"Interpretation Traversal permissions layer","text":"<p>A sample traversal permissions layer looks like the following </p> <ul> <li>Yellow lines is the link between a stop and the street graph.</li> <li>Grey lines are streets one can travel with the mode walk, bike, or car</li> <li>Green lines are paths one can travel with the mode walk only</li> <li>Red lines are streets one can travel with the mode car only</li> <li>Grey dots vertices where edges are connected. If two edges are crossing w/o a vertice at the   intersection point, users will not be able to go from one street to the other. But this can be   valid in case of over/under pass for example. If it's an error, it's usually caused by improperly   connected OSM data (a shared OSM node is required).</li> </ul>"},{"location":"Troubleshooting-Routing/#openstreetmap-data","title":"OpenStreetMap Data","text":""},{"location":"Troubleshooting-Routing/#tags-affecting-permissions-and-bicycle-safety","title":"Tags affecting permissions and bicycle safety","text":"<p>OTP has a very flexible system for deciding when a street is to be allowed by pedestrians, bicycles or cars.</p> <p>To configure the which settings to use for your location, please use the osmTagMapping config attribute.</p> <p>In the following section we will discuss the default case, which will be used if the property is not set.</p>"},{"location":"Troubleshooting-Routing/#default-settings","title":"Default settings","text":"<p>Access tags (such as bicycle/foot = yes/no/designated) can be used to override default graph-building parameters.</p> <p>As a default, foot and bicycle traffic is ''not'' allowed on <code>highway=trunk</code>, <code>highway=trunk_link</code> , <code>highway=motorway</code>, <code>highway=motorway_link</code>, or <code>highway=construction</code>.</p> <p>Both are allowed on <code>highway=pedestrian</code>, <code>highway=cycleway</code>, and <code>highway=footway</code>.</p> <p>Finally, bicycles are not allowed on highway=footway when any of the following tags appear on a footway: <code>footway=sidewalk</code>, <code>public_transport=platform</code>, or <code>railway=platform</code>.</p> <p>Other access tags (such as <code>access=no</code> and <code>access=private</code> affect routing as well, and can be overridden similarly. While <code>access=no</code> prohibits all traffic, <code>access=private</code> disallows through traffic.</p>"},{"location":"Troubleshooting-Routing/#bicycle-safety-factor","title":"Bicycle safety factor","text":"<p>Bicycle routing is even more configurable than the other traverse modes: during graph build a so-called bicycle safety score is computed for each street. You can think of this score as a penalty for traversing this way so the lower the score the better.</p> <p>For example if a way is tagged with <code>surface=sand</code> it receives a safety score of 100 which means that it's 100 times worse to cycle on when compared to a way which has a safety score of 1.</p> <p>How this is calculated depends on two things</p> <ul> <li>the incline of the way (not read from OSM but from   the separately configured elevation data)</li> <li>its OSM tags</li> </ul> <p>At request time you can then use the <code>triangleFactors</code> to decide how important bicycle safety is compared to shorter distances and flatness.</p> <p>Each <code>WayPropertySet</code> contains rules for a given set of tag matchers that influence the bicycle safety score. For example, a rule looks like this:</p> <pre><code>props.setProperties(\"highway=track\", StreetTraversalPermission.ALL, 1.3, 1.3);\n</code></pre> <p>This means that an OSM way with the tag <code>highway=track</code> is traversable by all modes (pedestrian, bicycle, car) and that its bicycle safety score when you traverse in order of the way is <code>1.3</code> and also <code>1.3</code> when going the other way (smaller means more cycle-friendly).</p> <p>If there is a more specific matcher like <code>highway=track;bicycle=no</code> and it matches a given OSM way, it is chosen instead and its settings applied.</p> <p>The score can be any positive number but the range (as of writing this) goes from <code>0.6</code> for bike lanes to <code>100</code> for ways that consist of sand. To figure out a good value for your set of tags you should read the bicycle safety report (see below) or the source code of your <code>OsmTagMapper</code> to get a feeling for how much certain tags are penalised or rewarded.</p> <p>There are also so-called mixins. These are applied on top of the most specific matchers and a single OSM way can match many mixins. The mixins' safety values are multiplied with the value of the base (non-mixin) match. A mixin looks like this (note the <code>true</code> at the end):</p> <pre><code>props.setProperties(\"surface=mud\", StreetTraversalPermission.ALL, 1.5, 1.5, true);\n</code></pre> <p>The Javadoc of <code>OSMSpecifier.java</code> contains the precise documentation about the syntax of the matchers.</p> <p>There are a lot of rules for which tags results in a specific safety score so it's not easy to get an overview. There is however an OTP feature to get an HTML viewer with a search feature that lets you browse through the rules.</p> <p></p> <p>To enable it activate the Report API sandbox feature.</p> <p>To view the output of the bicycle safety calculation on a map, check the debug layers.</p>"},{"location":"Troubleshooting-Routing/#railway-platforms","title":"Railway Platforms","text":"<p>OTP users in Helsinki have documented their best practices for coding railway platforms in OpenStreetMap. These guidelines are available in the OSM Wiki.</p>"},{"location":"Troubleshooting-Routing/#transit-search","title":"Transit search","text":"<p>The Raptor implementation support instrumentation of ACCEPT, REJECT, and DROP events for stop-arrivals and trip boardings. Use the SpeedTest to pass in a set of stops and/or a specific path to debug. This is useful when debugging why you do (not) get a particular result.</p> <p>Read the logging page for more information.</p>"},{"location":"Troubleshooting-Routing/#gtfs-transferstxt-and-netex-interchange-import","title":"GTFS Transfers.txt and NeTEx Interchange import","text":"<p>Transfers may have effects on the routing which may be difficult to predict. OTP can dump all imported transfers to file - transfers-debug.csv. This may help verify the result of the import or find special test cases. To turn on the export enable the slf4j logger:</p> <pre><code>  &lt;logger name=\"TRANSFERS_EXPORT\" level=\"info\" /&gt;\n</code></pre>"},{"location":"Troubleshooting-Routing/#further-information","title":"Further information","text":"<ul> <li>General information</li> <li>Bicycle routing</li> <li>Indoor mapping</li> <li>Elevators</li> </ul>"},{"location":"UpdaterConfig/","title":"Realtime Updaters","text":""},{"location":"UpdaterConfig/#updater-configuration","title":"Updater configuration","text":"<p>This section covers options that can be set in the updaters section of <code>router-config.json</code>.  See the parameter summary and examples in the router configuration documentation</p> <p>Real-time data are those that are not added to OTP during the graph build phase but during runtime.</p> <p>Real-time data sources are configured in the <code>updaters</code> section is an array of JSON objects, each of which has a <code>type</code> field and other configuration fields specific to that type. </p>"},{"location":"UpdaterConfig/#gtfs-realtime","title":"GTFS-Realtime","text":"<p>GTFS feeds contain schedule data that is published by an agency or operator in advance. The feed does not account for unexpected service changes or traffic disruptions that occur from day to day. Thus, this kind of data is also referred to as 'static' data or 'theoretical' arrival and departure times.</p> <p>GTFS-Realtime complements GTFS with three additional kinds of feeds. In contrast to the base GTFS schedule feed, they provide real-time updates ('dynamic' data) and are updated from minute to minute.</p>"},{"location":"UpdaterConfig/#alerts","title":"Alerts","text":"<p>Alerts are text messages attached to GTFS objects, informing riders of disruptions and changes.  The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"real-time-alerts\" <code>enum</code> The type of the updater. Required 1.5 earlyStartSec <code>integer</code> How long before the posted start of an event it should be displayed to users Optional <code>0</code> 1.5 feedId <code>string</code> The id of the feed to apply the alerts to. Required 1.5 frequency <code>duration</code> How often the URL should be fetched. Optional <code>\"PT1M\"</code> 1.5 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 1.5 url <code>string</code> URL to fetch the GTFS-RT feed from. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u_0_headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[0] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"real-time-alerts\",\n      \"frequency\" : \"30s\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/FeedSpecAlerts/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Some-Header\" : \"A-Value\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#tripupdates-via-https","title":"TripUpdates via HTTP(S)","text":"<p>TripUpdates report on the status of scheduled trips as they happen, providing observed and  predicted arrival and departure times for the remainder of the trip. The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"stop-time-updater\" <code>enum</code> The type of the updater. Required 1.5 backwardsDelayPropagationType <code>enum</code> How backwards propagation should be handled. Optional <code>\"required-no-data\"</code> 2.2 feedId <code>string</code> Which feed the updates apply to. Required 1.5 frequency <code>duration</code> How often the data should be downloaded. Optional <code>\"PT1M\"</code> 1.5 fuzzyTripMatching <code>boolean</code> If the trips should be matched fuzzily. Optional <code>false</code> 1.5 url <code>string</code> The URL of the GTFS-RT resource. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details_1","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__5__backwardsDelayPropagationType","title":"backwardsDelayPropagationType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"required-no-data\"</code> Path: /updaters/[5]  Enum values: <code>required-no-data</code> | <code>required</code> | <code>always</code></p> <p>How backwards propagation should be handled.</p> <p>REQUIRED_NO_DATA:   Default value. Only propagates delays backwards when it is required to ensure that the times   are increasing, and it sets the NO_DATA flag on the stops so these automatically updated times   are not exposed through APIs.</p> <p>REQUIRED:   Only propagates delays backwards when it is required to ensure that the times are increasing.   The updated times are exposed through APIs.</p> <p>ALWAYS   Propagates delays backwards on stops with no estimates regardless if it's required or not.   The updated times are exposed through APIs.</p>"},{"location":"UpdaterConfig/#u__5__url","title":"url","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[5] </p> <p>The URL of the GTFS-RT resource.</p> <p><code>file:</code> URLs are also supported if you want to read a file from the local disk.</p>"},{"location":"UpdaterConfig/#u__5__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[5] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"stop-time-updater\",\n      \"frequency\" : \"1m\",\n      \"backwardsDelayPropagationType\" : \"REQUIRED_NO_DATA\",\n      \"url\" : \"http://developer.trimet.org/ws/V1/TripUpdate/appID/0123456789ABCDEF\",\n      \"feedId\" : \"TriMet\",\n      \"headers\" : {\n        \"Authorization\" : \"A-Token\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#streaming-tripupdates-via-mqtt","title":"Streaming TripUpdates via MQTT","text":"<p>This updater connects to an MQTT broker and processes TripUpdates in a streaming fashion. This means that they will be applied individually in near-realtime rather than in batches at a certain interval.</p> <p>This system powers the realtime updates in Helsinki and more information can be found  on Github.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"mqtt-gtfs-rt-updater\" <code>enum</code> The type of the updater. Required 1.5 backwardsDelayPropagationType <code>enum</code> How backwards propagation should be handled. Optional <code>\"required-no-data\"</code> 2.2 feedId <code>string</code> The feed id to apply the updates to. Required 2.0 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 2.0 qos <code>integer</code> QOS level. Optional <code>0</code> 2.0 topic <code>string</code> The topic to subscribe to. Required 2.0 url <code>string</code> URL of the MQTT broker. Required 2.0"},{"location":"UpdaterConfig/#parameter-details_2","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__6__backwardsDelayPropagationType","title":"backwardsDelayPropagationType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"required-no-data\"</code> Path: /updaters/[6]  Enum values: <code>required-no-data</code> | <code>required</code> | <code>always</code></p> <p>How backwards propagation should be handled.</p> <p>REQUIRED_NO_DATA:   Default value. Only propagates delays backwards when it is required to ensure that the times   are increasing, and it sets the NO_DATA flag on the stops so these automatically updated times   are not exposed through APIs.</p> <p>REQUIRED:   Only propagates delays backwards when it is required to ensure that the times are increasing.   The updated times are exposed through APIs.</p> <p>ALWAYS:   Propagates delays backwards on stops with no estimates regardless if it's required or not.   The updated times are exposed through APIs.</p>"},{"location":"UpdaterConfig/#example-configuration_2","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"mqtt-gtfs-rt-updater\",\n      \"url\" : \"tcp://pred.rt.hsl.fi\",\n      \"topic\" : \"gtfsrt/v2/fi/hsl/tu\",\n      \"feedId\" : \"HSL\",\n      \"fuzzyTripMatching\" : true\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#vehicle-positions","title":"Vehicle Positions","text":"<p>VehiclePositions give the location of some or all vehicles currently in service, in terms of  geographic coordinates or position relative to their scheduled stops. The information is downloaded in a single HTTP request and polled regularly.</p> Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-positions\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> Feed ID to which the update should be applied. Required 2.2 frequency <code>duration</code> How often the positions should be updated. Optional <code>\"PT1M\"</code> 2.2 fuzzyTripMatching <code>boolean</code> Whether to match trips fuzzily. Optional <code>false</code> 2.5 url <code>uri</code> The URL of GTFS-RT protobuf HTTP resource to download the positions from. Required 2.2 features <code>enum set</code> Which features of GTFS RT vehicle positions should be loaded into OTP. Optional 2.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"UpdaterConfig/#parameter-details_3","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u__7__features","title":"features","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>enum set</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[7]  Enum values: <code>position</code> | <code>stop-position</code> | <code>occupancy</code></p> <p>Which features of GTFS RT vehicle positions should be loaded into OTP.</p>"},{"location":"UpdaterConfig/#u__7__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[7] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_3","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-positions\",\n      \"url\" : \"https://s3.amazonaws.com/kcm-alerts-realtime-prod/vehiclepositions.pb\",\n      \"feedId\" : \"1\",\n      \"frequency\" : \"1m\",\n      \"headers\" : {\n        \"Header-Name\" : \"Header-Value\"\n      },\n      \"fuzzyTripMatching\" : false,\n      \"features\" : [\n        \"position\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#gbfs-vehicle-rental-systems","title":"GBFS vehicle rental systems","text":"<p>Besides GTFS-RT transit data, OTP can also fetch real-time data about vehicle rental networks including the number of vehicles and free parking spaces at each station. We support vehicle rental systems that use the GBFS standard.</p> <p>GBFS can be used for a variety of shared mobility services, with partial support for both v1 and v2.2 (list of known GBFS feeds). OTP supports the following GBFS form factors:</p> <ul> <li>bicycle</li> <li>scooter</li> <li>car</li> </ul> Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-rental\" <code>enum</code> The type of the updater. Required 1.5 allowKeepingRentedVehicleAtDestination <code>boolean</code> If a vehicle should be allowed to be kept at the end of a station-based rental. Optional <code>false</code> 2.1 frequency <code>duration</code> How often the data should be updated. Optional <code>\"PT1M\"</code> 1.5 geofencingZones <code>boolean</code> Compute rental restrictions based on GBFS 2.2 geofencing zones. Optional <code>false</code> 2.3 language <code>string</code> TODO Optional 2.1 network <code>string</code> The name of the network to override the one derived from the source data. Optional 1.5 overloadingAllowed <code>boolean</code> Allow leaving vehicles at a station even though there are no free slots. Optional <code>false</code> 2.2 sourceType <code>enum</code> What source of vehicle rental updater to use. Required 1.5 url <code>string</code> The URL to download the data from. Required 1.5 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 1.5"},{"location":"UpdaterConfig/#parameter-details_4","title":"Parameter details","text":""},{"location":"UpdaterConfig/#u_1_allowKeepingRentedVehicleAtDestination","title":"allowKeepingRentedVehicleAtDestination","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /updaters/[1] </p> <p>If a vehicle should be allowed to be kept at the end of a station-based rental.</p> <p>In some cases it may be useful to not drop off the rented vehicle before arriving at the destination. This is useful if vehicles may only be rented for round trips, or the destination is an intermediate place.</p> <p>For this to be possible three things need to be configured:</p> <ul> <li>In the updater configuration <code>allowKeepingRentedVehicleAtDestination</code> should be set to <code>true</code>.</li> <li><code>allowKeepingRentedVehicleAtDestination</code> should also be set for each request, either using routing defaults, or per-request.</li> <li>If keeping the vehicle at the destination should be discouraged, then <code>keepingRentedVehicleAtDestinationCost</code> (default: 0) may also be set in the routing defaults.</li> </ul>"},{"location":"UpdaterConfig/#u_1_geofencingZones","title":"geofencingZones","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>boolean</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>false</code> Path: /updaters/[1] </p> <p>Compute rental restrictions based on GBFS 2.2 geofencing zones.</p> <p>This feature is somewhat experimental and therefore turned off by default for the following reasons:</p> <ul> <li>It delays start up of OTP. How long is dependent on the complexity of the zones. For example in Oslo it takes 6 seconds to compute while Portland takes 25 seconds.</li> <li>It's easy for a malformed or unintended geofencing zone to make routing impossible. If you encounter such a case, please file a bug report.</li> </ul>"},{"location":"UpdaterConfig/#u_1_network","title":"network","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[1] </p> <p>The name of the network to override the one derived from the source data.</p> <p>GBFS feeds must include a system_id which will be used as the default <code>network</code>. These ids are sometimes not helpful so setting this property will override it.</p>"},{"location":"UpdaterConfig/#u_1_sourceType","title":"sourceType","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[1]  Enum values: <code>gbfs</code> | <code>smoove</code></p> <p>What source of vehicle rental updater to use.</p>"},{"location":"UpdaterConfig/#u_1_headers","title":"headers","text":"<p>Since version: <code>1.5</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[1] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"UpdaterConfig/#example-configuration_4","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-rental\",\n      \"network\" : \"socialbicycles_coast\",\n      \"sourceType\" : \"gbfs\",\n      \"language\" : \"en\",\n      \"frequency\" : \"1m\",\n      \"allowKeepingRentedVehicleAtDestination\" : false,\n      \"geofencingZones\" : false,\n      \"url\" : \"http://coast.socialbicycles.com/opendata/gbfs.json\",\n      \"headers\" : {\n        \"Auth\" : \"&lt;any-token&gt;\",\n        \"&lt;key&gt;\" : \"&lt;value&gt;\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"UpdaterConfig/#other-updaters-in-sandboxes","title":"Other updaters in sandboxes","text":"<ul> <li>Vehicle parking</li> <li>Siri over HTTP</li> <li>Siri over Azure Message Bus</li> <li>VehicleRentalServiceDirectory</li> </ul>"},{"location":"Version-Comparison/","title":"Comparing OTP2 and OTP1","text":""},{"location":"Version-Comparison/#summary","title":"Summary","text":"<p>OpenTripPlanner has been under development since 2009, leading up to a 1.0 release in 2016. Research and development on higher performance routing has been ongoing since 2013-2014, and work on the second major release referred to as OTP2 officially began in 2018. As of Q3 2023, OTP2 is the only version to receive regular updates and OTP1 is considered legacy and unsupported. This page explains  key differences between the two versions (referred to as OTP1 and OTP2). </p> <p>OTP1 has existed for over a decade and is in widespread use. It aims to do many things for many people: it provides passenger-facing itinerary services over APIs, but also serves as a network analysis toolkit for urban planning and research. Though OTP1 is widely used and gets the job done, its transit routing approach is obsolete. We have long recognized that more resource-efficient approaches were possible. Reasonable response times and scaling to larger data sets have been achieved through a series of complex incremental interventions that became difficult to maintain. OTP1 has also accumulated large amounts of experimental code and specialized tools, which can be useful in a research or consulting setting but complicate long-term maintenance.</p> <p>OTP2 offers much better performance in larger transportation networks and geographic areas, and a wider variety of alternative itineraries. OTP2's public transit routing component has been completely rewritten, and is now distinct from bike, walk, and motor vehicle routing. Non-transit routing remains very similar to OTP1, benefiting from years of adaptations to nuances of OpenStreetMap data and end-user walking and biking preferences. Unlike OTP1, OTP2 is completely focused on passenger-facing itinerary services. The innovations in OTP2 have already been applied to planning, research, and analysis work for several years through Conveyal's R5 project, which informed and inspired the OTP2 transit routing system.</p>"},{"location":"Version-Comparison/#otp2-use-cases","title":"OTP2 Use Cases","text":"<p>The benefits of OTP2 will be most evident in large or dense networks spanning multiple cities: entire countries (Netherlands, Switzerland, Norway), US states, metropolitan regions and cross-border conurbations (e.g. NYC metro area). Although the scale of trip planners is sometimes limited by the geographic extent of administrative structures (national rail or bus operators or ticketing agencies), OTP2 should be capable of handling even larger networks, and we do for example regularly test on a unified Nordic trip planner in hopes that such systems will materialize over time as more territories adopt OTP.</p> <p>OTP2 development has been driven by adoption of open source routing software in Northern Europe. Importantly for deployments in Europe, OTP2 introduces support for EU-standard Netex and SIRI data sources in addition to GTFS. The Nordic profile of Netex understood by OTP2 uses the same schema as the EU profile, and generalization to the EU profile should be feasible once it is standardized.</p>"},{"location":"Version-Comparison/#high-level-feature-comparison","title":"High-level feature comparison","text":"Feature OTP1 OTP2 OSM street data yes yes GTFS transit data yes yes Netex transit data no yes(Nordic profile) GTFS-Realtime yes(streaming, polling, incremental) yes(streaming, polling, incremental) SIRI Realtime no yes Elevation data TIFF and NED TIFF and NED One-to-many routing, isochrones and scripting yes no Isochrones yes yes Java version 8+ 21+ Multiple regions per server yes no Hot reloading of graphs yes no Street (OSM) routing algorithm Generalized cost A* Generalized cost A* Transit routing algorithm Generalized cost A* Multi-criteria range-RAPTOR Search segmentation Single search through access, transit, egress Access/egress separate from transit search Goal direction Upper bound search backward from destination, over streets and transit, interleaved with forward search Upper bound search backward from destination  on transit only, before forward search begins Alternative itineraries \"Trip banning\", N lowest generalized costs True Pareto-optimal results Departure/arrival time Single departure or arrival time only Every minute in a window up to several days long API Paging no yes Timetable View no yes Plugin Sandbox Extensions no yes (See extensions) Data storage local, S3 (elevation only) extensible with local, ZIP,and Google Cloud plugins, S3 available Transfer Priority yes yes"},{"location":"Version-Comparison/#commentary-on-otp1-features-removed-from-otp2","title":"Commentary on OTP1 features removed from OTP2","text":"<p>OTP2 brings significant improvements in speed and scalability, but does not retain all features of OTP1. We have chosen to prioritize long-term maintainability, so only those features that are  \"owned\" by a team of professional developers will be carried over to OTP2.</p> <p>Some features have been removed to simplify the code base and improve maintainability. Others have been removed to reflect separation of concerns: following principles of modular design they should be handled outside OTP, or are already covered by other projects where they are more actively developed.</p>"},{"location":"Version-Comparison/#analysis","title":"Analysis","text":"<p>Many OpenTripPlanner contributors have been primarily interested in transportation and urban planning use cases. We consider these use cases quite important. This has been a major area of application for OpenTripPlanner and has helped popularize cumulative opportunities accessibility metrics. For example, the University of Minnesota Accessibility Observatory used OpenTripPlanner for Access Across America. Nonetheless, the analysis code in OTP1 is essentially an unmaintained and unsupported early prototype for later projects, specifically Conveyal's R5 (and the Conveyal Analysis system built upon it). OTP1 seems to have gained popularity for analysis uses due to the existence of documentation and an active user community, but has significant technical shortcomings. One of these is simply speed: OTP1 can be orders of magnitude slower (and more memory-intensive) than the approaches exemplified in R5. The other is the requirement to search at a single specific time. Travel times and especially wait times on scheduled transit vary greatly depending on when you depart. Accounting for variation over a time window requires repeated independent searches at each possible departure time, which is very inefficient. R5 is highly optimized to capture variations in travel time across time windows and account for uncertainty in waiting times on frequency-based routes.</p> <p>Due to its similarity to the R5 approach, OTP2's transit router would not have these same problems. Nonetheless, we have decided not to port the OTP1 analysis features over to OTP2 since it would broaden the focus away from passenger information and draw finite attention away from existing projects like R5 and Conveyal Analysis.</p> <p>Accordingly, we have made an effort to clean up and augment OTP1 analysis documentation for researchers who will continue to need it. It should remain possible for people to continue using OTP1 if they prefer. If you would instead like to apply the innovations present in OTP2, we recommend looking into R5 or Conveyal Analysis.</p>"},{"location":"Version-Comparison/#routers-api-and-hot-reloading","title":"Routers API and Hot Reloading","text":"<p>Via it's Routers API, OTP1 allows loading data and serving APIs for multiple separate geographic areas. This is functionally equivalent to running more than one OTP server with separate data sets. This system also allows reloading transportation network data when it changes, or even pushing new data over a network connection.</p> <p>These were all adaptations to the very different IT environment that existed earlier in OTP history. These days, containerization and on-demand cloud servers have become ubiquitous, and most users solve these problems in totally different ways - by provisioning and starting up entirely new virtual servers, then switching a load balancer over to those new servers. Because the Routers API is complex and exposes potentially damaging functionality over the network, it has been removed from OTP2 to simplify the code base and make it easier to reason about security.</p>"},{"location":"Version-Comparison/#routing-request-parameters","title":"Routing request parameters","text":"<p>Less parameters are available on the OTP2 REST API than in OTP1. Often there is no practical loss of functionality, just a different way of expressing things due to the new routing algorithms. A summary of parameters that have been removed and their replacements can be found in the migration guide</p>"},{"location":"Version-Comparison/#otp-trip-planning-and-transit-index-apis","title":"OTP Trip planning and Transit index APIs","text":"<p>OTP1 had two APIs for trip planning, the REST API and an GraphQL API (early version of the GTFS GraphQL API). This API has been formalised and is now, together with the Transmodel  GraphQL API, the only supported way of sending requests to the OTP routing engine.</p> <p>Details of those two APIs are available at the following pages:</p> <ul> <li>GTFS GraphQL API - HSL's GraphQL API used by the Digitransit   project.</li> <li>Transmodel API - Entur's Transmodel API</li> </ul> <p>The plan is to merge the two APIs above, clean it up and make it the new official API. The HSL API uses GTFS terminology, while the Entur API is Transmodel (NeTEx) based. Both APIs are similar in semantics and structure, and provide the same functionality. </p>"},{"location":"Version-Comparison/#additional-characteristics-added-in-otp2","title":"Additional characteristics added in OTP2","text":"<p>Sandbox Extensions OTP2's Sandbox system allows for plugins, proprietary extensions, and experimental feature development with less overhead. It forces OTP2 to become more extensible, while reducing process overhead when developing non-core features.</p> <p>Cloud support In OTP1 all data access (config, input data, and graph output) is by direct access to the local filesystem. The only exception is elevation data, which can be loaded from AWS S3 as well. In OTP2, all data access is through an abstraction layer. This can be configured to support individual local files, zip files, and Google Cloud Storage. The new data access treats directories and zip files as \u201cequal\u201d, and this functionality is used to read the contents of GTFS and NeTEx archives. Other data sources can be supported by writing plugins. Entur has written a plugin for AWS S3 which has not been merged. If requested they can provide this code for AWS S3.</p> <p>Library upgrades We have adapted OTP2 to run on Java 11+ and moved to newer versions of some dependencies such as GraphQL and One Bus Away.</p> <p>Bugfixes At least bug issues have been resolved in OTP2. Critical fixes have been backported to OTP1. See https://github.com/issues?q=is%3Aclosed+is%3Aissue+label%3AOTP2+label%3Abug</p>"},{"location":"Version-Comparison/#other-features-removed-from-otp2","title":"Other features removed from OTP2","text":"<p>AlertPatch GTFS-RT Service Alerts will no longer affect routing (e.g. cancel trips). A GTFS-RT Trip Updates feed should be used for this purpose.</p>"},{"location":"Version-Comparison/#migration-guide","title":"Migration guide","text":"<p>The development community has maintained a migration guide from version 1.5.0 up to 2.2.0 when it was no longer feasible to document every change as version 2 was considered the only supported one. The document can be found in the documentation of version 2.2.0.</p>"},{"location":"Visual-Identity/","title":"OpenTripPlanner Visual Identity","text":"<p>This is the OpenTripPlanner logo in scalable vector format, with knockout transparency:</p> <p></p> <p>Here is a link to this SVG logo as a downloadable file. This is the raw SVG XML source code:</p> <pre><code>&lt;?xml version=\"1.0\" encoding=\"utf-8\"?&gt;\n&lt;!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\" \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\"&gt;\n&lt;svg version=\"1.1\" id=\"Layer_1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    x=\"0px\" y=\"0px\" width=\"512px\" height=\"512px\" viewBox=\"0 0 125.333 125.334\" xml:space=\"preserve\"&gt;\n&lt;path fill=\"#2179BF\" d=\"M62.668,0C33.83,0,9.559,19.483,2.258,46l72.681-0.003c4.729-0.011,8.555-3.837,8.561-8.568\n    c-0.006-4.729-3.831-8.555-8.561-8.559c-4.731,0.004-8.557,3.83-8.564,8.559v4.592h-13.7v-4.592\n    c0-12.294,9.962-22.261,22.265-22.263c12.298,0.002,22.262,9.969,22.266,22.263c-0.003,12.3-9.968,22.264-22.266,22.271H0.074\n    C0.028,60.684,0,61.671,0,62.666c0,34.611,28.057,62.668,62.668,62.668c34.609,0,62.665-28.057,62.665-62.668\n    C125.333,28.057,97.277,0,62.668,0 M92.222,85.667v-3.473v-4.86l-47.058,0.003c-4.729,0.011-8.556,3.837-8.561,8.568\n    c0.005,4.728,3.831,8.555,8.561,8.559c4.731-0.004,8.558-3.831,8.565-8.559v-4.592h13.699v4.592\n    c0,12.294-9.961,22.261-22.265,22.263c-12.298-0.002-22.26-9.969-22.264-22.263c0.002-12.3,9.966-22.264,22.264-22.271h47.058V56.12\n    l21.712,14.775L92.222,85.667z\"/&gt;\n&lt;/svg&gt;\n</code></pre> <p>This concept behind this logo design was \"infinite roads\". Besides the clear references to movement and wayfinding through a transportation network, it (somewhat subliminally) contains the letters O T and P. This design is more geometric and austere than our previous logo, which makes it readily recognizable in a crowd of small app icons, bookmarks, or favicons. It also channels the high modern logos and 1970s supergraphics that were the visual style of public transport for a generation.</p> <p>The color of the logo in the RGB colorspace is <code>#2179BF</code>.</p> <p>The name of the OpenTripPlanner project is written in CamelCase: capital letters at the beginning of each word, with no spaces between the words. For the logotype we do not strictly adhere to a standard typeface. The OTP website just uses the CSS declarations <code>font: 30pt helvetica, sans-serif; font-weight: bold;</code>.</p> <p>The OpenTripPlanner logo was created by Brooklyn-based cartographer and graphic designer Kate Chanba, who has also done extensive work on transit system maps.</p>"},{"location":"apis/Apis/","title":"APIs","text":"<p>Several services are built upon OTP's routing and transit data indexing engines. They expose these APIs:</p> <p>The GTFS GraphQL API has been used by the Digitransit and otp-react-redux  projects as a general purpose routing and transit data API in production for many years.  If your input data is mostly GTFS then this is probably the best choice as it uses the same vocabulary.</p> <p>The Transmodel GraphQL API is used at Entur in production since 2020. Like the GTFS GraphQL API it is also a general purpose API. If your input data is mostly NeTeX then you might want to investigate this API as it uses the Transmodel vocabulary to describe  its entities.</p> <p>The Vector tiles API is a special purpose API for displaying entities on a vector map.</p> <p>The Actuator API provides endpoints for checking the health status of the OTP instance and reading live application metrics. </p> <p>The Geocoder API allows you to geocode stop names.</p>"},{"location":"apis/Apis/#legacy-apis-to-be-removed","title":"Legacy APIs (to be removed)","text":"<p>The OTP REST API used to power many apps and frontends. For years it was the only way to access OTP programmatically.</p> <p>Over time it has been replaced by the GraphQL APIs and is scheduled to be disabled by default and eventually removed completely. It's therefore not recommended to use it.</p>"},{"location":"apis/GTFS-GraphQL-API/","title":"GTFS GraphQL API","text":"<p>The GTFS GraphQL API is a general purpose API which was created for the Digitransit project and is  used heavily by digitransit-ui.</p> <p>otp-react-redux has also migrated to this API in 2023.</p>"},{"location":"apis/GTFS-GraphQL-API/#urls","title":"URLs","text":"<ul> <li>GraphQL endpoint: <code>http://localhost:8080/otp/gtfs/v1</code></li> <li>HTML schema documentation: https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/</li> <li>Built-in visual GraphQL client: http://localhost:8080/graphiql</li> </ul>"},{"location":"apis/GTFS-GraphQL-API/#built-in-api-client","title":"Built-in API client","text":"<p>A browser based GraphQL API client is available at http://localhost:8080/graphiql</p> <p></p> <p><code>curl</code> example</p> <p>A complete example that fetches the list of all stops from OTP is:</p> <pre><code>curl --request POST \\\n  --url http://localhost:8080/otp/gtfs/v1 \\\n  --header 'Content-Type: application/json' \\\n  --header 'OTPTimeout: 180000' \\\n  --data '{\"query\":\"query stops {\\n  stops {\\n    gtfsId\\n    name\\n  }\\n}\\n\",\"operationName\":\"stops\"}'\n</code></pre>"},{"location":"apis/GTFS-GraphQL-API/#configuration","title":"Configuration","text":"<p>The API is enabled by default.</p> <p>If you want to disable it, do it in <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\" : {\n    \"GtfsGraphQlApi\": false\n  }\n}\n</code></pre>"},{"location":"apis/GraphQL-Tutorial/","title":"GraphQL Tutorial","text":""},{"location":"apis/GraphQL-Tutorial/#graphql-tutorial","title":"GraphQL tutorial","text":"<p>This document will give you a quick start tutorial on how to get started with OTP's GraphQL APIs. For  this tutorial we will be using the GTFS GraphQL API as this is the most commonly used one.</p> <p>First of all, make sure that you've loaded street and transit data into your instance by following the basic tutorial</p>"},{"location":"apis/GraphQL-Tutorial/#visual-graphql-api-client","title":"Visual GraphQL API client","text":"<p>OTP has a built-in API client to help you build queries and view documentation. After having started OTP, visit http://localhost:8080/graphiql to open it.</p> <p>It should look like this:</p> <p></p>"},{"location":"apis/GraphQL-Tutorial/#sending-your-first-query","title":"Sending your first query","text":"<p>For our first query we want to get the list of routes loaded into OTP. Therefore paste the following  GraphQL query in the left hand panel of the page:</p> <pre><code>{\n    routes {\n        longName\n        shortName\n        gtfsId\n        agency {\n            gtfsId\n            name\n        }\n        mode\n        bikesAllowed\n    }\n}\n</code></pre> <p>After pressing the \"Execute query\" button you should see the result of the query on the right hand side panel.</p> <p>Now would be a good time to explore the auto-complete capabilities of the tool by moving the cursor into the query panel and hitting Ctrl-Space to see what other query parameters are possible.</p> <p></p> <p>The explorer also has documentation built into it. If you hover your pointer over a property on the  left hand side you can see its documentation.</p> <p></p>"},{"location":"apis/GraphQL-Tutorial/#a-more-advanced-query","title":"A more advanced query","text":"<p>Most people want to get routing results out of OTP, so lets see the query for this:</p> <pre><code>{\n    plan(\n        # these coordinates are in Portland, change this to YOUR origin\n        from: { lat: 45.5552, lon: -122.6534 }\n        # these coordinates are in Portland, change this to YOUR destination\n        to: { lat: 45.4908, lon: -122.5519 }\n        # use the correct date and time of your request\n        date: \"2023-02-15\",\n        time: \"11:37\",\n        # choose the transport modes you need\n        transportModes: [\n            {\n                mode: WALK\n            },\n            {\n                mode: TRANSIT\n            },\n        ]) {\n        itineraries {\n            startTime\n            endTime\n            legs {\n                mode\n                startTime\n                endTime\n                from {\n                    name\n                    lat\n                    lon\n                    departureTime\n                    arrivalTime\n                }\n                to {\n                    name\n                    lat\n                    lon\n                    departureTime\n                    arrivalTime\n                }\n                route {\n                    gtfsId\n                    longName\n                    shortName\n                }\n                legGeometry {\n                    points\n                }\n            }\n        }\n    }\n}\n</code></pre> <p>Again, please use the autocomplete and documentation viewers to figure out what each input parameter and property means.</p> <p>More examples for a variety of queries can also be found in the test code.</p>"},{"location":"apis/TransmodelApi/","title":"Transmodel GraphQL API","text":""},{"location":"apis/TransmodelApi/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"apis/TransmodelApi/#documentation","title":"Documentation","text":"<p>This is the official OTP2 API for Transmodel (NeTEx). The terminology is based on the  Transmodel (NeTEx) with some limitations/simplification. It provides both a routing API  (trip query) and index API for transit data.</p> <p>Entur provides a GraphQL explorer where you may browse the GraphQL schema and try your own queries.</p> <p>When running OTP locally the endpoint is available at: <code>http://localhost:8080/otp/transmodel/v3</code></p> <p>Note! Versions <code>v1</code> and <code>v2</code> do not exist in the main OTP git repository, but in  the Entur fork from which this code originates from.</p>"},{"location":"apis/TransmodelApi/#configuration","title":"Configuration","text":"<p>To turn this API off, add the feature <code>TransmodelGraphQlApi : false</code> in <code>otp-config.json</code>.</p>"},{"location":"apis/TransmodelApi/#changelog-old","title":"Changelog - old","text":"<p>The Transmodel API is now part of the main OTP supported APIs. New changes in the changelog  will be added to the main change log, and NOT here (2023-12-13).</p> <ul> <li>Initial version of Transmodel Graph QL API (September 2019)</li> <li>Added support for multimodal StopPlaces (November 2019)</li> <li>Fix bug querying stopPlaces #3591</li> <li>Fix the field bikesAllowed #3586</li> <li>Add triangle factors for bicycle   routing #3585</li> <li>Fix correct type for BookingArrangementType#latestBookingDay</li> <li>Fix NPE in BookingArrangementType data   fetchers #3649</li> <li>Add BookingInfo to TimetabledPassingTime and   EstimatedCall #3666</li> <li>Use correct capitalization for GraphQL   fields #3707</li> <li>Allow filtering by a list of   ids #3738</li> <li>Don't filter out stops who don't have multimodal parents in the nearest   query #3752</li> <li>Restore ability to filter by private   code #3764</li> <li>Narrow down non-null types   type #3803</li> <li>Fix issue with fetching parent StopPlaces in nearest query in Transmodel   API #3807</li> <li>Fix invalid cast in situations resolver for line   type #3810</li> <li>Deduce enum for bookWhen in Transmodel   API #3854</li> <li>Fix coercion of default parameter for maximumDistance in   nearest #3846</li> <li>Expose stopPositionInPattern on   EstimatedCall #3846</li> <li>Allow selecting first or last quays in a   ServiceJourney #3846</li> <li>Make language nullable in MultilingualString, as it is not set in NonLocalizedString   #4074</li> <li>Transmodel API transport mode not present or null is all transport modes   #4123</li> <li>Expose datedServiceJourney from EstimatedCall   #4128</li> <li>Expose stop-to-stop journey pattern geometries   #4161</li> <li>Add possibility to filter dated service journeys by replacementFor   #4198</li> <li>Add support for groupOfLines in top level query   #4232</li> <li>Fix issue when ServiceJourney is created by an updater and expose necessary information via DSJ   #4365</li> <li>Allow specifying allowed/banned rental networks in trip query   #4459</li> <li>Add flexible stops   #4485</li> </ul>"},{"location":"examples/Readme/","title":"Example configurations","text":"<p>When setting up OTP it is often useful to have some examples to look at. If you have an example to share just add it here.</p>"},{"location":"examples/Readme/#examples","title":"Examples","text":"Name Organisation Description entur Entur, Norway Deployment Configuration with NeTEX input data ibi IBI Group, USA Allow routing for wheelchair users even if accessibility data is incomplete skanetrafiken Sk\u00e5netrafiken, Sweden, Sk\u00e5ne Deployment Configuration with combination of NeTEx and GTFS input data"},{"location":"examples/Readme/#support","title":"Support","text":"<p>The examples are provided \"as is\" - they may get outdated over time or miss information, and it is left to the provider, not the PLC, to include whatever the provider find useful.</p>"},{"location":"examples/Readme/#how-to-share-an-example","title":"How to share an example","text":"<p>Anyone who want can add their example here as long as it is OTP \"related\". Just create a normal pull-request to add it. </p>"},{"location":"examples/entur/Readme/","title":"Entur Deployment Configuration","text":"<p>This is a snapshot of Enturs deployment configuration. At Entur we run OTP in the cloud, so some of the provided config will not work outside Enturs cluster, but it is provided \"as is\" for others to replicate if they want.</p>"},{"location":"examples/entur/Readme/#config-files","title":"Config files","text":"<p>See the config files provided. The <code>updaters</code> section of the <code>router-config.json</code> is provided, but is not working. Remove it if you want to run OTP. It is provided for others as an example on how to configure the SIRI updaters. The same goes for the <code>storage</code> section in the <code>build-config.json</code>, remove it run OTP locally.</p> <p>The <code>&lt;host&gt;</code>, <code>&lt;OperatorNameSpace&gt;</code> and <code>${GCS_BUCKET}</code> are placeholders you need to change.</p>"},{"location":"examples/entur/Readme/#data-input-files","title":"Data input files","text":"<p>At Entur we run OTP with the latest NeTEx data we have. You may download it from here:</p> <p>https://developer.entur.org/stops-and-timetable-data</p> <p>We use the Entire Norway file.</p> <p>In the past the file did not contain the stops, so they needed to be downloaded separably (Entire Norway (Current stops) - Latest valid version of all country stops) and inserted into the Netex-file. Unpack the stops zipfile, rename the stops file to <code>_stops.xml</code>. Unpack the netex file and move the <code>_stops.xml</code> into the netex directory. Copy the netex directory and config files into the same directory and start OTP with it as the base directory.</p> <p>We also build with elevation data, which is not available on the internet without transformation. Send us a request, and we will find a way to share it.</p> <p>We download the OSM data file norway-latest.osm.pbf every night and build a street-graph with OSM and elevation data. We also use some custom OSM files for areas outside Norway, but they in most cases insignificant. If requested, we can provide them.</p>"},{"location":"examples/skanetrafiken/Readme/","title":"Sk\u00e5netrafiken Deployment Configuration","text":"<p>This is a snapshot of Sk\u00e5netrafiken deployment configuration. At Sk\u00e5netrafiken we deploy our OTP instances as microservices to a Kubernetes cluster. Some parts of the config are missing due to confidentiality.</p>"},{"location":"examples/skanetrafiken/Readme/#data-input-files","title":"Data input files","text":""},{"location":"examples/skanetrafiken/Readme/#netex","title":"NeTEx","text":"<p>NeTEx is used for transport data inside Sweden. Each night the system automatically builds new file based on data from SQL database. At the moment those files are not accessible through any public endpoint.</p>"},{"location":"examples/skanetrafiken/Readme/#gtfs","title":"GTFS","text":"<p>GTFS data is used for traffic inside Denmark. GTFS for danish public transport can be downloaded here. There is some processing applied to the original data so that unnecessary trips are filtered out and ID structure for journeys and stop point / stop places matches with the NeTEx. The modified GTFS is not accessible through any public endpoint either.</p>"},{"location":"examples/skanetrafiken/Readme/#osm","title":"OSM","text":"<p>Two different OSM files are used:</p>"},{"location":"examples/skanetrafiken/Readme/#sweden","title":"Sweden","text":"<p>OSM data is downloaded from <code>http://download.geofabrik.de/europe/sweden-latest.osm.pbf</code>. To reduced graph size, only data for southern part of Sweden is used.</p>"},{"location":"examples/skanetrafiken/Readme/#denmark","title":"Denmark","text":"<p>OSM data is downloaded from <code>http://download.geofabrik.de/europe/denmark-latest.osm.pbf</code>. To reduce graph size, only data for northern part of Denmark is used.</p>"},{"location":"examples/skanetrafiken/Readme/#real-time","title":"Real-time","text":"<p>The Azure Service Bus is used to propagate SIRI SX and ET real-time messages to OTP. This is solved through Siri Azure updaters that Sk\u00e5netrafiken had implemented in OTP. There are separate updaters for SIRI SX and ET. Those updaters are used to provide data for Swedish traffic (NeTEx). Right now, there is no connection to any real-time source for danish traffic (GTFS data).</p> <p>Except for receiving messages from Service Bus there are two endpoints through which historical ET and SX messages can be downloaded at OTP startup. The updater will first create new subscription on ServiceBus topic and then send request to the history endpoint. It can take some time get a response from the endpoint, so the timeout is set quite high. Once OTP is done with processing of history messages the updater will start querying messages from the subscription.</p> <p>Once the updaters are done with processing of history messages they will change their status to primed, and the system will start channeling request to this OTP instance. This ensures that no real-time message is omitted and all OTP instance that ran in the cluster does have exact same real-time data. Thi means that no matter which instance the client is hitting it will always get the same search results.</p>"},{"location":"examples/skanetrafiken/Readme/#history-endpoint-contract","title":"History endpoint contract","text":"<p>See the <code>updaters</code> section of <code>router-config.json</code> file provided in this folder. This is an example configuration for the updaters. The <code>history</code> configuration is optional. It can be skipped so that OTP does not fetch any historical messages on startup.</p> <p>There are two separate endpoints for respectively SX and ET. They are basic GET endpoints with following query parameters:</p> parameters format fromDateTime ISO 8601 toDateTime ISO 8601 <p>Those two parameters are used to define time boundaries for the messages.</p> <p>Both endpoints generate XML response which is an SIRI object containing SX or ET messages. Messages are formatted according to Siri Nordic Profile. Since in SIRI ET standard each messages contains all necessary data, Sk\u00e5netrafikens implementation of the endpoint returns only the last message for each DatedServiceJourney ID (sending multiple messages would be pointless since they will override each other). The messages are processed in the same order as they came in (in the list) so it would still work to include multiple messages on same DatedServiceJourney as long as they are sorted in correct order and the newest message is the last one in the list.</p>"},{"location":"examples/skanetrafiken/Readme/#matching-on-stop-arrival-times","title":"Matching on stop arrival-times","text":"<p>Normally ET messages are matched with corresponding trips based on ServiceJourney or DatedServiceJourney id from the message. In case OTP was not able to find corresponding trip additional search will be performed based on arrival-times/stop-patterns from the ET message. This feature turned off by default but can be activated by adding fuzzyTripMatching property to updater configuration. </p>"},{"location":"sandbox/ActuatorAPI/","title":"Actuator API","text":""},{"location":"sandbox/ActuatorAPI/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/ActuatorAPI/#changelog","title":"Changelog","text":"<ul> <li>Initial implementation of readiness endpoint (November 2019)</li> <li>Prometheus metrics added using Micrometer (October 2021)</li> <li>GraphQL metrics added to prometheus export (November 2021)</li> </ul>"},{"location":"sandbox/ActuatorAPI/#documentation","title":"Documentation","text":"<p>This provides endpoints for checking the health status of the OTP instance. It can be useful when running OTP in a container.</p> <p>The API will be at the endpoint <code>http://localhost:8080/otp/actuators</code> and follows the Spring Boot actuator API standard.</p>"},{"location":"sandbox/ActuatorAPI/#configuration","title":"Configuration","text":"<p>To enable this you need to add the feature <code>ActuatorAPI</code>.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\" : {\n    \"ActuatorAPI\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/ActuatorAPI/#endpoints","title":"Endpoints","text":""},{"location":"sandbox/ActuatorAPI/#health","title":"/health","text":"<p>The health endpoints returns an 200 OK status code once the graph is loaded and all updaters are ready. Otherwise, a 404 NOT FOUND is returned.</p>"},{"location":"sandbox/ActuatorAPI/#prometheus","title":"/prometheus","text":"<p>Prometheus metrics are returned using Micrometer. The default JVM and jersey metrics are enabled.</p> <p>Also, GraphQL timing metrics are exported under <code>graphql.timer.query</code> and <code>graphql.timer.resolver</code>, if the GraphQL endpoints are enabled.</p>"},{"location":"sandbox/DataOverlay/","title":"Data Overlay","text":"<p>Use grid data in NetCDF format to populate the graph. Also provides custom route endpoint parameters for the data \"penalty\" and \"threshold\". This allows route planning to be based on the custom data calculated penalties. Data examples: air quality, environmental, and other data types that are tied to certain geographical locations.</p>"},{"location":"sandbox/DataOverlay/#contact-info","title":"Contact Info","text":"<p>Developed and maintained by Metatavu OY, Finland.</p> <p>Developers:</p> <p>Katja Danilova - katja.danilova@metatavu.fi\\ Simeon Platonov - simeon.platonov@metatavu.fi\\ Daniil Smirnov - daniil.smirnov@metatavu.fi</p> <p>In case of any questions please contact any of the people above by emails. We would like to continue developing and improving this feature and would love to hear any ideas from the community.</p> <p>Company email: info@metatavu.fi</p>"},{"location":"sandbox/DataOverlay/#changelog","title":"Changelog","text":"<ul> <li>Initial version (December 2021)</li> </ul>"},{"location":"sandbox/DataOverlay/#documentation","title":"Documentation","text":"<p>We have been working with OTP since version 1 mainly for producing the Air Quality affected routing for the city of Helsinki, Finland. That project required us to modify the original OTP quite a lot so we didn't propose our efforts for the community.</p> <p>With the OTP2 release we decided to create a dedicated layer on top of OTP2 which not only leaves the initial structure of the OpenTripPlanner intact, but also brings some additional features for those, who actually need them. This layer's main feature is populating the graph with a grid data ( i.e air quality, temperature, humidity, pressure, wind speed and direction, and e.t.c). For this to work two files are required: the actual data file (i.e in NetCDF format) and a .json settings file which describes the contents of the data file. Please refer to the diagram for more information.</p> <p>It is a sandbox feature.</p> <p>Please see the configuration part for setup instructions and examples.</p>"},{"location":"sandbox/DataOverlay/#configuration","title":"Configuration","text":"<p>Enable the feature by including it to the <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{ \"otpFeatures\": { \"DataOverlay\" : true } }\n</code></pre> <p>Plugin configuration should explain the NetCDF data file and request parameters that use the data file.</p> <ul> <li>fileName points to the data file</li> <li>latitudeVariable, longitudeVariable and timeVariable should be equal to the corresponding   variable names of the data file</li> <li>timeFormat options: MS_EPOCH, SECONDS, HOURS</li> <li>indexVariables contain a list of variables of data file that will affect the routing.<ul> <li>name can have any value and exists to act as a reference for requestPatameters (see below)</li> <li>displayName is a variable name in human-readable form that should make it more   understandable</li> <li>variable is the actual name of the variable from data file</li> </ul> </li> <li>requestParameters contains the list of REST request parameters that affects the cost   calculation.<ul> <li>name should be chosen from the list of enums:   org.opentripplanner.ext.dataoverlay.api.ParameterName</li> <li>variable should correspond to the name of one of the entries from indexVariables list   and explain which data field this parameter corresponds to</li> <li>formula should use the keywords VALUE and THRESHOLD and describe the way the penalty is   calculated. Note: if the result of the formula is negative it is ignored.</li> </ul> </li> </ul> <p>Example of build-config.json that includes the dataOverlay plugin configuration:</p> <pre><code>// build-config.json\n{\n  \"dataOverlay\" :\n  {\n    \"fileName\": \"graphs/data-file.nc4\",\n    \"latitudeVariable\": \"lat\",\n    \"longitudeVariable\": \"lon\",\n    \"timeVariable\": \"time\",\n    \"timeFormat\": \"HOURS\",\n    \"indexVariables\": [\n      {\n        \"name\": \"harmfulMicroparticlesPM2_5\",\n        \"displayName\": \"Harmful micro particles pm 2.5\",\n        \"variable\": \"cnc_PM2_5\"\n      },\n      {\n        \"name\": \"harmfulMicroparticlesPM10\",\n        \"displayName\": \"Harmful micro particles pm 10\",\n        \"variable\": \"cnc_PM10\"\n      }\n    ],\n    \"requestParameters\": [\n      {\n        \"name\": \"PARTICULATE_MATTER_2_5\",\n        \"variable\": \"harmfulMicroparticlesPM2_5\",\n        \"formula\": \"(VALUE + 1 - THRESHOLD) * PENALTY\"\n      },\n      {\n        \"name\": \"PARTICULATE_MATTER_10\",\n        \"variable\": \"harmfulMicroparticlesPM10\",\n        \"formula\": \"(VALUE + 1 - THRESHOLD) * PENALTY\"\n      }\n    ]\n  }\n\n}\n</code></pre> <p>Default values for Data overlay plugin can also be included in router-config instead of being sent with each request. If any Data overlay parameters are passed in user query, all the default values from router-config are ignored.</p> <pre><code>// router-config.json\n{\n  \"routingDefaults\": {\n    \"dataOverlay\" : {\n      \"particulate_matter_10_threshold\" : 100,\n      \"particulate_matter_10_penalty\" : 19\n    }\n  }\n}\n</code></pre>"},{"location":"sandbox/Emissions/","title":"CO\u2082 Emissions calculation","text":""},{"location":"sandbox/Emissions/#contact-info","title":"Contact Info","text":"<ul> <li>Digitransit Team</li> </ul>"},{"location":"sandbox/Emissions/#documentation","title":"Documentation","text":"<p>Graph build import of CO\u2082 Emissions from GTFS data sets (through custom emissions.txt extension) and the ability to attach them to itineraries by Digitransit team. The emissions are represented in grams per kilometer (g/Km) unit.</p> <p>Emissions data is located in an emissions.txt file within a gtfs package and has the following columns:</p> <p><code>route_id</code>: route id</p> <p><code>avg_co2_per_vehicle_per_km</code>: Average carbon dioxide equivalent value for the vehicles used on the route at grams/Km units.</p> <p><code>avg_passenger_count</code>: Average passenger count for the vehicles on the route.</p> <p>For example: <pre><code>route_id,avg_co2_per_vehicle_per_km,avg_passenger_count\n1234,123,20\n2345,0,0\n3456,12.3,20.0\n</code></pre></p> <p>Emissions data is loaded from the gtfs package and embedded into the graph during the build process.</p>"},{"location":"sandbox/Emissions/#configuration","title":"Configuration","text":"<p>To enable this functionality, you need to enable the \"Co2Emissions\"  feature in the <code>otp-config.json</code> file.</p> <p><pre><code>//otp-config.json\n{\n  \"Co2Emissions\": true\n}\n</code></pre> Include the <code>emissions</code> object in the <code>build-config.json</code> file. The <code>emissions</code> object should contain parameters called <code>carAvgCo2PerKm</code> and <code>carAvgOccupancy</code>. The <code>carAvgCo2PerKm</code> provides the average emissions value for a car in g/km and the <code>carAvgOccupancy</code> provides the average number of passengers in a car.</p>"},{"location":"sandbox/Emissions/#example-configuration","title":"Example configuration","text":"<pre><code>// build-config.json\n{\n  \"emissions\" : {\n    \"carAvgCo2PerKm\" : 170,\n    \"carAvgOccupancy\" : 1.3\n  }\n}\n</code></pre>"},{"location":"sandbox/Emissions/#overview","title":"Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since carAvgCo2PerKm <code>integer</code> The average CO\u2082 emissions of a car in grams per kilometer. Optional <code>170</code> 2.5 carAvgOccupancy <code>double</code> The average number of passengers in a car. Optional <code>1.3</code> 2.5"},{"location":"sandbox/Emissions/#details","title":"Details","text":""},{"location":"sandbox/Emissions/#changelog","title":"Changelog","text":""},{"location":"sandbox/Emissions/#otp-25","title":"OTP 2.5","text":"<ul> <li>Initial implementation of the emissions calculation.</li> </ul>"},{"location":"sandbox/Fares/","title":"Fares","text":""},{"location":"sandbox/Fares/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried (mail@leonard.io)</li> </ul>"},{"location":"sandbox/Fares/#documentation","title":"Documentation","text":"<p>The code in this sandbox used to be part of OTP core but to allow more experimentation - in  particular regarding GTFS Fares V2 - it was moved into a sandbox.</p>"},{"location":"sandbox/Fares/#fares-v2","title":"Fares V2","text":"<p>In 2022 the GTFS spec was extended to contain a powerful new model, called Fares V2, to describe fares, prices and products for public transport tickets. A baseline effort was merged into the main spec in May.</p> <p>OTP experimentally supports the merged baseline plus a few extensions from the larger, unmerged spec.</p> <p>To enable Fares V2 support, add the following to <code>otp-config.json</code>:</p> <pre><code>{\n  \"otpFeatures\" : {\n    \"FaresV2\" : true\n  }\n}\n</code></pre>"},{"location":"sandbox/Fares/#supported-fares-v2-fields","title":"Supported Fares V2 fields","text":"<p>A full list of the fields that OTP supports is available in the Fares V2 Adoption Google Sheet.</p>"},{"location":"sandbox/Fares/#custom-fare-calculators","title":"Custom fare calculators","text":"<p>When the GTFS Fares V1 spec was not enough, some organizations have developed their own calculators which are also part of the sandbox code.</p> <p>The classes and their maintainers are as follows:</p> class maintainer HighestFareInFreeTransferWindowFareService IBI Group (David Emory) AtlantaFareService IBI Group (David Emory) CombinedInterlinedLegsFareService IBI Group (David Emory) HSLFareServiceImpl HSL (Viljami Nurminen) OrcaFareService IBI Group (Daniel Heppner)"},{"location":"sandbox/Fares/#fares-configuration","title":"Fares configuration","text":"<p>By default OTP will compute fares according to the GTFS specification if fare data is provided in your GTFS input. It is possible to turn off this by setting the fare to \"off\". For more complex scenarios or to handle vehicle rental fares, it is necessary to manually configure fares using the <code>fares</code> section in <code>build-config.json</code>. You can combine different fares (for example transit and vehicle-rental) by defining a <code>combinationStrategy</code> parameter, and a list of sub-fares to combine (all fields starting with <code>fare</code> are considered to be sub-fares).</p> <pre><code>// build-config.json\n{\n  // Select the custom fare \"seattle\"\n  \"fares\": \"seattle\"\n}\n</code></pre> <p>Or this alternative form that could allow additional configuration</p> <pre><code>// build-config.json\n{\n  \"fares\": {\n    \"type\": \"seattle\"\n  }\n}\n</code></pre> <p>Turning the fare service off, this will ignore any fare data in the provided GTFS data.</p> <pre><code>// build-config.json\n{\n  \"fares\": \"off\"\n}\n</code></pre> <p>The current list of custom fare type is:</p> <ul> <li><code>highest-fare-in-free-transfer-window</code> Will apply the highest observed transit fare (across all   operators) within a free transfer window, adding to the cost if a trip is boarded outside the free   transfer window. It accepts the following parameters:<ul> <li><code>freeTransferWindow</code> the duration (in ISO8601-ish notation) that free transfers are   possible after the board time of the first transit leg. Default: <code>2h30m</code>.</li> <li><code>analyzeInterlinedTransfers</code> If true, will treat interlined transfers as actual transfers.   This is merely a work-around for transit agencies that choose to code their fares in a   route-based fashion instead of a zone-based fashion. Default: <code>false</code></li> </ul> </li> <li><code>atlanta</code> (no parameters)</li> <li><code>combine-interlined-legs</code> Will treat two interlined legs (those with a stay-seated transfer in   between them) as a single leg for the purpose of fare calculation.   It has a single parameter <code>mode</code> which controls when exactly the combination should happen:<ul> <li><code>ALWAYS</code>: All interlined legs are combined. (default)</li> <li><code>SAME_ROUTE</code>: Only interlined legs whose route ID are identical are combined.</li> </ul> </li> <li><code>orca</code> (no parameters)</li> <li><code>off</code> (no parameters)</li> </ul>"},{"location":"sandbox/Fares/#removed-fare-calculators","title":"Removed fare calculators","text":"<p>The following calculators used to be part of the OTP codebase but since their maintainership was unclear and no-one offered to maintain, they were removed in July 2022.</p> <ul> <li>SeattleFareServiceImpl</li> <li>DutchFareServiceImpl</li> </ul> <p>The NYC fare calculator was removed in #4694.</p> <p>The <code>MultipleFareService</code> was removed in #5100.</p> <p>The <code>SFBayFareServiceImpl</code> and <code>TimeBasedVehicleRentalFareService</code> were removed in #5145.</p> <p>If you were using these calculators, you're welcome to re-add them to the code base and become their maintainer.</p>"},{"location":"sandbox/Fares/#changelog","title":"Changelog","text":"<ul> <li>Initial move into sandbox #4241</li> <li>Add HighestFareInFreeTransferWindowFareService #4267</li> <li>Add Fares V2 #4338</li> <li>Add CombineInterlinedLegsFareService #4509</li> </ul>"},{"location":"sandbox/Flex/","title":"Flexible transit routing","text":""},{"location":"sandbox/Flex/#contact-info","title":"Contact Info","text":"<ul> <li>Kyyti Group Oy, Finland</li> <li>Entur, Norway</li> <li>Hannes Junnila</li> </ul>"},{"location":"sandbox/Flex/#documentation","title":"Documentation","text":"<p>To enable this turn on <code>FlexRouting</code> as a feature in <code>otp-config.json</code>.</p> <p>The GTFS feeds should conform to the GTFS-Flex v2.1 draft</p>"},{"location":"sandbox/Flex/#configuration","title":"Configuration","text":"<p>This feature allows a limited number of config options. To change the configuration, add the  following to <code>router-config.json</code>.</p>"},{"location":"sandbox/Flex/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"flex\" : {\n    \"maxTransferDuration\" : \"5m\",\n    \"maxFlexTripDuration\" : \"45m\",\n    \"maxAccessWalkDuration\" : \"15m\",\n    \"maxEgressWalkDuration\" : \"15m\"\n  }\n}\n</code></pre>"},{"location":"sandbox/Flex/#overview","title":"Overview","text":"Config Parameter Type Summary Req./Opt. Default Value Since maxAccessWalkDuration <code>duration</code> The maximum duration the passenger will be allowed to walk to reach a flex stop or zone. Optional <code>\"PT45M\"</code> 2.3 maxEgressWalkDuration <code>duration</code> The maximum duration the passenger will be allowed to walk after leaving the flex vehicle at the final destination. Optional <code>\"PT45M\"</code> 2.3 maxFlexTripDuration <code>duration</code> How long can a non-scheduled flex trip at maximum be. Optional <code>\"PT45M\"</code> 2.3 maxTransferDuration <code>duration</code> How long should a passenger be allowed to walk after getting out of a flex vehicle and transferring to a flex or transit one. Optional <code>\"PT5M\"</code> 2.3"},{"location":"sandbox/Flex/#details","title":"Details","text":""},{"location":"sandbox/Flex/#flex_maxAccessWalkDuration","title":"maxAccessWalkDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>The maximum duration the passenger will be allowed to walk to reach a flex stop or zone.</p> <p>If you have multiple overlapping flex zones the high default value can lead to performance problems. A lower value means faster routing.</p> <p>Depending on your service this might be what you want to do anyway: many flex services are used by passengers with mobility problems so offering a long walk might be problematic. In other words, if you can walk 45 minutes to a flex stop/zone you're unlikely to be the target audience for those services.</p>"},{"location":"sandbox/Flex/#flex_maxEgressWalkDuration","title":"maxEgressWalkDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>The maximum duration the passenger will be allowed to walk after leaving the flex vehicle at the final destination.</p> <p>If you have multiple overlapping flex zones the high default value can lead to performance problems. A lower value means faster routing.</p> <p>Depending on your service this might be what you want to do anyway: many flex services are used by passengers with mobility problems so offering a long walk might be problematic. In other words, if you can walk 45 minutes to a flex stop/zone you're unlikely to be the target audience for those services.</p>"},{"location":"sandbox/Flex/#flex_maxFlexTripDuration","title":"maxFlexTripDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT45M\"</code> Path: /flex </p> <p>How long can a non-scheduled flex trip at maximum be.</p> <p>This is used for all trips which are of type <code>UnscheduledTrip</code>. The value includes the access/egress duration to the boarding/alighting of the flex trip, as well as the connection to the transit stop.</p>"},{"location":"sandbox/Flex/#flex_maxTransferDuration","title":"maxTransferDuration","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT5M\"</code> Path: /flex </p> <p>How long should a passenger be allowed to walk after getting out of a flex vehicle and transferring to a flex or transit one.</p> <p>This was mainly introduced to improve performance which is also the reason for not using the existing value with the same name: fixed schedule transfers are computed during the graph build but flex ones are calculated at request time and are more sensitive to slowdown.</p> <p>A lower value means that the routing is faster.</p>"},{"location":"sandbox/Flex/#changelog","title":"Changelog","text":""},{"location":"sandbox/Flex/#otp-21","title":"OTP 2.1","text":"<ul> <li>Initial implementation of Flexible transit routing</li> <li>Use one-to-many search in order to make the performance of the StreetFlexPathCalculator   acceptable. (April 2021)</li> <li>Also link transit stops used by flex trips to the closest car traversable edge. This allows flex   street routing all the way to the stop. (April 2021)</li> <li>Fix performance issues with the   StreetFlexPathCalculator #3460</li> <li>Improve performance of flex access/egress   routing #3661</li> <li>Allow getting on and off at the same flex stop   time #3720</li> <li>Calculate fare for flex   routes #3743</li> </ul>"},{"location":"sandbox/Flex/#otp-23","title":"OTP 2.3","text":"<ul> <li>Enable configuration of <code>maxFlexTripDuration</code> and change of type of <code>maxTransferDuration</code>   routes #4642</li> </ul>"},{"location":"sandbox/GeocoderAPI/","title":"Geocoder API","text":""},{"location":"sandbox/GeocoderAPI/#contact-info","title":"Contact Info","text":"<ul> <li>realCity, Hungary</li> <li>Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/GeocoderAPI/#documentation","title":"Documentation","text":"<p>This sandbox feature implements geocoding endpoints for a number of use cases.</p> <p>To enable this you need to add the feature to <code>otp-config.json</code>. </p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"SandboxAPIGeocoder\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/GeocoderAPI/#endpoints","title":"Endpoints","text":""},{"location":"sandbox/GeocoderAPI/#debug-ui","title":"Debug UI","text":"<p>The required geocode API for Stop and From/To searches in the debug client.</p> <p>Path: <code>/otp/routers/{routerId}/geocode</code></p> <p>It supports the following URL parameters:</p> Parameter Description <code>query</code> The query string we want to geocode <code>autocomplete</code> Whether we should use the query string to do a prefix match <code>stops</code> Search for stops, either by name or stop code <code>clusters</code> Search for clusters by their name"},{"location":"sandbox/GeocoderAPI/#stop-clusters","title":"Stop clusters","text":"<p>A stop cluster is a deduplicated groups of stops. This means that for any stop that has a parent station only the parent is returned and for stops that have identical names and are very close to each other, only one is returned.</p> <p>This is useful for a general purpose fuzzy \"stop\" search.</p> <p>Path: <code>/otp/routers/{routerId}/geocode/stopClusters</code></p> <p>It supports the following URL parameters:</p> Parameter Description <code>query</code> The query string we want to geocode"},{"location":"sandbox/GeocoderAPI/#changelog","title":"Changelog","text":"<ul> <li>Initial version (June 2021)</li> <li>Updated to use Lucene (March 2022)</li> <li>Add stop clusters (May 2023)</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/","title":"Google Cloud Storage - Using GCS Bucket as a OTP Data Source","text":""},{"location":"sandbox/GoogleCloudStorage/#contact-info","title":"Contact Info","text":"<ul> <li>Thomas Gran, Entur, Norway</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/#changelog","title":"Changelog","text":""},{"location":"sandbox/GoogleCloudStorage/#otp-20","title":"OTP 2.0","text":"<ul> <li>Initial implementation to access Google Cloud Storage (read and write). (December 2019)</li> </ul>"},{"location":"sandbox/GoogleCloudStorage/#documentation","title":"Documentation","text":"<p>To enable this turn on the feature <code>GoogleCloudStorage</code>. OTP can load or store artifacts from one or more Google Cloud Storge locations. Each artifact must be configured in the build-config.json: See <code>BuildConfig</code> on how to configure artifacts.</p> <p>Example (build-config.json):</p> <pre><code>{\n  \"gcsCredentials\": \"file:///Users/alf/secret/otp-test-1234567890.json\",\n  \"graph\": \"gs://otp-test-bucket/a/b/graph.obj\",\n  \"buildReportDir\": \"gs://otp-test-bucket/a/b/np-report\",\n  \"osm\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.pbf\"\n    }\n    ],\n  \"dem\": [\n    {\n      \"source\": \"gs://otp-test-bucket/a/b/northpole.dem.tif\"\n    }\n    ],\n  \"transitFeeds\": [\n    {\n      \"type\": \"gtfs\",\n      \"source\": \"gs://otp-test-bucket/a/b/gtfs.zip\"\n    }\n    ]\n}\n</code></pre>"},{"location":"sandbox/IBIAccessibilityScore/","title":"IBI Group Accessibility Score - OTP Sandbox Extension","text":""},{"location":"sandbox/IBIAccessibilityScore/#contact-info","title":"Contact Info","text":"<ul> <li>IBI Group (transitrealtime@ibigroup.com)</li> </ul>"},{"location":"sandbox/IBIAccessibilityScore/#changelog","title":"Changelog","text":"<ul> <li>Create initial   implementation #4221</li> </ul>"},{"location":"sandbox/IBIAccessibilityScore/#documentation","title":"Documentation","text":"<p>This extension computes a numeric accessibility score between 0 and 1 and adds it to the itinerary and its legs.</p> <p>Note: the information to calculate this score are all available to the frontend, however calculating them on the backend makes life a little easier and changes are automatically applied to all frontends.</p> <p>To enable the feature add the following to <code>router-config.json</code>:</p> <pre><code>// router-config.json\n{\n  \"routingDefaults\": {\n    \"itineraryFilters\": {\n      // add IBI accessibility score between 0 and 1\n      \"accessibilityScore\": true\n    }\n  }\n}\n</code></pre> <p>The score is only computed when you search for wheelchair-accessible routes.</p>"},{"location":"sandbox/InteractiveOtpMain/","title":"Interactive OTP Launcher","text":"<p>A GUI popup window to which help you to start OTP Main interactively.</p>"},{"location":"sandbox/InteractiveOtpMain/#contact-info","title":"Contact Info","text":"<ul> <li>Thomas Gran, Norway</li> </ul>"},{"location":"sandbox/InteractiveOtpMain/#changelog","title":"Changelog","text":"<ul> <li>Initial version (October 2020)</li> </ul>"},{"location":"sandbox/InteractiveOtpMain/#documentation","title":"Documentation","text":"<p>This is a simple GUI to help launch OTP Main. It is useful if you frequently launch OTP with data set and/or configuration. The <code>InteractiveOtpMain</code> search for all OTP data configurations directories available and help the user configure and start OTP.  </p>"},{"location":"sandbox/MapboxVectorTilesApi/","title":"Mapbox Vector Tiles API","text":""},{"location":"sandbox/MapboxVectorTilesApi/#contact-info","title":"Contact Info","text":"<ul> <li>HSL, Finland</li> <li>Arcadis, US</li> </ul>"},{"location":"sandbox/MapboxVectorTilesApi/#documentation","title":"Documentation","text":"<p>This API produces Mapbox vector tiles, which are used by Digitransit-ui and  <code>otp-react-redux</code> to show information about public transit entities on the map.</p> <p>The tiles can be fetched from <code>/otp/routers/{routerId}/vectorTiles/{layers}/{z}/{x}/{y}.pbf</code>, where <code>layers</code> is a comma separated list of layer names from the configuration.</p> <p>Maplibre/Mapbox GL JS also requires a tilejson.json endpoint which is available at <code>/otp/routers/{routerId}/vectorTiles/{layers}/tilejson.json</code>.</p> <p>Translatable fields in the tiles are translated based on the <code>accept-language</code> header in requests. Currently, only the language with the highest priority from the header is used.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#configuration","title":"Configuration","text":"<p>To enable this you need to add the feature <code>otp-config.json</code>.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"SandboxAPIMapboxVectorTilesApi\": true\n  }\n}\n</code></pre> <p>The feature must be configured in <code>router-config.json</code> as follows</p> <pre><code>{\n  \"vectorTiles\": {\n    \"basePath\": \"/only/configure/if/required\",\n    \"layers\": [\n      {\n        \"name\": \"stops\",\n        \"type\": \"Stop\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600\n      },\n      {\n        \"name\": \"stations\",\n        \"type\": \"Station\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 12,\n        \"cacheMaxSeconds\": 600\n      },\n      // all rental places: stations and free-floating vehicles\n      {\n        \"name\": \"citybikes\",\n        \"type\": \"VehicleRental\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60,\n        \"expansionFactor\": 0.25\n      },\n      // just free-floating vehicles\n      {\n        \"name\": \"rentalVehicles\",\n        \"type\": \"VehicleRentalVehicle\",\n        \"mapper\": \"DigitransitRealtime\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60\n      },\n      // just rental stations\n      {\n        \"name\": \"rentalStations\",\n        \"type\": \"VehicleRentalStation\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600\n      },\n      // Contains just stations and real-time information for them\n      {\n        \"name\": \"realtimeRentalStations\",\n        \"type\": \"VehicleRentalStation\",\n        \"mapper\": \"DigitransitRealtime\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60\n      },\n      // This exists for backwards compatibility. At some point, we might want\n      // to add a new real-time parking mapper with better translation support\n      // and less unnecessary fields.\n      {\n        \"name\": \"stadtnaviVehicleParking\",\n        \"type\": \"VehicleParking\",\n        \"mapper\": \"Stadtnavi\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 60,\n        \"expansionFactor\": 0.25\n      },\n      // no real-time, translatable fields are translated based on accept-language header\n      // and contains less fields than the Stadtnavi mapper\n      {\n        \"name\": \"vehicleParking\",\n        \"type\": \"VehicleParking\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 20,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600,\n        \"expansionFactor\": 0.25\n      },\n      {\n        \"name\": \"vehicleParkingGroups\",\n        \"type\": \"VehicleParkingGroup\",\n        \"mapper\": \"Digitransit\",\n        \"maxZoom\": 17,\n        \"minZoom\": 14,\n        \"cacheMaxSeconds\": 600,\n        \"expansionFactor\": 0.25\n      }\n    ] \n  }\n}\n</code></pre> <p>For each layer, the configuration includes:</p> <ul> <li><code>name</code> which is used in the url to fetch tiles, and as the layer name in the vector tiles.</li> <li><code>type</code> which tells the type of the layer. Currently supported:<ul> <li><code>Stop</code></li> <li><code>Station</code></li> <li><code>VehicleRental</code>: all rental places: stations and free-floating vehicles</li> <li><code>VehicleRentalVehicle</code>: free-floating rental vehicles</li> <li><code>VehicleRentalStation</code>: rental stations</li> <li><code>VehicleParking</code></li> <li><code>VehicleParkingGroup</code></li> </ul> </li> </ul> Config Parameter Type Summary Req./Opt. Default Value Since basePath <code>string</code> The path of the vector tile source URLs in <code>tilejson.json</code>. Optional 2.5 layers <code>object[]</code> Configuration of the individual layers for the Mapbox vector tiles. Optional 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = \"stop\" <code>enum</code> Type of the layer. Required 2.0 cacheMaxSeconds <code>integer</code> Sets the cache header in the response. Optional <code>-1</code> 2.0 expansionFactor <code>double</code> How far outside its boundaries should the tile contain information. Optional <code>0.25</code> 2.0 mapper <code>string</code> Describes the mapper converting from the OTP model entities to the vector tile properties. Required 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0maxZoom <code>integer</code> Maximum zoom levels the layer is active for. Optional <code>20</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0minZoom <code>integer</code> Minimum zoom levels the layer is active for. Optional <code>9</code> 2.0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name <code>string</code> Used in the url to fetch tiles, and as the layer name in the vector tiles. Required 2.0"},{"location":"sandbox/MapboxVectorTilesApi/#details","title":"Details","text":""},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_basePath","title":"basePath","text":"<p>Since version: <code>2.5</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Optional</code> Path: /vectorTiles </p> <p>The path of the vector tile source URLs in <code>tilejson.json</code>.</p> <p>This is useful if you have a proxy setup and rewrite the path that is passed to OTP.</p> <p>If you don't configure this optional value then the path returned in <code>tilejson.json</code> is in the format <code>/otp/routers/default/vectorTiles/layer1,layer2/{z}/{x}/{x}.pbf</code>. If you, for example, set a value of <code>/otp_test/tiles</code> then the returned path changes to <code>/otp_test/tiles/layer1,layer2/{z}/{x}/{x}.pbf</code>.</p> <p>The protocol and host are always read from the incoming HTTP request. If you run OTP behind a proxy then make sure to set the headers <code>X-Forwarded-Proto</code> and <code>X-Forwarded-Host</code> to make OTP return the protocol and host for the original request and not the proxied one.</p> <p>Note: This does not change the path that OTP itself serves the tiles or <code>tilejson.json</code> responses but simply changes the URLs listed in <code>tilejson.json</code>. The rewriting of the path is expected to be handled by a proxy.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers","title":"layers","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /vectorTiles </p> <p>Configuration of the individual layers for the Mapbox vector tiles.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_cacheMaxSeconds","title":"cacheMaxSeconds","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>integer</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>-1</code> Path: /vectorTiles/layers/[0] </p> <p>Sets the cache header in the response.</p> <p>The lowest value of the layers included is selected.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_expansionFactor","title":"expansionFactor","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>double</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>0.25</code> Path: /vectorTiles/layers/[0] </p> <p>How far outside its boundaries should the tile contain information.</p> <p>The value is a fraction of the tile size. If you are having problem with icons and shapes being clipped at tile edges, then increase this number.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#vectorTiles_layers_0_mapper","title":"mapper","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /vectorTiles/layers/[0] </p> <p>Describes the mapper converting from the OTP model entities to the vector tile properties.</p> <p>Currently <code>Digitransit</code> is supported for all layer types.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#extending","title":"Extending","text":"<p>If more generic layers are created for this API, the code should be moved out from the sandbox, into  the core, perhaps potentially leaving specific property mappers in place.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#creating-a-new-layer","title":"Creating a new layer","text":"<p>In order to create a new type of layer, you need to create a new class extending <code>LayerBuilder&lt;T&gt;</code>. You need to implement two methods, <code>List&lt;Geometry&gt; getGeometries(Envelope query)</code>, which returns a list of geometries, with an object of type <code>T</code> as their userData in the geometry, and <code>double getExpansionFactor()</code>, which describes how much information outside the tile bounds should be included. This layer then needs to be added into <code>VectorTilesResource.layers</code>, with a new <code>LayerType</code> enum as the key, and the class constructor as the value.</p> <p>A new mapper needs to be added every time a new layer is added. See below for information.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#creating-a-new-mapper","title":"Creating a new mapper","text":"<p>The mapping contains information of what data to include in the vector tiles. The mappers are defined per layer.</p> <p>In order to create a new mapper for a layer, you need to create a new class extending <code>PropertyMapper&lt;T&gt;</code>. In that class, you need to implement the method <code>Collection&lt;KeyValue&lt;String, Object&gt;&gt; map(T input)</code>. The type T is dependent on the layer for which you implement the mapper for. It needs to return a list of attributes, as key-value pairs which will be written into the vector tile.</p> <p>The mapper needs to be added to the <code>mappers</code> map in the layer, with a new <code>MapperType</code> enum as the key, and a function to create the mapper, with a <code>Graph</code> object as a parameter, as the value.</p>"},{"location":"sandbox/MapboxVectorTilesApi/#changelog","title":"Changelog","text":"<ul> <li>2020-07-09: Initial version of Mapbox vector tiles API</li> <li>2021-05-12: Make expansion factor configurable</li> <li>2021-09-07: Rename <code>BikeRental</code> to <code>VehicleRental</code></li> <li>2021-10-13: Correctly serialize the vehicle rental name #3648</li> <li>2022-01-03: Add support for VehicleParking entities</li> <li>2022-04-27: Read the headsign for frequency-only patterns correctly #4122</li> <li>2022-08-23: Remove patterns and add route gtfsTypes to stop layer #4404</li> <li>2022-10-11: Added layer for VehicleParkingGroups #4510</li> <li>2022-10-14: Add separate layers for vehicle rental place types #4516</li> <li>2022-10-19 #4529:</li> <li>Translatable fields are now translated based on accept-language header</li> <li>Added DigitransitRealtime for vehicle rental stations</li> <li>Changed old vehicle parking mapper to be Stadtnavi</li> <li>Added a new Digitransit vehicle parking mapper with no real-time information and less fields</li> <li>2024-01-22: Make <code>basePath</code> configurable #5627</li> </ul>"},{"location":"sandbox/ParkAndRideApi/","title":"Park and Ride API","text":""},{"location":"sandbox/ParkAndRideApi/#contact-info","title":"Contact Info","text":"<ul> <li>Evan Siroky, IBI Group, USA</li> </ul>"},{"location":"sandbox/ParkAndRideApi/#changelog","title":"Changelog","text":"<ul> <li>Initial version of the Park and Ride API. (February 2021)</li> </ul>"},{"location":"sandbox/ParkAndRideApi/#documentation","title":"Documentation","text":"<p>This adds a new API endpoint for fetching Park and Rides included in the current graph. It is possible to search using a bounding box and/or proximity of Park and Rides to nearby transit stops.</p>"},{"location":"sandbox/ReportApi/","title":"Report API","text":"<p>The report API is a collection of reports generated as CSV files. The main use-case is to download data for manual analyzes and verification. The CSV files should not be used as a service by another programs, the report can be changed at any time - without any notice.</p> <p>Feel free to add more reports and to add your organization to the contact info list.</p>"},{"location":"sandbox/ReportApi/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> <li>Leonard Ehrenfried, Germany, mail@leonard.io</li> </ul>"},{"location":"sandbox/ReportApi/#changelog","title":"Changelog","text":"<ul> <li>2021-05-19: Initial version of the report API. Support listing all transfers as a CSV text file.</li> <li>2021-07-19: Add report that exports the bicycle safety factors as CSV and an interactive HTML   table view.</li> </ul>"},{"location":"sandbox/ReportApi/#documentation","title":"Documentation","text":"<p>This module mounts an endpoint for generating reports under <code>otp/report</code>. Available reports:</p> <ul> <li>/otp/report/transfers.csv</li> <li>/otp/report/graph.json   Detailed numbers of transit and street entities in the graph</li> <li>/otp/report/bicycle-safety.html:   Interactive viewer of the rules that determine how bicycle safety factors are calculated.</li> <li>/otp/report/bicycle-safety.csv: Raw CSV   data for the bicycle safety report.<ul> <li>Norwegian version</li> <li>German version</li> <li>UK version</li> <li>Finnish version</li> </ul> </li> <li>/otp/report/transit/group/priorities:   List all transit groups used for transit-group-priority (Competition neutral planning).   </li> </ul>"},{"location":"sandbox/ReportApi/#configuration","title":"Configuration","text":"<p>The report API is turned off by default. To turn it on enable the <code>ReportApi</code> feature.</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"ReportApi\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/RideHailing/","title":"Ride hailing services","text":"<p>This sandbox feature allows you to use ride hailing services like Uber.</p>"},{"location":"sandbox/RideHailing/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/RideHailing/#configuration","title":"Configuration","text":"<p>In order enable this feature, add a new section <code>rideHailingServices</code> in <code>router-config.json</code>.</p> <p>The supported ride-hailing providers are listed below.</p>"},{"location":"sandbox/RideHailing/#uber","title":"Uber","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"uber-car-hailing\" <code>enum</code> The type of the service. Required 2.3 clientId <code>string</code> OAuth client id to access the API. Required 2.3 clientSecret <code>string</code> OAuth client secret to access the API. Required 2.3 wheelchairAccessibleProductId <code>string</code> The id of the requested wheelchair-accessible product ID. Required 2.3 bannedProductIds <code>string[]</code> The IDs of those product ids that should not be used for estimates. Optional 2.3"},{"location":"sandbox/RideHailing/#details","title":"Details","text":""},{"location":"sandbox/RideHailing/#rideHailingServices_0_wheelchairAccessibleProductId","title":"wheelchairAccessibleProductId","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /rideHailingServices/[0] </p> <p>The id of the requested wheelchair-accessible product ID.</p> <p>See <code>bannedProductIds</code> for a list of product IDs.</p>"},{"location":"sandbox/RideHailing/#rideHailingServices_0_bannedProductIds","title":"bannedProductIds","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /rideHailingServices/[0] </p> <p>The IDs of those product ids that should not be used for estimates.</p> <p>See the current list of Uber product ids.</p>"},{"location":"sandbox/RideHailing/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"rideHailingServices\" : [\n    {\n      \"type\" : \"uber-car-hailing\",\n      \"clientId\" : \"secret-id\",\n      \"clientSecret\" : \"very-secret\",\n      \"wheelchairAccessibleProductId\" : \"545de0c4-659f-49c6-be65-0d5e448dffd5\",\n      \"bannedProductIds\" : [\n        \"1196d0dd-423b-4a81-a1d8-615367d3a365\",\n        \"f58761e5-8dd5-4940-a472-872f1236c596\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriAzureUpdater/","title":"Siri Azure Updater","text":"<p>It is sandbox extension developed by Sk\u00e5netrafiken that allows OTP to fetch Siri ET &amp; SX messages through Azure Service Bus. IT also OTP to download historical data from en HTTP endpoint on startup.</p>"},{"location":"sandbox/SiriAzureUpdater/#contact-info","title":"Contact Info","text":"<p>Sk\u00e5netrafiken, Sweden developer.otp@skanetrafiken.se</p>"},{"location":"sandbox/SiriAzureUpdater/#changelog","title":"Changelog","text":"<ul> <li>Added configuration for turning off stop arrival time match feature. </li> <li>Initial version (April 2022)</li> <li>Minor changes in logging (November 2022)</li> <li>Retry fetch from history endpoint if it failed (February 2023)</li> <li>Solve a bug in SiriAzureETUpdater and improve error logging (March 2023)</li> </ul>"},{"location":"sandbox/SiriAzureUpdater/#documentation","title":"Documentation","text":"<p>Documentation available here.</p>"},{"location":"sandbox/SiriAzureUpdater/#configuration","title":"Configuration","text":"<p>See example configuration in <code>examples/skanetrafiken/router-config.json</code>.</p>"},{"location":"sandbox/SiriUpdater/","title":"Siri Updater","text":"<p>Support for consuming SIRI ET and SX messages. The updater is developed to support the Nordic SIRI profile which is a subset of the SIRI specification.</p>"},{"location":"sandbox/SiriUpdater/#contact-info","title":"Contact Info","text":"<ul> <li>Lasse Tyrihjell, Entur, Norway</li> </ul>"},{"location":"sandbox/SiriUpdater/#documentation","title":"Documentation","text":"<p>This updater consumes SIRI real time information. It is developed by Entur and supports the Nordic Profile for SIRI. It should be possible to develop it further to support a broader set of the SIRI specification.</p> <p>For more documentation goto the Entur Real-Time Data documentation and the Norwegian SIRI profile .</p>"},{"location":"sandbox/SiriUpdater/#configuration","title":"Configuration","text":"<p>To enable the SIRI updater you need to add it to the updaters section of the <code>router-config.json</code>.</p>"},{"location":"sandbox/SiriUpdater/#siri-et-via-https","title":"Siri-ET via HTTPS","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"siri-et-updater\" <code>enum</code> The type of the updater. Required 1.5 blockReadinessUntilInitialized <code>boolean</code> Whether catching up with the updates should block the readiness check from returning a 'ready' result. Optional <code>false</code> 2.0 feedId <code>string</code> The ID of the feed to apply the updates to. Required 2.0 frequency <code>duration</code> How often the updates should be retrieved. Optional <code>\"PT1M\"</code> 2.0 fuzzyTripMatching <code>boolean</code> If the fuzzy trip matcher should be used to match trips. Optional <code>false</code> 2.0 previewInterval <code>duration</code> TODO Optional 2.0 requestorRef <code>string</code> The requester reference. Optional 2.0 timeout <code>duration</code> The HTTP timeout to download the updates. Optional <code>\"PT15S\"</code> 2.0 url <code>string</code> The URL to send the HTTP requests to. Required 2.0 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/SiriUpdater/#parameter-details","title":"Parameter details","text":""},{"location":"sandbox/SiriUpdater/#u__8__url","title":"url","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[8] </p> <p>The URL to send the HTTP requests to.</p> <p>Use the file protocol to set a directory for reading updates from a directory. The file loader will look for xml files: '*.xml' in the configured directory. The files are renamed by the loader when processed:</p> <p> a.xml \u00a0 \u279e \u00a0 a.xml.inProgress \u00a0 \u279e \u00a0 a.xml.ok \u00a0 or \u00a0 a.xml.failed</p>"},{"location":"sandbox/SiriUpdater/#u__8__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[8] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/SiriUpdater/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"siri-et-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Authorization\" : \"Some-Token\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriUpdater/#siri-sx-via-https","title":"Siri-SX via HTTPS","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"siri-sx-updater\" <code>enum</code> The type of the updater. Required 1.5 blockReadinessUntilInitialized <code>boolean</code> Whether catching up with the updates should block the readiness check from returning a 'ready' result. Optional <code>false</code> 2.0 earlyStart <code>duration</code> This value is subtracted from the actual validity defined in the message. Optional <code>\"PT0S\"</code> 2.0 feedId <code>string</code> The ID of the feed to apply the updates to. Required 2.0 frequency <code>duration</code> How often the updates should be retrieved. Optional <code>\"PT1M\"</code> 2.0 requestorRef <code>string</code> The requester reference. Optional 2.0 timeout <code>duration</code> The HTTP timeout to download the updates. Optional <code>\"PT15S\"</code> 2.0 url <code>string</code> The URL to send the HTTP requests to. Supports http/https and file protocol. Required 2.0 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/SiriUpdater/#parameter-details_1","title":"Parameter details","text":""},{"location":"sandbox/SiriUpdater/#u__9__earlyStart","title":"earlyStart","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>duration</code> \u2219 Cardinality: <code>Optional</code> \u2219 Default value: <code>\"PT0S\"</code> Path: /updaters/[9] </p> <p>This value is subtracted from the actual validity defined in the message.</p> <p>Normally the planned departure time is used, so setting this to 10s will cause the SX-message to be included in trip-results 10 seconds before the the planned departure time.</p>"},{"location":"sandbox/SiriUpdater/#u__9__url","title":"url","text":"<p>Since version: <code>2.0</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[9] </p> <p>The URL to send the HTTP requests to. Supports http/https and file protocol.</p> <p>Use the file protocol to set a directory for reading updates from a directory. The file loader will look for xml files: '*.xml' in the configured directory. The files are renamed by the loader when processed:</p> <p> a.xml \u00a0 \u279e \u00a0 a.xml.inProgress \u00a0 \u279e \u00a0 a.xml.ok \u00a0 or \u00a0 a.xml.failed</p>"},{"location":"sandbox/SiriUpdater/#u__9__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[9] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/SiriUpdater/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"siri-sx-updater\",\n      \"url\" : \"https://example.com/some/path\",\n      \"feedId\" : \"feed_id\",\n      \"timeout\" : \"30s\",\n      \"headers\" : {\n        \"Key\" : \"Value\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/SiriUpdater/#changelog","title":"Changelog","text":"<ul> <li>Initial version of SIRI updater (October 2019)</li> <li>Include situations with no or no handled entity selectors with Unknown EntitySelector (December   2021, https://github.com/opentripplanner/OpenTripPlanner/pull/3780)</li> </ul>"},{"location":"sandbox/SmooveBikeRental/","title":"HSL Smoove Bike Rental Updater Support - OTP Sandbox Extension","text":""},{"location":"sandbox/SmooveBikeRental/#contact-info","title":"Contact Info","text":"<ul> <li>Digitransit team, HSL, Helsinki, Finland</li> </ul>"},{"location":"sandbox/SmooveBikeRental/#changelog","title":"Changelog","text":"<ul> <li>Move this functonality into a sandbox</li> <li>Add allowOverloading through updater config to the stations and isRenting, isReturning and   capacity from the data to stations (October   2021, https://github.com/opentripplanner/OpenTripPlanner/pull/3632)</li> <li>Rename <code>allowOverloading</code> to <code>overloadingAllowed</code></li> </ul>"},{"location":"sandbox/SmooveBikeRental/#documentation","title":"Documentation","text":"<p>TODO</p>"},{"location":"sandbox/SmooveBikeRental/#configuration","title":"Configuration","text":"<p>An example updater configuration:</p> <pre><code>{\n    \"type\": \"bike-rental\",\n    \"sourceType\": \"smoove\",\n    \"network\": \"smoove-network-1\",\n    \"url\": \"https://helsinki-fi.smoove.pro/api-public/stations\",\n    \"frequency\": 10,\n    \"overloadingAllowed\": true\n}\n</code></pre> <p><code>network</code> (optional) allows defining custom network id</p> <p><code>overloadingAllowed</code> (optional) defines if the stations in the network allow overloading (ignoring available spaces)</p>"},{"location":"sandbox/StopConsolidation/","title":"Stop Consolidation","text":""},{"location":"sandbox/StopConsolidation/#stop-consolidation","title":"Stop consolidation","text":""},{"location":"sandbox/StopConsolidation/#contact-info","title":"Contact Info","text":"<ul> <li>Jon Campbell, Arcadis, USA</li> </ul>"},{"location":"sandbox/StopConsolidation/#feature-explanation","title":"Feature explanation","text":"<p>This sandbox feature allows you to \"combine\" equivalent stops from across several feeds into a single, consolidated one. </p> <p>It is achieved by defining a \"primary\" stop and one or more \"secondary\" stops. During the graph build all trip patterns are modified so that the secondary ones are swapped out for their primary equivalent.</p>"},{"location":"sandbox/StopConsolidation/#effects","title":"Effects","text":"<p>This has the following consequences </p> <ul> <li>When you query the departures for a primary stop you see a consolidated view of all the equivalent departures.</li> <li>When transferring at a consolidated stop you no longer get instructions like \"walk 5 meters to stop X\"</li> </ul> <p>Downsides</p> <p>However, this feature has also severe downsides:</p> <ul> <li>It makes real-time trip updates referencing a stop id much more complicated and in many cases    impossible to resolve.    You can only reference a stop by its sequence, which only works in GTFS-RT, not Siri.</li> <li>Fare calculation and transfers are unlikely to work as expected.</li> </ul>"},{"location":"sandbox/StopConsolidation/#configuration","title":"Configuration","text":"<p>To enable this feature you need to add a file to OTP's working directory and configure its name like this:</p> <pre><code>// build-config.json\n{\n  \"stopConsolidationFile\" : \"consolidated-stops.csv\"\n}\n</code></pre> <p>The additional config file must look like the following:</p> <pre><code>stop_group_id,feed_id,stop_id,is_primary\n1,pierce,1705867009,0\n1,kcm,10225,1\n2,pierce,1569,0\n2,commtrans,473,0\n2,kcm,1040,1\n</code></pre> <p>The column names mean the following:</p> <ul> <li><code>stop_group_id</code>: id to group several rows in the file together</li> <li><code>feed_id</code>: feed id of the stop</li> <li><code>stop_id</code>: id of the stop</li> <li><code>is_primary</code>: whether the row represents a primary stop, <code>1</code> means yes and <code>0</code> means no</li> </ul>"},{"location":"sandbox/TravelTime/","title":"Travel Time (Isochrone &amp; Surface) API","text":""},{"location":"sandbox/TravelTime/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/TravelTime/#changelog","title":"Changelog","text":"<ul> <li>2022-05-09 Initial implementation</li> </ul>"},{"location":"sandbox/TravelTime/#documentation","title":"Documentation","text":"<p>The API produces a snapshot of travel time form a single place to places around it. The results can be fetched either as a set of isochrones or a raster map.</p>"},{"location":"sandbox/TravelTime/#configuration","title":"Configuration","text":"<p>The feature must be enabled in otp-config.json as follows:</p> <pre><code>// otp-config.json\n{\n    \"otpFeatures\" : {\n        \"SandboxAPITravelTime\" : true\n    }\n}\n</code></pre>"},{"location":"sandbox/TravelTime/#api-parameters","title":"API parameters","text":"<ul> <li><code>location</code> Origin of the search, can be either <code>latitude,longitude</code> or a stop id</li> <li><code>time</code> Departure time as a ISO-8601 time and date (example <code>2023-04-24T15:40:12+02:00</code>). The default value is the current time.</li> <li><code>cutoff</code> The maximum travel duration as a ISO-8601 duration. The <code>PT</code> can be dropped to simplify the value.    This parameter can be given multiple times to include multiple isochrones in a single request.   The default value is one hour.</li> <li><code>modes</code> A list of travel modes. WALK is not implemented, use <code>WALK, TRANSIT</code> instead.</li> <li><code>arriveBy</code> Set to <code>false</code> when searching from the location and <code>true</code> when searching to the    location</li> </ul>"},{"location":"sandbox/TravelTime/#isochrone-api","title":"Isochrone API","text":"<p><code>/otp/traveltime/isochrone</code></p> <p>Results is the travel time boundaries at the <code>cutoff</code> travel time.</p>"},{"location":"sandbox/TravelTime/#travel-time-surface-api","title":"Travel time surface API","text":"<p><code>/otp/traveltime/surface</code></p> <p>The travel time as a GeoTIFF raster file. The file has a single 32-bit int band, which contains the  travel time in seconds.</p>"},{"location":"sandbox/TravelTime/#example-request","title":"Example Request","text":"<pre><code>http://localhost:8080/otp/traveltime/isochrone?batch=true&amp;location=52.499959,13.388803&amp;time=2023-04-12T10:19:03%2B02:00&amp;modes=WALK,TRANSIT&amp;arriveBy=false&amp;cutoff=30M17S\n</code></pre>"},{"location":"sandbox/VehicleParking/","title":"Vehicle Parking Updaters","text":""},{"location":"sandbox/VehicleParking/#contact-info","title":"Contact Info","text":"<ul> <li>For HSL Park and Ride updater: Digitransit team, HSL, Helsinki, Finland</li> <li>For Bikely updater: Leonard Ehrenfried, mail@leonard.io</li> </ul>"},{"location":"sandbox/VehicleParking/#documentation","title":"Documentation","text":"<p>This sandbox contains vehicle parking updaters. Unlike for some other sandbox features, this is not enabled/disabled through <code>otp-config.json</code> but from <code>router-config.json</code> updaters.</p> <p>Currently contains the following updaters:</p> <ul> <li>HSL Park and Ride</li> <li>ParkAPI</li> <li>Bikely</li> </ul>"},{"location":"sandbox/VehicleParking/#configuration","title":"Configuration","text":"<p>These sandboxed vehicle parking updaters can be enabled by editing the <code>updaters</code> section in the <code>router-config.json</code> according to the following examples.</p> <p>All updaters have the following parameters in common:</p> <ul> <li><code>type</code>: this needs to be <code>\"vehicle-parking\"</code></li> <li><code>feedId</code>: this is used as a \"prefix\" for park ids, entrance ids and sometimes also for tags.</li> </ul>"},{"location":"sandbox/VehicleParking/#hsl-park-and-ride","title":"HSL Park and Ride","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 facilitiesFrequencySec <code>integer</code> How often the facilities should be updated. Optional <code>3600</code> 2.2 facilitiesUrl <code>string</code> URL of the facilities. Optional 2.2 feedId <code>string</code> The name of the data source. Required 2.2 hubsUrl <code>string</code> Hubs URL Optional 2.2 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 timeZone <code>time-zone</code> The time zone of the feed. Optional 2.2 utilizationsFrequencySec <code>integer</code> How often the utilization should be updated. Optional <code>600</code> 2.2 utilizationsUrl <code>string</code> URL of the utilization data. Optional 2.2"},{"location":"sandbox/VehicleParking/#details","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__2__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[2] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__2__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[2]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__2__timeZone","title":"timeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[2] </p> <p>The time zone of the feed.</p> <p>Used for converting abstract opening hours into concrete points in time.</p>"},{"location":"sandbox/VehicleParking/#example-configuration","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"hsl-park\",\n      \"feedId\" : \"hslpark\",\n      \"timeZone\" : \"Europe/Helsinki\",\n      \"facilitiesFrequencySec\" : 3600,\n      \"facilitiesUrl\" : \"https://p.hsl.fi/api/v1/facilities.json?limit=-1\",\n      \"utilizationsFrequencySec\" : 600,\n      \"utilizationsUrl\" : \"https://p.hsl.fi/api/v1/utilizations.json?limit=-1\",\n      \"hubsUrl\" : \"https://p.hsl.fi/api/v1/hubs.json?limit=-1\"\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#parkapi","title":"ParkAPI","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> The name of the data source. Required 2.2 frequency <code>duration</code> How often to update the source. Optional <code>\"PT1M\"</code> 2.2 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 timeZone <code>time-zone</code> The time zone of the feed. Optional 2.2 url <code>string</code> URL of the resource. Optional 2.2 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.2 tags <code>string[]</code> Tags to add to the parking lots. Optional 2.2"},{"location":"sandbox/VehicleParking/#details_1","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__3__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[3] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__3__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[3]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__3__timeZone","title":"timeZone","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>time-zone</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>The time zone of the feed.</p> <p>Used for converting abstract opening hours into concrete points in time.</p>"},{"location":"sandbox/VehicleParking/#u__3__headers","title":"headers","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleParking/#u__3__tags","title":"tags","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string[]</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[3] </p> <p>Tags to add to the parking lots.</p>"},{"location":"sandbox/VehicleParking/#example-configuration_1","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"sourceType\" : \"park-api\",\n      \"feedId\" : \"parkapi\",\n      \"timeZone\" : \"Europe/Berlin\",\n      \"frequency\" : \"10m\",\n      \"url\" : \"https://foo.bar\",\n      \"headers\" : {\n        \"Cache-Control\" : \"max-age=604800\"\n      },\n      \"tags\" : [\n        \"source:parkapi\"\n      ]\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#bikely","title":"Bikely","text":"Config Parameter Type Summary Req./Opt. Default Value Since type = \"vehicle-parking\" <code>enum</code> The type of the updater. Required 1.5 feedId <code>string</code> The name of the data source. Required 2.2 frequency <code>duration</code> How often to update the source. Optional <code>\"PT1M\"</code> 2.3 sourceType <code>enum</code> The source of the vehicle updates. Required 2.2 url <code>string</code> URL of the locations endpoint. Optional 2.3 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.3"},{"location":"sandbox/VehicleParking/#details_2","title":"Details","text":""},{"location":"sandbox/VehicleParking/#u__4__feedId","title":"feedId","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>string</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[4] </p> <p>The name of the data source.</p> <p>This will end up in the API responses as the feed id of of the parking lot.</p>"},{"location":"sandbox/VehicleParking/#u__4__sourceType","title":"sourceType","text":"<p>Since version: <code>2.2</code> \u2219 Type: <code>enum</code> \u2219 Cardinality: <code>Required</code> Path: /updaters/[4]  Enum values: <code>park-api</code> | <code>bicycle-park-api</code> | <code>hsl-park</code> | <code>bikely</code></p> <p>The source of the vehicle updates.</p>"},{"location":"sandbox/VehicleParking/#u__4__headers","title":"headers","text":"<p>Since version: <code>2.3</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /updaters/[4] </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleParking/#example-configuration_2","title":"Example configuration","text":"<pre><code>// router-config.json\n{\n  \"updaters\" : [\n    {\n      \"type\" : \"vehicle-parking\",\n      \"feedId\" : \"bikely\",\n      \"sourceType\" : \"bikely\",\n      \"url\" : \"https://api.safebikely.com/api/v1/s/locations\",\n      \"headers\" : {\n        \"X-Bikely-Token\" : \"${BIKELY_TOKEN}\",\n        \"Authorization\" : \"${BIKELY_AUTHORIZATION}\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"sandbox/VehicleParking/#changelog","title":"Changelog","text":"<ul> <li>Create initial sandbox implementation (January 2022, #3796)</li> <li>Add timeZone parameter to hsl and parkapi updaters (September 2022, #4427)</li> <li>Added support for HSL parking hubs (October 2022, #4510)</li> <li>Add Bikely updater (November 2022, #4589)</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/","title":"Vehicle Rental Service Directory API support.","text":"<p>This adds support for the GBFS service directory endpoint component located at  https://github.com/entur/lamassu. OTP uses the service directory to lookup and connect to all GBFS endpoints registered in the directory. This simplifies the management of the GBFS endpoints, since multiple services/components like OTP can connect to the directory and get the necessary configuration from it.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#contact-info","title":"Contact Info","text":"<ul> <li>Entur, Norway</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/#changelog","title":"Changelog","text":"<ul> <li>Initial implementation of bike share updater API support</li> <li>Make json tag names configurable #3447</li> <li>Enable GBFS geofencing with VehicleRentalServiceDirectory #5324</li> </ul>"},{"location":"sandbox/VehicleRentalServiceDirectory/#configuration","title":"Configuration","text":"<p>To enable this you need to specify a url for the <code>vehicleRentalServiceDirectory</code> in the <code>router-config.json</code></p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#parameter-summary","title":"Parameter Summary","text":"Config Parameter Type Summary Req./Opt. Default Value Since language <code>string</code> Language code. Optional 2.1 sourcesName <code>string</code> Json tag name for updater sources. Optional <code>\"systems\"</code> 2.1 updaterNetworkName <code>string</code> Json tag name for the network name for each source. Optional <code>\"id\"</code> 2.1 updaterUrlName <code>string</code> Json tag name for endpoint urls for each source. Optional <code>\"url\"</code> 2.1 url <code>uri</code> Endpoint for the VehicleRentalServiceDirectory Required 2.1 headers <code>map of string</code> HTTP headers to add to the request. Any header key, value can be inserted. Optional 2.1 networks <code>object[]</code> List all networks to include. Use \"network\": \"default-network\" to set defaults. Optional 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0geofencingZones <code>boolean</code> Enables geofencingZones for the given network Optional <code>false</code> 2.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0network <code>string</code> The network name Required 2.4"},{"location":"sandbox/VehicleRentalServiceDirectory/#parameter-details","title":"Parameter Details","text":""},{"location":"sandbox/VehicleRentalServiceDirectory/#vehicleRentalServiceDirectory_headers","title":"headers","text":"<p>Since version: <code>2.1</code> \u2219 Type: <code>map of string</code> \u2219 Cardinality: <code>Optional</code> Path: /vehicleRentalServiceDirectory </p> <p>HTTP headers to add to the request. Any header key, value can be inserted.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#vehicleRentalServiceDirectory_networks","title":"networks","text":"<p>Since version: <code>2.4</code> \u2219 Type: <code>object[]</code> \u2219 Cardinality: <code>Optional</code> Path: /vehicleRentalServiceDirectory </p> <p>List all networks to include. Use \"network\": \"default-network\" to set defaults.</p> <p>If no default network exists only the listed networks are used. Configure a network with name \"default-network\" to include all unlisted networks. If not present, all unlisted networks are dropped. Note! The values in the \"default-network\" are not used to set missing field values in networks listed.</p>"},{"location":"sandbox/VehicleRentalServiceDirectory/#example","title":"Example","text":"<pre><code>// router-config.json\n{\n  \"vehicleRentalServiceDirectory\" : {\n    \"url\" : \"https://example.com\",\n    \"sourcesName\" : \"systems\",\n    \"updaterUrlName\" : \"url\",\n    \"updaterNetworkName\" : \"id\",\n    \"headers\" : {\n      \"ET-Client-Name\" : \"otp\"\n    },\n    \"networks\" : [\n      {\n        \"network\" : \"oslo-by-sykkel\",\n        \"geofencingZones\" : true\n      }\n    ]\n  }\n}\n</code></pre>"},{"location":"sandbox/VehicleToStopHeuristics/","title":"Vehicle-to-Stop heuristics - OTP Sandbox Extension","text":""},{"location":"sandbox/VehicleToStopHeuristics/#contact-info","title":"Contact Info","text":"<ul> <li>Leonard Ehrenfried (mail@leonard.io)</li> </ul>"},{"location":"sandbox/VehicleToStopHeuristics/#changelog","title":"Changelog","text":"<ul> <li>Create initial   implementation #3906</li> </ul>"},{"location":"sandbox/VehicleToStopHeuristics/#documentation","title":"Documentation","text":"<p>This feature is meant to improve the performance and result quality for routing requests where a vehicle (car, bike, scooter) is ridden to a stop where transit is boarded.</p> <p>Before this feature existed a search for nearby stops was executed finding all candidate stops for boarding transit. For walking this yields a low number of stops but when driving a car this can easily mean to an entire city of stops, since the default was a drive of 45 minutes.</p> <p>Having a very long driving time has several problems:</p> <ul> <li>the access search itself is comparatively slow</li> <li>having many candidate stops slows down the transit search as many routes have to be checked</li> <li>often the quickest route would be to drive almost all the way to the destination and board transit   for a single stop</li> </ul> <p>We did not want to lower the maximum access time since in rural regions 45 minutes might be a useful maximum, but we want it to scale with the density of well-connected stops.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#vehicle-to-stop-heuristic","title":"Vehicle-to-stop heuristic","text":"<p>In order to improve the Park+Ride and Bike+Ride results we reduced the number of candidate stops with the following heuristic:</p> <ol> <li>When a stop is encountered check which routes depart from it</li> <li>Each route adds to an \"importance score\"</li> <li>Modes which are fast (RAIL, SUBWAY, FERRY) have a higher score than for example BUS</li> <li>Once a maximum score is reached, the search is complete</li> </ol> <p>The code for this is located in <code>VehicleToStopSkipEdgeStrategy.java</code>.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#bicycle-on-transit-heuristic","title":"Bicycle-on-transit heuristic","text":"<p>This heuristic works slightly differently in that it doesn't assign a score but simply stops the access search when a certain number of routes were encountered that allow you to take your bike onto transit.</p> <p>The code for this is located in <code>BikeToStopSkipEdgeStrategy.java</code>.</p>"},{"location":"sandbox/VehicleToStopHeuristics/#configuration","title":"Configuration","text":"<p>Enable the feature by adding it to the <code>otp-config.json</code>:</p> <pre><code>// otp-config.json\n{\n  \"otpFeatures\": {\n    \"VehicleToStopHeuristics\": true\n  }\n}\n</code></pre>"},{"location":"sandbox/VehicleToStopHeuristics/#collaborators-wanted","title":"Collaborators wanted","text":"<p>Since the current settings, scores and weights are hardcoded in the source code we are looking for collaborators that can help to make it more adaptable for different environments.</p> <p>These are some the goals for the future:</p> <ul> <li>make the scores that are assigned for routes of a certain mode configurable in JSON</li> <li>pre-calculate stop importance scores during the graph build</li> </ul> <p>If you want to help making this feature more flexible, please contact Leonard Ehrenfried or use the regular channels of communication outlined in CONTRIBUTING.md</p>"},{"location":"sandbox/transferanalyzer/","title":"Direct transfer analyzer module","text":""},{"location":"sandbox/transferanalyzer/#contact-info","title":"Contact Info","text":"<ul> <li>Gard Mellemstrand, Entur, Norway</li> </ul>"},{"location":"sandbox/transferanalyzer/#changelog","title":"Changelog","text":""},{"location":"sandbox/transferanalyzer/#may-20th-2019","title":"May 20th 2019","text":"<ul> <li>Added the direct transfer analyzer module (May 2019)</li> </ul>"},{"location":"sandbox/transferanalyzer/#documentation","title":"Documentation","text":"<p>Module used for analyzing the transfers between nearby stops generated by routing via OSM data. It generates lists of both unusually long and unroutable transfers. These lists can typically be used to improve the quality of OSM data for transfer purposes.</p> <p>See javadoc in DirectTransferAnalyzer class</p>"}]}
\ No newline at end of file