Add more weather provider

[jeremy447]

Hello,

OpenWeather is really often inaccurate, at least here in Bordeaux, France. That lead me to stop using the app and to rely on a website for now. However I noticed that the Norwegian Meteorological Institute is far more accurate and is free to use as you can see in the links below. For instance, it's the weather provider of Gnome Weather that I use and that allow me to confirm that is precise.

http://www.met.no/ http://www.met.no/English/Data_Policy_and_Data_Services/ http://www.yr.no/

Maybe OpenWeather is better for some location so it will be great if we can choose our provider.

Thank you for the app !

[martykan]

I will definitely want to implement this in a future release, Yr.no is also pretty accurate in my area.

[jeremy447]

I saw in libgweather code, that Gnome Weather use, that there is some other useful providers that can maybe be integrated too:

• METAR office, providing current conditions worldwide
• US weather office, providing 7 days of forecast
• Yahoo Weather Service, worldwide but non commercial only

I compared the weather forecast for my location from OpenWeather, Norwegian Meteorological and Yahoo Weather and the most accurate is always Yahoo Weather.

[trymeouteh]

I love this app. But I would like to see Dark Sky added since I always check the weather using DuckDuckGo and DuckDuckGo uses DarkSky within their smart search results. I would to have the same weather provider on my phone also through Forecastie since I have a degoogled phone and the best weather app I can get outside of the Google Play Store is Forecastie on F-Droid.

[robinpaulson]

Yes, it would be a fine addition to the app, along with all the others. Unless someone steps forward to do a fairly significant piece of coding, it's not going to happen I'm afraid. At the moment, we have quite a list of bugs to fix in the core software, never mind doing this.

[chihuahua45]

I will definitely want to implement this in a future release, Yr.no is also pretty accurate in my area.

Yr.no is the only one that gets it right for my city. The other day, it was pouring buckets and OpenWeather was showing "Sunny" 😂

[vestingz]

For Germany there is the Bright Sky project, which provides current weather and hourly weather forecast data through a free JSON API, which sources open data from the national weather institute DWD (Deutscher Wetterdienst). There is a thorough documentation along with working examples and even a simple form to generate valid request through the webfrontend.

They also provide the relevant docker-compose config files to set up your own instance.

[Lee-Carre]

Would it not be better to have OpenWeatherMap use these data sources itself, to then distribute the benefits to all?

If it's a problem of licensing, then I suggest tackling that by persuading the data providers to apply more permissive licensing terms. Take inspiration from USoA's NOAA; because they recognise the benefits of freely available weather data, including for commercial use.

This way, OWM is then more of a data aggregator (and makes access convenient for projects like Forecastie).

Otherwise, sounds like a lot of wheel-reinvention (for each implementor).

[robinpaulson]

@Lee-Carre Yes, to everything you said. I fear this would take a lot of effort and a particular type of person to be successful. Maybe there are libraries out there which abstract all the free/open data weather providers so the differences between them are erased? I know there are Java (and Python and ...) libraries for talking to OWM already. I and of course others have noticed the way the internet has splintered in ways that traditional UNIX-like distros have not, this is another symptom of that.

[Lee-Carre]

@robinpaulson I can only concur.

Maybe there are libraries out there which abstract all the free/open data weather providers so the differences between them are erased?

this would take a lot of effort

Hence my criticism of wheel-reinvention, and that for each implementor. Wheel-reinvention² ?

Goes completely against so many principles.

