walkSpeed: ⓘ

Float. The user's walking speed in meters/second. Defaults to approximately (1.33 meters/second). Typical values are 1.0-1.5 m/s. This value is used as a "user max walk speed baseline" to calculate the walking time, but some conditions (e.g. hills, stairs, lifts, underground station access, street crossings, etc.) may increase the overall walking time.

bikeSpeed: ⓘ

Float. Cycling speed in meters per second. Typical values are 3.0-5.0 m/s.

wheelchairAccessible: ⓘ

Boolean. defaults to off. Whether to include wheelchair accessible trips.

numTripPatterns: ⓘ

Integer. Default to 50. The maximum number of trip patterns to return. Note! This reduce the number of trip patterns AFTER the OTP travel search is done in a post-filtering process. There is little/no performance gain in reducing the number of trip patterns returned. See also the trip meta-data on how to implement paging.

maximumTransfers: ⓘ

integer. The maximum number of transfers (that is, one plus the maximum number of boardings) that a trip will be allowed. Larger values will slow performance, but could give better routes. This is limited on the server side by the MAX_TRANSFERS value in org.opentripplanner.api.ws.Planner.

maximumAdditionalTransfers: ⓘ

Integer. Defaults to 5. Maximum number of additional transfers beyond the base limit.

searchWindow: ⓘ

Integer. Minutes. The length of the search-window in minutes. This parameter is optional. The search-window is defined as the duration between the earliest-departure-time(EDT) and the latest-departure-time(LDT). OTP will search for all itineraries in this departure window. If arriveBy=true the dateTime parameter is the latest-arrival-time, so OTP will dynamically calculate the EDT. Using a short search-window is faster than using a longer one, but the search duration is not linear. Using a "too" short search-window will waste resources server side, while using a search-window that is too long will be slow. OTP will dynamically calculate a reasonable value for the search-window, if not provided. The calculation comes with a significant overhead (10-20% extra). Whether you should use the dynamic calculated value or pass in a value depends on your use-case. For a travel planner in a small geographical area, with a dense network of public transportation, a fixed value between 40 minutes and 2 hours makes sense. To find the appropriate search-window, adjust it so that the number of itineraries on average is around the wanted numItineraries. Make sure you set the numItineraries to a high number while testing. For a country wide area like Norway, using the dynamic search-window is the best. When paginating, the search-window is calculated using the numItineraries in the original search together with statistics from the search for the last page. This behaviour is configured server side, and can not be overridden from the client. The search-window used is returned to the response metadata as searchWindowUsed for debugging purposes.

ignoreRealtimeUpdates: ⓘ

When true, real-time updates are ignored during this search.

includePlannedCancellations: ⓘ

When true, service journeys cancelled in scheduled route data will be included during this search.

includeRealtimeCancellations: ⓘ

When true, service journeys cancelled by real-time updates will be included during this search.

walkReluctance: ⓘ

Float. Defaults to 2. Walk cost is multiplied by this value. This is the main parameter to use for limiting walking. walkReluctance is a multiplier for how bad walking is compared to being in transit. Higher values discourage walking. Empirically, values between 10 and 20 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.

waitReluctance: ⓘ

Float. Multiplier for how bad waiting for transit is compared to being on transit. Higher values discourage waiting.

transferPenalty: ⓘ

Integer. Defaults to 0. An extra penalty added on transfers (i.e. all boardings except the first one). The transferPenalty is used when a user requests even less transfers. In the latter case, we don't actually optimise for fewest transfers, as this can lead to absurd results. Consider a trip in New York from Grand Army Plaza (the one in Brooklyn) to Kalustyan's at noon. The true lowest transfers trip pattern is to wait until midnight, when the 4 train runs local the whole way. The actual fastest trip pattern is the 2/3 to the 4/5 at Nevins to the 6 at Union Square, which takes half an hour. Even someone optimise for fewest transfers doesn't want to wait until midnight. Maybe they would be willing to walk to 7th Ave and take the Q to Union Square, then transfer to the 6. If this takes less than transferPenalty seconds, then that's what we'll return.

transferSlack: ⓘ

Integer. Defaults to 120. 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.

boardSlackDefault: ⓘ

Integer. Defaults to 0. The boardSlack is the minimum extra time to board a public transport vehicle.This is the same as the 'minimumTransferTime', except that this also applies to to the first transit leg in the trip.This is the default value used, if not overridden by the 'boardSlackList'.

boardSlackList: ⓘ

JSON: `Array<{ slack: Int, modes: [OTP2TransportMode] }>`. Defaults to `[]`. OTP2TransportMode: `bus`, `rail`, `metro`, `tram`. List of boardSlack for a given set of modes. Defaults to [].
example. `[ { "slack": 60: "modes": ["bus", "rail"] } ]`

alightSlackDefault: ⓘ

Integer. Defaults to 0. The alightSlack is the minimum extra time after exiting a public transport vehicle. This is the default value used, if not overridden by the 'alightSlackList'.

alightSlackList: ⓘ

JSON: `Array<{ slack: Int, modes: [OTP2TransportMode] }>`. Defaults to `[]`. OTP2TransportMode: `bus`, `rail`, `metro`, `tram`. List of alightSlack for a given set of modes. Defaults to [].
example. `[ { "slack": 60, "modes": ["bus", "rail"] } ]`

useBikeRentalAvailabilityInformation: ⓘ

Whether or not bike rental availability information will be used to plan bike rental trips.

pageCursor: ⓘ

String. Use the cursor to go to the next "page" of itineraries. Copy the cursor from the last response and keep the original request as is. This will enable you to search for itineraries in the next or previous time-window.
If you are using the BMC Lab Ui, this is done automatically via the prev/next button of the Planner results list.

triangleFactorsSafety: ⓘ

Safety: How important is bicycle safety expressed as a fraction of 1. Triangle Factors: How much the factors safety, slope and distance are weighted relative to each other when routing bicycle legs. In total all three values need to add up to 1.

triangleFactorsSlope: ⓘ

Slope: How important is slope/elevation expressed as a fraction of 1. Triangle Factors: How much the factors safety, slope and distance are weighted relative to each other when routing bicycle legs. In total all three values need to add up to 1.

triangleFactorsTime: ⓘ

Time: How important is time expressed as a fraction of 1. Note that what this really optimises for is distance (even if that means going over terrible surfaces, so I might be slower than the safe route). Triangle Factors: How much the factors safety, slope and distance are weighted relative to each other when routing bicycle legs. In total all three values need to add up to 1.