New Maps Client Route Truck over Mountain Pass

[MoltenLight]

I’m using the new maps client, and am trying to compare route times and lengths.
In my test case, there is the long way around on highways, or the short way over a mountain road. The client will let me route a bike over the mountain road, but not a vehicle, even though I know for a fact that the road is passible.

I have tried the example on the openrouteservice.
I have downloaded the ors-map-client, and done: npm run dev
Both bring up the GUI, but does not let me route properly.

I was recently told:
“The client is responsible for sending the parameters/filters according to what is supported by ORS API. In this case, the restriction is related to the routing engine (our API) and not the client. So I guess you would have to run a local instance of our back-end/API in order to achieve your purpose”

I have the local server installed and running, and am able to perform a ‘distance’ request.
However, I have been unsuccessful in connecting the maps client to the local server.

I would appreciate direction on the missing piece.
Thanks

[amoncaldas]

@MoltenLight

To connect the maps client to the local server you are running, you have two options:
1 - Change the apiBaseUrl in the src/config/default-map-settings.js to your local address (e.g.: http://localhost:port) and run the client.

2 - Change the endpoints via maps client interface in advanced section of the client settings (go to your local maps client, like http://localhost:8080/#/settings) change the API base URL and save it. This will save this option in your browser storage. So, it will be valid only for this browser.

[MoltenLight]

Thanks for the info.
I think I still have a configuration issue:

So if understood correctly, I execute the ‘npm run dev’ command, and connect the maps client to it (http://localhost:8090/#/) (I changed the port )
And “apiBaseUrl” gets pointed to https://localhost:8095 (I changed the port when I built it)

Issue:
If apiBaseUrl points to: https//api.openrouteservice.org I am able to create a route.
if apiBaseUrl points to: https://localhost:8095, I get the error:
“It was not possible to find a route connecting the places with the selected profile and filters”

I found “base_url” in …/openrouteservice-js/conf/app.config and changed it to: https://localhost:8095/ and rebuilt and restarted the Docker container, but it had no affect.

Furthermore, if I stop the Docker container for my server, it has no affect on the above issue.
Also, if I connect a browser to http://localhost:8095/#/
I get an Apache Tomcat screen telling me “If you’re seeing this, you’ve successfully installed Tomcat. Congratulations!”

Here is my ORS Server build command:

set pwd=C:\Project\openrouteservice-js
docker run -dt ^
  --name ors-map-server-8095D ^
  -p 8095:8080 ^
  -v %pwd%/graphs:/ProgramData/Docker/ors-core/data/graphs ^
  -v %pwd%/elevation_cache:/ProgramData/Docker/ors-core/data/elevation_cache ^
  -v %pwd%/conf:/ProgramData/Docker/ors-conf ^
  -v %pwd%/us-west-latest.osm.pbf:/ProgramData/Docker/ors-core/data/osm_file.pbf ^
  -e "JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g" ^
  -e "CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost" ^
  openrouteservice/openrouteservice:latest

I obviously have something incorrect…

[MoltenLight]

I’m making no headway… would appreciate any ideas.
Thanks

[amoncaldas]

Hey @MoltenLight

Considering that the maps client and the back-end are distinct pieces of software, they are expected to work independently one from another. If you are facing some issue, I recommend you to run the back-end and try to consume the API (provided by your local running instance) via command line, like cURL or via postman. If you can consume the services, then we can go to the step of connecting it to the web client. If not, then the issue is related to the local instance you’re running and not to the connection between the client and the back-end.

[MoltenLight]

amoncaldas

I really appreciate your guidance. I’m new to Web development, so the learning curve is steep, and I don’t always understand the references. And no experience with cURL. That said…

I performed a: curl localhost:8095 and got back a lot of HTML code,
which I’m sure matches the Tomcat webpage I mentioned earlier.

I performed a: curl localhost:8095/ors and got back a blank line

I performed a: curl localhost:8095/ors/health and got back: {“status”:“ready”}

I have been unable to find a curl example for ‘directions’ that doesn’t have a runtime error. Ex:

curl -X POST   "http://localhost:8095/ors/v2/directions/driving-car"   -H "Content-Type: application/json" 
   -H "Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8"
   -H "Authorization: mykey"   
   -d "{""locations"":[[-70.6033605,-33.5040664],[-70.609089,-33.452756]],""destinations"":[0],
   ""metrics"":[""distance"",""duration""],""resolve_locations"":""true"",""units"":""km""}"

{"error":{"code":2002,"message":"Parameter 'coordinates' has incorrect value or format."},
"info":{"engine":{"version":"6.6.0","build_date":"2021-07-01T14:02:07Z"},"timestamp":1625167203423}}

Was any of this what you were looking for?

[MoltenLight]

So, I figured out that I had incorrectly modified the “docker run -dt …” command.
I believe it is now correctly configured, and I am now getting this error:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting “/Singularity/MLDL/AWS/openrouteservice-js/osmFiles/us-west-latest.osm.pbf” to rootfs at “/ors-core/data/osm_file.pbf” caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

Unfortunately, this is a documented and current bug for Windows Docker Desktop:

"not a directory: unknown: Are you trying to mount a directory onto a file" error produced when mounting a single file on a container

The problem appears to be because of the volume mount on ‘/ors-core/…’ for both directories and the PBF file.

Is there an easy way to change the ‘/ors-core/data/osm_file.pbf’ path to a different path?

Thanks!

[MoltenLight]

Ok, I have the local server configured and working successfully with cURL commands.
I am still unable to route the HGV over the mountain pass.
I would like all 4-wheel roads/paths (short of rock crawling) to be available.
The particular mountain pass I’m trying to route over is a gravel/dirt forest road, but does get steep in a few places. Note: Bikes will route over this road

I have been modifying the …\openrouteservice\docker\conf\app.config file
The HGV portion is:

            "profiles": "driving-hgv",
            "parameters": {
              "encoder_flags_size": 8,
              "encoder_options": "maximum_grade_level=5|turn_costs=true|block_fords=false|use_acceleration=true",
              "maximum_distance": 100000,
              "elevation": true,
              "preparation": {
                "min_network_size": 200,
                "min_one_way_network_size": 200,
                "methods": {
                  "ch": {
                    "enabled": false,
                    "threads": 1,
                    "weightings": "recommended"
                  },
                  "core": {
                    "enabled": false,
                    "threads": 1,
                    "weightings": "recommended,shortest",
                    "landmarks": 64,
                    "lmsets": "highways;allow_all"
                  }
                }
              },
              "execution": {
                "methods": {
                  "ch": {
                    "disabling_allowed": false
                  },
                  "core": {
                    "disabling_allowed": false,
                    "active_landmarks": 6
                  }
                }
              },
              "ext_storages": {
                "WayCategory": {},
                "HeavyVehicle": {
                  "restrictions": false
                },
                "WaySurfaceType": {}
              }
            }
          },

As can be seen, I have even added the maximum_grade_level=5 flag.

I am building with: docker-compose up -d --build
And have tried setting the BUILD_GRAPHS=True in the YML file.

Nothing has made a difference.

I would appreciate any guidance on how I can resolve this.

[amoncaldas]

Maybe @adam or @andrzej can help here.

[andrzej]

Thanks for your feedback @MoltenLight !

Could you maybe provide and example of an OSM way you would like to include in your route?

Please note that driving profiles such as HGV allow routing only down to OSM highway=track. Paths and trails are not supported as they are generally too narrow for 4 wheel vehicles.

[MoltenLight]

Yes, I am trying to route from Bernalillo, NM to Sandia Park, NM

Route that is provided: S on I-25, E on I-40, N on 14, W on 536
Route that it won’t take: E on 165, E on 536.

If I use a car, it will route on 165 to “Left on Camino del Tecolote”, and then wanders through residential for a bit, and then on what I can only guess are trails.

165 is a gravel forest road
It is passable by most any vehicle (some cars sit so low that they would have an issue).
536 is a paved road

This test case is excellent for comparison, showing: long distance and high speed, versus short distance and windy steep grade.

[jschnell]

Hey,
I assume that you’re talking about roughly this route.

I’m not entirely sure about this, but there is a barrier:gate on the route it won’t take, here. I suspect that this is why it doesn’t take that particular road in this case.

Could you clarify what you mean by

@MoltenLight

If I use a car, it will route on 165 to “Left on Camino del Tecolote”, and then wanders through residential for a bit, and then on what I can only guess are trails.

The route provided above uses a car, but doesn’t go via the 165 but uses the road you described first.

Best regards

[MoltenLight]

Ok, apparently only the ‘car’ is working on my local server; the HGV is failing. But the car shows the issue.

Using the online server, the bike will take the mountain road:

curl -X POST "https://api.openrouteservice.org/v2/directions/cycling-mountain/gpx" -H "Content-Type: application/json; charset=utf-8" -H "Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8" -H "Authorization: key" -d "{""coordinates"":[[-106.547805,35.31302],[-106.365579,35.164889]],""extra_info"":[""steepness"",""suitability"",""surface"",""waycategory"",""waytype"",""traildifficulty"",""osmid"",""roadaccessrestrictions""],""language"":""en"",""preference"":""shortest""}"

Using my local server, using the car, recommend path:

curl -X POST "http://localhost:8095/ors/v2/directions/driving-car/gpx" -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"":[[-106.547805,35.31302],[-106.365579,35.164889]],""extra_info"":[""steepness"",""suitability"",""surface"",""waycategory"",""waytype"",""traildifficulty"",""osmid"",""roadaccessrestrictions""],""language"":""en"",""preference"":""recommended""}"

