Can someone review my current understanding of the localhost install process? (windows 10 computer, using Docker-Toolbox VirtualBox). **I am trying to get graphhopper to run on my localhost:8989 using my regions PBF and the bike vehicle profiles
- I need to switch
berlin-latest.osm.pbf
to thearizona-latest.osm.pbf
- and switch the
car
profile tobike
,bike2
,mtb
,racingbike
I have successfully run graphhopper on localhost:8989 with the default germany-berlin data, and the default car
profile - so I know this should work.
To setup a custom install of graphhopper (on windows using Docker-Toolbox):
- Use
cd
command to navigation into myProjects
folder git clone https://github.com/graphhopper/graphhopper.git
- create an
arizona_data
folder, downloadarizona-latest.osm.pbf
into that folder downloaded from here
I now have this folder structure
Project
|
+-- graphhopper (git cloned)
|
+-- arizona_data
|
+-- arizona-latest.osm.pbf (downloaded)
- Open
graphhopper/Dockerfile
and edit line 33 of the docker file:
- From:
COPY ./graphhopper.sh ./pom.xml ./config-example.yml ./
- To:
COPY ./graphhopper.sh ./pom.xml ./config.yml ./
- Open
graphhopper/Dockerfile
and edit line 41 of the docker file:
- From:
CMD [ "/data/europe_germany_berlin.pbf" ]
- To:
CMD [ "/data/north-america_us_arizona.pbf" ]
- Create a
config.yml
file by copy and pasting theconfig-example.yml
file - Open the
config.yml
file, and make the following edits, shown below
graphhopper:
# OpenStreetMap input file PBF or XML, can be changed via command line -Ddw.graphhopper.datareader.file=some.pbf
datareader.file: "../arizona_data/arizona-latest.osm.pbf"
# Local folder used by graphhopper to store its data
graph.location: graph-cache
##### Vehicles #####s
# 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: bike, bike2, mtb, racingbike
# 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
##### 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.
#
# 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: bike
vehicle: bike
weighting: fastest
- name: bike2
vehicle: bike2
weighting: fastest
- name: mtb
vehicle: mtb
weighting: fastest
- name: racingbike
vehicle: racingbike
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`.
profiles_ch:
- profile: bike
- profile: bike2
- profile: mtb
- profile: racingbike
# - 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/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
#### 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
# avoid being stuck in a (oneway) subnetwork, see https://discuss.graphhopper.com/t/93
prepare.min_network_size: 200
prepare.min_one_way_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
# routing.ch.disabling_allowed: 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/src/main/resources/assets/
# 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/1.3.8/docs/manual/configuration.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"
- Open Docker Quickstart Terminal (installed with Docker-Toolbox)
- In Docker terminal, use
cd
command to navigate toProjects/graphhopper
- Build the Docker Image from the Dockerfile by running
docker build -t graphhopper:master .
(Wait 5-10 minutes for it to complete) docker run --name graphhopper -v //C/Users/user/Projects/arizona_data:/data -p 8989:8989 graphhopper:master
Questions - Please Answer
- Can I modify my the
config.yml
after I create the Docker Image? But before I I create the Docker Container? -
- If not, do I need to recreate a Docker Image every time I modify my config.yml file?
- Was I suppose to modify the dockerfile?
- If yes, did I correctly modify the dockerfile?
- Did I correctly modify the config.yml file?
- Can the Dockerfile read parent folders ?(
-
- i.e. When I specify in the
config.yml
filedatareader.file: "../arizona_data/arizona-latest.osm.pbf"
Can docker read the../
portion of the filepath?
- i.e. When I specify in the
- Yes or No - Is the
graph-cache
folder that stores the graphs data is stored after graphhopper runs? - Where/when does the
graph-cache
suppose to show up? -
- Inside the
Projects/graphhopper
folder?
- Inside the
-
- Inside the Docker Container itself?