Not all "active" modes in ors-config have graphs generated

openrouteservice
1

Greetings All,

I successfully installed the back-end ORS router, which I am using to generate isochrones. I want to generate isochrones for walking and cycling. Here’s what I did:

  1. In ors-config.json, I set ors.services.routing.profiles.active = [ "walking", "bike-regular"], following the configuration documentation
  2. I delete any existing graph folders in the ~/docker/graphs folder
  3. I run docker container restart ors-app
  4. Folders for both walking and bike-regular are created in the ~/docker/graphs, but only the walking folder has anything in it. The bike-regular folder is empty–even after waiting ~20mins.

Interestingly, if I switch the order of modes in the config file, i.e., I set ors.services.routing.profiles.active = [ "bike-regular", "walking"], the opposite happens, i.e., the bike-regular folder gets created and filled, but the walking folder is empty.

In theory I should be able to make multiple routing profiles, but I can only seem to create one for whatever mode is listed first in the config file–has anyone else had this issue?

Cheers,

2

Hey,

my first guess would be that it just takes a lot of time to build the graphs.

What pbf are you building from? If it’s any bigger than, say, 250MB, I wouldn’t be surprised if it takes more than 20 min per profile. Maybe you an check with the default heidelberg.osm.gz-file? That should build within minutes.

Have a look at this section on how to check whether the service is running.

Are there any errors in the logs created by the ors?

Best regards

3

Hi,

Re: “takes a lot of time to build the graphs”, the walking graph built in ~10mins. Several minutes after that, the bike graph folder was created, but nothing ever got built in it–even 8 hours later, not even the .lock files was in there.

I then went to http://localhost:8080/ors/v2/health and it said status "not ready", so maybe that has something to do with it? I am able to run scripts and generate isochrones for walking, whose graphs were built.

Regarding logs, are you referring to the log files stored in ~docker/logs/ors? If so, I did find the excerpt below which, although I’m not positive, may explain why the walking graph was built but the biking one wasn’t. There are a few points where it mentions java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError–could this be the problem? That somehow it’s running out of memory? I unfortunately don’t know the mechanics of how the graphs are built so I can’t be sure, but it’s the one thing that stands out for me.

And as reference, the PBF I’m reading for the Sacramento, CA USA region is a little over 500MB.

