Tracking equipment changes and QC in 52N

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Tracking equipment changes and QC in 52N

TSlawecki
I am continuing to work on implementing 52N SOS instances to handle a number of different sensor configurations and use cases. One situation that comes up is the tracking of equipment changes at a given location - say we measure dissolved oxygen one year with one particular sensor with serial number 0001, then we replace it with sensor serial number 0002. We could certainly set up separate sensor procedures for each period, but I'd rather have a single discoverable procedure that is just called "dissolved oxygen" that would have the sensor history encoded. I'm thinking that this is an opportunity to use <sml:history>. If so, does anyone have a similar use case? I'm curious about what can be included in the history block.

I'm also interested in indicating whether data or "provisional" or "final", with "final" indicating that a manual quality control procedure has been applied to the data. What may happen at a given location is that data from previous years is "final" while the current year's continuous data is "provisional". What are some ways that have been used to track this, whether point-by-point or with some sort of history?

Thanks again,

Tad
Reply | Threaded
Open this post in threaded view
|

Re: Tracking equipment changes and QC in 52N

jfredericks
On 8/3/16 10:09 PM, TSlawecki wrote:
> We could certainly
> set up separate sensor procedures for each period, but I'd rather have a
> single discoverable procedure that is just called "dissolved oxygen" that
> would have the sensor history encoded. I'm thinking that this is an
> opportunity to use <sml:history>. If so, does anyone have a similar use
> case? I'm curious about what can be included in the history block.

We also took this approach, see:

http://www.sensorml.com/2.0/mvco/sensor/MVCO_Workhorse_1200.xml

We have one data stream - the things that don't effect data
behavior/quality imho don't require new streams ... so we document the
sensor swap as a history event with history -> EventList-> Event-> with
time/property including Serial number firmware version

If we changed technologies (e.g., went from four-beam to five-beam
and/or used acoustic means of detecting the surface rather than a
pressure sensor), one would not want to have the same data stream.  But
if you are using the same technology and set up, it is only significant
to identify the swap-out - just incase there are issues and that
particular time-frame needs to be identified.

I hope this helps.
Janet


_______________________________________________
SWE mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/swe
http://sensorweb.forum.52north.org
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines