As a user, I would like to be able to tell the WRES to apply the zeroDatum found with RFC forecast data

[HankHerr-NOAA]

In staging, the WRDS team has implement VLab #132444 which adds zeroDatum to the metadata associated with RFC forecasts. Here is a snippet of JSON that shows where its located (though position doesn't really matter):

            "producer": "APRFC",
            "issuer": "ACR",
            "distributor": "SBN",
            "zeroDatum": 975.0,
            "verticalDatumName": "NGVD29",
            "type": "deterministic",
            "issuedTime": "2024-10-10T20:49:00Z",

I think our users may want to be able to apply that zeroDatum. I believe the initial solution to this was a feature specific adjustment implemented in #36.

I recognize that there may not be a reasonable way to implement this. If we need it to be automated, how can we go about identifying when the zeroDatum should be applied? Its usually not just a matter of applying it blindly, because many times there will be a non-zero zeroDatum value that doesn't need to be applied for it to be evaluated against USGS NWIS observations for whatever reason (this is based on past testing). If it can't be automated, then it will require a flag of some sort which would be very specific to WRDS and the RFC forecast service. That doesn't sound good either. Hmmm...

I'm fine with us rejecting this ticket if there is no reasonable way to handle it. Thanks,

Hank

[james-d-brown]

The moment to apply this is when requesting an elevation variable, i.e., stage, from the WRDS RFC forecast service. If there is an evaluation variable and an elevation offset, the elevation offset must be applied. Shouldn't be that hard.

[james-d-brown]

There is an entirely separate challenge, however, of identifying when the observed, predicted and baseline variables do not use a common vertical datum and, initially, excepting, but eventually transforming.

There may be other tickets in the backlog related to this, perhaps created at the same time the declared datum offset was implemented.

[HankHerr-NOAA]

First, I want to note the WRDS ticket involved: #132444.

I don't think it will be that easy, Recall that the issue arose when evaluating RFC forecast stage against USGS NWIS. For example, consider FROV2. I've never had to worry about applying any datum at that location to support an evaluation against USGS NWIS in the past. However, WRDS returns, "zeroDatum": 468.93. I'm rerunning an old FROV2 evaluation now just to double check.

Yet for a point like BGDA2, we discovered that it was necessary to compare the RFC forecasts with USGS NWIS.

Hank

[james-d-brown]

Well, there's no accounting for bugs in WRDS, but that doesn't change anything w/r to our solution. Once we can trust WRDS to correctly report a datum offset, the datum offset should be applied. There may be a separate issue w/r to inconsistency in whether NWIS applies an offset, but we cannot build software around multiple inconsistencies that cancel each other out. If there is a legitimate and accurate datum offset, it should be applied. If there are bugs in dependent services, they should be fixed. If datum offsets are unknown or not applied, they should be declared manually.

[HankHerr-NOAA]

I just confirmed that the FROV2 evaluation for stage does not require any datum shifting.

When I looked at this before, I think I concluded that I couldn't tell from the metadata for WRDS or USGS NWIS exactly when a zero datum shift will be needed. However, it is possible that I overlooked something.

I've attached the WRDS metadata for FROV2 and BGDA2 below. Maybe the datum name can be checked?

Thanks,

Hank

==========

"forecasts": [
        {
            "location": {
                "names": {
                    "nwsLid": "FROV2",
                    "usgsSiteCode": "01631000",
                    "nwm_feature_id": 5907079,
                    "nwsName": "Front Royal",
                    "usgsName": "S F SHENANDOAH RIVER AT FRONT ROYAL, VA"
                },
                "coordinates": {
                    "latitude": 38.91400059,
                    "longitude": -78.21083388,
                    "crs": "NAD83",
                    "link": "[https://maps.google.com/maps?q=38.91400059,-78.21083388](https://maps.google.com/maps?q=38.91400059%2C-78.21083388)"
                },
                "nws_coordinates": {
                    "latitude": 38.913888888889,
                    "longitude": -78.211111111111,
                    "crs": "NAD27",
                    "link": "[https://maps.google.com/maps?q=38.913888888889,-78.211111111111](https://maps.google.com/maps?q=38.913888888889%2C-78.211111111111)"
                },
                "usgs_coordinates": {
                    "latitude": 38.91400059,
                    "longitude": -78.21083388,
                    "crs": "NAD83",
                    "link": "[https://maps.google.com/maps?q=38.91400059,-78.21083388](https://maps.google.com/maps?q=38.91400059%2C-78.21083388)"
                }
            },
            "producer": "MARFC",
            "issuer": "LWX",
            "distributor": "SBN",
            "zeroDatum": 468.93,
            "verticalDatumName": "NAVD88",
            "type": "deterministic",
            "issuedTime": "2024-11-01T14:10:00Z",
            "generationTime": "2024-11-01T14:24:23Z",
            "parameterCodes": {
                "physicalElement": "HG",
                "duration": "I",
                "typeSource": "FF",
                "extremum": "Z",
                "probability": "Z"
            },
            "thresholds": {
                "units": "FT",
                "action": 8.0,
                "minor": 12.0,
                "moderate": 14.0,
                "major": 18.0,
                "record": 34.8
            },
            "units": {
                "stage": "FT"
            },

"forecasts": [
        {
            "location": {
                "names": {
                    "nwsLid": "BGDA2",
                    "usgsSiteCode": "15478000",
                    "nwm_feature_id": null,
                    "nwsName": "Tanana River at Big Delta",
                    "usgsName": "TANANA R AT BIG DELTA AK"
                },
                "coordinates": {
                    "latitude": 64.1551284,
                    "longitude": -145.8523536,
                    "crs": "NAD83",
                    "link": "[https://maps.google.com/maps?q=64.1551284,-145.8523536](https://maps.google.com/maps?q=64.1551284%2C-145.8523536)"
                },
                "nws_coordinates": {
                    "latitude": 64.156944444444,
                    "longitude": -145.86444444444,
                    "crs": "NAD83",
                    "link": "[https://maps.google.com/maps?q=64.156944444444,-145.86444444444](https://maps.google.com/maps?q=64.156944444444%2C-145.86444444444)"
                },
                "usgs_coordinates": {
                    "latitude": 64.1551284,
                    "longitude": -145.8523536,
                    "crs": "NAD83",
                    "link": "[https://maps.google.com/maps?q=64.1551284,-145.8523536](https://maps.google.com/maps?q=64.1551284%2C-145.8523536)"
                }
            },
            "producer": "APRFC",
            "issuer": "ACR",
            "distributor": "SBN",
            "zeroDatum": 975.0,
            "verticalDatumName": "NGVD29",
            "type": "deterministic",
            "issuedTime": "2024-10-10T20:49:00Z",
            "generationTime": "2024-10-10T21:10:17Z",
            "parameterCodes": {
                "physicalElement": "HG",
                "duration": "I",
                "typeSource": "FE",
                "extremum": "Z",
                "probability": "Z"
            },
            "thresholds": {
                "units": "FT",
                "action": 22.0,
                "minor": 23.0,
                "moderate": 25.0,
                "major": 27.0,
                "record": null
            },
            "units": {
                "stage": "FT"
            },

[HankHerr-NOAA]

Saw your other comment. You got my point. WRDS is giving us a zeroDatum that appears to turn the stage into an elevation from sea level if we apply it (just a guess). USGS NWIS, however, gives us that stage, and, iirc, little to no information about the datum (some times it returns a stage, sometimes a number relative to sea level).

Understood about it being issues with the data services that will need correcting.

Thanks,

Hank