Failing to load map of the Netherlands together with Germany

Hi all,

After configuring ORS locally, I managed to get some test routes in Germany functioning well. However, when I try to do a longer route starting in the Netherlands I get the following message:

{"error":{"code":2010,"message":"Could not find routable point within a radius of 1000.0 meters of specified coordinate 0: 4.9434413 52.2882224."},"info":{"engine":{"version":"6.7.1","build_date":"2022-10-17T13:42:43Z"},"timestamp":1666014663917}}

The volumes in my .yml config file:

    volumes:
      - ./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
      - ./netherlands-latest.osm.pbf:/ors-core/data/osm_file.pbf
      - ./germany-latest.osm.pbf:/ors-core/data/osm_file.pbf

It could be that Germany also isn’t loaded, and it only uses the standard demo file to function. I need some steering in the right direction how to solve this.

EDIT:

Start & End: start=4.943441309860964,52.288222425735206&end=13.125420605307463,51.59878782054607

Have also checked this against the API, and there it works fine.

Hey,

currently, you cannot configure more than one osm file for the ors.
Thus, I’d assume that the second entry overwrites the first, and you only get german data.

To check whether you’re running on the “default” data or on your germany-data, request a route anywhere that is not near Heidelberg, e.g. Berlin or Munich - if it works, you’re not running the “default” data.
(Also, building should take more than minutes if your pbf file is decent-sized).

To use data from germany and the netherlands, use a tool like osmium or osmosis to merge the two pbf files into one, see this comment.

Best regards

Hi there, thanks for your swift reply @jschnell

How long would you suggest it needs to build? And it builds automatically by just running docker compose --build? My designated machine has 30GB ram.

Update:

~/ors/osmosis$ bin/osmosis --rb de.osm.pbf --rb nl.osm.pbf --merge -wb NL_DE.osm.pbf
Oct 17, 2022 4:52:48 PM org.openstreetmap.osmosis.core.Osmosis main
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Only one default (un-named) argument can exist per task.  Arguments 7 and 6 have no name.
	at org.openstreetmap.osmosis.core.cli.CommandLineParser.parseTask(CommandLineParser.java:303)
	at org.openstreetmap.osmosis.core.cli.CommandLineParser.parse(CommandLineParser.java:75)
	at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:74)
	at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

Osmosis doesn’t like me that much. How to solve?

Hey,

seems like you mistyped -wb where it should read --wb.

Best regards

I’ve used osmium in the meanwhile:

ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - ====> Recycling garbage...
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - Before:  Total - 2 GB, Free - 48.74 MB, Max: 2 GB, Used - 1.95 GB
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - After:  Total - 1024 MB, Free - 999.70 MB, Max: 2 GB, Used - 24.30 MB
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - ========================================================================
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - ====> Memory usage by profiles:
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - Total: 0 B (0.0%)
ors-app  | 17 Oct 15:42:17 INFO [routing.RoutingProfileManager] - ========================================================================

UPDATE:
Figured out it’s now a memory issue:

Caused by: java.lang.OutOfMemoryError: Java heap space - problem when allocating new memory. Old capacity: 439353344, new bytes:4, segmentSizeIntsPower:20, new segments:1, existing:419
	at com.graphhopper.storage.RAMDataAccess.ensureCapacity(RAMDataAccess.java:107) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.reader.PillarInfo.ensureNode(PillarInfo.java:58) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.reader.PillarInfo._setNode(PillarInfo.java:72) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.reader.PillarInfo.setNode(PillarInfo.java:68) ~[graphhopper-core-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.addNode(OSMReader.java:671) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.processNode(OSMReader.java:632) ~[graphhopper-reader-osm-v0.13.21.jar:?]
	at com.graphhopper.reader.osm.OSMReader.writeOsm2Graph(OSMReader.java:293) ~[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.1]
	at org.heigit.ors.routing.RoutingProfile.initGraphHopper(RoutingProfile.java:184) ~[classes/:6.7.1]
	at org.heigit.ors.routing.RoutingProfile.<init>(RoutingProfile.java:128) ~[classes/:6.7.1]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:35) ~[classes/:6.7.1]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:21) ~[classes/:6.7.1]
	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

Looking how to adjust this. @jschnell any idea? Thanks for your help so far

Hey,

have a look at the backend-docs and this thread.

Best regards

Hi,

I’ve increased both. Does the following mean it is still building?

2022-10-17 16:02:39,030 INFO [routing.RoutingProfile] - [1] Profiles: 'driving-car', location: 'data/graphs/car'.
2022-10-17 16:41:07,520 INFO [core.PrepareCore] - 0, updates:0, nodes: 12 477 112, shortcuts:0, dijkstras:44 813 730, t(dijk):51.47, t(period):0.0, t(lazy):0.0, t(neighbor):0.0, meanDegree:1, algo:190MB, totalMB:20480, usedMB:9178
2022-10-17 16:55:01,459 INFO [core.PrepareCore] - 2 495 422, updates:2, nodes: 9 981 690, shortcuts:11 601, dijkstras:123 693 058, t(dijk):802.11, t(period):741.63, t(lazy):0.0, t(neighbor):78.09, meanDegree:1, algo:190MB, totalMB:20480, usedMB:9386
2022-10-17 17:05:33,994 INFO [core.PrepareCore] - 4 990 844, updates:4, nodes: 7 486 268, shortcuts:12 120, dijkstras:181 172 333, t(dijk):1371.88, t(period):1311.1, t(lazy):0.0, t(neighbor):135.8, meanDegree:1, algo:190MB, totalMB:20480, usedMB:10458

All working, had to wait out :). Thanks @jschnell for your adequate help.

2 Likes