Whenever I see a weather "app" I always think: "This is really a weather display utility" and then wonder about the quality / longevity of the service it depends on and how the information is provided.
What would interest me is an implementation that allows you to plug in different weather backends, so that having an API key to worldweatheronline, or screen-scraping weather underground, or building a bridge to your serial-port connected weather station all can target the same interface; to provide current conditions/historical conditions, a forecast, etc.
Are there standards for this, or is it mostly ad-hoc, the whim of the sites or commercial services which aggregate information and provide forecasts?
I've found they vary quite a bit, both in the data points they provide, and the depth of data. Especially comparing free vs paid services. Some provide historical data, others want lots of extra cash for that. Some provide hourly and even minutely results (like my current favorite -- forecast.io), and some do not. And the underlying conditions they provide can vary. You might get simply 'partly_cloudy' from one, an actual cloud cover percentage from another, or even the cloud cover at different altitudes from a yet another provider. So you'd have to do a lot of normalizing between providers to come up with a common API.
So it certainly could be done. And I actually looked into this a few years ago, but it wasn't trivial enough to make it worth the time back then.
I know very little about this space, but when you suggest screen scraping WU, are you implying that they have no API or XML feed or some kind of open feed of their data ?
That's disappointing. I always assumed they did ...
It gets me the information for the forecast and current conditions quickly and painlessly. I have used it for years. I much rather have the NOAA forecast and current conditions to anything else.
A few years ago, you'd get notice by taking an old text-based service and wrapping it up in a web frontend. Now, the cool kids are taking web-based services and wrapping them up in text-based frontends.
Next thing someone will have the bright idea of transmitting data as sounds over VOIP services, and we can start setting up BBSes on skype...
Necessary, but not sufficient. A lot of terminal apps are still - to borrow a phrase - captive user interfaces, which don't play much better with others than a GUI. Decompose all the things into individual utilities (or libraries) so they can be reused and recombined!
I built a shell in Haskell for a class project this semester. At some point I'll get around to releasing it on Github. It doesn't do much aside from backgrounding tasks, piping, and supporting environment variables (both in a config file and dynamically through a built in export command). But it was fun to build!
I would totally use something that allowed me to use Haskell like I use bash. Turtle allows me to do some of it. I'm thinking more along the lines of this project that never took off though:
Idk, i use this kind of thing before I go out to see if I have to prepare better. "oh look it's getting colder, I better not go in shorts", "oh look it's actually pretty cold despite how sunny it looks"
What would interest me is an implementation that allows you to plug in different weather backends, so that having an API key to worldweatheronline, or screen-scraping weather underground, or building a bridge to your serial-port connected weather station all can target the same interface; to provide current conditions/historical conditions, a forecast, etc.
Are there standards for this, or is it mostly ad-hoc, the whim of the sites or commercial services which aggregate information and provide forecasts?