Fog BoundingBox Clarification
Describe the bug
Fog uses the BoundingBox tag for its "area". Within BoundingBox the Center is described with: "Represents the geometrical center of the bounding box expressed in coordinates that refer to the coordinate system of the entity (e.g. the vehicle coordinate system)." (https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/BoundingBox.html) Fog cannot refer to the coordinate system of the entity as it is used within a GlobalAction and it is intended to be set in world coordinates.
Describe how to reproduce the bug
See documentation of Fog: https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Fog.html and documentation of BoundingBox: https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/BoundingBox.html
Describe the expected behavior
Fitting descriptions. So we should either state in the Fog description explicitly that the Center is in world coordinate system or change the description of BoundingBox, so that it does not confuse users.
Activity
- A deleted user
changed milestone to %1.3 & 2.1
- A deleted user
added Actions + 1 deleted label
added isType:Bug label and removed 1 deleted label
assigned to @bhanu.rathore
I agree that the specification of
Fogcurrently is unclear in the UML model. I wouldn't define the center of the bounding box in world coordinates because:- this would be inconsistent with the center point definition and bounding box usage of the entities
- then fog could only be placed in world coordinates without orientation and not conveniently with a
Positiontype
Therefore, I'd recommend to:
- clarify the local coordinate system of Fog (e.g. same as MiscObject with origin at bottom of bounding box) either in the user guide or the UML model
- Add an optional
Areaelement containing a mandatoryBoundingBoxandPositionelement, so the Fog can be placed with allPositiontypes. - Clarify that if the
Areaelement is omitted, then the Fog's area is unlimited across the whole map. - Deprecate the old
BoundingBoxelement inside theFogclass
This makes the changes also backward compatible.
Edited by Andreas RAUSCHERT (BMW Group)
added isState:Accepted label
We can imagine 2 different fogs here: one is global and other is fog banks.
For global fog bounding box does not make sense.
For fog bank we would require several fogs and at the moment you can only have one fog per scenario.
Our suggestion would be just support global fog and deprecate the bounding box.
Should we one day decide to have fog banks we would need to increase the cardinality and as suggested by @Andreas.Rauschert above in point 2 ( Add an optional
Areaelement containing a mandatoryBoundingBoxandPositionelement, so the Fog can be placed with allPositiontypes).Edited by Bhanu RATHORE (Hexagon)-
Group discussion:
- Agreed on concept to deprecate bounding box and introduce area element with cardinality 0..* containing mandatory bounding box and position element.
- @bhanu.rathore will create concepts for UML model change and user guide change (chapter 6.3.5)
Edited by Andreas RAUSCHERT (BMW Group) added UML Model User Guide labels and removed Actions label
Proposed concept
UML model change request
Background
Specification of Fog is unclear in UML model.
Change description
- Deprecate BoundingBox in Fog class
- Introduce new class Area (cardinality 0..*) with mandatory Dimensions and Position element.
Class Fog
Annotation:
Defines fog at simulation runtime.Attributes:
Name Type Cardinality AppliedStereotypes Annotation visualRange double 1...1 XSDattribute Unit: [m]. Range: [0..inf[. D boundingBox BoundingBox 0...1 XSDelement Dimensions and center of fog in fixed coordinates. area Area 0...* XSDelement Detail information about the individual Fog Bank. Class Area
Annotation:
Defines the visual area for a Fog Bank.Attributes:
Name Type Cardinality AppliedStereotypes Annotation position Position 1...1 XSDelement Represents the geometrical center of the entities bounding box. dimensions Dimensions 1...1 XSDelement Width, length and height of the entities bounding box. Backwards compatibility
No, as current class is adjusted and new classes and attributes are added.
Additional context
None.
Edited by Benedikt SCHOTT (Vector Informatik GmbH)Proposed Concept
User Guide change request
Background
Fog element is not defined in User Manual.
Description
The following chapter will be changed to include Fog object in its decription.
Chapter < 6.3.5. Pedestrian / MiscObject coordinate system (Xp/m , Yp/m , Zp/m) >
Original content
6.3.5. Pedestrian / MiscObject coordinate system (Xp/m , Yp/m , Zp/m)
The axis system for a pedestrian (subscript p) or a miscellaneous object (subscript m) is fixed in the reference frame of the object’s bounding box. The X axis is horizontal and normal to the object’s front plane. The Y axis is horizontal, perpendicular to X, and points to the left. The Z-axis points upward.
New content
6.3.5. Pedestrian / MiscObject /Fog coordinate system (Xp/m/f , Yp/m/f , Zp/m/f)
The axis system for a pedestrian (subscript p) or a miscellaneous object (subscript m) or fog object(subscript m) is fixed in the reference frame of the object’s bounding box. The X axis is horizontal and normal to the object’s front plane. The Y axis is horizontal, perpendicular to X, and points to the left. The Z-axis points upward.
Edited by Bhanu RATHORE (Hexagon)Group discussion:
- mention that origin of fog system is also projected onto ground plane (add sentence from 6.3.5 to concept)
- suggestion: keep the original BoundingBox element within the Fog element (no deprecation necessary anymore). Move the Position (with cardinality 0..1) to the Fog element
- If BoundingBox is defined without additional Position, the box center is defined as world position. If position is defined, the bbox center is defined relativ to the defined position. If Position is defined without a BoundingBox definition, the position definition will have no effect
- Still open question: how to define multiple fog banks with different visual ranges
- To decide if we should start describing the fog concept also in the user guide
Edited by Benedikt SCHOTT (Vector Informatik GmbH)
This proposal is fully backward compatible (while the suggestion moving BoundingBox to a new Area element is not).
Regarding multiple fogs: One potential, fully backward compatible, solution is to allow multiple Fog instances. Just clarifying that whenever more than one Fog is used, they all must define a Bounding Box. - not perfect, but maybe good enough.
Sounds good to me. @bhanu.rathore could you please create a 2nd reworked proposal based on the discussion for the next meeting?
Proposed concept 2
UML model change request
Background
Specification of Fog is unclear in UML model.
Change description
- Extend cardinality of Fog to 0..* to support multiple Fog Banks.
- Introduce new element Position in Fog Class (cardinality 0..1).
Class Fog
Annotation:
Defines fog at simulation runtime. If BoundingBox is defined without additional Position, the box center is defined as world position. If position is defined, the bounding box center is defined relativ to the defined position. If Position is defined without a BoundingBox definition, the position definition will have no effect.Attributes:
Name Type Cardinality AppliedStereotypes Annotation visualRange double 1...1 XSDattribute Unit: [m]. Range: [0..inf[. boundingBox BoundingBox 0...1 XSDelement Dimensions and center of fog in fixed coordinates. position Position 0...1 XSDelement Represents the geometrical center of the entities bounding box. Class Weather
Annotation:
Defines the weather conditions in terms of light, fog, precipitation, cloud, temperature and atmospheric pressure states. If one of the conditions is missing it means that it doesn't change.Attributes:
Name Type Cardinality AppliedStereotypes Annotation atmosphericPressure double 0...1 XSDattribute Reference atmospheric pressure at z=0.0 in world coordinate system. Unit: [Pa]. Range: [80000..120000]. The actual atmospheric pressure around the entities of the scenario has to be calculated depending on their z position. See also the Standard Atmosphere as defined in ISO2533. D cloudState CloudState 0...1 XSDattribute, deprecated Definition of the cloud state, i.e. cloud state and sky visualization settings. fractionalCloudCover FractionalCloudCover 0...1 XSDattribute Definition of cloud states using the fractional cloud cover in oktas. temperature double 0...1 XSDattribute Outside temperature at z=0.0 in world coordinate system. Unit: [K]. Range: [170..340]. The actual outside temperature around the entities of the scenario has to be calculated depending on their z position. sun Sun 0...1 XSDelement Definition of the sun, i.e. position and intensity. fog Fog 0...* XSDelement Definition of fog, i.e. visual range and bounding box. Whenever more than one Fog is used, they all must define a Bounding Box. precipitation Precipitation 0...1 XSDelement Definition of precipitation, i.e. type and intensity. wind Wind 0...1 XSDelement Definition of the wind: direction and speed. domeImage DomeImage 0...1 XSDelement Image reference to represent the sky. Mutually exclusive with "fractionalCloudCover". If the image also contains lighting information (HDRi) it is also mutually exclusive with "sun". Backwards compatibility
Yes. Only Position element is added with 0..1 cardinality and Fog element cardinality is extended.
Additional context
None.
Edited by Bhanu RATHORE (Hexagon)-
Group discussion:
- both concepts still have the disadvantage that it's possible to define either only one visual range for all fog banks or it's possible to define a fog bank inside a global fog. Concept needs to be refined here. overlapping fog banks could be allowed. then the user has to take care during definition of the scenario.
- The second proposed concept offers more possibilities to the user to describe invalid definitions and then the standrad must explain what happens in these cases.
- proposal to use the new "area" definition of the first concept, but reduce the cardinality to 0..1 and use the increased cardinality for the fog element 0...* from the second concept.
Edited by Andreas RAUSCHERT (BMW Group)
Proposed concept 3
UML model change request
Background
Specification of Fog is unclear in UML model.
Change description
- Extend cardinality of Fog to 0..* to support multiple Fog Banks in Weather Class.
- Introduce new element Area (cardinality 0..1) in Fog Class with mandatory Dimensions and Position element.
- Deprecate BoundingBox in Fog class.
- Introduce new class Area with mandatory Dimensions and Position element.
Class Weather
Annotation:
Defines the weather conditions in terms of light, fog, precipitation, cloud, temperature and atmospheric pressure states. If one of the conditions is missing it means that it doesn't change.Attributes:
Name Type Cardinality AppliedStereotypes Annotation fog Fog 0...* XSDelement Definition of fog, i.e. visual range and bounding box. Supports multiple Fog Banks Class Fog
Annotation:
Defines fog at simulation runtime. If BoundingBox is defined without additional Position, the box center is defined as world position. If position is defined, the bounding box center is defined relativ to the defined position. If Position is defined without a BoundingBox definition, the position definition will have no effect.Attributes:
Name Type Cardinality AppliedStereotypes Annotation visualRange double 1...1 XSDattribute Unit: [m]. Range: [0..inf[. D boundingBox BoundingBox 0...1 XSDelement Dimensions and center of fog in fixed coordinates. position Position 0...1 XSDelement Represents the geometrical center of the entities bounding box. area Area 0...1 XSDelement Detail information about the individual Fog Bank. Class Area
Annotation:
Defines the visual area for a Fog Bank.Attributes:
Name Type Cardinality AppliedStereotypes Annotation position Position 1...1 XSDelement Represents the geometrical center of the entities bounding box. dimensions Dimensions 1...1 XSDelement Width, length and height of the entities bounding box. Backwards compatibility
No, as current class is adjusted and new classes and attributes are added.
Additional context
None.
Edited by Bhanu RATHORE (Hexagon)-
Here's my review:
- the "Position" element in the "Fog" class must be removed, since it duplicates the "Position" element in the "Area" class.
- the new "Area" class needs the "BoundingBox" element instead of the "Dimensions" element as proposed here: #546 (comment 50880). Otherwise the reference point / origin of the local coordinate system of the fog is not defined.
- the description of the "Position" element in the "Area" class must be changed to: "Defines the position of the reference point of the bounding box."
- the description of the "Area" class must be more generic, so the class can be reused in the future for other purposes. Therefore the terms "Entity" and "Fog" must be removed.
- the description of the "Area" element in the "Fog" class must be adjusted to: "Defines the visual area for a fog bank. If omitted, the fog is interpreted as global fog without borders."
Edited by Andreas RAUSCHERT (BMW Group)
@bhanu.rathore does anyone from Hexagon continue working on this topic for 1.3?
Hi @bschott, i will work on this topic from Hexagon side.
@bhanu.rathore @Andreas.Rauschert are use planning to continue working on this issue for OSC 1.3? If this is case, we would need to approve a final concept until Friday at the latest.
removed isState:Accepted label
