Adding (vertical) offset as mandatory / optional property for Sensors

[lorenz-c]

Within our institute, we are running a large number of different environmental sensors and platforms like climate stations, lysimeters, measurement towers, etc. Within the near future, we would like to move towards an STA-based sensor data infrastructure for enabling a better connectivity to other research data infrastructures and providing a standardised, yet flexible and efficient data model for our quite large pool of sensors.

One fundamental information in this context is the "vertical offset" of a sensor. As an example, we are running a soil net for measuring soil properties. This consists of 55 "locations", at which sensors are installed in different depths (5cm, 50cm, 100cm, etc.). Other examples are sensors for measuring wind or temperature, that are usually installed at different heights above the surface (2m, 10m, etc.).

So far, there seems to be no "standardised" entity and property, where such information can be stored. However, at least in environmental sciences, I think that there should be at least some official "best practice" or "guideline" for this property so that we can easily filter e.g. for all sensors in a certain depth.

At least in our case, I think that adding a property offset (or vertical offset?) to the sensor and setting this to negative values for sensors in the soil and a positive values for sensors above the surface might be the most straightforward solution. See the picture below for an example:

What do you think? Thanks a lot in advance!

[ksonda]

I face similar issues in interoperability for various water monitoring use cases across STA implementations. To some extent it seems like the province of the domain working groups. But I agree, I would love for there to be a "Surface Water", "Groundwater", "Air", "Soil", etc. 'profiles' of STA that orgs could use.

[jkreft-usgs]

seconding the idea of shared profiles for these kinds of properties, which is something that I am also starting to have to think about for USGS sensors as we roll out our sensorthings implementation.

[lorenz-c]

Thanks a lot for your comments! I also think that the STA data model covers already the majority of mandatory "properties" of a sensor and, hence, could serve as a perfect "parent" (meta)data schema. But there is still room for a kind of "community" or "thematic" expansion for specific use cases.

Besides a "vertical_offset" (or just "offset") of a sensor from the surface (both in the air and in the soil), users also require some standardised attribute / property / etc. for the following metadata:

• PID of the sensor and / or serial number and / or inventory number
• Contact (PI / technical staff / scientific staff / etc.)
• Accuracy information
• Some more information about the origin of the sensor (manufacturer, model number, etc.)

From many discussions across several research centres here in Germany, I realised that a) this information is crucial for our users (independent from the chosen data model or metadata scheme) and that b) if we choose STA as our main data model for our sensor data, we have to come up with some standardised naming conventions (either in our geoscientific community, or at some higher-level initiative) for providing this information.

I have seen that there is already a section for specific use-cases here in this repo. So, in order to advance this discussion, we can define a use-case for such applications which could serve as a "blueprint" for (e.g.,) a thematic profile for STA. What do you think?

[humaidkidwai]

I think this can be accommodated with the "position" property within Deployment entity of STA V2.0 Draft Design. As each (vertical_)offset will produce a new collection of observations that will be uniquely identified due their new offset in deployment.