Logical Lanes in OSI

[tbleher]

Adds "logical lanes" to OSI. These logical lanes correspond much more closely to lanes as defined in map formats like OpenDRIVE or OpenLaneModel. Thus they can be used to represent maps more closely in a standard manner.

Logical Lanes make it much easier to implement agent models using OSI as their input. Especially since the logical lanes on intersections can be represented now, fixing a long-known problem when trying to implement agent models using OSI.

The change is backward compatible, so can be added to OSI 3.5.

[clemenshabedank]

I think there is no mention yet, for how many lanes and lane boundaries a reference line should be used and where it should be located. If this is on purpose left up to implementation, probably this needs a mention, otherwise maybe some rules like in OpenDRIVE. The singular use in should roughly have the same shape as the boundary sounds a bit as if each boundary should have its own reference line which I think is not what you intend.

[clemenshabedank]

I think here we might need an even more precise definition of what a logical lane really is / what its boundaries are when not limited by physical lane boundaries (e.g. how wide are the overlapping logical lanes in narrow urban roads?). Or write that this is free for implementations to decide.

While I currently don't have a general approach, I think in intersections it would be quite easy to define (width of ingoing and outgoing lanes) and also for the case you sketch in line 330ff. (width of the preceding and succeeding lanes.

[tbleher]

Hmm, the original purpose of this pull request was to make as much map information as possible available to OSI. So I would rather not define this too strictly, but say something like "lanes from the underlying map should be represented as accurately as possible". I think it is OK to split or merge them like this:

 --------------          --------  ------
 --> lane1       ==>  lane 2  lane 3
 --------------          --------  ------

Splitting them like this doesn't change any semantics. But the widths etc. should not be changed.

Rationale: if we define separate rules, then it WILL diverge from OpenDRIVE, which means that again OpenDRIVE maps cannot be represented in OSI correctly, and implementations will have more effort to convert between different formats.

[tbleher]

@HendrikAmelunxen I have added 34484f4 to explain height changes a little more.
Does that look sensible to you?

I thought about describing the lane height further, but as far as I know, lane surface information (or height in general) is not really described in OSI. I think describing this better belongs to PR #619.

[clemenshabedank]

As you @HendrikAmelunxen and @tbleher state, hight information is planned to come primarily from surface lines (PR619). The x,y,z fields in the lane boundaries and the logical lane boundaries will be a bit of a duplication regarding hight information but they currently carry certain differing requirements (e.g. 5cm rule for curvature). Going forward it could be discussed to reuse the surface lines to describe lane boundaries (partly), i.e. deprecate LaneBoundary.boundary_line and instead point to a surface line.

For the hight profile of curbs there are currently different approaches on the table (incl. PR608 and PR436) while they all seem to have shortcomings. For coming up with a decision we said we needed input from CCB, maybe even ISO23150.

A bit of a problem I still see (and I think @HendrikAmelunxen you might have the same reading your comment above). So thinking the LogicalLane with TYPE_CURB through, we would have no value for LogicalLane.physical_lane_reference (I think), because there doesn't exist a physical Lane of type curb. Then I guess we would have a LogicalLane.right_boundary_id and a LogicalLane.left_boundary_id. But what values should the respective LogicalLaneBoundary.physical_boundary_id and LogicalLaneBoundary.passing_rule have? So probably LogicalLaneBoundary.physical_boundary_id should be empty and LogicalLaneBoundary.passing_rule for the lower edge PASSING_RULE_NONE_ALLOWED. Maybe this PR should be a bit more specific regarding that issue, if it is meant like this. @tbleher what do you think?

[clemenshabedank]

Here a some options on curbs (physical) we already discussed in the Road Model group: Curb_ModellingOptions.pptx

[tbleher]

@clemenshabedank : yes, curbs are a difficult topic. From my POV, the main drivers for modelling curb as a lane are:

1. Compatibility with OpenDRIVE, which also describes curbs as lanes
2. Requirement to cover the whole road surface via lanes -> no gaps between lanes, same as in OpenDRIVE

It doesn't help that map formats are divided on this topic. I did a quick survey:

• OpenDRIVE and RoadXML (used by SCANeR Studio) treat curbs as lanes
• NDS/OpenLaneModel and Lanelet2 treat curbs as boundaries

It looks as if map formats focused on autonomous driving treat curbs as boundaries (since the world ends there from their point of view), while maps that support more agents (both OpenDRIVE and RoadXML are used in simulators that also support autonomous pedestrians and bicycles) treat curbs as lanes. Since OSI should be usable beyond autonomous driving also for modelling other agents, I'm leaning towards treating curbs as lanes.

When filling in the logical lanes, I would expect that LogicalLane.physical_lane_reference is empty, since there is no matching physical lane. I think it would make sense to reference the physical lane boundary either from the left or from the right logical lane boundary (maybe even both?). I don't have a strong preference there.

Regarding the passing rule: that depends on the type of curb. E.g. OpenLaneModel differentiates between CURB and CURB_TRAVERSABLE (plus a host of other types). CURB_TRAVERSABLE is described as "Physical boundary between lane and side of the road. Vehicles may cross traversable curbs in normal traffic situations". Lanelet2 also supports both high and low curbstones, with different passing rules (see https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/master/lanelet2_core/doc/LinestringTagging.md).

[clemenshabedank]

@tbleher thanks for doing this survey on such short notice! It's interesting to see that we can't really harmonize with both OpenDRIVE and NDS at the same time in that regard. To complement this the ISO23150 (where we also have harmonization requirements - in my feeling the strongest) treats curbs also as boundaries AFAIK. Therefore as well as for backward-compatibility reasons I would prefer to leave curbs as (physical) lane boundaries.

Since we probably can't make the decision of potentially changing the (phyiscal) curb to a lane (which I would not prefer) prior to merging this PR I think we should go with the current definition of a curb as a (physical) lane boundary.

Nevertheless since agent models have stronger requirements to harmonize with OpenDRIVE, and LogicalLanes shall be consumed especially by agent models rather than sensor models I think we can and should keep it as it is in this PR (although it is ugly that we treat curbs differently).

So I would suggest to add comments for:

• LogicalLane.physical_lane_reference should stay empty for the curb case -> we seem to agree on this.
• LogicalLaneBoundary.physical_boundary_id: I would find referencing only one (left or right) random. Both is probably better than empty because then there is access to fields of the physical curb (e.g. hight).
• The passing rule currently reads more from a legal perspective. If traversing is possible or safe for vehicles I guess depends on other things like vehicle type and speed, so I would say we better leave it out of scope and up for the agent model to decide. We currently have the hight field for physical curbs, so this information could be used by agent models if needed. So a comment that for LogicalLaneBoundary.passing_rule of LogicalLanes of type curb should always be PASSING_RULE_OTHER might be the best solution.

Do you want me to make an inline suggestion for that @tbleher ?

[clemenshabedank]

And of course @HendrikAmelunxen would that help to clarify?

[tbleher]

@clemenshabedank Thank you for all the sensible suggestions! Yes, an inline suggestion would be appreciated :)

[clemenshabedank]

These suggestions try to fix the issues in #599 (comment)

[tbleher]

These suggestions try to fix the issues in #599 (comment)

Thank you @clemenshabedank for the suggestions! All applied.

[stefancyliax]

OSI CCB 30.03.2022:

• All feedback from BMW was implemented. There was no other feedback that would prevent a merge.
• @tbleher is fixing the DCO
• @stefancyliax to merge

[stefancyliax]

Merging this as decided in the OSI CCB on 30.03.2022