Improve lane pairing documentation

[FabianPfeufferCAP]

Reference to a related issue in the repository

Antecessor and successor definition for lanes #530

Add a description

• Added an extended version of the image OSI_LaneBoundaries_And_CenterLine.svg
  that includes, connected by a junction.

  • The new image is called
    OSI_LaneBoundaries_And_CenterLine_Intersection.svg and will replace
    the old one in the Lane/Classification/Centerline section.
  • The old image will still be used in the LaneBoundary/BoundaryPoint
    section.

• Added a more precise description to Lane/Classification/lane_pairing
  on how antecessor and successor have to be set.

Some questions to ask:

What is this change?

• Improvement for OSI documentation

What does it fix?

• Documentation for OSI lane pairing

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

[HendrikAmelunxen]

This topic has been discussed at the harmonisation working group meeting. Some points are not clear, e.g. does it make sense to have such a strict rule regarding the overlapping of start/end-points of centerlines and laneboundaries? How to handle road-road-connections? etc.
The attached ppt shows the current status of discussion to be further discussed.
Lane_Pairings_Discussion.pptx

[FabianPfeufferCAP]

Thanks for the update, I looked at the ppt and it seems fine for roads, but I see an issue with non-driving roads here.

Let's say a Pedestrian is walking from one sidewalk onto another one (both connected to each other).
The pedestrian walks along the first sidewalk in e.g. ascending lane boundary order. When reaching the second sidewalk, the pedestrian has to determine the new order of the lane boundary order. To do this, the pedestrian has to check the antecessor/successor of the second sidewalk and see, if one of the antecessors/successors matches the first sidewalk. This is a bit inconvenient, but should be fine.
However, in the roundabout case shown in the ppt, this approach is no longer possible. The first sidwalk will appear as antecessor and successor of the second one, so the result will be arbitrary.

How should the definition order for non-driving roads be determined in this case?

[FabianPfeufferCAP]

@HendrikAmelunxen
I have an additional question regarding intersections and sidewalks.
The picture below shows the intersection used in the OSI-Lane documentation ( https://opensimulationinterface.github.io/open-simulation-interface/structosi3_1_1Lane.html ).

There are tree sidewalks (marked in red) that lead across this intersection. Are these sidewalks part of the intersection itself, i.e. do they have the TYPE_INTERSECTION type and SUBTYPE_SIDEWALK subtype?

If this is indeed the case, I have another question with regards to the successor/antecessor pairing, proposed in the ppt. The ppt states that the successor/antecessor pairing of the intersection should be done using the "centerline_is_driving_direction" attribute of the connected roads. This is fine for driving lanes, but how should the successor/antecessor pairing be done for sidewalks?

[HendrikAmelunxen]

@FabianPfeufferCAP
Regarding closed connection of two sidewalks: Yes, you are right. This situation is undefined for non-driving lanes. In this specific situation a third, intermediate lane would solve the situation.

Regarding the sidewalks at intersections: Since sidewalks have a left and right boundary I would not assign them to an intersection.

In general, the current roadmodel does not fit very well to the usecase of navigating along non-driving lanes. Therefore this is also a usecase which is addressed in the road model 2.0 project. Feel free to contribute there as well.

[ThomasNaderBMW]

@HendrikAmelunxen and @clemenshabedank , we should not forget that topic here. Does a discussion in the Road Model Group make sense?

[clemenshabedank]

@ThomasNaderBMW yes we can discuss it in the Road Model Group. Should I invite Fabian for that?

[clemenshabedank]

Might be handled through #599

[clemenshabedank]

Let's try to make a decision what to do with this quite old PR considering the upcoming v3.5 release! Here is my opinion:

• syntactically, concatenating 2 identifiers to one identifier as suggested (identifier is of type uint64, the symbols with letters are just for illustrative purpose I think) does not look like a solution to me, as the identifier would not be splittable unambiguously from the receiving side. Besides this syntax issue I think it is more than just a documentation change leading to much effort on the receiving side.
• since we currently still have the centerline_is_driving_direction flag, the antecessor and successor with respect to the real driving direction can be unambiguously determined by a combination of this flag and the storage order of centerline points, as far as I can tell. So in your l2 -> l3 example, l2 would be the antecessor (points going away from the intersection and driving direction false) and l3 would be the successor (points going away from the intersection and driving direction true).
• the in the conversation section discussed issue with not connected non-driving lanes is not solved with this PR and would need to be a separate one. The already merged PR599 seems like a proper solution for those use cases. In my opinion the highlighted lanes in the picture in Improve lane pairing documentation #542 (comment) shall be modelled as non-driving lanes not being part of the intersection.

For those reasons I would not like to merge it as-is and rather close it. In case logical connections for non-driving lanes are needed and not already covered by the logical lane approach I suggest to open a new PR.

Is my argumentation correct and would this be fine for you @FabianPfeufferCAP ?

[FabianPfeufferCAP]

@clemenshabedank

From my point of view, we can close this issue as the logical lanes should solve this problem for my use case.
However, I have a some doubts about the combination of "centerline_is_driving_direction" + point order to determine if a connected lane is a successor or an antecessor.

For a human looking at it, it's pretty straightforward to determine if points go away from an intersection, but turning this statement into code can be quite tricky.
Let's say we use the distance of the centerline points from the intersection as our metric to determine "going away". Here are a couple of remarks/questions:

1. Where is the reference point on the intersection to determine the distance?
2. Let's assume we found a suitable reference point. How many centerline points have to be checked until "going away" is true? It's pretty easy to create an example where half the centerline points lead away and the other half towards the intersection. Do you only need to check the first two?
3. Will the standard define how "going away" should be determined?
4. Using distance checks to determine the intersection's connection orientation seems quite expensive (not necessarily an issue if done during initialization time)