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.
Yeah, this probably requires some explanation. Currently, briefsky doesn't depend on a geocoding API, so it can't map locations to coordinates or vice-versa. It just uses the lat/long from the browser's geolocation or manual coordinates in the settings. But ideally it'll have location search and location text at the top.
The way I use it is as a bookmark with a pre-configured provider and the location in the title. briefsky stores all configuration in the URL, so you can bookmark multiple locations / providers.
Yup, all good points. I've found Open-Meteo's default to be subpar for US. Briefsky offers Pirate Weather too, but will require a free API key. (MerrySky is Pirate Weather, so it's baked in.)
I was actually hoping to make NWS the default for US, but ran into some limitations with their API missing machine readable conditions codes/icons. Open-Meteo does have https://open-meteo.com/en/docs/gfs-api, which should probably be used in the meanwhile for a better default forecast with US locations.
You can use lat,lon with the points endpoint: https://www.weather.gov/documentation/services-web-api , then properties.forecast and properties.forecastHourly endpoints from there to get daily and hourly forecasts. I don't have enough experience with it to comment on rate limiting, though.
The main issue I ran into with the NWS API was a lack of stable conditions codes/icons (something like WMO codes that could be easily mapped). They encode some weird dynamic image URL that renders a summary of the weather, but isn't machine readable. I think they're deprecating it anyway. Otherwise, it had pretty much everything through one endpoint or another.
I considered handling this with some coarse longitude heuristic, but settled on just using the browser's locale for now, so it should default to metric for non-US locales. In the metric setting, the visibility and wind speed will be km and km/h, respectively.
Locale, in practice on the web, is mostly about language (fortunately!). I’m Dutch in NL and my browser (and OS!) is set to prefer en-US. Most of my friends do too. Dutch software UI translations are terribly cringey.
To me, that means I prefer English UI text but it doesn’t suddenly mean I want my units in arms and ounces and firestoves or whatever weird shit you Anglosaxons do :-)
I recognize that formally this is me breaking the locale model, but if so, then that’s a flaw in the design of locales and not a flaw in me. At the risk of ranting a bit, the idea that I can’t have a Color Picker named “Color Picker” without also bending over and accepting Fahrenheit is just weird to me. Lumping all this stuff together (don’t get me started on number formatting!) into a single 5-character language-and-region code is just dumb. The model assumes one dimensional einheitswurst humans who do as they’re told in primary school, never move away from their home town and never learn a second language. It sucks.
Let’s be happy so many websites get this right and treat locale as a language selector only.
(Meta sidenote, “Einheitswurst”, literally “unit sausage” but kinda also “unity sausage” which gives this word for dullness a delightful political angle, has got to be the second-best word in the German language)
Thanks, I'll take a look! New plotting sinks are easy to add and I really would like to migrate to something more stable. Gnuplot has been finicky with many people's setups, and it's been a real sore point. They seem to run best with the wxt output on Linux.
See here for notes on other unsupported providers: https://github.com/vsergeev/briefsky#unsupported-providers