Is it possible to get skycover from the forecast/hourly endpoint?

[seanpwlms]

If so, how would I specify that?

[dwhitemv25]

I don't see a way to request it from the API. You can look at the icon URL or shortForecast text to get a rough approximation, though.

[seanpwlms]

Thanks!

[KyleRGill]

Looking to see if this is a possibility to add into the API? It would be helpful for a project rather than parsing through the short forecast.

[scadergit]

The forecast and hourly forecast schema hasn't been modified since the mandate was to replicate what is on the forecast site. I want it for our weather.gov presentation layers, too--will keep pushing for a review, including more weather data.

[carloshwa]

The current hourly forecast site (and the digitalDWML / digitalJSON feeds when they were still working) does include sky cover, qpf & wind gust:

https://forecast.weather.gov/MapClick.php?lat=37.7705&lon=-122.4428&unit=0&lg=english&FcstType=graphical

So I would argue that these should be part of the original mandate of replicating that site.

Thank you!

[sullynole]

Check the forecastGridData url from the points endpoint for hourly skyCover data.

[carloshwa]

Thanks for the suggestion! I did try using that, but the forecastGridData response comes in at around 250kb, while the hourly response comes in around 150kb and the old digitalDWML response is around 50kb & old digitalJSON around 20kb. I'm pulling this data for a mobile app so the increased payload size has a pretty big impact.

In addition, the times in forecastGridData don't contain the location's timezone offset (they all report +00:00) which makes it difficult to process.

[dwhitemv25]

Somewhat relevant for this discussion, SCN 24-50, which announced the decommissioning of the digitalJSON and digitalDWML formats, has been changed to occur at a future time. Those outputs are sticking around until they can port the missing elements to API and make the formats available there. Apparently there is still enough traffic in those formats to keep them alive.

[netbymatt]

Thanks for the suggestion! I did try using that, but the forecastGridData response comes in at around 250kb, while the hourly response comes in around 150kb and the old digitalDWML response is around 50kb & old digitalJSON around 20kb. I'm pulling this data for a mobile app so the increased payload size has a pretty big impact.

Hopefully your mobile client is using gzip which is pretty much a de-facto standard now for transferring http data. The response sizes you state are correct, but are the decompressed sizes. What's actually sent "over the wire" is significantly smaller. This is because the JSON they're returning is very verbose, but that makes it very compressible. Here are a few uncompressed and compressed sizes that I grabbed this morning for comparison.

• /stations/KMCO/observations/latest - 4.9 kb > 1.5 kb
• /gridpoints/MLB/26,68 - 276 kb > 12.8 kb
• /gridpoints/TBW/67,97/forecast - 18.8 kb > 2.8 kb

In addition, the times in forecastGridData don't contain the location's timezone offset (they all report +00:00) which makes it difficult to process.

There are a few things that may help here. If you're on mobile, you might be able to just take the timestamps in the data which are all UTC and convert them to the mobile device's current time zone which it typically available through your programming environment.

I don't know exactly what your workflow is when getting this data but the call to /points/39.3643,-74.4229 does return a timezone in the form of "America/New_York" which can usually be processed fairly easily by a library on any modern platform you might be using.

[carloshwa]

Thanks for the suggestions, yes I am seeing gzip to be quite effective with the response size. I hadn't thought about how big of a difference that would make before!

I see the timezone in the points response, thanks for calling that out! Yes I can use that to determine the locations time offset.