Unresolvable way overlaps

[polarkernel]

There exist way segments, that overlap each other. A typical situation is shown in the left image below. The end of the cyan segment still overlaps the other way segment above it. The cyan dot is the node of the intersection to be processed. The right image shows the result of the processing by the current code, where this intersection remains unprocessed.

It is easy to detect these segments, one of their endpoints is inside a neighboring way polygon. If the way boundary to such an endpoint leaves the other way before re-entering it, the intersection area can be calculated correctly:

We need ideas on what has to be done with such cases. Currently, these ways are removed from the intersection to compute its area, but remain as ways.

[vvoovv]

Where are these examples located?

[polarkernel]

Where are these examples located?

_osm_extracts/streets/milano01.osm red arrow: Unresolvable way (upper row) green arrow: Counter-example (lower row)

But there are many more examples of unresolvable ways in the same scene:

[vvoovv]

I am getting an error for _osm_extracts/streets/milano01.osm in the method tmpPrepare(). I am trying to figure out the cause of the problem.

[vvoovv]

I am getting an error for _osm_extracts/streets/milano01.osm in the method tmpPrepare(). I am trying to figure out the cause of the problem.

There is at least one ID of a way-section present in TransitionSymLane.connectors but not present in manager.waySections. The following code snippet outputs all those IDs:

[idx for idx in set(abs(idx) for t in manager.transitionSymLanes for idx in t.connectors) if idx not in manager.waySectionLines]

It can be placed wherever the variable manager is available.

[polarkernel]

There is at least one ID of a way-section present in TransitionSymLane.connectors but not present in manager.waySections.

The reason were polygons of TransitionSymLanes that overlapped polygons of the intersection areas. The former are now merged with the latter. This fix is committed.

The issue of unresolvable path overlaps is still open. Currently, these paths are removed.

[vvoovv]

What is the reason that an intersection is not computed for the cyan point?

[vvoovv]

There is a similar case (Straße der Pariser Kommune) in the right lower corner of _osm_extracts/facade_visibility/berlin_karl_marxallee.osm:

But an intersection is computed there.

What is the reason for the different result in those two cases?

[polarkernel]

What is the reason that an intersection is not computed for the cyan point?

This is simply due to my temporary solution of excluding such way segments from further processing. I still have no good idea what else to do with them.

[polarkernel]

What is the reason for the different result in those two cases?

They are different. The branching way segment in _milano01.osm (left image) overlaps the second path along its entire length. Its end, and thus the intersection there, is still partly within the other way segment. In _berlin_karl_marxallee.osm (right image), on the other hand, the branching segment completely leaves the other way segment, so there is no intersection overlap.

[vvoovv]

Would it help for that particular case in _milano01.osm, if the width of the way-sections with oneway=yes (marked with red color on the image below) is halved?

[polarkernel]

Would it help for that particular case in milano_01.osm, if the width of the way-sections with oneway=yes (marked with red color on the image below) is halved?

I suppose so. I have already thought about this possibility. Another solution might be to adaptively adjust the width of such conflicting way segments. This is a bit difficult to program. Imagine that the intersection of the three way segments at the bottom right has been calculated (without problems), while later the calculation of the intersection at the top left reveals the problem. Changing the width of the ways now also changes the result of the intersection at the bottom right. This is somehow similar to changing list entries during a for loop?

[vvoovv]

The number of lanes is not given for those OSM-ways in the OSM database. So halving of the width for oneway=yes certainly makes sense in that case.

For a general case, I would suggest creating a polygon for the whole conflict area.

[polarkernel]

... certainly makes sense in that case.

What do you see as the criteria that distinguish this case from the general cases?

[vvoovv]

What do you see as the criteria that distinguish this case from the general cases?

No specific criteria. If way-segments intersect like in _milano01.osm, then it's a general case.

[vvoovv]

Another solution might be to adaptively adjust the width of such conflicting way segments.

If I understand that correctly, a change of the width of a way-segments affects only the intersections connected to the way-segment, i.e. the polygons for the intersection must be regenerated. Is it correct?

[polarkernel]

If I understand that correctly, a change of the width of a way-segments affects only the intersections connected to the way-segment, i.e. the polygons for the intersection must be regenerated. Is it correct?

Yes, I think so.

[vvoovv]

I suggest generating a polygon for now.

Adaptive width adjustment can be later used for clusters.

[polarkernel]

Adaptive width adjustment can be later used for clusters.

This is what I am currently studying. Clusters will make the problem even more complicated, because several intersection areas now constructed individually may be merged then into a larger area. I am not sure yet if it would be better to wait with the construction of the intersection areas until the clusters are defined.

Is it important for your development that I fix this problem now, maybe just temporarily with a patch, or can it remain unfixed for a while (I don't know how long)?

[vvoovv]

Having a code to process clusters is more important.