Difference in table distance versus "web" distance

[fillipe-gsm]

I found some issues mentioning possible (slight) differences between the table and route services results (like this one), but my question is with respect to the results obtained with the web version.

Consider two sources (in lat, lng formats):

• source 1: (-23.6389477, -46.7166683)
• source 2: (-23.6306127, -46.731617)

and the following destination:

• destination: (-23.63680458, -46.80519867)

When calling the table service

curl "http://localhost:5000/table/v1/driving/-46.71666829999999,-23.6389477;-46.731617,-23.6306127;-46.8051986694336,-23.63680458068848?sources=0;1&destinations=2&annotations=duration,distance"

I get as result

{'code': 'Ok',
 'sources': [{'hint': 'drsggIS7IIA4AAAAmQAAADwAAAAAAAAAJg4eQhfs0kLCeyVCAAAAADgAAACZAAAAPAAAAAAAAADfAgAA4ig3_ZlMl_4EKTf9XEyX_gEA7wPdEgLn',
   'distance': 7.594487,
   'name': 'Rua Leriuçú',
   'location': [-46.716702, -23.638887]},
  {'hint': 'rVgVgN5YFYAAAAAAGgAAAHwAAABeAAAA4k_nPs7mjkFA061C_L2CQgAAAAAaAAAAfAAAAF4AAADfAgAAuu42_QVtl_6f7jb962yX_gcAXwjdEgLn',
   'distance': 3.985294,
   'name': 'Rua Itapecoca',
   'location': [-46.73159, -23.630587]}],
 'destinations': [{'hint': 'A_IUgAryFIAIAAAAKwAAAHgAAABfAAAAtv-2QMtJ7UGzk6ZC_4yDQggAAAArAAAAeAAAAF8AAADfAgAAwc81_ZhUl_4xzzX9u1SX_gMA7wDdEgLn',
   'distance': 15.197282,
   'name': 'Rua Marechal Artur da Costa e Silva',
   'location': [-46.805055, -23.63684]}],
 'durations': [[1104.9], [949.4]],
 'distances': [[11601.8], [11709.9]]}

but when computing these values from the web version (source 1 and source 2) I get the results in the next figure:

In summary:

• Source 1 to destination:
  • Distance: 11601.8 (OSRM) vs 13k (web)
  • Duration: 1104.9 ~ 18 min (OSRM) vs 18 min (web)
• Source 2 to destination:
  • Distance: 11709.9 (OSRM) vs 10k (web)
  • Duration: 949.4 ~ 15 min (OSRM) vs 15 min (web)

So while the durations are basically the same, the distances not only differ in magnitude by more than 1k, but there is a disagreement in which source is actually the closest one to the destination (this is honestly the biggest problem for me).

Do you know the cause of this difference or how I can alleviate it? I found this old issue explaining the problem but it got no updates since then.

For reference, I am using the latest data from Geofabrik and running the server with the mld algorithm.

[mjjbell]

The default OSRM car profile will be different from the one used in the web service. Try processing a local graph with the same profile as the web and see if you still observe discrepancies: https://github.com/fossgis-routing-server/routing-chef/blob/43ad483497b85c883f61bbb27333bfb45b922a4d/cookbooks/osrm/recipes/default.rb#L215

[fillipe-gsm]

Hey, @mjjbell , thanks for the quick answer, but I am not quite sure how to do that.

When processing the osm.pbf file I simply followed the instructions here and used:

docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-extract -p /opt/car.lua /data/berlin-latest.osm.pbf

(but replacing berlin-latest.osm.pbf with my file)

I realize this uses the default profile, but I don't know how to the use the web one. I looked into this doc but I could not find it.

[mjjbell]

Try this to use the web profile (replacing with your file), :

git clone [email protected]:fossgis-routing-server/cbf-routing-profiles.git
cd cbf-routing-profiles && git checkout 4a0ebb9974a806fb9df652ed75b79694aa038f1a && cd ../
docker run -t -v "${PWD}:/data" -v "${PWD}/cbf-routing-profiles:/profile" osrm/osrm-backend osrm-extract -p /profile/car.lua /data/berlin-latest.osm.pbf

The following processing steps remain the same.

[mjjbell]

Just tried this out on sudeste

Local table request

"durations": [
    [
      1082.5
    ],
    [
      928
    ]
  ],
  "distances": [
    [
      13195.5
    ],
    [
      10066.6
    ]
  ]

Web route: Source 1

"distance":13208.6,"duration":1082.7

Web route: Source 2

"distance":10053.2,"duration":918.2

So this looks pretty good now, probably within the expected level of accuracy given OSM changes and #5316

[fillipe-gsm]

@mjjbell, thank you a lot for your time and help.

It turns out that my osm.pdf file was from last month, and with the update from 18 hours ago I got the same results as your last comment, regardless of the car profile.

This last point is interesting: by using

# Forcing the 4a0ebb9974a806fb9df652ed75b79694aa038f1a commit in the `cbf-routing-profiles` repo
docker run -t -v "${PWD}:/data" -v "${PWD}/cbf-routing-profiles:/profile" osrm/osrm-backend osrm-extract -p /profile/car.lua /data/sudeste-latest.osm.pbf

or

# Using the default car.profile
docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-extract -p /opt/car.lua /data/sudeste-latest.osm.pbf

I actually got the same results as long as the data files were the latest.

I am going to close this issue then. Thank you again.

[datendelphin]

yes the car profile is actually pretty close. foot and cycle differ more I think