Observation - parameters vs. properties

[KathiSchleidt]

Related to the proposed properties extension, we have now run into the question on how to continue with STA Observation:

• utilize the parameter attribute (currently defined as NamedValue in the UML, "Key-value pairs showing the environmental conditions during measurement." of type NamedValues in a JSON Array in V1.0 of the standard) [Update: already changed to JSON_Object - https://github.com/opengeospatial/sensorthings/issues/66]
• add a properties attribute in parallel with the other classes

Based on our current requirements, simple Key-value pairs are not sufficient, as we have cases where we provide both a code and a label for a topic. If we utilize the observation parameter, we would have to provide a JSON object as the value.

Also, if we utilize "properties" in all other classes, wouldn't it be more consistent to also have "properties" on the observation (to my understanding, the name "parameter" in the observation stems from the om:parameter in the O&M Observation)

Link to Fraunhofer GitHub: https://github.com/FraunhoferIOSB/FROST-Server/issues/97 Link to INSIDE-information-systems GitHub: https://github.com/INSIDE-information-systems/SensorThingsAPI/issues/4

[taniakhalafbeigi]

Notes from OGC Singapore Feb 25: For Observations we adopt parameters from O&M and we want to keep the parameters field name to be consistent with O&M.