Repository navigation
Is SensorDataSeries as top-level message? #900
Description
Describe the problem
I recently came across an OSI trace file of a SensorDataSeries message. It was marked as sd in the file name, so I assumed it was a SensorData trace file which lead to a failure during deserialization.
Describe your research
Next to SensorData, there is also SensorDataSeries and SensorDataSeriesList. Both are not listed in the top-level interfaces in the standard documentation and they are also not listed as types in the OSI trace file naming convention.
Ask your question
Should SensorDataSeries and SensorDataSeriesList be added to the top-level messages and also as separate types to the trace file naming convention?
And as an additional question: What is the intention of the SensorDataSeries? Why not just use SensorData directly?
Activity
jdsika commentedon Apr 29, 2026
Using the SensorDataSeries would entail that I hold the different SensorData in memory in order to write them out at once. Doing a git blame shows that it was introduced at the very beginning of osi as a project which means it predates the idea of e.g. ".osi - traces" which is in fact a SensorDataSeries as a single trace file. The SensorDataSeriesList is now an OSI multi channel trace. The council of the wise (@pmai @thomassedlmayer and @jdsika ) recommend adding a deprecation note in this file and the removal of the whole file in v4.0.0 - What is your opinion?
ClemensLinnhoff commentedon Apr 29, 2026
I also looked at git blame and was very surprised that these two messages were in the standard from the beginning. I have never used them and have never seen them be used until recently in this data set: https://twice.eletrica.ufpr.br/
I would be fine with deprecatiing them as they just lead to confusion.
docs: deprecate SensorDataSeries and SensorDataSeriesList for removal…
ClemensLinnhoff commentedon Apr 29, 2026
I talked to one of the guys who created that dataset and they thought that you need to use SensorDataSeries to put a time series of SensorData messages in a single trace file. They did not know that you can do that also with standard SensorData messages. This also point in favor of deprecating this message type.