Besides, there already exist libre apps which make use of those specific data sources (I've seen them while browsing through F-Droid repositories). Thus, I'm also reminded of the ‘if you want X then you know where to find it’ rule. Lest Forecastie become Yet Another™ clone (likely eroding, in the process, why people liked it in the first place).

‘Perfection is attained not when there is nothing more to add, but when there is nothing more to take away.’ (I forget his name, but this is an English translation of what a French aircraft designer once said).

Further; even if this herculean effort were made; it then sets a precedent, and invites further requests for handling yet more special-cases. ‘Hey, could you just quickly add the data (which isn't in machine-readable format(!)) from the Met service of my tiny island? Thanks’ 🤦‍♂️🙄 Where does it end?

I also doubt that each source supplies equivalent data. In perusing this repository's older issues, I noticed #79 which made clear that OWM didn't supply probability-of-precipitation for quite a while. Yet, the concept of that datum has existed for a long time. I'd bet that there would be other disparities between different sources; so then you'd have to handle what to do when a given source doesn't supply some metric that another source does. I imagine that'll become quite messy, fast. Spaghetti-code, anyone?

To me, that is all something to be handled by the backend, not a GUI API-client.

I and of course others have noticed the way the internet has splintered in ways that traditional UNIX-like distros have not, this is another symptom of that.

Absolutely. It's one reason why I refuse to use the likes of Fa[r]cebook, Twitter, & similar; centralised walled-gardens, which then impose draconian policies. Just, no. We knew how to do better in the 70s. Makes me glad to see the rise of PeerTube, and all the federated social networks.

So many hard-learned lessons being ignored or forgotten. Especially annoying when people whine about what a mega-corp is doing, yet continue to choose to be subject to said bad-actor, instead of choosing network autonomy. Jumping ship to a younger competitor, which still has all the same fundamental flaws, is merely resetting the timer, rather than fundamentally changing anything; because the same set of incentives will lead to a similar outcome. The younger ones are likely getting by on vulture-capital investment for now. What happens later when they need revenue to feed the servers & networking? They'll likely pander to the same advertisers as today. Round and round that goes. I'm reminded of Einstein's definition of insanity.

Even (some) non-tech folks have noticed the trend: A Tale of YouTuber Stupidity.

Anyway, returning to Forecastie specifically, from that aside / mini-rant (I'm here all week; tip your waitresses); another POSIX principle I recall is that simpler tends to be more robust. I dread to think (short of finding an ideal multi-data-source library) how much complexity (and what tends to come with that) would be introduced by deviating from the model of a single (mostly-)libre data aggregator.

A preferable approach would be to add the possibility of a user-configurable API URL / hostname to Forecastie. Then, whoever wants to feed it with a different data source could then run a ‘proxy’ of sorts which reads whatever other data-source (Spanish, Norwegian, NOAA, whatever else, or all of the above) and as output presents what appears to be OWM's API (following the spec of their API, but just the weather data is different). Thus, API schema is a pseudo-standard of a kind, to keep apps simple, and the complexity of data-format-conversion is the job of said external proxy. Each part doing one job, in order to do that one job well. Let the proxy become a bloated mess, instead of Forecastie. I, for one, want efficient, lean apps(, which play well with others).

If people want hyper-local weather, then Trail Sense (also available via F-Droid) is doing interesting things (using the phone's barometer) without requiring any network connectivity.

I'm tempted to suggest that the real problem is non-standardisation of weather-data APIs, but I recall XKCD #927 “Standards”.

However, there does seem to be some truth in the non-standardisation point. Especially with all the buzz about climate, there should be a push to have the data be public (since, to my understanding, its production is publically-funded anyway), then available in standardised formats, to then work on refining the algorithms of aggregators so that they have global coverage, but local forecasts are accurate.

Adding a multitude of disparate sources to an app which should be concerned with the job of how to nicely present the response to an API call to the user (rather than doing any data integration of its own) seems, at best, like a massive kludge of a workaround, which does nothing to solve the underlying problem(s).

Fixing the general case also improves the specific (special) case. I say that as someone for whom the only reliable forecast is the 24-hour from the local met office (because tiny island located such that it's notoriously (in met circles) difficult to predict for. Even the local 5-day tends to be useless. The solution is to improve OWM (or whatever fully-libre system might replace it), not to bypass it.

If the decision were mine, then this would be closed as won't-fix (because it's not Forecastie's problem). But, I'm an asshole like that 🙂.

I'm also mindful of what may result in future, for Forecastie's development. If the request of this issue were done, then development time might end up being spent largely on that fragile module (imagine a data-source changing their API spec, which you know will happen eventually, and sometimes without notice), instead of refining being (basically) a front-end for an API.

Then imagine the complaints about this bug, or that one, and why it then takes so long to implement a new feature, or become compatible with the newest Android API.

Worse; you may become bogged down & frustrated, lose your passion & motivation (at least for Forecastie), and development would grind to a halt. Everyone loses, then.

So, I'd be wary of the temptation to appease folks with this request, given that they may well not like the future results of it (and end up abandoning Forecastie anyway, for some other reason).

Finally, for the curious who've made it this far, what do robinpaulson & I mean by ‘POSIX principles & (design) philosophy’? Learn: The Art of Unix Programming. Then, when you've finished assimilating that wisdom; The Art of Unix Usability. You're welcome.

[robinpaulson]

There's a lot of very interesting and useful information in there. I'm going to be stepping back from maintaining the app in the near future, the owner/original coder may be on the lookout for another maintainer.

As an aside, it's not acceptable to use language like this: "Tw*tter"

It's derogatory and likely misogynistic. I'm pretty sure it breaks the terms of the Code of Conduct. I appreciate that Twitter et al are appalling, there are acceptable ways to insult and mock them though.

This isn't so bad, but it's still unnecessarily insulting, it doesn't progress the conversation or the software anywhere useful: "special-snowflakes"

[robinpaulson]

Going further on the principles it breaks, there are multiple reasons why a person would write/maintain a particular piece of software.

Yes, it will probably provide some utility, but it may also be because they enjoy coding, are bored or unfulfilled in some other way - OWM is particularly easy data to re-use and weather apps are relatively low bar, hence their proliferation.

It may improve their standing in the free software/Android community, think ESR's arguments in The Cathedral and the Bazaar, and provides them a way to make a lasting mark on the world.

Perhaps it's a way to fame and fortune? In 1991, Linux was just another UNIX kernel, a small side-project and hobby for Linus.