Faster startup of ORS on local machine host

This may have been asked before, but I’m not finding it.

I’ve got ORS up and running fine on my imac using docker. The only issue that I have is that it takes hours to restart the service after I close docker. It’s rebuilding all of the files in the graphs and the elevation cache, which takes a long time.

I would think that there would be some sort of switch that says “don’t rebuild anything, just start using what I already have”.

I don’t see anything in the Dockerfile to control this, and I have played around with the docker-compose.yml, but nothing seems to work.

version: ‘2.4’
container_name: ors-app
- 8080:8080
- 9001:9001
image: openrouteservice/openrouteservice:latest
# build:
# context: …/
# args:
# APP_CONFIG: ./openrouteservice/src/main/resources/app.config.sample
# OSM_FILE: ./openrouteservice/src/main/files/KS_NE_OK_TX.pbf
# OSM_FILE: ./openrouteservice/src/main/files/heidelberg.osm.gz
- ./graphs:/ors-core/data/graphs
- ./elevation_cache:/ors-core/data/elevation_cache
- ./logs/ors:/var/log/ors
- ./logs/tomcat:/usr/local/tomcat/logs
- ./conf:/ors-conf
#- ./your_osm.pbf:/ors-core/data/osm_file.pbf
- BUILD_GRAPHS=False # Forces the container to rebuild the graphs, e.g. when PBF is changed
- “JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g”
- “ -Djava.rmi.server.hostname=localhost”

Am I missing something or will it always rebuild everything when started?

Is the image line causing this to happen?

image: openrouteservice/openrouteservice:latest

I’m looking at making a system covering many of the states of the US, and worry that this will be undoable as when I shut the system down, it will then take ~3 days to rebuild and restart the system.



By default, openrouteservice will always use what is available, meaning that if the graphs are present in the graphs folder, it will just reload them and not rebuild (same for the elevation). The only exception to that is if you set the “build graphs” option and/or the “clear elevation cache” to be true in the app.config or in the docker-compose.yml/Dockerfile.

Even using the image from DockerHub though should not rebuild the graphs unless you delete the folders or tell it to in the compose/config files.
I have seen before that if you do a docker-compose restart it does not take into account any changes in the compose file, so if you have been using that you should try doing a docker-compose down followed by docker-compose up as it could be the case that the BUILD_GRAPHS is still being seen as true. If that still doesn’t work, make sure that when you do the docker-compose down that the ./grpahs and ./elevation_cache folders are not empty. Other than that, try clearing out the images and volumes for Docker and then rebuild without using cache.

Hopefully those will either fix it or at least highlight where the problem comes from.

I started Docker Desktop, confirmed nothing was running, then went to the command line to the Docker folder, did a docker-compose down, then a docker-compose up, and as soon as TomCat was loaded and deployed, ORS was up and running. No waiting 3 hours for it to come up.

I’m wondering now if there is something in Docker Desktop that was forcing it to reload everything, as I had been starting ORS from the Docker Dashboard on my mac.

Anyways, It seems to be up and running quickly without any problems.

Thanks for your help.