Rethink how we store our measurement data

[vhirtham]

During the creation of another tutorial, I got the feeling that our current approach on how to store measurement-related data in a WelDX file could be improved. Here is the info output of the corresponding file content:

├─measurements (list)
│ ├─[0] (Measurement)
│ ├─[1] (Measurement)
│ ├─[2] (Measurement)
│ └─[3] (Measurement)

From the structure, I don't see so far, which data is contained and have to get the list, iterate through measurements and print their names to get a clue where the one is I am looking for. Furthermore, the Measurement class is just a data class that stores the name of the measurement, all measurement data, and the measurement chain. It feels a bit pointless since all the data is also already stored in the MeasurementChain.

My suggestion is to build a dedicated container class for all measurements with some utility functions. From the data structure, it would simply be a dictionary with the measurement name as key and the measurement chain as data.

Then I might do stuff like this:

> measurements.names

welding current
welding voltage
temperature T1
temperature T2

Some possible functions

measurements.get_data("welding current")
measurements.get_measurement_chain("welding voltage") 
measurements.plot_measurement_chain("temperature T2")
measurements.plot("welding voltage")
measurements.plot_data("temperature T1")

The plot function would simply plot the measurement chain and all the attached data, while plot_data either plots all data or can get another parameter to select a specific plot.

We can also keep the Measurements data class and return it with

mesurements["temperature T1"]

Yes, the current approach works and isn't too complicated, but it feels a bit unwieldy to me when compared with the other tools that WelDX offers.

[marscher]

I really like the simplicity of this API proposal. Especially the directly available plotting routines are a great benefit for the user. Also handling more different measurements becomes easier with this.

After this is implemented, we could simply return this new class after deserialization giving the measurements standard names (e.g. upon unit matching).

[CagtayFabry]

Some thoughts:

• I think it introducing a new (python + asdf) class to 'manage' the Measurements would just make the WeldxFile.info() stop even sooner, like

  ├─measurements (MeasurementContainer)
  ├─process
  

• I agree that some convenience functions would be handy, I would just refrain from creating a class that is associated with a new asdf tag (because I don't really see a benefit on the ASDF side)
• the utility class to handle measurements and add some extra API can just be build to work with a list/dict of measurements independently from what it looks like in the ASDF schema
• not sure if having a dict to store the measurements over a list would be good because that would force measurement names to be unique. (on the plus side it would look nice in the asdf output though and we could do set extra requirements on what measurements are required by using the the required asdf validator, sooo).
• so far the Measurement class is rather empty and could probably be handled completely via the measurement chain

Maybe just build the helper class and we can take a look at the schemas later?

[vhirtham]

Maybe just build the helper class and we can take a look at the schemas later?

👍