Intended representation of guard rails or barriers in general

[ClemensLinnhoff]

Describe the problem

There are two different approaches to representing barriers in OSI.
A stationary object can be of type barrier as well as a lane boundary. Lane boundaries have a distinction between guard rail and barrier, stationary objects do not.

Describe your research

In OpenDRIVE guard rails, or any type of barrier that follows the curvature of a road, is represented as an object with an outline, for example like this:

<object id="25" name="GuardRail" s="8.9425250584115815e+01" t="2.1041273659654401e+01" zOffset="3.3019998669624329e-01" hdg="-3.1415926530054130e+00" roll="0.0000000000000000e+00" pitch="0.0000000000000000e+00" orientation="-" type="barrier" subtype="guardRail" height="3.0480000000000002e-01" width="8.4376949871511897e-15" length="1.7885050846499973e+02" validLength="0.0000000000000000e+00" dynamic="no">
    <outlines>
        <outline id="1" outer="true" closed="false">
            <cornerLocal u="-8.9425257880883933e+01" v="-1.2880872333198568e-06" z="1.3303756707383485e-08" height="3.0480000000000002e-01" id="1"/>
            <cornerLocal u="-8.6299565230264136e+01" v="-1.2899138113198205e-06" z="1.3303756707383485e-08" height="3.0480000000000002e-01" id="2"/>
            <cornerLocal u="-8.0808164736064754e+01" v="-1.2931228781098980e-06" z="1.3303756707383485e-08" height="3.0480000000000002e-01" id="3"/>
            <cornerLocal u="-7.5316764241865386e+01" v="-1.2963319448999755e-06" z="1.3303756707383485e-08" height="3.0480000000000002e-01" id="4"/>
            <cornerLocal u="-6.9825363747666017e+01" v="-1.2995410259009077e-06" z="1.3303756707383485e-08" height="3.0480000000000002e-01" id="5"/>
            ...
        </outline>
    </outlines>
</object>

To convert this to OSI ground truth, it could either be represented as a lane boundary with every cornerLocal from the OpenDRIVE as a boundary_line. Or it could be represented as a stationary object with every cornerLocal as a base_polygon vector.

In the rather old issue #271 guard rails are implemented as lane boundaries. But esmini implements them as stationary objects using base_polygon.

Ask your question

Is there an officially "correct" way of representing a guard rail from OpenDRIVE in OSI?

[ClemensLinnhoff]

Maybe @pmai, @thomassedlmayer or @jdsika?

[thomassedlmayer]

I assume both ways are the officially "correct" way as they are both present and allowed in the standard. Both ways do work complementarily, so there is not an issue when providing a guard rail/barrier lane boundary AND a barrier object, right? You could even link it using limiting_structure_id.

Though, I don't know if barrier and guard rail/railing are actually interchangeable terms. It is usually a lot safer to crash into a guard rail as compared to a solid barrier based on impact absorption characteristics. We could think about introducing an actual guard rail type in OSI which maps to OSC/ODR "railing". (@jakobkaths This might be something to work on in an harmonized way?)

I could imagine that using the lane boundary type for guard rails might be great for simple "road network-only" use cases, so you don't need to consider stationary objects at all but still have the info that there are guard rails/barriers. An advantage of representing it as stationary object might be increased object details (e.g. material, model reference, base polygon).

[ClemensLinnhoff]

I agree with the potential benefits of describing a guard rail as an object. The only thing that makes it a bit counter intuitive for me is the bounding box. A guard rail in a curve will have a very large bounding box that covers a big portion of the road. In this case it is crucial to also define and use the base polygon. And the base polygon cannot just have the cornerLocal points from the OpenDRIVE, as the base polygon cannot be a simple line. It has to have a width, because the last polygon point needs to be connected to the first.

And I also agree, that there should be an object type guard rail separate from barrier, as there is for the lane boundary.

[thomassedlmayer]

If you put a long curved (or even arched in height) guard rail into a single OSI object you end up with a weird bounding box indeed. If someone wants to represent it as stationary object this could be mitigated by splitting it up into sections, maybe based on some threshold for the maximum deviation between the object’s bounding box and the actual curvature of the continuous structure. As of the current state this seems to be left to the requirements and discretion of the implementer. In that regard, it might be easier to map it to the lane boundary approach.

And the base polygon cannot just have the cornerLocal points from the OpenDRIVE, as the base polygon cannot be a simple line. It has to have a width, because the last polygon point needs to be connected to the first.

You can still build a base polygon from a zero-width object though. You just have to define points back towards the initial cornerLocal point step by step, as you would with a non-zero-width object. Or maybe I didn't get the point?

[ClemensLinnhoff]

Yes you are right, it can also be a zero width polygon.

[ClemensLinnhoff]

I just realized one major drawback of using a stationary object with a base_polygon as a guard rail: If the road has an elevation profile, the height of the guard rail object is wrong, because it has a fixed position and orientation and cannot change its z-positing along the way. This is not a problem with the lane boundary, because each boundary point has an individual xyz-coordinate.