Handling Junctions with OSI::GroundTruth::Lane

[JonathanSchmalhoferBMW]

I currently try to find the proper representation of junctions with OSI. With the current implementation given, I propose the handling of junction as described for following example:

• each lane is defined by an array of points along its center line which is sorted in ascending order along the allowed driving direction (in this example right-hand traffic)
• ID 1 has the antecessor ID 7, no successor, the left adjacent lane is ID 2, no right adjacent lane
• ID 2 has no antecessor, the successor is ID 8, the left adjacent lane is ID 1, no right adjacent lane
• ID 3 has no antecessor, the successor is ID 7, the left adjacent lane is ID 4, no right adjacent lane
• ID 4 has the antecessor ID 8, no successor, the left adjacent lane is ID 3, no right adjacent lane
• ID 5 has the antecessor ID 9, no successor, the left adjacent lane is ID 6, no right adjacent lane
• ID 6 has no antecessor, the successor is ID 10, the left adjacent lane is ID 5, no right adjacent lane
• ID 7 has the antecessor ID 3, the successor ID 1, the left adjacent lane ID 8, no right adjacent lane
• ID 8 has the antecessor ID 2, the successor ID 4, the left adjacent lane ID 7, no right adjacent lane
• ID 9 has the antecessor ID 2, the successor ID 5, the left adjacent lane ID 10, no right adjacent lane
• ID 10 has the antecessor ID 6, the successor ID 1, the left adjacent lane ID 9, no right adjacent lane

Especially I want to propose to handle lanes on junction as following:

• ID 7 and ID 8 are not in any relation (antecessor, successor, right adjacent, left adjacent) to ID 9 and vice versa
• ID 7, ID 8, ID 3 and ID 4 are not in any relation (antecessor, successor, right adjacent, left adjacent) to ID 10 and vice versa

I would like to put this handling of junctions to a discussion. Unless other/better suggestions are being made, I propose this handling as kind of Best Practice until a better Representation within OSI allows a more detailled handling of relations.

@AndreasVIRES @MHerrmannIPG @HendrikAmelunxen could you please evaluate this "best practice" proposal?

Ein Tool für Kreuzungen

@JonathanSchmalhoferBMW we will plan a workshop end of 01/18 at BMW, where we talk about the lane modell.

[AndreHildebrandt]

As discussed in the meeting on 30th of November, the definition of the lanes have been changed. In order to get a feeling, some sketches of example crossings shall be discussed. I start with an example of a small crossing within a city:

Since the crossing has become a type of lane, it inheritates its properties like a LaneID. It has been discussed that each entry point of a crossing is given by a antecessor and each exit point is given by the successor. This has bee depicted by not filled and filled circles. Recently there has been the idea to replace these antecessor and successor points by pair ids, which is hard to show in this sketch.

[AndreHildebrandt]

Another example: A larger crossing in a city.

@MHerrmannIPG do you have an example too or any suggestions? @pmai and @carsten-kuebler maybe you can verify the examples together and bring up the pullrequest together?