hello black road path planning failed
thanks
graphhopper：3.0
profiles:
- name: fastest_time
vehicle: car
weighting: fastest
Hi,
Can you please explain in more detail what you are trying to achieve:)?
Also the latest GraphHopper version is 4. Perhaps see if the latest version gives you what you are looking for
I have the road network data of a city, but the path planning of Expressway at the edge of the road network always fails. As shown in the figure above, the black line segment and the line segment pointed by the arrow are expressway. The path planning always fails on this road, but when I supplement the data of cities around the city, the road can be planned.
version 4 I also tried, but also the planning failed
I wonder if you might have a specific tag in that road segment that is blocking routing on that segment. For example, a “no access” tag.
Does the same happen when you try the shortest and short_fastest weightings?
fastest and shortest
I can’t even try
There are no specific tag in that road segment that is blocking routing on that segment
Interesting. What are the start and end coordinates of your
black road?
Other sections of the black line
Has been unable to bind to this highway
However, this expressway exists in the basic road network
thanks
Can you send your conifg.yml file?
graphhopper:
# 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: E:\OSM\graphhopper-graph-cache-test
##### 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
# 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,smoothness,max_width,max_height,max_weight,max_axle_load,max_length,hazmat,hazmat_tunnel,hazmat_water,toll,track_type,
# mtb_rating, hike_rating,horse_rating,lanes
# graph.encoded_values: surface,toll,track_type
##### 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 or json file inside your custom_model_folder
# or working directory that defines the custom_model. If you want an empty model you can also set "custom_model_file: empty".
# You can also use th e`custom_model` field instead and specify your custom model in the profile directly.
#
# For more information about profiles and especially custom profiles have a look into the documentation
# at docs/core/profiles.md or the examples under web/src/test/java/com/graphhopper/application/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`.
profiles:
- name: fastest_time
vehicle: car
weighting: fastest
- name: shortest_distance
vehicle: car
weighting: shortest
- name: hs_custom_profile
vehicle: car
weighting: custom
custom_model: { }
- name: shortest_foot_distance
vehicle: foot
weighting: shortest
# - 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`.
profiles_ch:
- profile: fastest_time
- profile: shortest_distance
- profile: hs_custom_profile
- profile: shortest_foot_distance
# - 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:
- profile: fastest_time
- profile: shortest_distance
- profile: hs_custom_profile
##### Elevation #####
# To populate your graph with elevation data use SRTM, default is noop (no elevation). Read more about it in docs/core/elevation.md
# 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
# To enable bilinear interpolation when sampling elevation at points (default uses nearest neighbor):
# graph.elevation.interpolate: bilinear
# To increase elevation profile resolution, use the following two parameters to tune the extra resolution you need
# against the additional storage space used for edge geometries. You should enable bilinear interpolation when using
# these features (see #1953 for details).
# - first, set the distance (in meters) at which elevation samples should be taken on long edges
# graph.elevation.long_edge_sampling_distance: 60
# - second, set the elevation tolerance (in meters) to use when simplifying polylines since the default ignores
# elevation and will remove the extra points that long edge sampling added
# graph.elevation.way_point_max_distance: 10
#### 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.
# prepare.ch.threads: 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 edges) 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
# 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.default_type: 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
##### Country Rules #####
# GraphHopper reads GeoJSON polygon files including their properties from this directory and makes them available
# to all tag parsers and flag encoders. Country borders (see countries.geojson) are always included automatically.
# custom_areas.directory: path/to/custom_areas
##### Country Rules #####
# GraphHopper applies country-specific routing rules during import (not enabled by default).
# You need to redo the import for changes to take effect.
# country_rules.enabled: true
# Dropwizard server configuration
server:
application_connectors:
- type: http
port: 8989
# for security reasons bind to localhost
bind_host: localhost
request_log:
appenders: []
admin_connectors:
- type: http
port: 8990
bind_host: localhost
# See https://www.dropwizard.io/en/latest/manual/core.html#logging
logging:
appenders:
- 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"
I am not sure why you are getting that issue, sorry.
Hopefully the GraphHopper guys will assist you soon:slightly_smiling_face:
Just out of interest, are you only getting that issue for that black road?
Hello, thank you for your answer. At the edge of the road network, there are many similar black lines, which cannot be planned
Check Open street map data set to ensure route is actually feasible.
hello
It’s actually passable
Moreover, if the road data of surrounding cities are combined, the road can pass through, but there are similar black lines at the edge of the combined data, and the path planning cannot be carried out.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.