Document direction of LaneBoundaries

[tbleher]

The documentation is currently silent with respect to the orientation (i.e. the order of points) of a lane boundary attached to a lane. In other words: it is not described whether going along the points of a lane boundary follows a lane in driving direction or not.

As an example, assume a simple country road:

------------lb1------------
            <-- l1
- - - - - - lb2 - - - - - -
            --> l2
------------lb3------------

Currently the order of points inside the lane boundaries is not described. I think this should be fixed, to make implementation easier.

A few possibilities:

1. All boundaries have the same direction (in this example from left to right or from right to left). This direction could match the OpenDRIVE road direction. It has the advantage that different directions can share the same lane boundary (e.g. both l1and l2 can reference lb2), but the disadvantage that boundary direction and driving direction is not necessarily the same. Would probably need a flag in the LaneClassification to tell whether the lane boundary goes into the same direction as the driving direction.
2. All boundaries match the driving direction. This would mean that l1 and l2 could not share lb2. This has the advantage that it is easy to determine the driving direction, but the disadvantage that it is no longer easy to see which lanes have a common boundary. It also bloats the data to be stored.
3. Lane boundaries go into the driving direction, except for the line between different directions. This would probably be the worst option, since it means that either l1 or l2 has two boundaries which are defined in two different directions.

I think it is important that all boundaries of a lane go into the same direction. This rules out option 3. I could live with both option 1 or option 2. It would be good if the standard clearly said which of the options should be used, so all fill in the same (and driver models have to support only one of the options).

[tbleher]

OK, I re-read the description for Lane::Classification::left_lane_boundary_id. If I understand the description correctly, this rules out sharing lb2 between l1 and l2, since the description says that a left lane boundary may only be shared with a left neighbor as a right boundary, but in this example, lb2 would be a left boundary for both.

This mostly leaves option 2 as being compatible with the current description, though it still leaves open the possibility that the direction is swapped. It would be good if this could be clarified in the documentation.

[HendrikAmelunxen]

As discussed in the harmonization workinggroup today we understand it like this:

• The order of the centerline points on lanes of the same road should be the same.
• Based on the order of the centerline points, it is defined what is left/right and what are antecessor/successor lanes.
• The centerline_is_driving_direction-flag determines in which direction the traffic participants move within the lane.

The following picture shows an exemplary country road with two lanes:

For right-hand traffic it holds:
Lane 1:
• Left_lane_boundary: lb1
• Right_lane_bounary: lb2
• Right_adjacent_lane: lane2
• Centerline_is_driving_direction: false
Lane 2:
• Left_lane_boundary: lb2
• Right_lane_bounary: lb3
• Left_adjacent_lane: lane1
• Centerline_is_driving_direction: true

Are we missing anything? If not, this might be included in the documentation.

[clemenshabedank]

Hey @HendrikAmelunxen I know we have discussed it like that, but after re-reading the proto-description I think it doesn't match it and wouldn't be backwards compatible. So I think we can't change it like this vor Release 3.3.
It states

       // List of IDs of all lane segments that are directly adjacent to the
       // lane on the right side (w.r.t. intended driving direction).

So explicitly stating "w.r.t. intended driving direction" it must be yet like this to be consistent to current implemenations I think:
Lane 1:
• Left_lane_boundary: lb2
• Right_lane_bounary: lb1
• Left_adjacent_lane: lane2
• Centerline_is_driving_direction: false
Lane 2:
• Left_lane_boundary: lb2
• Right_lane_bounary: lb3
• Left_adjacent_lane: lane1
• Centerline_is_driving_direction: true

With this description lb2 is then allowed to be shared:

        // The left adjacent lane boundaries \c #left_lane_boundary_id may only
        // be shared with/as the right adjacent lane boundaries \c
        // #right_lane_boundary_id of the nearest left adjacent lane \c
        // #left_adjacent_lane_id.

