Environmental Conditions

[jruebsam]

Hi,

in the Current OSI implementation the Environmental Conditions like Rain, Fog, etc. are defined by enumeration....

So for example the definition for precipation is like:

 enum Precipitation
    {
    // Intensity of precipitation is unknown (must not be used in ground
    // truth).
    //
    PRECIPITATION_UNKNOWN = 0;

    // Other (unspecified but known) intensity of precipitation.
    //
    PRECIPITATION_OTHER = 1;

    // No precipitation, when I in [0,0.1[ [mm/h]
    //
    PRECIPITATION_NONE = 2;

    // Very light intensity of precipitation, when I in [0.1,0.5[ [mm/h]
    //
    PRECIPITATION_VERY_LIGHT = 3;

    // Light intensity of precipitation, when I in [0.5,1.9[ [mm/h]
    //
    PRECIPITATION_LIGHT = 4;

    // Moderate intensity of precipitation, when I in [1.9,8.1[ [mm/h]
    //
    PRECIPITATION_MODERATE = 5;

    // Heavy intensity of precipitation, when I in [8.1,34[ [mm/h]
    //
    PRECIPITATION_HEAVY = 6;

    // Very heavy intensity of precipitation, when I in [34,149[ [mm/h]
    //
    PRECIPITATION_VERY_HEAVY = 7;

    // Extreme intensity of precipitation, when I in [149,infinity[ [mm/h]
    //
    PRECIPITATION_EXTREME = 8;
}

From my point of view this is not a good approach.. Lets say I want to build a Sensor Model reacting to different Precipitation levels in this case it would be much easier to define a single continous variable i.e. in [ 0, 1]. As a result the model will have a continous shift in its detection state/range.

It would be nice to get your opinion on this,

BR Jonas Ruebsam

[ghost]

I don't really see a problem here:

• The motivation for the use of enumerations is the visualization of sizes and values.
• The assignment of numerical value ranges provides a reference to physical quantities.
• Values in an enumeration can always be adressed using their indices, i.e. 0-8 in this case.

Do you see any other advantage in using plain numerical values?

[jruebsam]

Hi , thank you for the FB

The motivation for the use of enumerations is the visualization of sizes and values.

What exactly do you mean by this ?

My problem with the enumeration is that you don't have a continous state in your environmental conditions.

Lets say you want to build a phenomenological sensor model, which takes your precipitation level and returns a maximum detection distance. In case of a floating point variable you can have a continous and differentiable function this will not be possible with enumeration. In the latter case your detection range will have steps i.e. your detection range will drop from 100m to 80m when the precipitation level changes. So overall you will have a non-continous detection function

[ghost]

To put it in other words: The use of enumerations has an illustrative purpose.

The indices of the "steps" represented in the enumerations are continuous - so it comes down to a matter of discretization. Of course, a floating point number would allow a higher resolution. However, the question is whether the amount of (local) precipitation should be defined (modeled) in a range or as a fixed quantity.

[ghost]

There are a lot of models which use such classified values for e.g. "Mean Clutter Reflectivity Models".

M.M. Horst and M.T. Dyer, F.B.and Tuley. Radar sea clutter model. In URSI Digest, 1978 Int. IEEE AP/S URSI Symp., pages 6–10, 1978.

[goretkin]

I am also wondering, why discretize (and spend effort naming) specific ranges. One good reason reason is to avoid unnecessary significant figures. You may not expect your phenomenological sensor model to be sensitive to the precipitation measured in mm/hour any differently between 40 and 50 mm/h (both are PRECIPITATION_VERY_HEAVY). I would not trust a model that claims it behaves qualitatively different between 40 and 41 mm/h.

However many of these enums directly map to the continuous value. I believe it is cumbersome, and for no gain, to choose a discretization of a continuum.

I could understand if Precipitation was intended to be a qualitative measure. A qualitative measure might therefore be defined by "very light" or "moderate". But these are quantitative specifications of the environment... so I would expect to use a quantity.

At the risk of imposing my own discretization on what really is a continuum (:-)), we must choose "qualitative" or "quantitative". Either

1. the sensor models that consume OSI Environmental Conditions are intended to be qualitatively accurate, in which case the numerical range of precipitation a weak guideline, or
2. the model is intended to be quantitative, in which case, why not use a quantity to describe inputs to quantitative models?

Right now it seems like the benefit of the environmental enums is to equivocate (in a positive way) whether these phenomenological sensor models are quantitative or qualitative. If this is the case, are there any references?

[jdsika]

Right now it seems like the benefit of the environmental enums is to equivocate (in a positive way) whether these phenomenological sensor models are quantitative or qualitative. If this is the case, are there any references?

I in general agree with your observation! I think I can only reference my own experience and work on radar clutter models. The line between quatitative and qualitative is quite blurry - you want it to be quantitative but if you let someone measure rain in a measurement trial in order to validate if your modell corresponds correctly you will mostly realize that the accuracy of a rain measurement under most condition only leaves you with the possibility of a rough categorizations. The idea of introducing categories was to reference existing ones which are first of all not invented by me and second with the idea that I am already telling the reader: "you can try to be more correct but I bet it is not really possible or useful"

It would be great to have someone disproving my hypothesis!

[kmeids]

Hello everyone, One year after the creation of this issue, this request (double value representation of precipitation) is still being asked by different users, which is basically saying the current "Enum" definition is not sufficient.

Is there maybe a way to include both? Or any other suggestions on how to handle this request?

This issue is a result of the Sensor Modeling Working Group meeting that took place on 27.08.2020.

[jruebsam]

Hi everyone,

my proposal would be to separate this into two values e.g.

precipitation.label -> Enum
precipitation.state -> Double

im not sure about the best naming convention though...

Cheers

[ClemensLinnhoff]

I fully agree with @jr7. I have measurements showing the different influence of precipitation intensities within one class in OSI. They either need to have smaller discretization steps or even better just use double values, as proposed.

I really don't see a reason to use enums for some values and doubles for others. Temperature is also not just classified as cold, medium and hot. If some users really need these classifications I would agree to just add the double values as proposed. If no one is using them, I propose to remove the classifications in the next major release for simplification reasons.

[kmeids]

@jruebsam , Is this something that you would like to further discuss in the next SensorModeling meeting?

[jruebsam]

Hi Kmeid, do you know the last status of this item? I remember we had some internal discussion about this... BR Jonas

[PhRosenberger]

@LukasElster is there any activity on this from sensor modeling working group side?

[LukasElster]

Not yet. I asked @ClemensLinnhoff if he could look at it, but he won't be able to until some time in the future.

[PhRosenberger]

Not yet. I asked @ClemensLinnhoff if he could look at it, but he won't be able to until some time in the future.

Ok, we will now try to wade through the jungle of related PRs and issues and then hopefully get some momentum going on this topic.

@jruebsam, are you still interested in this topic? If so, I would like to include you in the discussions once we have an overview. Ok?

[jruebsam]

Sounds good, thank you!