Unable to find a route between points

openrouteservice directions
1

Hi all,

I am new here; hello everyone :wave:

Since a few days I am running my own instance of OpenRouteService (9.0.0) with the latest Europe map from Geofabrik (sized down to a single state for better debugging).

A lot of hgv routes (only this one profile is enabled) run smoothly but on some routes I can’t get any route between the points, e.g. for 7.5723050,51.5253400 and 8.3234420,51.8617630 (where the starting point is causing the problem).

With a get request (also tried post) of

http:// my-ors-server :8082/ors/v2/directions/driving-hgv?start=7.5723050,51.5253400&end=7.57726,51.52766

I get this error response:

{
    "error": {
        "code": 2009,
        "message": "Route could not be found - Unable to find a route between points 1 (7.5723050 51.5253400) and 2 (7.5772600 51.5276600)."
    },
    "info": {
        "engine": {
            "build_date": "2024-12-02T11:15:16Z",
            "graph_version": "1",
            "version": "9.0.0"
        },
        "timestamp": 1734534186780
    }
}

When using the playground with exact the same coordinates via

https://api.openrouteservice.org/v2/directions/driving-car?api_key=xxx&start=7.5723050,51.5253400&end=7.57726,51.52766

I do get a proper answer.

I have played around with really a lot of things (including several config changes and recalculations of graphs) but I don’t find the issue :pensive:

My ors-config.yml right now looks like this (but I also tried with all the standards setting):

logging:
  file:
    name: /home/ssm-user/ors/app/logs-9.0.0/ors.log
ors:
  endpoints:
    routing:
      enabled: true
      maximum_alternative_routes: 3
    matrix:
      maximum_routes: 10000000
      maximum_visited_nodes: 100000000
      maximum_search_radius: 3000
  engine:
    elevation:
      cache_path: /home/ssm-user/ors/app/elevation_cache-9.0.0
    profile_default:
      graph_path: /home/ssm-user/ors/app/graphs-9.0.0
      build:
        source_file: /home/ssm-user/ors/map/nordrhein-westfalen-latest.osm.pbf
        preparation:
          methods:
            lm:
              enabled: true
              threads: 4
              weightings: recommended
      service:
        maximum_distance: 9000000
        maximum_waypoints: 2000
        maximum_snapping_radius: 3000
    profiles:
      driving-car:
        enabled: false
      driving-hgv:
        enabled: true
        encoder_name: driving-hgv
        build:
          preparation:
            min_network_size: 200
            methods:
              ch:
                enabled: true
                threads: 4
                weightings: recommended
              lm:
                enabled: true
                threads: 4
                weightings: recommended
              core:
                enabled: true
                threads: 4
                weightings: recommended
                landmarks: 64
        service:
          maximum_distance: 10000000
          maximum_distance_dynamic_weights: 10000000
          maximum_distance_avoid_areas: 100000
          maximum_distance_alternative_routes: 10000000
          maximum_distance_round_trip_routes: 10000000
          maximum_way_points: 2000
          maximum_snapping_radius: 20000
          maximum_visited_nodes: 10000000
          force_turn_costs: false
        interpolate_bridges_and_tunnels: true
      cycling-regular:
        enabled: false
      cycling-mountain:
        enabled: false
      cycling-road:
        enabled: false
      cycling-electric:
        enabled: false
      foot-walking:
        enabled: false
      foot-hiking:
        enabled: false
      wheelchair:
        enabled: false
      public-transport:
        enabled: false

I thought this might be due to a snapping problem, but I can snap the point

http:// my-ors-server :8082/ors/v2/ors/v2/snap/driving-hgv

very well and get this (correct) point back:

{
    "locations": [
        {
            "location": [
                7.572784,
                51.524253
            ],
 ...
   "metadata": {
...
        "query": {
            "locations": [
                [
                    7.572305,
                    51.52534
                ]
            ],
            "profile": "driving-hgv",
            "profileName": "driving-hgv",
            "format": "json",
            "radius": 350.0
...
}

So snapping seems not the be the problem. But even with this snapped coordinates the direction api does not give a valid route back. Same error as above :frowning:

Any ideas on that?
Or is there a way to check against the config of the one of https://api.openrouteservice.org? It seems that a /status request is not valid.

Thanks for your help!

2

Hey,

I’m as of now not quite sure of the why, but your snapping results are a bit weird:

The Snapping result of the first point on your machine is on “Westfälische Straße”, according to your results:

On the live API, it snaps to “Asselner Hellweg”:

  "location" :  [
               7.571556,
               51.526625
             ],

Maybe that helps in further debugging?

What do you mean by

Best regards

3

Hi jschnell,

thanks for your response and the valuable finding with the different streets coming from the snap endpoint.

Indeed, my instance is returning the “Westfälische Straße”.
Overpass Turbo shows that this is a way with a ‘highway = track’ key.

So right now it looks like that the graphs preparation is including ways that are not available for hgv directions. It’s strange, that the directions api seems to snap to this invalid starting point, although the driving-hgv profile is selected.
Maybe I raise this as an issue in Github.

Although I properly read that docs I don’t see any config that explicit allows these keys to be excluded from the graphs. Maybe i could try to exclude these ways via osmosis before the ors preparation.

Querying the

http:// my-ors-server :8082/ors/v2/status

shows some of the current settings of the server. I was hoping to see some configurations from the official server to find out the differrence in the config to my system.

4

Hey,

have a look at the encoder_options config:

maximum_grade_level states:

… a negative value such as maximum_grade_level=-1 entirely disables routing on tracks.

which is exactly the value set in the hgv config on the live API ;))

Best regards

1 Like
5

Awesome, that’s it! Thank you so much :fist_right: :fist_left:

But shouldn’t the snapping and directions be aligned inside the engine anyway? What I mean is that the snapping in the hgv profile snaps to a track that the directions cannot pick up. I would assume that a point is only snapped to a place that the directions can pick up.

Is the a documentation out there, how the live API is configured?

6

Hey,

I agree that they should be and I can’t tell you for sure if they are.
As I see it, the behaviour of the public API and the differences between the public API and your setup make sense.

The open question is:
If your instance snaps to a different point, why can it not route to/from there.

Looking at this a bit more, there might be a few more things at play, namely these two:

The way has a tag vehicle=agricultural, prohibitting routing (compare the tag filtering docs and the node is a barrier=bollard which should also be impassable, as there is no tag permitting access on it.

Thus I could imagine that the ors snaps to the point since it allows routing on the track, but cannot route to or from there, since there is no connecting passable way.

If you want, you can check that by routing on a very small portion of

Did you know that you can use your local backend both as a backend for the API playground and as a backend for the maps-client?

For the playground, switch the API server in the top left and edit it.
For the client, you find the settings in :gear: Settings → Advanced

Best regards

1 Like
7

I did check a small route on the west-side of the barrier=bollard to the east-side. Both the official API as well as mine is taking the exact same route around the barrier as expected :ok_hand:

Thanks for you brilliant support and also for the tips for using the own backend, which a didn’t knew. I have to check about routing localhost to the AWS cloud (where my instance is hosted), but that should be feasible.

I wish you happy xmas days and the best for 2025

2 Likes