If I switch to shortest path:

Notice that it did not follow the bike up 165 over the mountain, but instead turns left onto Tecolote, as previously described

So I then placed a few points up 165 to try to force it:

Notice it went up 165, then back down, and then jumps back onto Tecolote.

So I would like to understand how to modify the configuration to allow cars and HGV’s to go over the pass.

Additionally, you said there is a ‘barrier:gate’ on the route.
Where/how do I find that info?

Thanks

[jschnell]

Hey,

I found that info by looking at the actual OpenStreetMap-Data on osm.org.
(One has to be a bit careful when doing so, because it can take a few weeks for the latest changes to reflect in the live openrouteservice instance.)

I found the openstreetmap node linked above:

I got a bit curious when, as you experienced as well, the car would turn around when I added a few points up 165 from both sides and noticing the car going up, making u-turn, going around, going up, making u-turn.

That made me think there might be some issues with the road in the middle, so I had a look on the OSM.
What I found is on the ending of the 165, just before it merges with the 536 going down to Sandia Park, NM.

There is a barrier, that is just tagged as a barrier:gate. That should mean that there’s a (non-passable, permanent) gate blocking access.
As the openrouteservice doesn’t know anything more about that gate, it’ll just assume it’s not passable and not route over it - compare this route that starts right before and ends right after the gate, which will take the long way around.

If that gate isn’t actually there or if it is passable or something, then that should be reflected in the OSM-Data (and will then integrate into ors within the next weeks).

The issue is not with the configuration of anything, but with the underlying OSM data.
I hope that helps,
Best regards

[MoltenLight]

Thanks for the info! Not something I knew how to do. Yes there is a gate there, but in my experience it’s always been open, but they may close it when the road is buried in 4’ of snow.

You state: “If that gate isn’t actually there or if it is passable or something, then that should be reflected in the OSM-Data (and will then integrate into ors within the next weeks).”

I have updated the access, and will watch for the update.

Thanks