Some Road Segments not Showing/generated

naul1190 · August 11, 2020, 2:20pm

Hi,

I’m a new Graphhopper user and currently exploring Graphhopper.jar on my local computer. I downloaded OSM PBF and rebuild it using default config file. I noticed that some of the road segments seems not generated on the graphhopper, I ticked the local MVT. Most of the road segments are having lift_gate or swing_gate tags on OSM. Is this expected? I attached screenshots the grey-colored line is the one that shows as local MVT layer on graphhopper UI, I opened the pbf file on QGIS to make sure that the pbf file has road segments on that particular area as you can see on the second screenshot image (blue-line)

Anything wrong on my local deployment? Any inputs are welcome.

Thanks!

lippertsjan · August 11, 2020, 3:18pm

Hi,

this behaviour seems to be expected (see CarFlagEncoder.java#L83). According to this code, swing_gates and lift_gates are treated as “potential barriers”. According to AbstractFlagEncoder.java#L200 “movable barriers block if they are not marked as passable”.

The area in question: https://www.openstreetmap.org/way/28294916

I checked one of the gates – https://www.openstreetmap.org/node/7098815254 – which is not marked as passable. After skimming over https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dlift_gate, I assume that appropriate access-tags need to be added to the gates. If you know the area, you could probably determine the correct access-tags if any

Best,
Jan

naul1190 · August 12, 2020, 2:07am

hi @lippertsjan

thank you for the explanations! so just to clarify all road segments that have gate/barrier tags will not be generated in graphhopper unless it has passable access-tag?

Regards
Naul

lippertsjan · August 12, 2020, 2:12pm

Hi,

yes, they need some tags that mark them as passable. I double-checked the code for the car encoder again. Taking both AbstractFlagEncoder.java#L206 and
CarFlagEncoder.java#L67 into account, one or more of the keys

"motorcar", "motor_vehicle", "vehicle", "access"

with values

"yes", "permissive"

would add the roads to routing.

So, e.g., if these roads are “regular” roads with gates that can be accessed by any vehicle, I’d assume that “vehicle=yes” would be appropriate (see Key:access).

Regard,
Jan

easbar · August 25, 2020, 6:07am

You can also try to set prepare.min_network_size: 0 in config.yml. GraphHopper first parses the OSM data and creates the road network, but then removes ‘islands/subnetworks’ that are not reachable from the main network. In this case the area on your screenshot is not reachable because of the gates. Setting above parameter to zero means no subnetworks will be removed (but they will still not be connected).

naul1190 · August 25, 2020, 10:57am

Thank you @lippertsjan @easbar !
So this network size parameter is a kind of search radius of Graphhopper to generates the reachable road network? I assume this is using meters unit?

easbar · August 25, 2020, 12:23pm

No its the number of nodes each sub network must have to not be removed, see the docs here:

github.com

graphhopper/graphhopper/blob/2207576a56b62da5a80fb4960fcac2096bdefb73/config-example.yml#L123-L127


# In many cases the road network consists of independent components without any routes going in between. In
# the most simple case you can imagine an island without a bridge or ferry connection. The following parameter
# allows setting a minimum size (number of nodes) for such detached components. This can be used to reduce the number
# of cases where a connection between locations might not be found.
prepare.min_network_size: 200

karussell · August 25, 2020, 8:16pm

You can reverse this default behaviour for potential barriers with:

graph.flag_encoders=car|block_barrier=false

without changing the code

system · November 23, 2020, 8:16pm

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