Cattlegrids with car routing


We’re having a problem with routing by car over a cattlegrid. It doesn’t seem to work with the build that we’re using (the janino_scripting branch). It routes OK over cattlegrids by mtb or hike, just not by car. I’ve checked it on the GH demo server and it seems to work OK there so I’m assuming this uses a later snapshot branch where the bug was fixed. If so, would you be able to point me to the best branch to use please that includes the janino scripting and the cattegrid fix? Or is it better to wait for version 3 (I know this was due out around March/April)?


The janino scripting branch has been merged to master already and you can just use the master branch it is as stable if not more stable than the janino scripting branch.

Great, thanks, I’ll give that a try.

The cattlegrid issue still seems to happen with the master branch - routing by car (without any customised profile) doesn’t allow cattlegrids. Here’s an example:


Ok but you mentioned that on the demo server the cattlegrid is allowed?

Yes, it works OK here:

and also here:

but not with the latest master build that I just downloaded. We’re using “shortest” rather than “fastest” - could that make any difference?

Maybe you are using a different version of the map data? Did you try with the latest OSM extract? I do not think it is related to shortest weighting. Do you get the same result when you use fastest?

No, it’s not the latest OSM extract but the cattlegrid has been there for many years, so I assumed this wouldn’t matter. I’ll download a fresh OSM file and also try the fastest weighting to see if that affects anything.

Yes the cattle grid has been there for some time. Maybe share your config.yml file as well so I can try to reproduce your issue.

