Change default snap preventions

Open Source Routing Engine
1

Hi, I’m trying to turn off snap prevention of bridges, but can’t really find it. I’m using version 10 and my code is based on the example in graphhopper/example/src/main/java/com/graphhopper/example/RoutingExample.java at 10.x · graphhopper/graphhopper · GitHub. Already tried to define my GHRequest with .setSnapPreventions(null); but it doesn’t change the result.

Can anyone help me?

2

Instead of null, which will trigger the default on the server-side, you’ll have to use an empty list.

Or you change this behaviour in the server-side configuration:

  routing.snap_preventions_default: ''
3

image
image1654×862 123 KB

With the Routing API in explorer, with the snap preventions empty , the result is right

I’m using the Java API locally, and after I did what you told me, the result is the same.
I’m really confused now. I tried main 2 ways to change snap preventions:

-In the config.yml (or in my case, json but irrelevant) for the hopper instance. I did what you told and even tried adding something like “tunnel”. Still not the right result.

-In the GHRequest directly, with .setSnapPreventions(snappreventions). With this method nothing happens aswell but if i try to this:

    List<String> snappreventions = new ArrayList<>();
    snappreventions.add("");
    GHRequest req = new GHRequest(start.valid_lat, start.valid_lon, end.valid_lat, 
  end.valid_lon)
            .setProfile("car")
            .setLocale(Locale.forLanguageTag("pt-PT"))
            .setSnapPreventions(snappreventions);

All routings are null, idenpendent of the routings
If i instead add ferry or tunnel, i don’t get the right result still

Am i creating the hopper or the GHRequest instances wrong?

config.json (698 Bytes)
GridRouting_All.java (20.7 KB)

Just to confirm that my snapping during route calculation is not working properly, i do a “pre-snap”, a snap before even calculate the route, and the snapping works well as intended, but during the routing something happens and it won’t snap to the right place

4

Do not add any value. Just do something like:

setSnapPreventions(List.of());

Note, if you are using an older versions <= 10.x then nothing at all is necessary and the empty list is automatically forced!

Only in newer (not yet released) versions of the client-hc library the server-side default will be used as the default (as snapPreventions=null and no list is sent as default behaviour) and you have to set:

setSnapPreventions(List.of());

(but you can already use this to ensure future compatibility)

5

setSnapPreventions(List.of()); won’t work as well…

I don’t know what else i can do. I bumped my head everywhere, I’m stuck here for days and I really need this to be fixed. Since your reply I went deep to try to understand what was going on, and the problem happens in the hopper.route(req) ->->-> Viarouting.lookup ->-> findClosest. The edgefilter is probably cutting out of the possible edges.

One thing I didn’t try was using a different osm file. I snipped the map on the osm website and i cut the bridge that i mentioned earlier. Maybe, and i really hope so it is that, that’s the problem. But for now i’ll have to see that later. Do you think it might be that?

Also thank you for your replies!

6

Which client-hc version are you using? And against the commercial API or your local server? (if local server, which version)

7

I’m using Graphhopper 9.0 currently, since going to earlier versions the code would not work
I’m not sure about which version of my local server i’m using, i guess the default one, sorry

Why?

8

Because the default not empty snap preventions were only introduced in latest master. So this can’t be the case here.

Please use the latest OSM data as well as the latest GraphHopper version 10.0 for the server and client and let me know if there is still an issue.

9

So, it was really the osm file!

In openstreetmap.org, you can choose the part of the osm map you want. In this case, i have cut the osm map for Lisbon area, instead of using portugal or a wider area, and i cut exactly in the bridge i mentioned. It seems that the conectivity matters in the default edgefilter for the main LocationIndexTree, and since i cut exactly the bridge in the middle of the river, the edge was not considered when searching for the closest edge.

I hope this can be helpful for anyone who encounters the same issue
I’m sorry for the bothering and thank you for your help @karussell !

2 Likes