Environmental conditions DRAFT for V4.0.0.

[stmswald]

With this draft the osi_environment.proto gets a major overhaul for OSI V4.0.0.

The basic idea is to move all attributes of the environment to an own message to create new messages easier for all attributes of the environmental conditions.

For now this is done exemplarily for the ambient illumination message.
Within this message there is the old Enum type, but it is easier now to create a numerical value range.

This draft is created and handled by the harmonization group.

TODO's:

• moving all attributes to there own messages
• assignment of numerical value ranges Environmental Conditions #255 Introduction of a additive description for old and new weather conditions #577
• assignment of numerical value ranges AND Enum types Introducing new Fog Model #578
• local environment descriptions Tunnel description in OSI #311
• precipitation type (rain, snow, hail or graupel) Precipitation Classification #415
• fog bounding box Add environmental conditions to bring in line with OpenSCENARIO 1.x #544

Will be for filled by PR #593 and merged into this PR after release of V3.5.0.

• sun description Add environmental conditions to bring in line with OpenSCENARIO 1.x #544
• cloud state Add environmental conditions to bring in line with OpenSCENARIO 1.x #544
• wind direction and speed Add environmental conditions to bring in line with OpenSCENARIO 1.x #544

Related:

• Discussion in Feature/issue 544, 577, 578, 255 Weather Conditions #582
• Discussion in Environmental conditions, added Sun, Wind, CloudState #593

[caspar-ai]

You're missing the actual field value which uses the enum from this message.

For example AmbientIlluminationLevel level = 1;.

[stmswald]

You are absolutely right. I haven't added a field yet, because how to name the ENUM field and how to name the field for the numerical value range?

AmbientIlluminationLevel level = 1
double intensity = 2

[thomassedlmayer]

The enum types should be prefixed with the full enum name and include another underscore right before the actual type. So if the enum name is AmbientIlluminationLevel it should be AMBIENT_ILLUMINATION_LEVEL_1, AMBIENT_ILLUMINATION_LEVEL_OTHER etc.

see https://opensimulationinterface.github.io/osi-documentation/#_interface_conventions

[stmswald]

Right, but then the naming goes like this
AMBIENT_ILLUMINATION_LEVEL_UNKNOWN = 0
...
AMBIENT_ILLUMINATION_LEVEL_LEVEL1
AMBIENT_ILLUMINATION_LEVEL_LEVEL2
sounds wired, how to solve this?
AMBIENT_ILLUMINATION_LEVEL_1
AMBIENT_ILLUMINATION_LEVEL_2
maybe?

[thomassedlmayer]

AMBIENT_ILLUMINATION_LEVEL_1 would not sound too bad, I think. Though, I don't know if we actually need the "AmbientIllumination" term in the types if the enum is located within the AmbientIllumination message anyway. Maybe we could name the enum Level and have the types LEVEL_UNKOWN, LEVEL_OTHER, LEVEL_1...LEVEL_9? It has been done similarly with Type, Material, etc. in other messages like StationaryObject.