OpenSimulationInterface
Handling of dead-end roads in LanePairings
With the introduction of LanePairings, I'm not quite sure how to handle dead-end roads. Is it allowed to assign an ID of -1 to one of the components?
@ReinhardBiegelIntech That thought crossed also my mind and I would say no! E.g. can you imagine a road which ends and you are not able to turn? If you are able to turn, there is a LanePairing!
@carsten-kuebler I see your point. But wouldn't this assumption imply that we need to specifiy a lane pairing for every left/right adjacent lane along the road? You are always able to turn, not just at the end of the road.
how do you handle this situation @Markus-Philosys or @ppannusch ? In principle I agree with @ReinhardBiegelIntech BUT I could imagine that a dead end where turning is allowed has an "intersection" at the end!
I wouldn't handle the possibility of turning by sending corresponding lane pairings, that#s crazy. The AD function has to imply from road markings, traffic rules etc if it can turn. Same for dead-end. I don't see why would have to do anything about it?
No, that is not my point. You don't have only one lane, you have "always" two lanes. At the "dead end" of your lane you can always turn or change your driving direction. So you would drive on the second lane (maybe the second lane superpose the first but has an other center line).
The only "dead end" lane for a vehicle is a auto graveyard.
Modelling a lane with two driving directions means two OSI lanes with same OSI laneboundaries but two different center lines.
At the "dead end" there could be also a turn around area defined with one lane.
DetectedLanes have only lanePairings, if there is a detected Lane, otherwise there is no lanePairing (at this moment)....
@ppannusch
The problem is that the LanePairing requires an antecessor and an successor to be specified. As we see from the example of a dead-end road this isn't possible in every situation. So when we stick to the current definition of LanePairing we would have to clarify how such situations are to be handled. I could imagine using @CarloVanDriestenBMW 's solution with an intersection, but my preference would be a short connecting lane at the dead-end.
I illustrated both of my proposals for narrow roads (the narrow road is modelled with 2 lanes with the same lane boundaries).
LanePairing is possible for both proposals.
If you don't modell both lanes you may get a dead lock for AD?!
- I think the "-1" in the LanePairing indicates that there is no successor or antecessor in two situations: Either there is really none e.g. you model a straight "autobahn" partially and there is really no way to turn because of the LaneBoundary structure (ghost driver). OR the GroundTruth does not send the the other successor or antecessor because it is "out of scope" but existent!
- I think both visual examples are critical because they indicate a center line which is not existent (and not clearly defined how it should be modelled?)
- We could define a dead end which has the possibility to turn as a square "intersection" element with no center line with the width of the road. Then a driver model could find a possible path to turn? BUT i mean they can always turn when there is a neighbouring lane with no structure in between?
I think this issue needs further refinement. Therefore, I'll postpone it to OSI 3.1.0.
We also stumbled upon this issue when building partial networks (as mentioned by @CarloVanDriestenBMW ). There you have a start and / or several endings, which by definition don't have LanePairings. I would suggest to just define no LanePairing at all there. Then you know that whenever a lane has no LanePairing, it is the end of a network. As far as I understood LanePairings are intended to support validation of algorithms, but the scenarios are defined irrespective of them. So my gut-feeling is that such a definition wouldn't have side effects.
In case of dead-end roads I would handle like illustrated by @carsten-kuebler in order to distinguish them from Endings/Starts of road networks.
I strongly disagree with the proposal of @AndreHildebrandt, because as a result the road network could not be re-constructed starting from the dead-end road.
From my perspective, the ability to re-construct the road network from OSI-GT or OSI-SD is necessary and at the same time sufficient. The "driving direction" information with the centerline is only required because "left", "right", "antecessor" and "successor" would be meaningless otherwise. Hence, I also disagree with the idea that there must always be at least two lanes or that all possible vehicle trajectories (lane changes) muse be modeled by lane links (@carsten-kuebler).
Finally, I cannot find any requirement that both an antecessor and a successor must be specified (@ReinhardBiegelIntech). So applying an ID of -1 in case of non-existence does not make sense to me. In my opinion, a LanePairing may well have only an antecessor_lane_id and no successor_lane_id, or vice versa.
Whether a dead-end lane (an actual dead-end or part of a partial network) should have an antecessor and no successor or should have a successor and no antecessor depends on its driving direction and where the dead-end is.
I agree with @TimFrickeBMW that the existence of only successor or only antecessor would perfectly make sense. The idea of assigning -1 came up since it is (to my understanding) convention to always set all fields of a OSI message - unless stated otherwise. The documentation of GroundTruth says:
To provide a complete interface, all fields of all contained messages must be properly set unless specifically stated in the field’s definition that the field may remain unset.
For the lane_pairing field, such an exception is not defined.
According to the definition of Identifier, -1 is the reserved value for "invalid ID or error" which I think would fit the semantics of i.e. "there is no lane successor here".
I learned that if the OSI-sender omits a field, the OSI-receiver may read a zero instead (protobuf seems to work that way). The receiver would have to explicitly check for the field's existence.
ID = -1 (or, actually, 2^64 - 1) therefore seems to be the better solution.