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.

[ghost]

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

[ghost]

Ein Tool für Kreuzungen

[ghost]

@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.

[ghost]

@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?

[MHerrmannIPG]

Sorry for the delay. Here are a few examples marked according to Andre's suggestion and some thoughts:

Simple intersection with a bending priority road:

Roundabout modelled as 4 intersections. Question: How to handle the inner "lane" used by trucks to cut across? I think it should be handled as a non-drivable lane, as the truck driver heads for the marked intersection entry/exit points. Just the trailer will go over the inner area automatically.

Simple highway exit/entry. Question: How to handle splitting links (split is marked in red)? There are no intersection areas per se in this case. In this suggestion I give lanes before and after the splits an individual lane ID. The emergency lane is modelled as a non-driving lane.

[ghost]

Thank you!

[AndreasVIRES]

Still, we would prefer taking into account the existing and functioning OpenDRIVE lane and intersection model as the basis for the OSI lane model. All shown examples can easily be modeled using OpenDRIVE (we could upload example files for the five examples if desired).

Will there be the announced workshop in 01/18 or has it already taken place?

[ghost]

@AndreasVIRES the workshop has already taken place - please share your proposal. What do you have in mind as a "base version"?

[ghost]

@carsten-kuebler should we include the examples in the images folder and reference them in the doxygen afterwards?

[carsten-kuebler]

@CarloVanDriestenBMW we should add the images afterwards to the documentation.

[carsten-kuebler]

There are road markings - lane 10 and 13. There is also a second junction on the left side (maybe also a third junction on the right).

[carsten-kuebler]

Maybe exit- and entrypoints should be after/before crosswalks?! Lane 11: construcion area should be mentioned. centerline is missing. Lane 2: closed lane because of construction area lane 11 should be mentioned. Warning signs should be mentioned. Lane 12: center line is missing. construction area... Lane 20: center line should not start at the beginning (compare line 18/19). Junction 21: warning signs should be mentioned (lane 12 --> lane 11. Lane 17: There is an additional lane.

There are also cycle paths...

[carsten-kuebler]

Maybe an other splitting link should be used at the beginning of the emergency lane.

[carsten-kuebler]

How should we handle the construction area and additional lane boundaries of the non drivable lanes?

[carsten-kuebler]

Is the lane boundary between lane 4 and 5 correct. Diagonal road markings are no lane boundary?!

[ghost]

@AndreHildebrandt and @MHerrmannIPG can you answer these questions?

[AndreHildebrandt]

@carsten-kuebler: general: Within the examples I marked only lane-ids, corresponding centerlines of driving-lanes, intended driving-direction, lane boundaries (without ids), entry points, and exit points at intersections. In order to avoid confusion all other information (for instance road markings, construction markings, traffic signs, etc.) have been neglected. As I understood, the aim is to get a rough overview of several crossings, in order to evaluate the new lane information. Also centerlines for non-driving lanes have been neglected, since they are not necessary and don't posses entry or exit points at intersections. Of course I can extend the sketches, if required. Small intersection in a city: You are right, I didn't even notice. This also depends on the interpretation of driveways. I see 3 different options: a) as it is sketched, driveways are not considered. b) an additional non-driving lane, short but wide. c) an intersection. How would you do this? I think within the workshop we talked about this, with the end of having intersections at each driveway. Is this correct? If so, I will add the crossings.

[carsten-kuebler]

@AndreHildebrandt Do non-driving lanes have center lines? I think only driving lanes have center lines! Carlo van Driesten suggested adding the examples to the documentation. To avoid misunderstandings, maybe we should crop some example images?! My understanding within the workshop was, that b) is our preferred modelling of driveways to handle complexity of maps. b) allows extraordinary scenarios (drive around an obstacle on the ego lane) and normal scenarios require no complex interpretation of many intersections (compute ego lane, "assign" free lane boundaries to right and left lane boundaries, ...). Additional driveways normally have no road markings, have only natural lane boundaries and access is "prohibited" for most vehicles.

[Markus-Philosys]

@CarloVanDriestenBMW @pmai I would be glad, if the (doxygen) documentation would contain some pictures describing the intersection part as discussed in this issue.

[ghost]

@carsten-kuebler Can we talk about the spots in the documentation that could make use of pictures?

solved by #110