search

valentinedwv / ioostech

Automatically exported from code.google.com/p/ioostech
0 stars 0 forks source link

Representing quality flags #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
NDBC has two ways of representing quality flags:

hard flags, 0 or 1.  They are defined (not free text).
soft flags, 0 or more.  They are defined (not free text).

How should they be represented in the responses?

Original issue reported on code.google.com by wilcox.k...@gmail.com on 21 Mar 2012 at 7:22

GoogleCodeExporter commented 9 years ago

Original comment by wilcox.k...@gmail.com on 21 Mar 2012 at 7:23

GoogleCodeExporter commented 9 years ago 
Brief description of NDBC quality flags may be found at 
http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml

More info in the QC manual at 
http://www.ndbc.noaa.gov/NDBCHandbookofAutomatedDataQualityControl2009.pdf

Original comment by mike.gar...@gmail.com on 21 Mar 2012 at 7:38

GoogleCodeExporter commented 9 years ago

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 1:57

GoogleCodeExporter commented 9 years ago 
This issue is closely linked to issue 12.

Original comment by emilioma...@gmail.com on 24 Apr 2012 at 7:44

GoogleCodeExporter commented 9 years ago 
If there are many excellent and viable QC Flag conventions, how will different 
conventions be represented?  May I suggest an approach that might answer this?  

Janet Fredericks at MVCO worked out different offerings that use QC Flags or 
provide QC Flags with the returned GetObservation response.

Please see:
http://q2o.whoi.edu/node/129

The QC Flags were then defined using MMI register codes or terms.

The semantic beauty of this approach is that different QC Flags 
terms/conventions from different organizations can be used or mapped or share 
meaningful relationships.

Original comment by sara.m.h...@gmail.com on 22 May 2012 at 3:26

GoogleCodeExporter commented 9 years ago 
Nice. Thanks for pointing this out. I'm sure that suggestion will be an 
important element of whatever approach we end up adopting.
Still, I suspect we won't have time to address QA/QC issues in a comprehensive 
way (if at all) in Milestone 1. But with QARTOD making renewed progress now, 
hopefully we'll be able to address this soon after -- in Milestone 1.1??

Original comment by emilioma...@gmail.com on 20 Jun 2012 at 4:47

GoogleCodeExporter commented 9 years ago 
Issue 12 has been merged into this issue.

Original comment by emilioma...@gmail.com on 20 Jun 2012 at 4:48

GoogleCodeExporter commented 9 years ago

Original comment by dpsnowde...@gmail.com on 22 Oct 2012 at 4:29

GoogleCodeExporter commented 9 years ago 
Most of the quality flags at NDBC are tied to individual measurements.  So, we 
can use the swe:Quantity/swe:quality coding for these instances.

However, ocean currents are quite different.  We have nine flags that apply to 
tests performed on each bin/depth in the profile.  One of these nine flags is a 
flag indicating the overall qc status of the bin.  For ocean currents, we will 
have to define extra swe:fields in the swe:DataRecord for these flags.  I don't 
see how we can use the swe:quality for these.

Any one have any other ideas?

Original comment by mike.gar...@gmail.com on 14 Nov 2012 at 8:45

GoogleCodeExporter commented 9 years ago 
This issue is tagged as a 1.1 Milestone Release.  However, we need a decision 
if we are to develop SWE responses with embedded quality information (flags).

As previously stated, NDBC quality flags are documented at 
(http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml).  A single EQC flag value may 
be associated with a measured or derived value.  However, more than one DQA 
flags may be associated with values.  In practice, the number of DQA flags 
count rarely exceeds two for any measurement.  Assuming these flags are 
reported using the swe:quality/swe:Category scheme means that we will have to 
include one EQC flag field and two DQA flag fields for each measurement value.  
These flag fields may be empty indicating no quality issues.  Using 
swe:quality/swe:Text would allow the combination of flag values into one 
quality element per quantity, but I do not think that is proper usage of the 
swe:Text element.

In the ocean current data responses, NDBC will have to use an approach similar 
to the one developed by Janet Fredericks (see comment 5) which defines 
swe:fields for the nine quality flags as part of the response without the use 
of the swe:quality scheme.  This is because there are nine qc flags for ocean 
currents that are applied to the total bin/depth -- not to the individual 
fields.  To see a description of the ocean currents qc flags, go to 
(http://sdf.ndbc.noaa.gov/sos/) and scroll down to the bottom of the 
GetObservation samples for ocean currents.

Does this sound like a valid approach to quality flags or should NDBC hold up 
on this effort?

Original comment by mike.gar...@gmail.com on 6 Dec 2012 at 8:00

GoogleCodeExporter commented 9 years ago

Original comment by dpsnowde...@gmail.com on 30 Jan 2013 at 5:03

GoogleCodeExporter commented 9 years ago 
Created a new wiki page to hold information related to this discussion.  For me 
this requires some visuals and examples to sort out.  See 
QualityControlResultsSOS

Original comment by dpsnowde...@gmail.com on 1 Feb 2013 at 2:16

GoogleCodeExporter commented 9 years ago

Original comment by wilcox.k...@gmail.com on 15 Feb 2013 at 3:03

GoogleCodeExporter commented 9 years ago 
Here is an example SWE response which includes NDBC QC flags for EQC and DQA as 
described in comment #10.

It is not possible to express a variable length array of SWE Quality elements 
so the maximum # must be statically declared as part of the record.

https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-SingleStation-TimeSeries-SingleSensor_WithQC.xml

Please consider this example as a delta to the base line for a single station, 
single sensor example:
https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-SingleStation-TimeSeries-SingleSensor.xml

Comments on aspects other than QC should go in a separate thread.

Original comment by stu3b3 on 1 Mar 2013 at 3:51

GoogleCodeExporter commented 9 years ago 
Addressing the ADCP QC flags:

https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-ADCP-TimeSeriesProfile_Alt1_WithQC.xml

This template is also based on comment #10 from Mike. 
Adding the 9 QC fields to the data array is straight forward (though tedious to 
do by hand).

Comments on the general form of the time series profile should be addressed in 
the appropriate thread. Comments specifically regarding the QC of this feature 
type should go here.

Original comment by stu3b3 on 1 Mar 2013 at 4:03

GoogleCodeExporter commented 9 years ago 
Publishing QC flags through multiple "swe:field" elements is not the only way 
to deliver QC info.

I did some research of the ways the QC info may be inserted into GO response, 
and published results on the QualityControlResultsSOS page of the ioostech Wiki 
(direct link is http://code.google.com/p/ioostech/wiki/QualityControlResultsSOS 
).

Original comment by abir...@gmail.com on 1 Mar 2013 at 6:59

GoogleCodeExporter commented 9 years ago 

I have created some Templates for Milestone 1.0 using Option 3 form the Wiki 
page based on the use cases described in this issue focusing primarily on the 
details provided by Mike in comment #10. 

What other use cases do we have and do we need Options 1&2 for Milestone 1.0?
David

Original comment by stu3b3 on 1 Mar 2013 at 7:36

GoogleCodeExporter commented 9 years ago 

Need to wrap this up this week for Milestone 1.0

Please make comments by close of business Thursday. 
We will be finalizing the draft templates for Milestone 1.0 on Friday unless 
someone asks to stop the presses.

David

Original comment by stu3b3 on 4 Mar 2013 at 6:31

GoogleCodeExporter commented 9 years ago 
David, Option 2 allows smaller result encoding part, in case the QC info is the 
same for all dataset - we may put flag values right in the array members count 
section. I am not sure whether it is relevant for Milestone 1 though...

Original comment by abir...@gmail.com on 4 Mar 2013 at 9:23

GoogleCodeExporter commented 9 years ago 
Hi Alex

Putting a static value in the quality field element totally makes sense to make 
the encoding section smaller if the value is static. I don't see why one would 
put it in the array members count section though? 

Why not just create a field for Data Gap in the outermost data record and put 
the quality flag there as a static value?

David

Original comment by stu3b3 on 5 Mar 2013 at 2:57

GoogleCodeExporter commented 9 years ago 
Adding qc flags to the count is basically a cheat.  It's not obvious to 
everyone that the qc info applies to the bin and I would prefer to avoid it.  
Unfortunately, there is no clear-cut way of defining quality for a record in 
SWE.  The quality nodes seem to be associated only with quantities.  I really 
hope someone can point out that I am wrong here and offer a better solution.

Original comment by mike.gar...@gmail.com on 5 Mar 2013 at 3:28

GoogleCodeExporter commented 9 years ago 
Yes, it is kind of cheat; however, it is formally right, and passes validation.

Option 1 is a way to define quality for the whole record if you are OK with 
diverging from strict SWE. It places QC info in a general metadata area, which 
seems to be kind of obvious

Original comment by abir...@gmail.com on 5 Mar 2013 at 4:43

GoogleCodeExporter commented 9 years ago 

The QC framework is significantly simplified using the new data structure with 
separate records for static and dynamic data. 

In a timeSeries feature it becomes straight forward to add static QC metadata 
to a station or sensor and dynamic metadata to each quantity. There is still no 
good solution for QC metadata for all fields in a sensor record at a single 
timestep.
https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-MultiStation-TimeSeries_QC.xml

In a timeSeriesProfile feature it is possible to apply static QC metadata to a 
station or sensor and dynamic QC metadata to a profile, a bin or a quantity.
https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-SingleStation-TimeSeriesProfile_QC.xml

The data array in the timeSeriesProfile provides additional structure on which 
to put a QC (quality) element for each timestep or profile. It is unfortunate 
that there is no obvious way to do the same for a timeSeries. Suggestions are 
welcome.

Please review and comment as needed by COB Monday, May 6.

Thanks

David

Original comment by stu3b3 on 1 May 2013 at 8:10

GoogleCodeExporter commented 9 years ago 
Closed and complete
David

Original comment by stu3b3 on 6 Jun 2013 at 4:53

GoogleCodeExporter commented 9 years ago 
Closed and complete - for real now.

David

Original comment by stu3b3 on 6 Jun 2013 at 4:54