-
Notifications
You must be signed in to change notification settings - Fork 131
Feature/issue 544, 577, 578, 255 Weather Conditions #582
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
Conversation
…onditions to OSI and changed emuns to double values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I wonder if this PR is trying to tackle too much at once.
There are some uncontroversial additions within this PR, specifically the new data such as Wind
, CloudState
, and Sun
. Perhaps it would be beneficial to split those into a separate PR which can get merged more easily into master
and then create new PR which addresses the more controversial issue of how to extend what are currently single fields. In particular, that may require separate PRs to get merged into a 3.x and 4.x release stream if breaking changes are desirable in the long-term.
// | ||
// \note Defines the cloud states according to OpenScenario 1.1 | ||
// | ||
optional CloudState cloud_state = 10; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest CloudState
should be a message which contains the current CloudState
enum.
It isn't required now but is more robust to wanting to extend how cloud state is described in future. (if all the other fields in this structure had done that originally this PR probably wouldn't exist 🙂)
osi_environment.proto
Outdated
// | ||
// \note Describes the wind speed and direction from OpenScenario 1.1 | ||
// | ||
message Wind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This Wind
message is never used anywhere, should there be an optional
field referencing it above?
I should also say, I'm happy to help with making those changes and PRs, but I didn't want to step on anyone's toes, if it would be helpful though, let me know. |
Is this planned to be done in 4.0? Maybe have a clean breaking change then extending strangely in order to align with OpenSCEANRIO 1.x and OpenLABEL? Is there already a decision here? |
@jdsika I would agree with that suggestion. There are some completely new parts that I think we could safely and sensibly include in 3.x, but I would agree that it would make more sense to make a breaking change to do this "properly" for the existing fields in 4.0. |
So I would leave out "XY Extended" and add the easy ones from OSC1.X. Is it "sun" e.g.? What is the status of the debate regarding "cloudState"? Could you remove the ones we agree to propose for 3.X here, clean it up (there are some errors from deleting and adding the same messages -> rebase completely), create a draft with tag 4.0 from this one and add the others to a separate PR, please? |
@kmeids do you think my proposal is agreeable? I think we should also have a quick look in the compatibility with the tag list from OpenLABEL Public Review here as well. The goal should be a harmonized feature set which is not necessaryly loss free transformable (not needed IMO) but compatible in a sense like "sun from the front of the car" is able to be derived from "sun angles and ego vehicle position". |
Hello everyone, |
Changed the sun to a StationaryObject Update after meeting and new input given of the Sensor Group
message Precipitation | ||
{ | ||
// The intensity of the precipitation (valid for all precipitation types). Unit [mm/h]. Range [0...inf[ | ||
// According to OpenScenario 1.1 and according to the context of ISO 2315 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
23150 ? Missing 0
// | ||
AMBIENT_ILLUMINATION_LEVEL4 = 5; | ||
CLOUD_STATE_SLIGHTLYCLOUDY = 5; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think should be CLOUD_STATE_SLIGHTLY_CLOUDY
Waiting for 4.0 may make sense. |
I recommend to leave the ENUMS in the v4.0.0 and add a DEPRICATED comment above. I think it is better to evaluate with user behavior if the new description is accepted. The only important point is a note that both fields should be set and you need a transformation rule. But I think this is easily done. |
@kmeids feel free to hand out my email for someone to discuss this in depth as I am not available on Fridays (part time currently). |
Sure, for the first draft for V4.0.0. we can add the idea of @jruebsam from issue #255:
and keep the idea of enums and double values? |
@thomassedlmayer this PR can be closed and not merged. The new PR for V3.4.0 is now PR #593. The PR for V4.0.0 will follow in within the next week |
@stmswald PR should be closed now. |
Signed-off-by: Markus Waldmann markus.waldmann@stud.hs-kempten.de & Markus Pauly markus.pauly@stud.hs-kempten.de
Reference to a related issue in the repository
#544
#577
#578
#255
Description
Introduction of the use of continuous values instead of enums for several weather-values.
More Information: See description in the several Issues.