So Left/Right would not be clear just from the ascending/descending order of points but only with the combination of Centerline_is_driving_direction.

The question that currently arises to me is: how is Right/Left for lane boundaries and adjacent lanes then specified for lanes without a centerline, e.g. Non-Driving lanes?
Am I missing something here?

Anyways I think the convention of consistent ascending/decending point order with OpenDRIVE roads is useful I think, as well as a picture to visualize. There seems to be misunderstanding for a lot of people.

[clemenshabedank]

I have to correct something: I think here the sharing lb2 (for this case: adjacent lanes without the same driving direction) is not really handled by the current description. Here, I think the documentation should be clear to cover this case.

[HendrikAmelunxen]

First of all here is an enhanced picture of the road layout with the driving direction information included here.

The quote from @clemenshabedank shows, that the sharing of the dashed line for lanes with different driving directions is not allowed. So the currently only allowed way to describe such a situation is to double the laneboundary information of the dashed line, which does not really makes sense to me.

Furthermore linking the left/right/antecessor/successor definition to the driving direction does not work for the planned new lanetypes like sidewalks, which have no explicit driving direction.

In my opinion it would be helpful, also with repect to the OpenDRIVE harmonization, to exclude the driving direction from the left/right/antecessor/successor definition. The centerline point-sequence follows then the s-coordinate from an OpenDRIVE point of view, whereas the direction of the point-sequence is the same for all lanes of the OpenDRIVE road.

To sum up:
I would prefer to change the left/right/antecessor/successor definition by excluding the driving direction. By this the doubling of the middle-line can be avoided, the left/right/antecessor/successor definition would be valid for lanes without explicit driving direction (as long as they have a centerline) and the transformation from OpenDRIVE => OSI would become easier and more consistent.

[clemenshabedank]

From the point of harmonization with OpenDRIVE it sound compelling to me. Another advantage would be, that we would be able to express left/right laneboundaries for Non-Driving lanes (without a center line).

Yet, my concerns:

• We wouldn't have backwards compatibility, correct?
• Another potential risk I think would be that the user / sensormodeller might be confused that the right lane boundary can be the left boundary (and vice versa) from a vehicle's perspective (e.g. image lane1). This would have implications on sensor model implementations I guess because they would probably need to change the calculations for DetectedLaneBoundary. (I don't think we should change those definitions analogously, because here I think we really want right/left in the sense of the ego's perspective).

@tbleher @TimFrickeBMW @ThomasNaderBMW @jdsika @pmai maybe you also have ideas...

[TimFrickeBMW]

It seems difficult to unify the GroundTruth and the SensorData point of view.

"Intended driving direction" is an interpretation of lane boundaries, road markings, traffic signs, the country, etc. To me, it makes sense in SensorData but not in GroundTruth.

In my opinion, defining left/right/antecessor/successor by the sorting of array elements (lane boundary / centerline points) instead of the "intended driving direction" has more benefits than disadvantages.

• (+) Doubling of the middle-line can be avoided in cases like the one above
• (+) Valid for lanes without explicit driving direction, e.g. non-driving lanes (or even all lanes in GroundTruth in my opinion)
• (+) Follows same approach as OpenDrive
• (-) Loss of backwards compatibility. I do not regret that much because I find the current definition slightly flawed.
• (-) Loss of intuitiveness. I think the "intuitiveness" of the current definition gives everyone a false sense of security, as if nothing could be misunderstood. What if my sensor moves against the "intended driving direction" during some overtaking maneuver? All of a sudden left and right change sides and no one has anticipated it.

[tbleher]

Speaking as one who maintains both a simulation tool and a pedestrian model based on OSI, I would prefer if OSI followed OpenDRIVE here (i.e. option 1 in the ticket, and in agreement with the last comments of @HendrikAmelunxen, @clemenshabedank and @TimFrickeBMW), even if it means a slight incompatibility compared to previous versions.