Map matching in own server has many gaps

[jbfondo]

Hi, I recently (last week) did an extract with version 5.18.0 I noticed that I can not do a map matching in some roads, the system is not able to find many points to match causing a gap in the result. It detects outliers in the middle of a highway.

I did some test in DEMO machine and I found some differences in the results. For example: https://router.project-osrm.org/match/v1/driving/-103.2143,20.5750;-103.2162,20.5769;-103.21699,20.58145;-103.21918,20.58829;-103.2199,20.5949?overview=full

Returns good data on DEMO, but the same query on my system returns: {"message":"Could not match the trace.","code":"NoMatch"}

What can be the reason for this discrepancy? Thank you a lot.

[chaupow]

Hi @jbfondo ! I just tried your request on our setup and it seems to find a route with 95% quality. Is this the route you're looking for?

The way map-matching works is that OSRM uses the routable graph with it's edge weights and calculates a path that is most likable to represent the coordinate trace.

As it is using the routable graph, that means

• if a road is not routable, it cannot be map matched. it won't map match against a one-way directions or on a foot path that is not accessible
• it is taking in account the speed values to calculate the likelyhood of matching

If your results look different from the demo route it could be

• that you are using a customized car profile that filters out a road
• the demo router finds routes different from yours because the demo router is being updated with traffic speed profiles (that are not open source) and that change the edge weights

If you want to debug the speed values of your machine, you can use the debug tiles to visualize your graph.

I hope this helps. If this solves your problem, can you close this issue? 🙂

[jbfondo]

I just tried your request on our setup and it seems to find a route with 95% quality. Is this the route you're looking for?

Yes, it is. Or any other route that passes on this highway.

* if a road is not routable, it cannot be map matched. it won't map match against a one-way directions or on a foot path that is not accessible

As you can check, this road is perfectly routable... in your machine :-)

* it is taking in account the speed values to calculate the likelyhood of matching

That sounds a bit weird. I am doing a map-matching, snapping my points to the nearest road. I can not see the relation between speed and matching.

If your results look different from the demo route it could be

* that you are using a customized car profile that filters out a road

No. I am using the default car profile.

* the demo router finds routes different from yours  because the demo router is being updated with traffic speed profiles (that are not open source) and that change the edge weights

As I write before, can not see the relation using matching service. If I were using the route service I would understand it.

The problem I spotted is that using my machine I get the message "Could not match the trace."

[qwertyabcxyz]

That sounds a bit weird. I am doing a map-matching, snapping my points to the nearest road. I can not see the relation between speed and matching.

OSRM needs the speed to calculate better probabilities: Imagine there are two roads running closely in parallel, one is a fast main road, the other a slow residential. If you mapmatch a trace and the trace is sometimes closer to one road or another (eg because of gps inaccuracy) it is not obvious to which road to map. In such a case: If you provided timestamps, the timestamps are used to match to speed values and the faster or slower road is being picked. If you don't provide timestamps (as in your case) I am not sure how exactly (or whether) it is taking into account but I strongly believe it does. You would have to check it in the code. The code knows the truth.

The problem I spotted is that using my machine I get the message "Could not match the trace."

Open-source maintainers are limited in time to debug all problems. It is also nearly impossible if we do not know your setup or input data.

I tried to reproduce this locally

• vanilla osrm-backend 5.18.0
• mexico.osm.pbf from geofabrik
• vanilla car.lua profile
• ran osrm-partition, osrm-customize and osrm-routed --algorithm=MLD mexico.osrm

and I can confirm that mapmatching does not return a route but routing from the trace's start- to endpoint also does not return the route that you're trying to match /route/v1/driving/-103.2143,20.5750;-103.2199,20.5949?overview=full:

As you can check, this road is perfectly routable... in your machine :-)

So no, this is not perfectly routable. You should check whether it is routable on your machine. If it is not, it is either a data problem or a profile bug.

If it is a data problem, an accidentally disconnected road might be the problem. I'm sure OSM would be thankful about a fix. If it is a profile problem, please report here again.

[jbfondo]

@qwertyabcxyz and @chaupow Thank you for your answers.

I did not connect in my head the concept timestamp with the concept speed. In this case I tested also with timestamps and have similar results (similar, not equal).

I tried to reproduce this locally

* vanilla osrm-backend 5.18.0

* mexico.osm.pbf from geofabrik

* vanilla `car.lua` profile

* ran `osrm-partition`, `osrm-customize` and `osrm-routed --algorithm=MLD mexico.osrm`

and I can confirm that mapmatching does not return a route but routing from the trace's start- to endpoint also does not return the route that you're trying to match /route/v1/driving/-103.2143,20.5750;-103.2199,20.5949?overview=full:

That is EXACTLY my problem, I did the same steps with México and planet-latest files. I can not find a match or a route that goes by this road (and some others). BUT, curiously if you do the route in the other direction (from north to south) there are no problem (I know that they are different roads or different nodes in OSM data, one road for each direction).

So no, this is not perfectly routable. You should check whether it is routable on your machine. If it is not, it is either a data problem or a profile bug.

If it is a data problem, an accidentally disconnected road might be the problem. I'm sure OSM would be thankful about a fix. If it is a profile problem, please report here again.

Well, on my machine I can not use this road. I always suspected that there are a problem in OSM, but the original question is why in the OSRM demo machine it runs ok? It uses the same data set (obviating the traffic layer).. or not?

I check the OSM data and I could see that highway (node: 215094322) and the nodes that intersects with adjacent ways. Maybe can be a problem with the pbf file that I downloaded? I tested several files, México, planet-latest... honestly, I am lost.

I don't know how to test if car profile have the problem or not.

[jbfondo]

Oh, by the way, I tested this issue with a Valhalla machine and get the same results or similar. That make me suspect more on a hole in OSM data. What is your opinion?