Distance Matrix, Isochrone do not use custom maxspeed values

openrouteservice
1

Hello,

we’re trying to create our own openrouteservice instance where we’d like to to have control on the route duration as the ones based a raw openstreetmap extract do not satisfy us.

To do that, we modify the maxspeed tag on ways in the pbf but it seems the values we are putting are not being used.

For this test, we have 2 running openrouteservice instance running on 2 different pbf, each having different sets of maxspeed applied, we’ll call them v9 and v12. We chose a starting and an end point at the start and end point of 1 way (w31159325)

start point coordinates are 2.5729919, 48.9909281 and end point coordinates are 2.5468596, 48.9900683.

the 2 pbf have differing maxspeed for this way :

$ osmium getid france-custom-v9.osm.pbf w31159325 -f xml| grep maxspeed
    <tag k="maxspeed" v="17.34"/>

$ osmium getid france-custom-v12.osm.pbf w31159325 -f xml| grep maxspeed
    <tag k="maxspeed" v="4.55175"/>

However, when asking a matrix between those two points, duration is the same : 117.4 even if maxspeed is different

With the 4.5 maxspeed :

curl -X POST http://192.168.50.121:9000/ors/v2/matrix/driving-car -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' -d '{"locations":[[2.5729919,48.9909281],[2.5468596,48.9900683]],"destinations":[1],"sources":[0],"metrics":["distance","duration"]}'
...
{
    "durations": [
        [
            117.4
        ]
    ],
    "distances": [
        [
            1956.78
        ]
    ],

...

With the 17 maxspeed :

curl -X POST http://192.168.50.121:9009/ors/v2/matrix/driving-car -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' -d '{"locations":[[2.5729919,48.9909281],[2.5468596,48.9900683]],"destinations":[1],"sources":[0],"metrics":["distance","duration"]}'
...
{
    "durations": [
        [
            117.4
        ]
    ],
    "distances": [
        [
            1956.78
        ]
    ],
....

When asking directions between these two points, the distance, duration, and instructions are the same although they should be different.

Is there anything beside the maxspeed tag we should consider ? Is there anything I should look at ?

I have extracted that segment from the pbf files and can give more details if anyone needs it.

2

Hey,

I cannot confirm this issue.
I tried to reproduce it using the ile-de-france-latest.osm.pbf OSM excerpt, changing the maxspeed of the way as you did.
However, I am getting the following response:

curl -X POST http://localhost:8082/ors/v2/matrix/driving-car -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' -d '{"locations":[[2.5729919,48.9909281],[2.5468596,48.9900683]],"destinations":[1],"sources":[0],"metrics":["distance","duration"]}'
...
{
  "distances" : [
      [
         1956.78
      ]
   ],
   "durations" : [
      [
         704.44
      ]
   ],
...

I also noticed that your response is exactly the one you’ll get from our API, using the “default” OSM maxspeed on this way.

This leads me to believe that your graphs haven’t been built with your modified osm file.
If given a valid folder in the config option services.routing.profiles.default-params.graphs_root_path, ors will read the graphs from that folder no matter what pbf has been configured.

Move or delete your graphs-folder and rebuild the ors. You should see it taking way longer to load and probably also some build output.

Best regards

3

thanks for that input; I’ll try that and update.

1 Like
4

Hi,

I’ve deleted both graphs/ directory (for both services), restarted the services with BUILD_GRAPHS=True (which was already set this way), both services took a long time to rebuild the graphs and I have the same response from both services 117 sec and 1956m.

I’ve checked one more time, both services are pointing to their respective pbf files and both have a different maxspeed the way id=31159325.

When I ask for directions between those two points, the OsmId used is 31159325, I am at loss now.

Is there anything else I could check or do ?

Could the surface tag coupled with the highway value play a role ?

$ osmium getid segment-v12.pbf w31159325 -f xml| grep tag
    <tag k="ref" v="D 88"/>
    <tag k="surface" v="asphalt"/>
    <tag k="name" v="Route Périphérique Sud"/>
    <tag k="lanes" v="2"/>
    <tag k="maxspeed" v="4.55175"/>
    <tag k="highway" v="secondary"/>
5

hi @mdesile,

could you maybe provide your ors-config.json and docker-compose.yml you are using?

6

V9, with the 17 maxspeed docker-compose.yml, ors-config.json

7

v12, with the 4.5 maxspeed docker-compose.yml, ors-config.json

Each service is started from a different directory, each containing their docker-compose.yml and conf/, graphs/, … directories

8

Hey,

I am a bit confused by this, since it worked on my machine without any issues. I am building from source, though, and not using docker, which adds an additional layer of misdirection

I’d recommend actually checking the .pbf inside of the container, whether it is what you expect (hoping that osmium is available for install within the container)
Do the same for the config file.

If that is correct, delete and rebuild the graphs inside of the container - stopping catalina, rebuilding via mvn package and restarting should do it. check the Dockerfile for the respective commands.

Best regards

9

Hello,

I am at loss now.

I started a shell into the docker instance, I stopped catalina, I erased the graph and restarted catalina, the graph was rebuilt and it still says the duration is 117 sec.

I checked the pbf file inside the container and it is the one with 4.5 maxspeed :

# docker exec  c4a209a5794b cat data/osm_file.pbf | osmium getid -F pbf - w31159325 -f xml | grep maxspeed
    <tag k="maxspeed" v="4.55175"/>

Does the directions call takes maxspeed into account ?

this is how I call it :

curl -X POST   'http://192.168.50.121:9000/ors/v2/directions/driving-car'  \
    -H 'Content-Type: application/json; charset=utf-8'\
   -H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8'\
   -d '{"coordinates":[[2.5729919,48.9909281],[2.5468596,48.9900683]],"extra_info":["osmid"],"attributes":["avgspeed"]}' | python -m json.tool

and this is the response I get.

For reference, the segment is like this :

# cat /tmp/w31159325.xml
<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.13.1">
  <bounds minlat="-90" minlon="-180" maxlat="90" maxlon="180"/>
  <way id="31159325" version="26" timestamp="2020-12-04T11:19:58Z">
    <nd ref="344960832"/>
    ...
    <nd ref="344960845"/>
    <tag k="disabled_surface" v="asphalt"/>
    <tag k="ref" v="D 88"/>
    <tag k="name" v="Route Périphérique Sud"/>
    <tag k="lanes" v="2"/>
    <tag k="maxspeed" v="4.55175"/>
    <tag k="highway" v="secondary"/>
  </way>
</osm>
10

Hi all,

It seems I found a cause for the problem we are encountering.

I did a test pbf where all ways have the maxspeed tag set to ‘10’ and when I asked directions on a motorway, the average speed was 10km/h.

I then set all maxspeed to ‘10.345’, asked the same directions on the motorway and then the average speed was 99.98 km/h, which seems like 0.9 * a default speed value.

Can anyone confirm that setting maxspeed to a float value will cause this behaviour, i.e. not considering float value as valid speed and thus using default maxspeed ?

11

Hey,

interesting find, this might indeed be a bug in the code.
I’m investigating this and will let you know whether I can reproduce it :))

Thanks, and best regards :))

12

thanks a lot for this !

kind regards

13

Hey,

this is indeed due to the strings in the tags being parsed as integers and thus disregarding floats.
I opened an issue for this.

We won’t tackle this now, but in the (not too distant) future.

If you need this functionality now, feel free to follow the steps in the issue yourself - or change your values to integers^^

Best regards

14

Thanks a lot for taking care of the issue and suggesting a solution.

I’ll try to implement it and build a working ors.war. If I can not, I’ll revert to using integer approximation.

Thanks a lot for your time and effort,

Cheers !