jsax

Thanks for taking a look!

It’s a good question. Initially, the URL was lat/long values, and then I did try place names. I ended up with the short code approach to minimise API calls to downstream services.

The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code.

The short code enables a forecast lookup to be a SQLite DB read, followed by a single API call for the forecast.

A more descriptive URL would have required two sequential calls - one to figure out the lat/long and/or place name, and another for the forecast. This wasn’t a huge speed problem, but I struggled to find geocoding APIs with generous free tiers or reasonable low volume pricing. It would have also made the forecast at a given URL somewhat non-deterministic, as the geocoding API could change its output or preferred result over time.

Short codes quite possibly wasn’t the right solution. It’s definitely something I’ll think more about. Thank you!

I’ve had a few pieces of feedback for plain text, and it’s definitely something I’ll look at adding.

OOI, would you expect the output to include a single days weather (like the site does now), multiple, or options for both?

Thanks! I’ve also got a long list of additional data I’d like to see, such as sunrise / sunset times and astrological activity like upcoming meteor showers etc.

I’m starting to think about dedicated sub pages that cover these use cases, with a single section on the main page that links into it. A sailing based page could definitely work here!

It uses open-meteo.com. Their forecast API returns data from around 30 different models depending on location, and typically uses Met Office data in the UK. I don’t force to only Met Office though, as they don’t give data for everything shown (such as the pollen count per species).

Open-meteo has a very generous free tier, and reasonable pricing. It also lets you fetch weather from previous days, which I’ve included so you can see if it’s relatively hotter/colder etc. than yesterday.

I love this idea. The brolly logo at the top of the page is also a unicode character, so this fits well.

Interesting, I’d have naively assumed that’d be cached after first load by Chrome. Definitely one to investigate further.

Sorry about this, and thank you for the heads up. The site runs as a PocketBase instance on a small 512mb DigitalOcean droplet in their London DC, and is getting more load than usual at the moment.

I’ll take a look though at whether there’s anything causing fundamental slowness in the cache read / page rendering pipeline.

I’ll definitely look at adding this in, along with potential the wet bulb temperature. Thanks for the feedback!

That’s frustrating, thank you for the feedback. I’ll take a look at improving the search and potentially switching out the API provider. I currently use open-meteo as I was already using it for the weather forecast (it has a great weather API), and it made sense at the time to keep with a single provider.

Great suggestion, thank you. I’ll definitely keep that in mind as an improvement. There’s been some other feedback that it’d be good if there was a ‘true’ plain text only mode, and this ties in well.

Thanks for the feedback!

I agree, it’s definitely something to work on as it takes up a considerable amount of vertical space.

I found the precipitation chart challenging as you need to present both the forecasted precipitation, and the potential likelihood of the precipitation occurring. Something I’ve considered is using a horizontal graph with different shades of grey through black in each bar to represent the probability, but it would somewhat reduce accessibility.

This is pretty cool.

This functionality is called ‘break back’ in a lot of enterprise modelling software. See [IBM TM1](https://www.ibm.com/docs/en/cognos-planning/10.2.1?topic=bre...) and [Anaplan](https://help.anaplan.com/breakback-1b7aa87d-aa13-49f6-8f7d-d...). They generally work in terms of scaling the inputs to match the new output though, which is a bit more basic than this approach.

York, UK currently has 1Gb coverage across about a 1/4 of the city, with the rest being connected in the next year I believe. Only £25 ($32) a month.