Documentation Update Collection - Clarification Static vs Dynamic data

[thempen]

In the PR #768, an update on static an dynamic data should be made.
Therefore the documentation on the data types will be updated.

This Issue will be the central collection of Q&A on the static or dynamic data description.
Please add questions, suggestions or answers to support this approach.

Currently used cocumentation notes:

• Dynamic value: The value can change while simulation
• Static value: The value will never change while simulation
• Depending: The changeability is depending on other aprameters within OSI. The depending value must have a description and a reference to the influencing parameter.

[thempen]

Here I will add some thoughts on different message parameters:

osi_trafficsign.proto
MainSign.Classification.variability
I would mark this as a static value, that is not allowed to change through a simulation. If this value could change, wouln't this corrupt the idea to have information if a traffic sign is variable or not?
MainSign.Classification.country
I would mark the country, country_revition even when the variability is set. Does anybody know a real use-case where traffic signs would change country information? Is this a use-case at borders?

[thempen]

osi_trafficupdate.proto
Traffic update is by default dynamic/changing.
Just the version is marked as static.

[thempen]

osi_trafficlight.proto
Traffic lights do (currently) not have a variability like traffic signs, therefore most parameters can not change.
Just TrafficLight.Classification.is_out_of_service, TrafficLight.Classification.counter, TrafficLight.Classification.mode are marked as dynamic.

[thempen]

osi_trafficcommand.proto and osi_trafficcommandupdate.proto
will both not be edited. These are event messages by default, which would just be sent sporadic.

[FabianPfeuffer]

Hm, I have some doubts about the current approach. As you mentioned in the pull request:

In many cases, it is unclear if data changes, or not. E.g., will the road geometry change? In the reality - probably not.

it is indeed not clear what label a variable should receive. For some variables like the ID or the version it might be clear that they're static, but things like obstacles, traffic lights, signs or even logical lanes might not necessarily be static.

In general, I'm a bit unsure about the use-case here. Why do we actually need these labels?
During the initialization of a new OSI receiving application, it should get a GroundTruthInit from the simulator, which contains all (or at least all static) data. Afterwards, the application can give a "omit_static_information" request to the simulator via the SensorViewConfiguration, so the application knows that all data it receives during runtime will be dynamic. This allows the simulator/scenario developer themselves to decide what is static data and what is dynamic data, as it probably should be.

It would be good, if you could give me a better understanding about the problem we're trying to solve here.

[Tbenjo3]

osi_trafficlight.proto Traffic lights do (currently) not have a variability like traffic signs, therefore most parameters can not change. Just TrafficLight.Classification.is_out_of_service, TrafficLight.Classification.counter, TrafficLight.Classification.mode are marked as dynamic.

How about the "assigned_lane" value?
There are cases in which the traffic light changes its assigned lane according to a sign prior to the junction.
One can think of an advanced scenario that the sign switches mid scenario

[thomassedlmayer]

The topic was discussed in today's Performance/Packaging meeting:

• Since project ends soon, Thomas Hempen will not continue with this.
• Maybe the GroundTruth initialization with omit_static_information already solves Thomas' issue. He needs to check and see how it works.
• Finding: GroundTruth initialization and omit_static_information is not documented well/at all.
• Actions:
  • @thempen: Document in the issue, what the initial problem was.
  • @FabianPfeuffer: As the one who is most familiar with the GroundTruth initialization topic, Fabian will try to create a PR adding 1-2 sentences to the documentation on how to use it properly.

[thempen]

Hm, I have some doubts about the current approach. As you mentioned in the pull request:

In many cases, it is unclear if data changes, or not. E.g., will the road geometry change? In the reality - probably not.

it is indeed not clear what label a variable should receive. For some variables like the ID or the version it might be clear that they're static, but things like obstacles, traffic lights, signs or even logical lanes might not necessarily be static.

In general, I'm a bit unsure about the use-case here. Why do we actually need these labels? During the initialization of a new OSI receiving application, it should get a GroundTruthInit from the simulator, which contains all (or at least all static) data. Afterwards, the application can give a "omit_static_information" request to the simulator via the SensorViewConfiguration, so the application knows that all data it receives during runtime will be dynamic. This allows the simulator/scenario developer themselves to decide what is static data and what is dynamic data, as it probably should be.

It would be good, if you could give me a better understanding about the problem we're trying to solve here.

Thanks, I got it. This could help for my problem. I wasn't aware of that. My problem for the understanding there was, that it is not referenced to the OSMP https://github.com/OpenSimulationInterface/osi-sensor-model-packaging repo, which specifies the "GroundTruthInit". In that regard, we can try to improve the documentation.