dsauerbrun / cragcast Goto Github PK

Some of our calls to noaa should be cached. For example, the /points/<lat,lng> endpoint should be cached. Would be nice if we could do something like httpWrapper.Get(url, 1000) which would cache the response for 1000 seconds.

We could also use this for the hourly forecast fetcher, realistically the forecast wont be changing all that often. Retrieval for hourly forecast takes a 1-2 seconds from noaa but we probably only need to get fresh data every ~2 hours.

There almost certainly is an existing package that does this and caches in memory which is probably good enough.

Before going too deep into the SDK/noaa-client creation, it's worth investigating whether we can use a tool like oapi-codegen to generate a bunch of the model/api interaction with api.weather.gov, since they do publish an OpenAPI specification.

Details about weather.gov's service definitions are available here: https://weather-gov.github.io/api/general-faqs

Namely, their OpenAPI (v3.0) specification is available at https://api.weather.gov/openapi.json.

Along with weather, there are 2 things I often find myself wondering about when planning a climbing day.

1. Sun/Shade profile of the crag(s)
2. Conditions at the crag
   • Notes on whether its still seeping water, snowy, problematic approach, etc.

I believe we can cleverly design this such that each crag can be attached to the weather profile of its own area, yet we are able to crowdsource the information on a per-crag basis to support 1 and 2.

For example, consider the following model looking at Avalon and Animal World in Boulder, Canyon:

For examples of 2, condition reports, look at examples like 14ers.com Mt Antero: https://www.14ers.com/php14ers/peakstatus_peak.php?peakparm=10010. We'd likely want to collect and display the data differently than this, but gives a sense for the value associated with these kinds of reports.

Add golang-lint as a make task and integrate that with our GitHub actions for pull requests.

This will provide linting and other analysis as we build the code-base out further.

@dsauerbrun the cragcast organization exists and you have an invite to join as an Owner.

When you can, transfer this repository to github.com/cragcast/cragcast.

if you look at https://api.weather.gov/gridpoints/BOU/52,75/forecast/hourly?units=us you'll see that precipitation amount as well as sky cover%(cloudiness) is missing. They definitely have this data as you can see it here: https://forecast.weather.gov/MapClick.php?lat=40.0231&lon=-105.3043&unit=0&lg=english&FcstType=graphical

I found https://graphical.weather.gov/xml/rest.php which is a pretty clunky api but gives you more data. Sample url: https://graphical.weather.gov/xml/sample_products/browser_interface/ndfdXMLclient.php?lat=40.0294122&lon=-105.3223779&product=time-series&begin=2023-04-28T00:00:00&end=2023-04-30T00:00:00&maxt=maxt&mint=mint&sky=sky&temp=temp&qpf=qpf . You just tack on the data you want returned as url params(options here: https://graphical.weather.gov/xml/docs/elementInputNames.php).

Downside of this NDFD api is that it responds with XML and is sort of all over the place(eg. 3 hour temperatures but 12 hour precip %).

Three options:

1. bail on sky cover and precip amount for now
2. find another api option
3. blend the nws api with another api to get what we want.

It'd be great to offer, or embed, a weather map (focused on precipitation) to each climbing area. Something akin to https://github.com/Makin-Things/weather-radar-card.

There are several considerations when we get to this point, for example:

• How can we ensure its load priority is low such that key weather data is provided first.
  • This ensures no bottle-neck in low-bandwidth situations
• Is there an external service we can embed into pages, perhaps by providing it coordinates?
  • Alternatively we can look to host an open source/free project ourselves or build something.