Live data from Hacker News

Pirate Weather: A free, open, and documented forecast API

pirateweather.net

41–50 of 201 posts

Re: Pirate Weather: A free, open, and documented forecast API

#41

> Why "PirateWeather"? I've always thought that the HRRR model was pronounced the same way as the classic pirate "ARRR". Also, there is one company out there that thinks APIs can be copyrighted, which might apply here. This answers the first question I had upon seeing the name, which was, is it free, open, documented and legal ? Based on the above the answer seems to be "probably". Very commendable effort, and I hope…

I agree, PirateWeather seems like a misbrand here. When I read it, i thought it was stealing weather data or something. On the web, the term "pirate" generally doesn't mean good things. This name almost implies that it is illegal or something. I'm imagining designing a software product around this and presenting it to a C-Level, explaining that we use "PirateWeather" and I think I'm going to get grilled with lots of…

I guess at least it’s a step up from the time someone was trying to brand a grassroots weather data collection effort and decided to name it after a terrorist organization.

I’m a massive fan of - and indeed contribute data to - the weather underground project, but the naming has always made me a little uncomfortable.

Re: Pirate Weather: A free, open, and documented forecast API

#42

> Why "PirateWeather"? I've always thought that the HRRR model was pronounced the same way as the classic pirate "ARRR". Also, there is one company out there that thinks APIs can be copyrighted, which might apply here. This answers the first question I had upon seeing the name, which was, is it free, open, documented and legal ? Based on the above the answer seems to be "probably". Very commendable effort, and I hope…

I agree, PirateWeather seems like a misbrand here. When I read it, i thought it was stealing weather data or something. On the web, the term "pirate" generally doesn't mean good things. This name almost implies that it is illegal or something. I'm imagining designing a software product around this and presenting it to a C-Level, explaining that we use "PirateWeather" and I think I'm going to get grilled with lots of…

Maybe most of the good products come out of places without too many C level types :)

Re: Pirate Weather: A free, open, and documented forecast API

#45

How does this differ from NOAA weather.gov api? https://www.weather.gov/documentation/services-web-api Or is this a friendlier overlay of their interface?

Under “Weather Sources”

> All weather data comes from the AWS open data program https://registry.opendata.aws/collab/noaa/. This is a fantastic program, since it is more reliable than the NOAA distribution, and means there are no data transfer changes!

Re: Pirate Weather: A free, open, and documented forecast API

#47
post #16

It's going to be a tangential comment but I work in science research that's adjacent to weather forecasting and I find the political/technical jockeying that is happening with forecasting to be fascinating. It's a nexus of capitalism, federal government spending, politics, and technology that has very real implications for individual Americans. In summary: horrible oversight by the federal govt (read, congress) of ou…

Have any nerdy Congresspeople wanted to solve this ridiculous inefficiency in recent years. Seems like a natural "the Europeans kick our ass at forecasting" message would go over well and potentially negate the lobbying from Weather Channel and others with a vested interest in perpetuating this stupid situation.

Yes, Congress passed the Weather Research and Forecasting Innovation Act back in 2017 which not only gave massive funding injection to model development activities, data procurement, and more, but also formalized the new next-generation community modeling initiatives which are focused on tackling the dominance of the EC models in the 2-5 day forecast space.

The diagnosis of the problems of the American forecast modeling community here is based on flawed premises. There are three major factors which led to the ECMWF leap-frogging the US in day-ahead forecasting capability. The first is the consolidated investment in supercomputing resources; the WRFIA tackles this by earmarking a much larger allocation of funding for NOAA's next gen supercomputer, but this still pales in comparison to ECMWF investments.

The second factor is the fragmentation of the research and operational weather modeling communities due to the divergent investment from NOAA and USAF in the 90's and 2000's; USAF in conjunction with NCAR sponsored the development of the WRF model which was widely adopted by the research community. NOAA continued investing the GFS lineage of models. The bifurcation of these communities slowed down the ability to matriculate advances in model developments to operations, and this was exacerbated by an old, closed-off approach by NOAA which made it extraordinarily difficult to run and develop the GFS on anything other than NOAA hardware.

Finally, the ECMWF went all-in on 4DVAR data assimilation in the late 90's, whereas the American community pursued a diversity of other approaches ranging from 4DVAR to ensemble Kalman filters. 4DVAR necessitates advances to core weather model software (e.g. you need to write a model's adjoint or its tangent linear in order to actually use 4DVAR) adn the US' failure to adopt it led, imo to a "double edged sword" effect of (a) failing to provide impetus to greatly improve the US modeling software suite and supporting tools, and (b) being a worse assimilation technique unless advanced EnsKF techniques are employed using very large ensembles of models (expensive).

The other problem as others have pointed out is that there is no accountability in the US private sector weather market. Virtually every player is re-transmitting raw model guidance or statistical post-processed forecasts using DiCast, _maybe_ with a some manual tweaking of forecast fields by humans. But this is not transparent, and many companies - if we're being charitable, here - are not honest about what they're actually doing to produce their forecasts. Put another way - there's a lot of BS claims out there, and it seems that investors have been more than happy to fund it over the past few years.

Re: Pirate Weather: A free, open, and documented forecast API

#48
post #37

Earlier quoted context omitted.

> "I know for instance you cannot use Amazon SES without also using S3 and Lambda" You can absolutely use SES without S3 and Lambda. I've used it many times in various projects.

Not on the receiving side https://docs.aws.amazon.com/ses/latest/dg/receiving-email-co...

As that page makes clear, SES can hand off incoming mail to a Lambda, or to S3 – or to SNS which can deliver it to any HTTP endpoint, or e-mail address, or text it to your phone for that matter.

Re: Pirate Weather: A free, open, and documented forecast API

#49

> Why "PirateWeather"? I've always thought that the HRRR model was pronounced the same way as the classic pirate "ARRR". Also, there is one company out there that thinks APIs can be copyrighted, which might apply here. This answers the first question I had upon seeing the name, which was, is it free, open, documented and legal ? Based on the above the answer seems to be "probably". Very commendable effort, and I hope…

I'm the dev behind this, so always great to hear things like this! I really struggled to try to come up with a name. My first thought was "Bright Ground" (opposite of Dark Sky), but that seemed a little too on the nose. Luckily, the legal aspect of this (I'm in the clear!) was pretty well settled after the final Oracle v. Google case, but at the time was a big enough deal that it seemed relevant, and the HRRR model was another plus. I should update that README though, since it's now very definitely legal!

Re: Pirate Weather: A free, open, and documented forecast API

#50
post #37

Earlier quoted context omitted.

> "I know for instance you cannot use Amazon SES without also using S3 and Lambda" You can absolutely use SES without S3 and Lambda. I've used it many times in various projects.

Not on the receiving side https://docs.aws.amazon.com/ses/latest/dg/receiving-email-co...

What do you expect SES to do with your mail after receiving it? S3 and Lambda are optional delivery locations, amongst other choices.
Post reply on HN