Get list of stations using /gridpoints/.. /stations endpoint - output has changed

[swbrains]

When I use the following endpoint:
https://api.weather.gov/gridpoints/TBW/71,111/stations

It seems the response is missing the observationStations array, but then it seems to have some type of encoded URL/list of station IDs in the pagination->next object:

{
    "@context": [
        "https://geojson.org/geojson-ld/geojson-context.jsonld",
        {
            "@version": "1.1",
            "@vocab": "https://api.weather.gov/ontology#",
            "observationStations": {
                "@container": "@list",
                "@type": "@id"
            }
        }
    ],
    "type": "FeatureCollection",
    "features": [],
    "observationStations": [],
    "pagination": {
        "next": "https://api.weather.gov/stations?id%5B0%5D=K28J&id%5B1%5D=K42J&id%5B2%5D=KAPF&id%5B3%5D=KBCT&id%5B4%5D=KBKV&id%5B5%5D=KBOW&id%5B6%5D=KCGC&id%5B7%5D=KCOF&id%5B8%5D=KCTY&id%5B9%5D=KDAB&id%5B10%5D=KDED&id%5B11%5D=KEVB&id%5B12%5D=KFIN&id%5B13%5D=KFLL&id%5B14%5D=KFMY&id%5B15%5D=KFPR&id%5B16%5D=KFXE&id%5B17%5D=KGIF&id%5B18%5D=KGNV&id%5B19%5D=KHWO&id%5B20%5D=KINF&id%5B21%5D=KISM&id%5B22%5D=KLAL&id%5B23%5D=KLEE&id%5B24%5D=KMCF&id%5B25%5D=KMCO&id%5B26%5D=KMKY&id%5B27%5D=KMLB&id%5B28%5D=KOBE&id%5B29%5D=KOCF&id%5B30%5D=KOMN&id%5B31%5D=KORL&id%5B32%5D=KPBI&id%5B33%5D=KPGD&id%5B34%5D=KPIE&id%5B35%5D=KPMP&id%5B36%5D=KRSW&id%5B37%5D=KSFB&id%5B38%5D=KSPG&id%5B39%5D=KSRQ&id%5B40%5D=KSUA&id%5B41%5D=KTIX&id%5B42%5D=KTPA&id%5B43%5D=KTPF&id%5B44%5D=KTTS&id%5B45%5D=KVDF&id%5B46%5D=KVNC&id%5B47%5D=KVRB&id%5B48%5D=KVVG&id%5B49%5D=KX60&id%5B50%5D=KZPH&cursor=eyJzIjo1MDB9"
    }
}

Our code that expects to parse the observationStations[] array to get a station to use for the call:
https://api.weather.gov/stations//observations/latest
to get the latest conditions in that location.

Previously this worked, but appears to fail for any location we specify to the /stations endpoint. I tested this on the NWS API test page and the results are the same. Is this a change the output specification or an anomaly?

Thanks!

[dfyockey]

Have the same problem. I've reported it to NCO/OMB Tech Control as per the direction at https://weather-gov.github.io/api/reporting-issues. You may wish to as well to get the issue more attention.

[swbrains]

Thanks for the confirmation and reporting information. I have relayed my comments regarding this issue to the email address provided on the issue reporting page you referenced.

[zaden1]

I have the same problem. It's such a relief to know I am not the only one. I was tearing my hair out thinking that it must have been some change I made on the server. I will report as well. Lucky I Have a fall back message for such an occasion and none of our clients are complaining yet.

[swbrains]

It looks like the problem has been corrected at this time.

[dfyockey]

Yep, it seems to have been corrected. However, if you're pulling the data in GeoJSON format, including the header field "Accept: application/geo+json" may now cause the same issue. That was the situation in my case. The full response would show up in a browser, but not in my software until removing that field (after much mucking around to figure that out). Fortunately, GeoJSON is the default format and I'd stuck in the field just to be thorough.

[swbrains]

Interesting... I'm using the Accept: application/geo+json header when calling the API from my script, and when I dump the return data the observationStations array is being populated properly. Perhaps they just corrected that as well?

[dfyockey]

Hmmm... Weird... I still have the issue if I stick the header back in. But I'm probably an outlier since I'm using libcurl in C++ rather than something in a script. Maybe it has something to do with that. No big deal, though, since it works fine without it.

[swbrains]

Strange indeed... At least we're all back up and running! :)

[scadergit]

Including the header will result in a different cache from our cdn, and this endpoint has a decent cache control given the data is relatively static. Perhaps the bad response just needed time to expire.

[dfyockey]

Just stuck the header back in and yes, it does now provide a full response. Strange, though, that some were getting good data while others were getting bad when using the header.