Unable to apply "ors.endpoints.matrix.maximum_routes"

[senaria]

Hi guys,

I have successfully set up my own version of open route service with VROOM. I tweak the configs and was able to build the graphs as I needed it with my custom pbf file.

Now while testing I recognized that I ran into an issue where the server reports “Request parameters exceed the server configuration limits. Only a total of 2500 routes are allowed.” when trying to solve optimization problems.

Now I look through the docs and found this option “ors.endpoints.matrix.maximum_routes”. Which I adjusted accordingly. But it seems that this config is not applied and I do not get why. Neither setting it to 10 nor to 100000 will have an effect.

My config is the following

ors:
  endpoints:
    matrix:
      enabled: true
      maximum_routes: 20000
      maximum_search_radius: 10000
      maximum_routes_flexible: 100
      maximum_visited_nodes: 300000
      u_turn_cost: 0
    routing:
      maximum_alternative_routes: 0
  engine:
    init_threads: 2048
    preparation_mode: false
    elevation:
      data_access: MMAP
      provider: gmted
    graphs_data_access: MMAP
    source_file: files/base.osm.pbf
    profiles:
      car:
        execution:
          method:
            astar:
              approximation: BeelineAccurate
              epsilon: 0.7
            lm:
              active_landmarks: 8
            core:
              active_landmarks: 6
        force_turn_costs: false
        location_index_search_iterations: 10
        location_index_resolution: 500
        maximum_distance: 2000000
        maximum_distance_dynamic_weights: 2000000
        maximum_distance_avoid_areas: 2000000
        maximum_snapping_radius: 5000
        maximum_way_points: 300
        optimize: true
        elevation: true
        elevation_smoothing: true
        enabled: true
        preparation:
          min_network_size: 350
          methods:
            ch:
              enabled: true
              threads: 512
              weightings: fastest
            lm:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 16
            core:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 32
              lmsets: highways;allow_all
      bike-regular:
        execution:
          method:
            astar:
              approximation: BeelineAccurate
            lm:
              active_landmarks: 8
            core:
              active_landmarks: 6
        force_turn_costs: false
        location_index_search_iterations: 10
        location_index_resolution: 500
        maximum_distance: 2000000
        maximum_distance_dynamic_weights: 2000000
        maximum_distance_avoid_areas: 2000000
        maximum_snapping_radius: 5000
        maximum_way_points: 300
        optimize: true
        elevation: true
        elevation_smoothing: true
        enabled: true
        encoder_options:
          consider_elevation: true
        preparation:
          min_network_size: 350
          methods:
            ch:
              enabled: true
              threads: 512
              weightings: fastest
            lm:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 16
            core:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 32
              lmsets: highways;allow_all
      hgv:
        execution:
          method:
            astar:
              approximation: BeelineAccurate
              epsilon: 0.7
            lm:
              active_landmarks: 8
            core:
              active_landmarks: 6
        force_turn_costs: false
        location_index_search_iterations: 10
        location_index_resolution: 500
        maximum_distance: 2000000
        maximum_distance_dynamic_weights: 2000000
        maximum_distance_avoid_areas: 2000000
        maximum_snapping_radius: 5000
        maximum_way_points: 300
        optimize: true
        elevation: true
        elevation_smoothing: true
        enabled: true
        preparation:
          min_network_size: 350
          methods:
            ch:
              enabled: true
              threads: 512
              weightings: fastest
            lm:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 16
            core:
              enabled: true
              threads: 512
              weightings: fastest,shortest
              landmarks: 32
              lmsets: highways;allow_all

I am running “openrouteservice/openrouteservice:v8.2.0” via docker.

I would really appreciate some help here.

[amandus]

Hi @senaria,

it seems you don’t pass your config properly. How are you running and configuring your ors docker?
By default you would need to adjust ./ors-docker/config/ors-config.yml.
If you set maximum_routes to 2
the following should fail

curl --location 'http://localhost:8080/ors/v2/matrix/driving-car/json' \
--header 'Content-Type: application/json; charset=utf-8' \
--header 'Accept: application/json' \
--header 'Authorization: ••••••' \
--data '{
  "locations": [[8.675315, 49.423104], [8.675315, 49.423204000000005], [8.675315, 49.423304], [8.675315, 49.423404000000005], [8.675315, 49.423504], [8.675315, 49.423604000000005], [8.675315, 49.423704]],
  "id": "my_request",
  "sources": [
    0,1,2,3
  ],
  "destinations": [
    "all"
  ],
  "metrics": [
    "duration"
  ],
  "resolve_locations": false,
  "units": "m"
}'

If you increase the route limit, you will also need to increase visited nodes.

Best regards

[senaria]

Hi @amandus,

thanks upfront for the fast reply.

Not sure where to find the ./ors-docker/config/ors-config.yml.
Do you refer to /home/ors with ./? Even then, inside the docker container there is the config under /home/ors/config/ors-config.yml which is also generate if not available by the app at startup with basics.

My config is the one I posted above. And I am to 100% sure its read. Since if I change the source_file or any of the threads the changes are applied.
E.g. source_file not found error or for the threads the change is visible in the logs. The profiles seem to be also applied properly.

What I can say is that setting ORS_ENDPOINTS_MATRIX_MAXIMUM_ROUTES as environment variable seem to be respected.

Let me know if you need any further information.

Best regards

[amandus]

if you run with docker compose, /home/ors/ inside the container is mounted to ./ors-docker where you run the compose command (so usually the folder where the docker-compose.yml is). So if you change the config file there, it will be reflected after a restart.

It seems strange that some parts of the config are respected and others not.
And the config entry for ‘maximum_routes’ should be correct.
How did you evaluate if the limit is respected?

If i use your config, with the normal pbf file it properly respects the 20.000 limit…

[senaria]

How did you evaluate if the limit is respected?

I have a deployed version with VROOM where I can easily run problems to solve against.
One of these is contains 174 locations split on 14 agents. With that I always ran into the error above. Changes to the matrix endpoint in the ors-config.yml config had no influence.

Then after setting the env variable for this specific setting seemed to change something since it then worked.

if you run with docker compose, /home/ors/ inside the container is mounted to ./ors-docker where you run the compose command

Ok got it. Was just confused in the first place. I tried that now locally with the same graphs etc as on my deployment and it works. No clue why this did not worked on my deployed server, since I am pretty sure its the same file locations etc. But maybe something is then wrong configured there.

Thanks for your help @amandus. I will try that later on remote then again.