HERE Route Matching v8 can compute the (most probable) route through a driven GPS trace. It is very similar to a route matching combined with a route calculation, but not each waypoint has to be reached accurately. Instead, the typical GPS inaccuracies are taken into account.
In addition to the GPS points matched onto road links and the most probable route path, the response provides relevant info for risk analytics and driver behavior:
&drivingReport=1 parameter to request the following info:
For weather archive premium pricing, contact your account executive.
GPS trace points are locations defined by their geographical coordinates. Applications need to be able to determine the road link (the road section with homogeneous attributes) to which a point belongs, its position in relation to the map link geometry and the direction of travel along the link. This allows applications to establish whether the driver is on the expected route, whether the driver is obeying the legal speed limit, the type of road and its characteristics (for example curvature, incline, road surface type, the number of lanes).
The accuracy of the GPS coordinates depends on many factors, with the result that the computed latitude and longitude can be from 0.5 meters to up to 40 meters away from the actual position. It is often impossible to determine a GPS position inside tunnels, inside buildings or in urban canyons. GPS receivers cannot provide a maximum deviation and thus, for example, are unable to indicate that the calculated location lies within 3.5 meters of the actual location with 95% probability. GPS receivers only provide an HDOP/VDOP/PDOP... value (horizontal/vertical dilution of precision), which indicates that the computed coordinates of a location cannot be more accurate than this value considering the number and/or position of satellites and the mathematical algorithms. This minimum error cannot be used to estimate the maximum error.
GPS heading and speed are computed by the receiver device based on the last several sets of GPS coordinates. The accuracy of the calculation depends on the actual speed of the vehicle and becomes unreliable if the vehicle speed drops below ~10 km/h. At low speeds, even the positional accuracy declines considerably, resulting in large random point clouds in some situations.
Route Matching algorithms assume that the route is taken on the official road network obeying legal restrictions for the vehicle type. The computed route includes illegal paths only if the GPS trace apparently proves that the driver ignored a one-way system, a turn, or an access restriction, and may also include a corresponding warning. Hence it is possible to find out legal violations using this service if they are very obvious from the trace points.
It is important to select the correct vehicle type, if known, or otherwise the most probable one. A car trace matched in pedestrian mode would tend to ignore one-way systems and favor footpaths, but avoid motorways, whereas a pedestrian trace matched in car mode would try to avoid footpaths and other illegal thoroughfares unless very obvious. So, especially for sparse traces or bad point accuracy, the matching quality is worse if the vehicle type is inappropriate.
In summary, Route Matching can determine where a driver most probably violated rules with regard to one-way systems, turn restrictions or access restrictions, and the matching algorithm stays on the safe side, giving preference to legal paths unless obvious.
Time-dependent legal restrictions are considered correctly, if the trace contains time stamps, otherwise they are considered as time independent.
Legal speed limits are not considered while constructing the most probable route, that is a road section is not avoided just because the GPS trace suggests that the driver would have speeded when traveling on it. Hence, Route Matching can be used to determine where the driver was speeding.
If a use case requires a strictly legal route, the request parameter
&legal specifies which illegal maneuvers to avoid, regardless whether the trace obviously reflects such violations.
The accuracy of the map geometry is optimized and depends on the requirements for the underlying routing application(s). Typically, the map contains a minimum number of geometry points that provide a certain absolute and relative accuracy. The modeling of the road network is also optimized for the routing application(s), for example intersections are modeled as simply as possible within the specification, and roads are polylines rather than lane level polygons. Each road is in part modeled as a single polyline for the whole road bed, including all lanes in both driving directions (single-digitized), but other sections of the road may include lanes for each driving direction modeled as separate polylines (multi-digitized), and in some cases, especially at intersections and exits, some lanes in the same driving direction can be modeled as separate polylines. HERE maps set road geometry points in such a way as to improve map matching quality in critical situations like motorway ramps or transitions between single and multi-digitized road beds.
Traces may contain bad GPS points that are either at 0/0 or far away from the trace path or – although not far away from the trace path – would require a large detour to be included in the route path. Route Matching ignores these traces when creating the most probable route path, but afterwards matches them onto the route path, indicating the issues by warnings and by a low point match confidence value. This way Route Matching always provides the most probable path as a fully connected route (without gaps) and matches all the trace points to their most probable place along this route.
Traces may traverse gaps in the HERE road network. This is due to gaps or errors in the HERE map, vehicles, or persons using paths that are outside the HERE map inclusion rules such as unofficial or private roads and/or paths, or vehicles and/or persons that use transport types such as walking, train, boat, or airplanes that do not follow HERE roads.
If that leads to few outlier points along an otherwise reasonable path, then Route Matching ignores these outliers when creating the route path, as described above. If it leads to gaps on an otherwise reasonably matched road path, then Route Matching includes detours to avoid the gaps. Route links on such detours have a low link match confidence value so it is easy to apply – depending on the use case – thresholds to treat these detours appropriately, for example to skip them for driver rating, since the driver most probably did not drive there. So Route Matching guarantees to provide a fully connected route without gaps, while it is easy for applications to detect and handle the situation appropriately, and "create" the gaps from the link match confidence values.
The most commonly used file formats generated by GPS receivers and tools are:
CSV: The first line contains the attribute names, the subsequent lines the data in temporal order. The following parameters are available:
longitudeare the geographic coordinates in WGS84 degree (mandatory).
timestampindicates the time and date, for example 2012-05-27T00:00:00Z or 16/05/2012 18:31:37(optional).
timestamp_msectime and date as a UNIX timestamp, milliseconds since 1970.
speed_mpsindicates the speed in meters per second (optional).
speed_mphreflects the speed in miles per hour (optional)
speed_kmhindicates the speed in kilometers per hour (optional).
headingindicates the heading in degrees clockwise from North (optional).
elevationindicates the height above the WGS84 ellipsoid in meters (optional).
GPX: Each trace point can have the following information:
Coordinates, for example
<trkpt lat="48.0289225" lon="-4.298227">(always present), WGS84 degree
Timestamp, for example
<time>2013-07-15T10:24:52Z</time>(optional), time zone UTC
Elevation, for example
<ele>102.5999</ele>(optional), meter above the WGS84 ellipsoid
HDOP, for example
Speed, for example
<extensions><speed>21.9432334</speed></extensions>(optional), meter per second
NMEA: The information from the $GPRMC records is used. If an NMEA trace does not contain $GPRMC records, then the $GPGGA records are used.
<LineStrings> can be submitted. Folders with multiple traces are not supported.
The demo provides an example for each format.
In order to get a response without timeouts, trace sizes should not exceed 100,000 points or 15,000 kilometers.
GPS receivers roughly generate one GPS position per second. However, due to mobile network bandwidth and/or cost limitations or processing capability limitations, this density is not always available. Route Matching is designed to work with trace densities between one per second up to one every few minutes.
The match quality is in general better for high trace point density. The bigger the gaps between any two trace points, the higher the risk that the assumed route in between them does not correspond to reality, and also the heuristic distinction between small detours actually driven versus just GPS coordinate outliers or shifts is more difficult.
Usually a GPS point every 10 seconds or every few 100 meters is sufficient to determine the driven path. Too high density increases the network load and the effort on HERE side without enhancing the match accuracy. However, for some advanced features like Stop Violation Detection, Cornering or Inappropriate Accelerating / Breaking, one point per second ensures good results.
More link attributes, such as speed limit or slope, can be retrieved directly in the response. This is an alternative to calling Map Attributes API along the route, for select use cases. Use request parameter
&attributes=... list of Map Attributes API layers and attributes out of each layer ...
When to retrieve attributes directly in the route match call and when to fetch them afterwards from Map Attributes API?
In general, a matched route spans a few Map Attributes API tiles only, because the major part of a route is on functional class 1 roads (motorways) that are stored in Map Attributes API layers with large tiles. Hence, after a route match, the distinct set of tiles to load from Map Attributes API should rarely exceed 20 or 30, resulting in a few Map Attributes API requests, because each Map Attributes API request can ask for multiple tiles of multiple layers. The advantage of using Map Attributes API is that the retrieved full tile content can be cached for up to a month, and hence repeated transmission is avoided, if the assets are repeatedly driving in similar areas, which is usually the case.
However, asking for the attributes directly in the route match request is easier on client side, and only the data of the links along the route are actually transferred. Where this is important, attributes should be fetched directly with the route match call.
Note: When using the more attributes option additional transactions are counted similarly as if requested directly from Map Attributes.
Currently, the following layers can be requested:
ADAS_ATTRIB_FCn BASIC_HEIGHT_FCn DISTANCE_MARKERS_FCn LANE_FCn LINK_FCn LINK_ATTRIBUTE_FCn LINK_ATTRIBUTE2_FCn LINK_TMC_FCn ROAD_ADMIN_FCn ROAD_GEOM_FCn ROAD_NAME_FCn ROAD_ROUGHNESS_FCn ROUNDABOUT_FCn SPEED_LIMITS_FCn SPEED_LIMITS_COND_FCn SPEED_LIMITS_VAR_FCn TOLL_BOOTH_FCn TOLL_LINK_FCn TRAFFIC_PATTERN_FCn TRAFFIC_SIGN_FCn TRUCK_SPEED_LIMITS_FCn TRUCK_RESTR_FCn TURN_RESTR_FCn
Route Matching can also be used for (almost) real-time use cases, where short traces from vehicles are matched and feedback during the journey is provided (driver alerts), or the journey is influenced (re-routing). Matching a trace that contains the latest few hundred driven meters provides better match results than matching isolated coordinates. For sensitive matches (alerts or rating penalties), disregard the end of the trace (last points) sent to Route Matching, because they lack future points for sufficient match quality.