Problem with ferry on own serwer

Hi,
I am trying to run my own server on GH 6.2 with Poland map on OSM. Everything is working OK, except ferry route (Connection between locations not found).
I checked that route on OSM map, and it is working ok, so probably I have to change something in mine configuration.
Example of route (working on OSM) OpenStreetMap

The same route on mine server:

My config file:

{
  "graphhopper": {
    "datareader.file": "",
    "graph.location": "graph-cache",
    "graph.dataaccess": "RAM_STORE",
    "graph.vehicles": "car,roads|transportation_mode=HGV",
    "graph.encoded_values":"hgv,max_axle_load,max_height,max_length,max_speed,max_weight,max_width,road_access,road_class,road_class_link,road_environment,surface,toll",
  "profiles": [
...
],
"profiles_ch": [
...
],
 "profiles_lm": [],
    "prepare.ch.threads": 14,
    "prepare.lm.threads": 14,
    "prepare.min_network_size": 200,
    "routing.max_visited_nodes": 50000000,
    "routing.non_ch.max_waypoint_distance": 4000000,
    "index.max_region_search": 8,
    "datareader.preferred_language": "pl",
    "import.osm.ignored_highways": "footway,cycleway,path,pedestrian,steps"
  },
  "server": {
    "application_connectors": [
      {
        "type": "http",
        "port": 80,
        "bind_host": "localhost"
      }
    ],
    "request_log": {
      "appenders": []
    },
    "admin_connectors": [
      {
        "type": "http",
        "port": 8990,
        "bind_host": "localhost"
      }
    ]
  },


custom car profile is only with distance_influence:

{
"distance_influence": 0
}

What should I add or change, to get it working?

What does the profiles section of your config look like? And did you try to calculate the same route simply using the config-example.yml?

They are all in one template (just different names), like this:

 "profiles": [
  {
        "name": "car_f",
        "vehicle": "car",
        "weighting": "custom",
        "custom_model_file": "car_f.json"
      },
...
],

What is interesting, if I start my route from ferry, it is calculated:

You could enable the MVT layer in the layers menu (top right corner of the map) to see the routing graph. You can also hover the ferry route. Maybe post a screenshot of this.

Which map file are you using?

Here is screenshot with MVT enabled:

I am using poland.osm.pbf map from geofabrik.de

This looks alright. I’ll try to reproduce this.

1 Like

The issue here is that this way is set to maxspeed=5: Way: ‪Pomorska‬ (‪378441011‬) | OpenStreetMap
GraphHopper uses a limited number of bits to store vehicle speeds and thus can only represent some discrete speed values. Since car uses something like 0.8 * maxspeed (=4) to model the speed the resulting value is below the smallest value it can store which is thus rounded down to zero, so the edge becomes inaccessible.

To work around this you can add graph.vehicles=car|speed_bits=6|speed_factor=3 to your config, but you’ll need to run a new import (delete graph-cache and run the import again).

@karussell I know this issue comes up from time to time and rounding the speed down to zero here really seems like the worst we can do?!

1 Like

What is interesting, if I start my route from ferry, it is calculated:

Yes, this works because as I explained above it is only this little way at the beginning of the ferry that cannot be routed. If you want to avoid snapping to ferry routes you can use snap_prevention: [ferry] for your requests.

This resolved my problem.
Thank you for help.

2 Likes

Shall we do this on the EncodedValue-level?
Because doing this “rounding up” is a bit suboptimal for other use cases like max_width, where then the vehicle would pass through although in reality the road could be a bit too small. Or we do this really only to the “round down to 0” case?

(Hm, but rounding up is already done for half of the cases with e.g. a factor=1 then the value=3.6 is rounded up already)

(And wasn’t there already an issue for this? Cannot find it)

Maybe you meant this one: Speed is 0 for low speed edges · Issue #1234 · graphhopper/graphhopper · GitHub

No, I don’t think we should do this on the EncodedValue-level, because as you described the desired behavior could depend on the use case. So it should rather be up to the speed parser to pick a value (and not set it to zero for low speed edges)?

1 Like