fix: the type error after vehicle lights implementation

[buraktiryaki]

The "vehicle_classification" field could sometimes return null even when it was present (if obj is pedestrian). This bug has been fixed in this PR.

[jdsika]

Shouldn't the name be rather "hasLightState" as that is what is checked? I am also wondering why you mention the StationaryObject here?
I am also questioning if the lightstate is actually sufficient as it is allowed to have e.g. only the field: license_plate_illumination_rear filled out without a break light state?
I am quoting Thomas:

This should be checked again. Pedestrians or animals usually don't have lights at all and in my opinion it should also be allowed to have incomplete OSI data (vehicles without light definitions) and still be able to render the rest of the object.

In which situations is this feature supposed to be used and when should the lights be rendered? I Would say the moment the state in that field is set and not undefined?

[buraktiryaki]

Null checks were separated out specifically. Now it is checking for brakelights and indicator lights only and if they are not defined or null we are not rendering any of lights.

For mentioning StationaryObject:
osiObject can be also StationaryObject
https://github.com/lichtblick-suite/asam-osi-converter/pull/119/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R95

[jdsika]

TODO: Please create a follow-up PR for some unit tests

[thomassedlmayer]

The changes of this PR only partially solve the issues I recently mentioned.

If I understand the code correctly, both hasBrakeLightState and hasIndicatorState only return false if

• the passed object's light_state is undefined (meaning it has no light state at all), or
• the passed object's vehicle_classification is already undefined which should be the case for
  • stationary objects,
  • pedestrians,
  • animals,
  • vehicles that don't have vehicle_classification.

So for those situations, the lights are not rendered at all, which is correct.

Though, if the object is a MovingObject which contains partial light states, it returns true because of protobuf semantics (independent of proto2 or proto3):

All basic typed fields (string, int, enum, etc.) of a protobuf message are deserialized to their default values if they are not explicitly set, e.g.:

• indicator_state is explicitly set to INDICATOR_STATE_OFF.
• All other enums in light_state are not set during serialization.
• All unset enums are deserialized as GENERIC_LIGHT_STATE_UNKNOWN (0) which is not equal to undefined!

This means that in the above example obj.vehicle_classification?.light_state?.brake_light_state != undefined should actually evaluate to true, as it is NOT undefined. Hence, if any light state is set (could also be the head light or whatever), both indicator and brake lights are visualized (probably with their off state).

@buraktiryaki @jdsika