There are values in the mesurements tab that are not floats, but include a < value (a maximum, because it means that this is the lowest value that the instrument could record)
And in principle some may also have a > (a minumum) and - (a range), tho I do not expect these
These have to be deal with in the following way
for the QC: still report a problem
for the transformed logsheets: copy over as-is - this means that ALL measurements have to be recorded as strings in logsheets_schema_extended
for the ttl - @laurianvm or @bulricht to change the procedure so that: If there is a "< float" in the cell, put the float as the value in the ttl for that parameter, and indicate that it is a maximum value; if there is a "> float" then put the float as the value and indicate that it is a minumum value; if there is a "float - float" then record it as a range min to max.
We will need to document that this is done because it will mean that not all values for measurements are described in the same way and the VRE code that may want to do maths on these data will run into problems. To consider: perhaps make ALL values at least a range, from min to max?
for the ENA workflow, as it will not accept strings, we will have to NOT include that value in the xml file BUT we will have to instead create a new entry called "[measurement name] additional info" and copy the string into there. See https://github.com/emo-bon/ena-sample-registration-action/issues/3
There are values in the mesurements tab that are not floats, but include a < value (a maximum, because it means that this is the lowest value that the instrument could record) And in principle some may also have a > (a minumum) and - (a range), tho I do not expect these
These have to be deal with in the following way