vsergeev
Joined 13 years ago
Karma
153
Submissions
29
Member since
Dec 3
Recent submissions
Comment · 3 years ago
Thanks, filed an issue.
Comment · 3 years ago
Thanks, I've filed an issue that the locale shouldn't be used for units.
Comment · 3 years ago
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.
Comment · 3 years ago
+1 Thanks. It looks like the Open-Meteo one may be worth a shot since it doesn't require an API key and briefsky is client-side.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
See here for notes on other unsupported providers: https://github.com/vsergeev/briefsky#unsupported-providers
Comment · 3 years ago
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.
Comment · 3 years ago
Thanks for the feedback. Will make a note of auto-expand settings.
Comment · 3 years ago
Seriously, thanks a ton for providing an API-key free weather API! That's why it's the default for briefsky. Sorry if there's a load spike today ;)
Comment · 3 years ago
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.
Comment · 3 years ago
Thanks, I'll add it to my list. At some point I was thinking of adding a location search too, just depends on a free & reliable geocoding API.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
For the others, I tried to document the main limitations here: https://github.com/vsergeev/briefsky#unsupported-providers
Comment · 3 years ago
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.