Manipulate barrier information trough java api

Hi everyone,

we are using graphhopper to (pre)calculate routing information in an emergency context utilizing the java api and osm. We have created several FlagEncoders honoring our specialized needs. This is working very well.

We are currently trying to improve our routing be identifying e. g. barriers which e.g. cannot be passed by normal traffic but can be used in an emergency context (much like the restricted value “emergency”).

Instead of modifying osm data we would like to manipulate the data from within the graphhopper java api after loading the osm data. The idea would be to provide a list of e.g. OSM IDs and modify the barrier handling.

Is there a way or a better approach to achieve this? Pointers appreciated.

What kind of barriers are you looking at? Do you mean OSM nodes with the barrier tag or things like driving on one-ways in the opposite direction, closed roads etc.?

Barriers in the sense of the osm barrier tag e.g. barrier:gate or something like that (e.g. Node: 1458544638 | OpenStreetMap).

It is important to note that GraphHopper can only block roads based on barrier node tags by adding artificial ‘barrier edges’. Not sure which GH version you are using, but there have been a few related changes in master (after 4.0).

In current master we add such artificial edges for all nodes that contain the barrier tag:

The edge flags (like access etc) for these edges can be manipulated based on the node tags here:

handleNodeTags forwards to all FlagEncoders and sets the access based on the return value of AbstractFlagEncoder#isBarrier. So all you probably need to do is adjust this method in your custom encoder or even simply setup the restrictedValues etc. (see AbstractFlagEncoder#handleNodeTags).

Instead of modifying osm data we would like to manipulate the data from within the graphhopper java api after loading the osm data. The idea would be to provide a list of e.g. OSM IDs and modify the barrier handling.

Do you want to use barrier node tags that are not contained in OSM? This would be harder to do, because then you cannot introduce the artificial edges during import. You would have to split the edges yourself. So basically load the graph from OSM and manipulate the graph afterwards.

I am currently in the process of updating to gh 4.0. Will deploy into our test environment tomorrow. While reading the changelog about the barriers I remembered that we wanted to improve our routing in that respect.

What I will do based on your answer is the following:

I will overwrite AbstractFlagEncoder#isBarrier in our custom FlagEncoders and match the node id against a list of barrier nodes and determine the result based on the result of the match so something like

if(excludeList.hasKey(node.getID())) { return false } else { return super.isBarrier() }

Thanks for your quick and helpful answer!

so something like

Yes, this will unblock barriers for nodes in your excludeList and keep the default behavior for all others. But note that the isBarrier method was only introduced after GH 4.0. In GH 4.0 (and before) it was called handleNodeTags, but I think you can do the same (just return 0 instead of false).

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.