| Meta data for PPMP measurement messages [message #1756178] |
Mon, 13 March 2017 10:38  |
Eclipse User |
|
|
|
Hi,
we are starting to notice that the available fields in measurement messages are not enough to correctly describe the data that is being transported. We need additional fields for things like unit, factor/gradient and offset. Such fields will need to be specified per sub-field.
My suggestion is to an optional object parallel to "series" and "limits" that is structured in the same way as "limits" and allows arbitrary key-value pairs (both strings, as with the existing meta data fields).
For example:
{
"ts": "...",
"series": {
"$_time": [ ... ],
"temperature": [ ... ]
},
"subfieldMetaData": {
"temperature": {
"unit": "Fahrenheit",
"gradient": "1.8",
"offset": "32"
}
}
}
Comments?
|
|
|
|
| Re: Meta data for PPMP measurement messages [message #1758578 is a reply to message #1756509] |
Thu, 30 March 2017 05:27  |
| Eclipse User |
|
|
|
I wondered if calling it "metaData" would be a good idea or not - as the internal structure differs from other fields named "metaData". Reusing the name for a different structure would make the definition incorrect. I don't otherwise mind which name is used.
Merging limits into this might cause problems for these reasons:
1. The metaData values are all strings, but limits are explicitly numeric.
2. Moving the limits would cause incompatibility issues with the existing standard.
Personally, I would prefer the limits to remain separated, as explicit numbers. This also avoids mixing explicitly named limit fields with arbitrarily named meta data fields.
|
|
|
Powered by
FUDForum. Page generated in 0.05695 seconds
Home