Adding build options makes build fail

openrouteservice
1

Here’s my config

ors:
  engine:
    profile_default:
      build:
        source_file: example.osm.pbf
    profiles:
      cycling-regular:
        enabled: true
        build:
          encoder_options:
            enable_custom_models: true
          ext_storages:
            OsmId:
      foot-walking:
        enabled: true
        build:
          encoder_options:
            enable_custom_models: true
          ext_storages:
            OsmId:

I’m getting the following error:

2026-08-07 16:59:19 WARN [o.a.c.l.WebappClassLoaderBase           ] - The web application [ors] appears to have started a thread named [ORS-pl-foot-walking] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 com.fasterxml.jackson.core.base.ParserBase.getDoubleValue(ParserBase.java:853)
 com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._fromFloat(JsonNodeDeserializer.java:784)
 com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:633)
 com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:100)
 com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:25)
 com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
 com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:4912)
 com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:3154)
 com.bedatadriven.jackson.datatype.jts.serialization.GeometryDeserializer.deserialize(GeometryDeserializer.java:27)
 com.bedatadriven.jackson.datatype.jts.serialization.GeometryDeserializer.deserialize(GeometryDeserializer.java:16)
 com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
 com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
 com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
 com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:361)
 com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:246)
 com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:30)
 com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:138)
 com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
 com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
 com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
 com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4939)
 com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3889)
 com.graphhopper.routing.lm.LMPreparationHandler.loadLandmarkSplittingFeatureCollection(LMPreparationHandler.java:281)
 com.graphhopper.routing.lm.LMPreparationHandler.init(LMPreparationHandler.java:106)
 com.graphhopper.routing.lm.LMPreparationHandler.init(LMPreparationHandler.java:78)
 com.graphhopper.GraphHopper.init(GraphHopper.java:506)
 com.graphhopper.gtfs.GraphHopperGtfs.init(GraphHopperGtfs.java:61)
 org.heigit.ors.routing.graphhopper.extensions.ORSGraphHopper.init(ORSGraphHopper.java:126)
 org.heigit.ors.routing.RoutingProfile.initGraphHopper(RoutingProfile.java:125)
 org.heigit.ors.routing.RoutingProfile.<init>(RoutingProfile.java:91)
 org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:42)
 org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:26)
 java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
 java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
 java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
 java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
 java.base/java.lang.Thread.run(Thread.java:1474)

When commenting the ext_storages part, the build works.

Any idea why?

Isn’t this the correct way to set this option?

2

It works if I add another option (e.g. TrailDifficulty) but not with OsmId.

Could it be an issue with my .pbf file?

3

Jerome,

Please make sure that you use an original PBF file which is not corrupted.
Did you try with another PBF-file?

Which ORS version did you use?
Please make sure to always use the latest version.

Cheers,
Matthias

4

Spot on. Thanks.

I have several .pbf files and I’ve been performing more tests. For one of them, it fails without even modifying build options.

I didn’t make the .pbf files myself. I suppose some of them lack information. It would be nice if this was caught more gracefully during the build, ideally returning a meaningful error message.

Is there a doc page detailing specifications to export a .pbf file containing required information?

5

The .pbf are exported from JOSM. There doesn’t seem to be many options. It is basically “save as osm.pbf”.

Is there something specific to do so that the build succeeds with OsmId info included?

6

I seem to remember JOSM produces some weird negative IDs for objects that you modified or added or something, and that gets resolved only after you used it to upload the changes to OSM. It’s been a while that I touched JOSM so sorry for the vague answer.

Since these IDs are invalid from ORS POV we don’t store them in the extended storage, but you are perfectly right that a more gracious handling of the error would make sense. We’d appreciate if you were motivated enough to fix it and make a PR, but I don’t think we’ll have time to fix that anytime soon…

7

Spot on, again.

Indeed we suspected negative IDs. This is what I wrote in Build fails when adding OsmId to ext_storages · Issue #2396 · GIScience/openrouteservice · GitHub.

Thanks for confirming this.

I can’t reasonably try to fix this. I don’t know the code base and last time I did Java was at school.

I’m not even sure you’re suggesting to handle negative IDs or just improve the error handling.

(BTW, there are other simple errors that could do with a better handling, like .pbf doesn’t exist, or not readable.)

I’m afraid I’m gonna have to find a workaround. I’m not familiar at all with this environment. From a quick search, it looks like there is no option for this but I could try to edit the files manually…

The case seems legit, though.

We’re trying to asses the benefit of improving a road network, so we add e.g. cycling-roads and we want to compare paths from a given set of addresses to a given set of services, calculating indicators on those paths by accessing the attributes using the osmids of path segments.

Obviously, we don’t want to send those modifications to OSM.

For some cases, we could get an approximation if only existing roads are modified and we assume the router would return the same paths (we’d use paths returned by the router from the initial map without the changes). But in practice, the duration may be impacted, and in some cases, we want to actually add ways, so it doesn’t work.

8

For the negative ID thing, as far as I remember JOSM only gives negative IDs to newly created features that haven’t been added to the OSM database yet. In the past when I have been working on datasets that I created through QGIS, saving as GeoJSON and then converting to pbf (I think I did that aprt in JOSM, but it could have been another tool) I ended up with the negative IDs. The only way I found around it was to instead save as a standard OSM file first, then use a quick Python script to search for the negative IDs and just remove the `-` (beware that needs doing for both the ID tag and any `rel` tag in ways or relations), and then converting to pbf through JOSM or another tool.

It’s a bit long winded, but then worked in ors. Obviously though this relies on there not being any duplicated IDs as a result of changing them from negative to positive.

Then again though, back when I was doing that, the failure came right at the start point of reading the OSM features and not at any point relating to constructing the extended storages, so I am not sure if negative IDs are actually the issue here as then I would expect it to fail all the time, not just for the osm id extended storage (unless changes have been made in the code in the time since I worked with it to allow the negative IDs)…