GPS trace formats and accuracy

HERE Route Matching v8 can compute the (most probable) route through a driven GPS trace. Typical GPS inaccuracies are taken into account, and arbitrary gaps are handled appropriately.

Most use cases want to enrich the riven trace with HERE map attributes, like speed limits, slope, curvature, motorway / inside city, number of lanes, traffic / weather situation. These can be directly retrieved in the route match response.

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.

Legal routes

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.

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. 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.

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. 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.

Response and more attributes for each route link

For each trace point, its most probable map matched position is returned, along with a confidence value. Even if a trace point is an obvious outlier, it will be matched to logically fit within the matched route. To retrieve map attributes for a matched trace point, the road link/segment id is provided along with the offset along this link/segment.

In addition, a full drivable (not necessary legal or safe) route path without gaps is returned, including link/segment ids, driving direction, driven geometry part of the link, along with a confidence value.

The confidence values allow to filter, depending on the use case, which of the matched positions or the matched road links should be used or skipped/ignored.

While the pure route match response tells the map matched positions and the map road links connecting the route in between the points, any map attributes can be retrieved along the matched route, either directly in the response or via additional Map Attributes API requests. See Map attributes along the route for more information.