ANNOUNCE: xfce4-weather-plugin 0.8.0 released

[Harald Judt]

Am 26.07.2012 20:38, schrieb Liviu Andronic:
> Hello Harald
> These are interesting points you make. Several comments below.
>
>
> On Thu, Jul 26, 2012 at 11:52 AM, Harald Judt <h.judt at gmx.at> wrote:
>> To elaborate a bit about the current provider: It is mainly a forecast API,
>> so what you get is forecasts, not the actual weather. You get data like
>> temperature for every hour (or three, or six depending on the location), and
>> calculated values for these intervals.
>>
> Hmm, this makes me thinking of a feature request. One of the killer
> features of The Weather Channel app in Android is that it provides
> forecasts broken down by hour for the 12 hours or so. This is very
> useful as it gives one a hint on how the weather is likely to evolve
> during the day: Do I take my umbrella or my sun glasses? Would
> something similar be remotely possible in the current UI with the
> current provider?

It depends on how much data is available. For some locations, you get 
data for every hour of the day, for others it's just every third hour, 
for others every sixth hour.

But to be honest, to me such detailed forecasts are not very useful. 
Rather, they will make me tired, having to look and interpret all that 
values that could be true. I will not trust them. Out of spontaneity the 
weather will change, and all forecasts are suddenly wrong. I'm not a 
weather scientist, and usually the only thing I want to know is: Will it 
rain today, and will it rain so much that it's better to take an 
umbrella? For that I think the current implementation is detailed 
enough. That said, just look at the old version or the android app you 
mentioned, they only provide current temp, lowest temp, highest temp, or 
day/night temps. And that are really the only values most users are 
interested in. Everything more detailed is just nice to have, something 
interesting to look at every once in a while.

The break-down into morning, afternoon, evening and night is easy to 
grasp because people divide their day into such segments. They are not 
asking themselves "What is the temperature at 3pm, 5pm, 7pm", that is 
already too complicated. They will usually translate this into "How hot 
can or will it get in the afternoon, evening,...?" anyway.

>> One problem is you may only get data
>> like temperature for three hours from now, so you cannot know the current
>> temperature.
>>
> That's slightly strange, indeed. But I guess users can get used to it.

Yes, you can get used to it, but it's certainly different from similar 
apps. I agree it's a bit of a disadvantage you cannot tell your 
colleague how high the temperature is at the exact moment. I myself did 
not like the idea at first, but now I'm quite satisfied with having the 
forecasts available. There will be ways to improve the situation, and 
I'm sure even the presentation of the forecasts can still be enhanced 
and made more interesting.

>> The current description of the plugin is a bit misleading in that regard.
>> Maybe it should just state that it shows weather forecasts, that would be
>> more correct.
>>
> Maybe this would be necessary, but also UI hints that the values
> indicated are short-time forecasts.

It tells you the times in the details tab.

>> As for the openweathermap provider, it seems pretty new. Some parts are not
>> documented yet, just look at the missing links in "About OpenWeatherMap.org"
>> on the bottom of the website.
>>
> Yes, the project doesn't yet seem mature enough for our purposes. I
> wanted to bring it forth mainly as a future candidate for weatehr
> provider, should such needs arise again. The fact that it is an "open"
> project should count, too. (Of course, provided it gets useful and
> mature enough.)

Free data is a necessary requirement, but not the only one.

>> Live data and availability of historical data would be nice indeed. Maybe we
>> could consider using this as an addition to the met.no API, and maybe
>> switching to it in the future. Before doing so, more experience with
>> openweather.org is certainly required.
>>
>> As a side note: Having a single provider is preferable for maintenance
>> reasons.
>>
> Yes, this would be one possibility. For example fetch current weather
> from one provider, and fetch forecasts from another. But this
> shouldn't be done if it significantly increases maintenance overhead.
>
>
>> Finally, I think the android application you referred to still uses google
>> weather, at least it reported such a link when it was blocked by the
>> firewall.
>>
> Yes, their bug report is still open [1]. I actually suggested them to
> use yr.no . :)
> [1] https://code.google.com/p/weather-notification-android/issues/detail?id=72
>
> Regards
> Liviu
>
> PS What about DDG? If you issue a search for weather you get this:
> https://duckduckgo.com/?q=weather+oslo
>
> I'm not sure if it has an API available, but I would suspect it does.
> (Should you be interested, I could inquire on this. Let me know.) It
> is quite friendly towards open-source, and has even opened a platform
> for open-source extensions. [2]
>
> And I notice that DDG uses [3], which itself provides a free API.
> Maybe this one could be of interest to us?
>
> [2] http://duckduckhack.com/
> [3] http://www.worldweatheronline.com/

AFAIK worldweatheronline requires you to register and obtain a license 
key required to access the data, which you may not even make public. Now 
how would we comply to that?

If we're going to use another provider:

* It needs to be free and without license issues.
* The API should be stable, no sudden changes. If you look at met.no, 
they do not change their API version very often but will announce it. 
I'm also pretty confident they won't turn off the old one so fast.
* Worldwide data is a requirement.

Maybe in one or two years there might be more choices. Myself, currently 
I don't know of any that would qualify.

Harald

-- 
`Experience is the best teacher.'