Unfortunately, the NWS API is missing machine readable condition codes/icons in the daily and hourly forecast, which is why it isn't available in briefsky. The API has nearly everything else, though. If I had a solution for those icons, I probably would have added support for their weather alerts too, and also made it the default for US locations.
The icon field is deprecated, no longer documented in the API, and also more complicated in practice, as it can mix multiple conditions, e.g. `...{day,night}/rain,30/snow,60?...`. The space of possible icons is also fairly large -- https://www.weather.gov/forecast-icons to get an idea -- and it's not clear what short string they all map to. So yeah, in theory you could parse and infer a weather condition out of that link, but as you can see it's pretty hacky and already deprecated. The API should really just return a code or enum (e.g. like a WMO code).
But maybe there's a cleaner way to infer it. PRs are always welcome.
I don't know why you think it's deprecated? I don't see that anywhere. They just updated the icons in 2015, which for govt API work is practically yesterday :)
I think it's just that the specifications document, like basically all documentation is out-dated. There are many fields in the output that are not in the documented spec.
My weather needs just call directly to api.weather.gov and have done so reliably for a year or two now, whenever the last API I was using started charging or broke or whatever happened to it(I don't even remember what API it was at this point). So I have no need of your project, but I wish you lots of success!
They're deprecated under the "Specification" tab: the `/icons/...` endpoints in the endpoint list, and the `icon` field in the `GridpointForecast` schema. The `shortForecast` field is documented as `A brief textual forecast summary` and not exhaustively enumerated, so it's also technically not machine readable. If it's anything like the icons, there could potentially be 50+ of these. I really couldn't find anything resembling an overall conditions enum or code anywhere, but I'd be happy to be wrong.
In the meanwhile, I could try to get it working with nearly everything else and try to find a last minute hack for the icons.
Yes, but if I'm making a website supporting hundreds of different APIs with different schemas and slightly different information available isn't really practical. Local providers aren't really a substitute for a single global source of weather data.
Assuming all of those things, I agree it's not great, but if you truly need global weather information, you either pay for an API(assuming one exists, I have no idea) or afford to hire developers/dedicate time to make one for you.
I would never expect a govt to provide global weather forecasts for places outside their jurisdiction. Though now I wonder is the US govt one provides weather for the US territories and other US places outside the 50 states. I don't have time to play with that at the moment, sadly.
See here for notes on other unsupported providers: https://github.com/vsergeev/briefsky#unsupported-providers