Still no luck. I’ve download the latest OSM data for the area I’m testing ( and have tried both shortest and fastest. Feels like I’m missing something obvious!

This is the test query:


This is what I get:

{"hints":{"visited_nodes.sum":8,"visited_nodes.average":8.0},"info":{"copyrights":["GraphHopper","OpenStreetMap contributors"],"took":7},"paths":[{"distance":101.199,"weight":12.143834,"time":12142,"transfers":0,"points_encoded":false,"bbox":[-3.519557,51.216385,-3.518204,51.216714],"points":{"type":"LineString","coordinates":[[-3.518204,51.216385],[-3.519557,51.216714]]},"instructions":[{"distance":101.199,"heading":291.73,"sign":0,"interval":[0,1],"text":"Continue onto Hill Road","time":12142,"street_name":"Hill Road"},{"distance":0.0,"sign":4,"last_heading":278.71531944138894,"interval":[1,1],"text":"Arrive at destination","time":0,"street_name":""}],"legs":[],"details":{},"ascend":0.0,"descend":0.0,"snapped_waypoints":{"type":"LineString","coordinates":[[-3.518204,51.216385],[-3.519557,51.216714]]}}]}

The cattlegrid is at: 51.216714,-3.519557 which is where the route stops as it can’t get past it.

And this is the config I’m using:


  # OpenStreetMap input file PBF or XML, can be changed via command line -Ddw.graphhopper.datareader.file=some.pbf
  datareader.file: ""
  # Local folder used by graphhopper to store its data
  graph.location: ""

  ##### Vehicles #####

  # More options: foot,hike,bike,bike2,mtb,racingbike,motorcycle,car4wd,wheelchair (comma separated)
  # bike2 takes elevation data into account (like up-hill is slower than down-hill) and requires enabling graph.elevation.provider below.
  graph.flag_encoders: car|block_fords=false,hike|block_fords=false,mtb|block_fords=false

  # Enable turn restrictions for car or motorcycle.
  # graph.flag_encoders: car|turn_costs=true

  # Add additional information to every edge. Used for path details (#1548), better instructions (#1844) and tunnel/bridge interpolation (#798).
  # Default values are: road_class,road_class_link,road_environment,max_speed,road_access (since #1805)
  # More are: surface,max_width,max_height,max_weight,max_axle_load,max_length,hazmat,hazmat_tunnel,hazmat_water,toll,track_type
  # graph.encoded_values: surface,toll,track_type
  graph.encoded_values: surface

  ##### Routing Profiles ####

  # Routing can be done for the following list of profiles. Note that it is required to specify all the profiles you
  # would like to use here. The fields of each profile are as follows:
  # - name (required): a unique string identifier for the profile
  # - vehicle (required): refers to the `graph.flag_encoders` used for this profile
  # - weighting (required): the weighting used for this profile, e.g. fastest,shortest or short_fastest
  # - turn_costs (true/false, default: false): whether or not turn restrictions should be applied for this profile.
  #   this will only work if the `graph.flag_encoders` for the given `vehicle` is configured with `|turn_costs=true`.
  # Depending on the above fields there are other properties that can be used, e.g.
  # - distance_factor: 0.1 (can be used to fine tune the time/distance trade-off of short_fastest weighting)
  # - u_turn_costs: 60 (time-penalty for doing a u-turn in seconds (only possible when `turn_costs: true`)).
  #   Note that since the u-turn costs are given in seconds the weighting you use should also calculate the weight
  #   in seconds, so for example it does not work with shortest weighting.
  # - custom_model_file: when you specified "weighting: custom" you need to set a yaml file that defines the custom_model.
  #   If you want an empty model you can also set "custom_model_file: empty".
  #   For more information about profiles and especially custom profiles have a look into the documentation
  #   at docs/core/ or the examples under web/src/test/resources/com/graphhopper/http/resources/ or
  #   the CustomWeighting class for the raw details.
  # To prevent long running routing queries you should usually enable either speed or hybrid mode for all the given
  # profiles (see below). Otherwise you should at least limit the number of `routing.max_visited_nodes`.
    - name: car
      vehicle: car
      weighting: fastest

  #  - name: car_with_turn_costs
  #    vehicle: car
  #    weighting: short_fastest
  #    distance_factor: 0.1
  #    turn_costs: true
  #    u_turn_costs: 60

  # Speed mode:
  # Its possible to speed up routing by doing a special graph preparation (Contraction Hierarchies, CH). This requires
  # more RAM/disk space for holding the prepared graph but also means less memory usage per request. Using the following
  # list you can define for which of the above routing profiles such preparation shall be performed. Note that to support
  # profiles with `turn_costs: true` a more elaborate preparation is required (longer preparation time and more memory
  # usage) and the routing will also be slower than with `turn_costs: false`.
    - profile: car
  #   - profile: car_with_turn_costs

  # Hybrid mode:
  # Similar to speed mode, the hybrid mode (Landmarks, LM) also speeds up routing by doing calculating auxiliary data
  # in advance. Its not as fast as speed mode, but more flexible.
  # Advanced usage: It is possible to use the same preparation for multiple profiles which saves memory and preparation
  # time. To do this use e.g. `preparation_profile: my_other_profile` where `my_other_profile` is the name of another
  # profile for which an LM profile exists. Important: This only will give correct routing results if the weights
  # calculated for the profile are equal or larger (for every edge) than those calculated for the profile that was used
  # for the preparation (`my_other_profile`)
  profiles_lm: []

  ##### Elevation #####

  # To populate your graph with elevation data use SRTM, default is noop (no elevation). Read more about it in docs/core/
  # graph.elevation.provider: srtm

  # default location for cache is /tmp/srtm
  # graph.elevation.cache_dir: ./srtmprovider/

  # If you have a slow disk or plenty of RAM change the default MMAP to:
  # graph.elevation.dataaccess: RAM_STORE

  #### Speed, hybrid and flexible mode ####

  # To make CH preparation faster for multiple profiles you can increase the default threads if you have enough RAM.
  # Change this setting only if you know what you are doing and if the default worked for you.
  # 1

  # To tune the performance vs. memory usage for the hybrid mode use
  # prepare.lm.landmarks: 16

  # Make landmark preparation parallel if you have enough RAM. Change this only if you know what you are doing and if
  # the default worked for you.
  # prepare.lm.threads: 1

  # 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

  ##### Routing #####

  # You can define the maximum visited nodes when routing. This may result in not found connections if there is no
  # connection between two points within the given visited nodes. The default is Integer.MAX_VALUE. Useful for flexibility mode
  routing.max_visited_nodes: 1000000

  # If enabled, allows a user to run flexibility requests even if speed mode is enabled. Every request then has to include a hint ch.disable=true.
  # Attention, non-CH route calculations take way more time and resources, compared to CH routing.
  # A possible attacker might exploit this to slow down your service. Only enable it if you need it and with routing.maxVisitedNodes true

  # If enabled, allows a user to run flexible mode requests even if the hybrid mode is enabled. Every such request then has to include a hint routing.lm.disable=true.
  # routing.lm.disabling_allowed: true

  # Control how many active landmarks are picked per default, this can improve query performance
  # routing.lm.active_landmarks: 4

  # You can limit the max distance between two consecutive waypoints of flexible routing requests to be less or equal
  # the given distance in meter. Default is set to 1000km.
  routing.non_ch.max_waypoint_distance: 1000000

  ##### Storage #####

  # configure the memory access, use RAM_STORE for well equipped servers (default and recommended)
  graph.dataaccess: RAM_STORE

  # will write way names in the preferred language (language code as defined in ISO 639-1 or ISO 639-2):
  # datareader.preferred_language: en

  # Sort the graph after import to make requests roughly ~10% faster. Note that this requires significantly more RAM on import.
  # graph.do_sort: true

  ##### Spatial Rules #####
  # Spatial Rules require some configuration and only work with the DataFlagEncoder.

  # Spatial Rules require you to provide Polygons in which the rules are enforced
  # The line below contains the default location for the files which define these borders
  # spatial_rules.borders_directory: core/files/spatialrules

  # You can define the maximum BBox for which spatial rules are loaded.
  # You might want to do this if you are only importing a small area and don't need rules for other countries.
  # Having less rules, might result in a smaller graph. The line below contains the world-wide bounding box, uncomment and adapt to your need.
  # spatial_rules.max_bbox: -180,180,-90,90

# Uncomment the following to point /maps to the source directory in the filesystem instead of
# the Java resource path. Helpful for development of the web client.
# Assumes that the web module is the working directory.
# assets:
#  overrides:
#    /maps: web/target/classes/assets/

# Dropwizard server configuration
  - type: http
    port: 8989
    # for security reasons bind to localhost
    bind_host: localhost
      appenders: []
  - type: http
    port: 8990
    bind_host: localhost
# See
  - type: file
    time_zone: UTC
    current_log_filename: logs/graphhopper.log
    log_format: "%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
    archive: true
    archived_log_filename_pattern: ./logs/graphhopper-%d.log.gz
    archived_file_count: 30
    never_block: true
  - type: console
    time_zone: UTC
    log_format: "%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

Ok I can reproduce this. It seems strange indeed. Will have to investigate.

OK, thanks. Good to know I wasn’t missing something simple.

The cattle grid blocks the road because there is no access tag. You can allow routing over it (and other potential barriers, see by using the block_barriers=false flag on your flag encoder (in your config set graph.flag_encoders: car|block_fords=false|block_barriers=false,hike...)

The OSM documentation does not really encourage mappers to set the access tag for cattle_grid, so I wonder if it should not be routeable by default @karussell?

Ok, yes. Let’s switch the default for block_barriers to false (for car as it is already the default for the other encoders).

btw: block_fords is already false for all encoders

The OSM documentation does not really encourage mappers to set the access tag for cattle_grid, so I wonder if it should not be routeable by default @karussell?

The problem is the assumed default access property for fords, barriers, ferries is unclear: but it seems we have the least unexpected settings if it is false for potential barriers (certain barriers like pollards or absolute barriers and should always block - at least for cars).

This behaviour is already the case for fords & ferries.

Thanks, that’s very helpful. Will you post back here when the change is available?

I opened a ticket for this here:

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