Matching GPS Traces

Fleet Telematics API's calculateroute.json resource can compute the (most probable) route through a driven GPS trace. It is very similar to a route calculation, but not each waypoint has to be reached accurately. Instead, the typical GPS inaccuracies are taken into account.

Driving Analytics Support

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:

  • Point/link match confidence values help deciding whether this point/link can be used for individual risk/legal assessment or only for statistical analysis (like motorway kilometers versus urban kilometers) or not at all (due to poor GPS signal).
  • Warnings for illegal driving maneuvers: One way, no access for vehicle type, illegal turn, illegal u-turn, weight/height/width/length/hazmat restrictions violated, gate traversal, no through traffic, deliveries only, environmental zones.
  • Truck driver legal rest time violations
  • Real time traffic situation at the time of driving (request traffic archive layer)
  • Any HERE map attributes can be included in response: Speed limit, curve radius, slope, height, traffic signs, urban, controlled access, ramp, number of lanes, road roughness, traffic pattern …

Following infos can be requested by parameter &drivingReport=1 :

  • Exact speed limits (date/time/vehicle dependent) for speeding detection
  • Curve speeds (lateral force) for cornering detection
  • Stop sign violations
  • Accelerations / breaking (driving aggresively or in traffic) for risk assessment
  • Light conditions (horizontal and vertical sun angle towards driver) for risk assessment
  • Local weather conditions (at the time of driving) for risk assessment (request weather archive layer) [please contact your account executive for weather archive premium pricing]

GPS Position Accuracy

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.

HERE Route Matching v8 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, HERE Route Matching v8 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, HERE Route Matching v8 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.

Map Detail

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.

Route Gaps and Ignored Trace Points

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. HERE Route Matching v8 ignores them 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 HERE Route Matching v8 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 HERE Route Matching v8 ignores them when creating the route path, as described above. If it leads to gaps on an otherwise reasonably matched road path, then HERE Route Matching v8 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 HERE Route Matching v8 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.

Trace File Formats

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:

    • latitude and longitude are the geographic coordinates in WGS84 degree (mandatory).
    • timestamp indicates the time and date, for example 2012-05-27T00:00:00Z or 16/05/2012 18:31:37(optional).
    • timestamp_msec time and date as a UNIX timestamp, milliseconds since 1970.
    • speed_mps indicates the speed in meters per second (optional).
    • speed_mph reflects the speed in miles per hour (optional)
    • speed_kmh indicates the speed in kilometers per hour (optional).
    • heading indicates the heading in degrees clockwise from North (optional).
    • elevation indicates 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 <hdop>15.0</hdop> (optional)
    • 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.

  • KML: Either <Placemarks> with <Points> or <Placemarks> with <LineStrings> can be submitted. Folders with multiple traces are not supported.

  • GeoJSON: {"type":"Feature","properties":{"timestamp_msec":1566314114000,"heading":141.0,"speed_mps":16.64},"geometry":{"type":"Point","coordinates":[8.53956,50.15789]}}

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.

Trace Point Density

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. HERE Route Matching v8 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.

More link attributes, like speed limit or slope, can be retrieved directly in the response. This is an alternative to calling Fleet Telematics API along the route, for select use cases. Use request parameter &attributes=... list of Fleet Telematics 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 Fleet Telematics API?

In general, a matched route spans a few Fleet Telematics API tiles only, because the major part of a route is on functional class 1 roads (motorways) that are stored in Fleet Telematics API layers with large tiles. Hence, after a route match, the distinct set of tiles to load from Fleet Telematics API should rarely exceed 20 or 30, resulting in a few Fleet Telematics API requests, because each Fleet Telematics API request can ask for multiple tiles of multiple layers. The advantage of using Fleet Telematics 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.

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

Real-Time Use Cases

HERE Route Matching v8 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 HERE Route Matching v8, because they lack future points for sufficient match quality.

results matching ""

    No results matching ""