Incorrect sequence of "reverse" ways sectioning (oneway=-1).

[vladlemberg]

Atlas way sectioning assigns identifier normally but swapping from-to nodes, which makes reverse ways ONEWAY=-1 as closed ways.
https://wiki.openstreetmap.org/wiki/Key:oneway?uselang=en https://wiki.openstreetmap.org/wiki/Item:Q4669

Turkey. Atlas Example:
https://www.openstreetmap.org/way/185261922 id: 185261922000001 start: POINT (30.3606031 37.766764) end: POINT (30.3611556 37.7668865) id: 185261922000002 start: POINT (30.3603143 37.7668942) end: POINT (30.3606031 37.766764)

Example: https://www.openstreetmap.org/way/204103539 id: 204103539000001 start: POINT (35.3743971 37.0080407) end: POINT (35.3738629 37.0082803) id: 204103539000002 start: POINT (35.3745187 37.0079797) end: POINT (35.3743971 37.0080407)

Notice that start node of section 1 and end node of section 2 sharing the same location, which making entire segment as closed way.

Expected behavior: Atlas way sectioning assigns identifiers according to vector.

[matthieun]

Hello @vladlemberg! So when we do way sectioning, we start from the OSM way, which is in the reverse direction of traffic. We follow the OSM way's direction:

|----------->N------------> (way 123)

So the first slice looks like this:

|----------->N------------>
  123...001   123...002

However Edges have to be in the direction of traffic, so their vector are reversed (oneway=-1)

<-----------|N<-----------|
  Edge..001    Edge..002

Fixing this would create significant work, and given the fact that the topology of the network is still valid (only the expected edge ids are in reverse order) I would be inclined to leave this as-is. What do you think?

[vladlemberg]

@matthieun, this case falls into false positive "closed ways" logic for new Atlas Checks. thats fine, i can find a workaround. no problem to leave it as is. thanks!