What are the gpxExtensions in EdgeMatch?

Open Source Routing Engine Map Matching
1

I’m looking to extend the Map Matching module with some methods from the literature. I’d like to do this in a way that can integrate nicely with the existing graphhopper API and perhaps eventually submit a pull request to the map matching repository with the new algorithms.

Anyway, I thought I’d start by deconstructing the map matching algorithm that exists already. I am somewhat stumped by the gpxExtensions in EdgeMatch. I have examined the usages and they don’t really seem to be used much. So I’d like to know what purpose do they serve - what are they for?

I have visualised them next to the map-matching result in my application. They are seemingly an alternate match?

map_match_gpx_extensions.jpg1001×835 177 KB

You can see the matched route in red (with the matched nodes in orange). The green dots are the gpxExtensions that the algorithm has stored for each matched node.

1 Like
2

That would be highly appreciated :slight_smile: ! The current method is roughly working and fast, but not that optimal and a method with higher quality (and potentially slower) would be very nice for many use cases.

I am somewhat stumped by the gpxExtensions in EdgeMatch.

It has two purposes:

  • Every edge can have multiple locations snapped on and the GPXExtension wraps the GPXEntry as well as the corresponding QueryResult.
  • As a final process only the entries with the correct order of the gpxListIndex will be picked (previously all matches are stored)

Maybe we should avoid this mixture of purpose, but we cannot avoid that multiple matches happen per edge. An often requirement is that users want not only the resulting path but can associate their original points to the matched ones, e.g. to associate OSM tags like maxspeed and determine speed violations