This section provides information essential to understanding and using the HERE Waypoints Sequence API v8.
The HERE Waypoints Sequence API v8 uses waypoints to identify the stops in your journey. The waypoints are defined at a minimum by WGS-84 compliant latitude and longitude pairs with values between -90 and 90, and -180 and 180 respectively. Each journey must have a start and end (optional, the service assumes the last waypoint is the final destination if you do not define one) point, which you can define explicitly with the relevant parameters (
end in the resource
findsequence. All other waypoints are identified with the parameters
destination2, and so on for however many waypoints you wish to sequence. You can also add a "human-readable" label to your waypoints. For an example, see Car with Traffic Information Waypoint Sequence.
The maximum number of waypoints including the start point and end point is 120 without traffic and 50 with traffic. If the routing mode
pedestrian is used, the distance between each two of the waypoints must not be greater than 5km.
When you use HERE Waypoints Sequence API v8 to optimize a series of waypoints, you need to specify the routing mode in your request. See HERE Routing API for a comprehensive description of the routing mode including possible limitations on some subfields. However, the parameter
mode may include three to four subfields as follows:
The options available are as follows:
fastest: routing favors the least amount of travel time, can consider traffic if enabled. This is the most commonly used routing type.
shortest: routing favors the least amount of travel distance and disregards traffic.
The transport mode allows you to specify the type of vehicle. Supported options are
bus. The modes for taxi and bus work best with traffic set to
enabled, because it takes advantage of bus and taxi lanes on and near high-traffic roads. Please see the transport mode description in HERE Routing API. There is also information on the available status, e.g. if a transport mode is provided with "beta" limitations.
Enabling traffic allows HERE Waypoints Sequence API v8 to consider up-to-date traffic information when calculating a route. Additionally, this live traffic information is augmented with historical traffic speeds when considering travel times in the future. The calculation for the current time uses live traffic information. For longer routes, the live traffic information is mixed with historical traffic information for the later portions of the route. Routes calculated for future times use historical traffic information to determine traffic speeds, as well as considering any long-term road closures on the route. If the request does not include a departure time, then all current live traffic events (at the time of calculation) are assumed to be valid for the entire length of the route.
The routing features can be used to define special conditions on calculated routes. Routing features include weighting roads such as toll road, motorways, etc. There is detailed information coming with the description of the RoutingModeType in HERE Routing API. Please note that routing features are separated by commas, if there is more than one:
For examples, see Examples.
findsequence, all waypoints are mandatory, none of them can be skipped. For
findpickups, only the start and the end waypoints are mandatory, while each of the intermediate waypoints is optional and can be skipped. It is currently not possible, to compute the optimal route given a mixture of these waypoint types (some mandatory, some optional). However, a mixed scenario can be approximated by assigning very high values to the intermediate waypoints to ensure they'll become part of the route.
When submitting a bug report or asking for support, always provide the routing request URI, request identifiers and the corresponding 8.1.11Code, if any.
You can tag your requests with a request identifier using the non-standard HTTP header X-Request-ID. The service will echo this value in the response, be it success or failure. While you can use any string as the request identifier, we recommend using a UUID to uniquely identify your requests.