Incorrect edge IDs after country slicing

[flowrean]

Converting an OSM PBF file to an Atlas, I noticed that the edge IDs generated during country slicing do not seem to be in line with what is described in the documentation.

To illustrate this, I have created a very small example, consisting of one way: ZIP file.

This is my logic:

final CountryBoundaryMap boundaries = CountryBoundaryMap.fromPlainText(boundariesFile);
final Atlas rawAtlas = new RawAtlasGenerator(osmPbfFile).build();
final Atlas slicedAtlas = new RawAtlasCountrySlicer(AtlasLoadingOption.createOptionWithAllEnabled(boundaries)).slice(rawAtlas);
final Atlas atlas = new WaySectionProcessor(slicedAtlas, AtlasLoadingOption.createOptionWithAllEnabled(boundaries)).run();
atlas.save(atlasFile);

Expected outcome:
Edge IDs 60342899001000, 60342899002001, 60342899001002, as indicated in the README.

Actual outcome:
Edge IDs 60342899003000, 60342899001000, 60342899002000.

[adahn6]

hey @flowrean! looking at your data, I think this is an issue of some ambiguity in the README about how these identifiers are created. The README you linked is our most high level, general purpose one, but for specifics regarding the slicing and sectioning steps, each has their own README going into more detail.

That being said, we could probably use a specific section in each step going over the identifier transformations that can happen. Here's a general explanation of the results you're seeing. During the slicing operation, the Way is getting sliced into three pieces, one inside the country boundary 60342899001000 and two outside (60342899002000 and 60342899003000). These follow the pattern of our slicing identifier creations, in which we alter the first three appended 000 of the atlas ID space. This step runs first, and slices the Way regardless of whether it will later become an Edge or not. This guarantees that we begin the way sectioning step with Line slices that belong to specific countries. Next, when the way sectioning step occurs, it will way section each sliced Line (60342899001000, 60342899002000, and 60342899003000) and if it passes the Edge filter, it will turn the Line slice into an Edge. From there, the ID will remain the same as the Line piece-- i.e. Line 60342899001000 will become Edge 60342899001000. Only after that will the way section processor decide to split the Edges based on intersections-- i.e. Edge 60342899001000 contained intersections with other Edges, then it would split that Edge into pieces and use the last three 000 identifiers in the Atlas identifier space to create smaller Edges, 60342899001001, 60342899001002, etc.

Since your data is just one Way, it's getting line sliced to three Line slices at the country boundary-- and during that line slicing, only the first three identifier 000s are used, hence 60342899001000 through 60342899003000. Later, during way sectioning, the Edges created from those Line slices use the same identifiers, and since they don't intersect other Edges, there's no need to subdivide further.

I hope that makes sense!

[flowrean]

It indeed makes sense @adahn6, thanks!
But I would conclude that the information in the README is not correct. And I believe it is the only place that details the edge identifier principles.

[matthieun]

@flowrean Feel free to submit a PR with corrections to the documentation!