ISO23150 compliance: Shift geometry from DetectedMainSign to MainSign

[FlorianMueller87]

Describe the feature

ASAM OSI and ISO 23150 or AUTOSAR ADI have a common history. Unfortunately, the inner structure, the naming and the definitions of the standards are differentiated from each other. This makes the work of developers unnecessary complicated for mostly no technical reasons. All sides should strive to reduce inequality.

ASAM OSI need to shift Geometry geometry from osi_detectedtrafficsign – DetectedMainSign to osi_trafficsign – MainSign to be compatible with AUTOSAR ADI MainSignClassification.

Describe the solution you would like

Shift Geometry geometry from osi_detectedtrafficsign – DetectedMainSign to osi_trafficsign – MainSign

   // The estimated geometry of the traffic sign.
   //
   optional Geometry geometry = 4;

       // Definition of traffic sign geometries.
        //
        enum Geometry
        {
            // Geometry of the traffic sign is unknown (must not be used in
            // ground truth).
            //
            GEOMETRY_UNKNOWN = 0;

            // Geometry of the traffic sign is unspecified (but known).
            //
            GEOMETRY_OTHER = 1;

            // Traffic sign has a circular geometry. (0 corners)
            //
            GEOMETRY_CIRCLE = 2;

            // Traffic sign has a triangular geometry pointing to the top. (3
            // corners)
            //
            GEOMETRY_TRIANGLE_TOP = 3;

            // Traffic sign has a triangular geometry pointing down. (3 corners)
            //
            GEOMETRY_TRIANGLE_DOWN = 4;

            // Traffic sign has a square geometry. (4 corners)
            //
            GEOMETRY_SQUARE = 5;

            // Traffic sign that has a pole geometry. (height is bigger than
            // width e.g. pole indicating highways exit in xx m). (4 corners)
            //
            GEOMETRY_POLE = 6;

            // Traffic sign has a rectangle geometry. (width is bigger than
            // height e.g. one-way) (4 corners)
            //
            GEOMETRY_RECTANGLE = 7;

            // Traffic sign that has an oversize rectangle geometry. (4 corners)
            // E.g. direction plates on highway or city signs.
            //
            GEOMETRY_PLATE = 8;

            // Traffic sign has a diamond geometry. (4 corners)
            //
            GEOMETRY_DIAMOND = 9;

            // Traffic sign has a geometry of an arrow pointing to the left. (5
            // corners)
            //
            GEOMETRY_ARROW_LEFT = 10;

            // Traffic sign has a geometry of an arrow pointing to the right. (5
            // corners)
            //
            GEOMETRY_ARROW_RIGHT = 11;

            // Traffic sign has an octagon geometry. (8 corners)
            //
            GEOMETRY_OCTAGON = 12;
        }

Describe alternatives you have considered

No alternative was considered.

Describe the backwards compatibility

Instead of shifting it should be also possible to copy Geometry. For the next releases both variants could be used.

Additional context

ISO23150:2021 A.2.107 Sign geometry
@ThomasNaderBMW @jdsika @schmidtlorenz

[pmai]

Besides the general reservations that I have with the approach to ISO 23150 that I see (i.e. unclear use case), stuff like this seems particularly unclear:

• This would move obvious sensor-specific output (i.e. Detected information) into GroundTruth which always should be considered carefully.

• The major change would be the addition to GroundTruth, which ISO 23150 by definition is not intended to have any opinion on (it is a sensor output interface description), with no real change to SensorData, since it already has that information.

Besides any other problems these issues raise this brings me back to the lacking use case for the detail obsessed harmonisation being proposed here: In most use cases where ISO 23150 or ADI plays a role, the sensor model should be producing ADI output directly, instead of (or in addition to) OSI SensorData (given that OSI is not used in the vehicle).

In the few use cases where bridging of SensorData to ADI/ISO even makes sense, mapping stuff like the above is trivial to do.

All other use cases do not care at all about any of this.

So in order to get started on the whole harmonisation issues, clear goals and use cases need to be defined first, otherwise this effort is heading nowhere, it seems to me.