Skip to content

Map Matching

Process

The map-matching process is currently started and managed manually. To have a collection map-matched or update the trips that have been map-matched, please contact Neal Feierabend or submit a ticket.

GPS data is pulled from DB2 sensor data tables, and run against a map-matching algorithm provided by Valhalla, an open-source project which uses OpenStreetMap (OSM) for its map data. The results are then loaded into a PostgreSQL database for querying by researchers and analysts. The code for this process can be found in this GitLab repo.

Accessing map-matched results

Currently, map-matched results are available in a PostgreSQL database: postgres-osm.vtti.vt.edu. Contact Neal Feierabend to get access to the database. Note that you will need to be a member of an Active Directory group associated with the project before access can be granted; ask the PI of the project to add you to one of these groups.

To get connected to the Postgres database, use the following connection settings:

  • Host: postgres-osm.vtti.vt.edu
  • Database: osm
  • SSL/TLS: require
  • Username: Your Active Directory (Windows) username
  • Password: Your Active Directory (Windows) password

Once connected, you'll see a number of schemas within the osm database, including ones associated with the project you want to access. Within that schema you should find the following:

Materialized Views (most commonly used):

  • trips_with_attributes - This is a materialized view that joins the edges and points table into a more useable and performant form. It essentially provides the edges table with all of the attributes about the road segment

Tables:

  • edges - The edges output from Valhalla with the VTTI file_id. This provides the individual "road segments" and associated attributes as determined by Valhalla, based on the data in OSM.
  • points - The matched points output from Valhalla along with the original lat, lon, VTTI timestamp, and file_id. These are the points that were snapped to the road segment Valhalla matched.
  • shapes - The "shape" output from Valhalla. This is a simplified, polyline encoded representation of the map-matched path returned by Valhalla. It should really only be used for high-level maps that don't need any road attribute data associated with them.

Doing your own map-matching with Valhalla

The Valhalla service is running on our on-prem Kubernetes cluster, providing a REST endpoint to send GPS traces that will return edges and points from the matched OSM road network. Valhalla also provides a number of other routing related capabilities. It can be accessed at https://valhalla-united-states.main.cloud.vtti.vt.edu/ from anywhere on VT's network.

Some things to note about the trace_attibutes endpoint, the one used for map-matching:

  • The POST request to the /trace_attributes endpoint is limited in size to 16k; more than that and the service will return an error. The standard pipeline process truncates GPS points to 6 decimals (as that is what Valhalla will use anyway) and then removes duplicates to keep it under 16k points. For trips that exceed that size limit, it splits the trip into multiple requests and then combines them back together before inserting into the database. This does not work for the polyline encoded shape, which is left null.
  • The /trace_attributes endpoint is supposed to return a matched_points field that has edge_index values that match to values returned in the edges field. However, there is a bug that causes some of these values to be the max int value instead of the actual edge_index. This can be fixed by looking at whether the distance_along_edge value is >= the previous row's value, in which case it is still the same edge_index, or whether it has reset and is < than the previous row's value, in which case it is now on the next edge_index. See the code in the data pipeline for an example of how this can be done.