2022-03-25 20:50:45,183 INFO [ors.Application] - Starting Application v6.7.0 on dd32507e6501 with PID 9 (/usr/local/tomcat/webapps/ors/WEB-INF/classes started by root in /ors-core)
2022-03-25 20:50:45,186 DEBUG [ors.Application] - Running with Spring Boot v2.3.5.RELEASE, Spring v5.2.10.RELEASE
2022-03-25 20:50:45,189 INFO [ors.Application] - No active profile set, falling back to default profiles: default
2022-03-25 20:50:49,682 INFO [ors.Application] - Started Application in 5.871 seconds (JVM running for 11.741)
2022-03-25 20:50:49,727 INFO [routing.RoutingProfileManager] -  Total - 1.00 GB, Free - 667.65 MB, Max: 2 GB, Used - 358.35 MB
2022-03-25 20:50:49,728 INFO [routing.RoutingProfileManager] -       
2022-03-25 20:50:49,749 INFO [routing.RoutingProfileManager] - ====> Initializing profiles from 'data/osm_file.pbf' (1 threads) ...
2022-03-25 20:50:49,753 INFO [routing.RoutingProfileManager] -                               
2022-03-25 20:50:49,757 INFO [routing.RoutingProfileManager] -                
2022-03-25 20:50:49,811 INFO [routing.RoutingProfile] - [1] Profiles: 'foot-walking', location: 'data/graphs/walking'.
2022-03-25 20:55:29,006 INFO [routing.RoutingProfile] - [1] FlagEncoders: 1, bits used [UNKNOWN]/64.
2022-03-25 20:55:29,007 INFO [routing.RoutingProfile] - [1] Capacity: [UNKNOWN]. (edges - 2816311, nodes - 2081419)
2022-03-25 20:55:29,008 INFO [routing.RoutingProfile] - [1] Total time: 279.197s.
2022-03-25 20:55:29,008 INFO [routing.RoutingProfile] - [1] Finished at: 2022-03-25 20:55:29.
2022-03-25 20:55:29,009 INFO [routing.RoutingProfile] -                               
2022-03-25 20:55:29,014 INFO [routing.RoutingProfile] - [2] Profiles: 'cycling-regular', location: 'data/graphs/bike-regular'.
2022-03-25 20:57:00,562 ERROR [routing.RoutingProfileManager] - java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space - problem when allocating new memory. Old capacity: 75497472, new bytes:140, segmentSizeIntsPower:20, new segments:1, existing:72
2022-03-25 20:57:00,562 ERROR [routing.RoutingProfileManager] - Failed to initialize RoutingProfileManager instance.
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space - problem when allocating new memory. Old capacity: 75497472, new bytes:140, segmentSizeIntsPower:20, new segments:1, existing:72
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
	at java.util.concurrent.FutureTask.get(FutureTask.java:191) ~[?:?]
	at org.heigit.ors.routing.RoutingProfileManager.initialize(RoutingProfileManager.java:178) ~[classes/:6.7.0]
	at org.heigit.ors.routing.RoutingProfileManager.getInstance(RoutingProfileManager.java:72) ~[classes/:6.7.0]
	at org.heigit.ors.servlet.listeners.ORSInitContextListener.lambda$contextInitialized$0(ORSInitContextListener.java:41) ~[classes/:6.7.0]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.lang.OutOfMemoryError: Java heap space - problem when allocating new memory. Old capacity: 75497472, new bytes:140, segmentSizeIntsPower:20, new segments:1, existing:72
	at com.graphhopper.storage.RAMDataAccess.ensureCapacity(RAMDataAccess.java:107) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.storage.BaseGraph.ensureGeometry(BaseGraph.java:973) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.storage.BaseGraph.setWayGeometryAtGeoRef(BaseGraph.java:879) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.storage.BaseGraph.setWayGeometry_(BaseGraph.java:868) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.storage.BaseGraph.access$400(BaseGraph.java:48) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.storage.BaseGraph$CommonEdgeIterator.setWayGeometry(BaseGraph.java:1328) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.addEdge(OSMReader.java:917) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.addOSMWay(OSMReader.java:830) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.processWay(OSMReader.java:431) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at org.heigit.ors.routing.graphhopper.extensions.ORSOSMReader.processWay(ORSOSMReader.java:172) ~[classes/:6.7.0]
	at com.graphhopper.reader.osm.OSMReader.writeOsm2Graph(OSMReader.java:302) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.readGraph(OSMReader.java:178) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.GraphHopper.importData(GraphHopper.java:735) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.GraphHopper.readData(GraphHopper.java:714) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.GraphHopper.process(GraphHopper.java:701) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.GraphHopper.importOrLoad(GraphHopper.java:680) ~[graphhopper-core-v0.13.21.jar:?]
	at org.heigit.ors.routing.graphhopper.extensions.ORSGraphHopper.importOrLoad(ORSGraphHopper.java:163) ~[classes/:6.7.0]
	at org.heigit.ors.routing.RoutingProfile.initGraphHopper(RoutingProfile.java:184) ~[classes/:6.7.0]
	at org.heigit.ors.routing.RoutingProfile.<init>(RoutingProfile.java:128) ~[classes/:6.7.0]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:35) ~[classes/:6.7.0]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:21) ~[classes/:6.7.0]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
	... 1 more
2022-03-25 20:57:00,569 INFO [routing.RoutingProfileManager] - ====> Recycling garbage...
2022-03-25 20:57:00,570 INFO [routing.RoutingProfileManager] - Before:  Total - 2 GB, Free - 33.92 MB, Max: 2 GB, Used - 1.97 GB
2022-03-25 20:57:00,611 INFO [routing.RoutingProfileManager] - After:  Total - 2 GB, Free - 911.67 MB, Max: 2 GB, Used - 1.11 GB
2022-03-25 20:57:00,612 INFO [routing.RoutingProfileManager] - ========================================================================
2022-03-25 20:57:00,612 INFO [routing.RoutingProfileManager] - ====> Memory usage by profiles:
2022-03-25 20:57:00,617 INFO [routing.RoutingProfileManager] - [1] 300.03 MB (26.4%)
2022-03-25 20:57:00,618 INFO [routing.RoutingProfileManager] - Total: 300.03 MB (26.4%)
2022-03-25 20:57:00,618 INFO [routing.RoutingProfileManager] - ========================================================================
4

Hey,

yeah, it looks like either your machine or your jvm doesn’t have enough memory available. This page of our backend documentation has a paragraph about that.

Try increasing at least the -Xmx-setting (There’s a typo in there, the first option should read -Xms1g).

Best regards

5

Thank you for following up! I’ll look into the backend documentation you linked to and explore the settings you mention. Worst case scenario I’ll need to restart the container whenever I want to change up modes.

Cheers,

1 Like