-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environmental Conditions #255
Comments
I don't really see a problem here:
Do you see any other advantage in using plain numerical values? |
Hi , thank you for the FB
What exactly do you mean by this ? My problem with the enumeration is that you don't have a continous state in your Lets say you want to build a phenomenological sensor model, which takes your precipitation |
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. |
There are a lot of models which use such classified values for e.g. "Mean Clutter Reflectivity Models".
|
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 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 At the risk of imposing my own discretization on what really is a continuum (:-)), we must choose "qualitative" or "quantitative". Either
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. It would be great to have someone disproving my hypothesis! |
Hello everyone, 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. |
Hi everyone, my proposal would be to separate this into two values e.g. precipitation.label -> Enum im not sure about the best naming convention though... Cheers |
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. |
@jruebsam , Is this something that you would like to further discuss in the next SensorModeling meeting? |
Hi Kmeid, |
@LukasElster is there any activity on this from sensor modeling working group side? |
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? |
Sounds good, thank you! |
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:
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
The text was updated successfully, but these errors were encountered: