As a user, when using USGS observations, I would like to include other information provided with the data in conditioning; example: ice effects

[epag]

---

Author Name: Hank (Hank) Original Redmine Issue: 51031, https://vlab.noaa.gov/redmine/issues/51031 Original Date: 2018-05-30

---

This is from the UAT status call on May 30.

This should be exposed in the XML configuration, and, therefore, the UI when it is implemented.

Its unclear to me if there is a generically useful manner in which this can be implemented, but I'm guessing it will need to be source specific. For example, PI-XML can include qualifier codes, data quality flags, and perhaps other information in the data which might be valuable to condition on. Would that require a separate ticket? TBD.

Hank

---

Redmine related issue(s): 70498

---

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2021-11-03T17:13:06Z

---

Implicitly requested again in a question by RFCs during training today. I cannot find where we found inconsistent coding of ice effects but I recall that being the case.

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2021-11-03T18:01:58Z

---

Example data with "estimated" flag alongside "approved" flag: https://nwis.waterservices.usgs.gov/nwis/iv/?format=json&indent=on&sites=01103500&parameterCd=00060&startDT=2021-01-31T00:00:00Z&endDT=2021-02-14T23:59:59Z

Edit: and revision info for same: https://nwis.waterdata.usgs.gov/usa/nwis/revision/?site_no=01103500&ts_ids=66093

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2021-11-03T18:20:13Z

---

Some provisional estimated from https://nwis.waterservices.usgs.gov/nwis/iv/?format=json&indent=on&sites=05064000&parameterCd=00060&startDT=2021-01-01T00:00:00Z&endDT=2021-02-14T23:59:59Z

 {
        "value" : "71.8",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-12T05:15:00.000-06:00"
      }, {
        "value" : "71.7",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-12T17:15:00.000-06:00"
      }, {
        "value" : "71.6",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-13T05:15:00.000-06:00"
      }, {
        "value" : "71.4",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-13T17:15:00.000-06:00"
      }, {
        "value" : "70.9",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-14T05:15:00.000-06:00"
      }, {
        "value" : "70.8",
        "qualifiers" : [ "P", "e" ],
        "dateTime" : "2021-02-14T17:15:00.000-06:00"
      } ],
      "qualifier" : [ {
        "qualifierCode" : "e",
        "qualifierDescription" : "Value has been estimated.",
        "qualifierID" : 0,
        "network" : "NWIS",
        "vocabulary" : "uv_rmk_cd"
      }, {
        "qualifierCode" : "P",
        "qualifierDescription" : "Provisional data subject to revision.",
        "qualifierID" : 1,
        "network" : "NWIS",
        "vocabulary" : "uv_rmk_cd"
      } ],
      "qualityControlLevel" : [ ],
      "method" : [ {
        "methodDescription" : "",
        "methodID" : 74203
      } ],
</code>

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2021-11-03T19:00:29Z

---

To explore:

• Do the qualifiers and descriptions of qualifiers vary from region to region in USGS data?
• Do the qualifiers and descriptions of qualifiers vary from WaterML JSON to RDB in USGS data?

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2021-11-03T19:17:48Z

---

Another thought is that if it is regional offices using the capability it doesn't matter so much that the codes vary from region to region. If we give some way to filter or flag arbitrary codes it might be enough.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2021-11-03T20:28:38Z

---

Jesse wrote:

Another thought is that if it is regional offices using the capability it doesn't matter so much that the codes vary from region to region. If we give some way to filter or flag arbitrary codes it might be enough.

I think that is what we need, a way to enable users to use flags as they see fit. What we cannot really do is police these flags or implement some kind of expert system or pretend that the wres can take a unified approach. It's just about getting users the tools they need to design their own filters and it may be that we already have this via the arbitrary url parameters, idk (I mean if the nwis service itself offers filters on top of the flags, but it may just supply the flags).