Hi all,
I grab a png image using the radar api every 15 minutes and then combine these to create my own animated radar image for the previous 12 hours. I have noticed recently that a "rogue" image creeps in, sometimes quite frequently. Its always the same image (I will try and attach). I also do a similar process on my brothers website using a different api key, different location etc and likewise get a rogue image, although the image is different to mine but always the same that appears.
I have deleted all my png files (my script automatically deletes images older than 12 hours anyway) to make sure somehow a rogue image was not being used but to no avail.
If you take a look at my website http://midlifedad.me.uk/weather/radar.php you may be able to see a live occurrence.
Any help or pointers would be gratefully received.
Thanks
Andy
I grab a png image using the radar api every 15 minutes and then combine these to create my own animated radar image for the previous 12 hours. I have noticed recently that a "rogue" image creeps in, sometimes quite frequently. Its always the same image (I will try and attach). I also do a similar process on my brothers website using a different api key, different location etc and likewise get a rogue image, although the image is different to mine but always the same that appears.
I have deleted all my png files (my script automatically deletes images older than 12 hours anyway) to make sure somehow a rogue image was not being used but to no avail.
If you take a look at my website http://midlifedad.me.uk/weather/radar.php you may be able to see a live occurrence.
Any help or pointers would be gratefully received.

Thanks
Andy
- 28 Posts
- 9 Reply Likes
Posted 2 years ago
- 2 Posts
- 0 Reply Likes
I grab an update once an hour and it happens several times a day for me. Interestingly, the radar image is always the same and believe from a few weeks ago. My app isn't caching so thinking it must be on the server side.
- 6 Posts
- 0 Reply Likes
Brendan Hayes, Official Rep
- 962 Posts
- 124 Reply Likes
There was a radar issue but it should be fixed now.
- 6 Posts
- 0 Reply Likes
hello,
always the same problem....
Do you think that you will soon cover the south of France?
Cordialy,
always the same problem....
Do you think that you will soon cover the south of France?
Cordialy,
- 6 Posts
- 0 Reply Likes
I am obliged to remove the WU radar for the moment and I am looking for an alternatv
cordialy
cordialy
- 28 Posts
- 9 Reply Likes
Hi Brendan,
Sorry to say that the same image re-appeared at 19:00 and 19:15 UK. I deleted all my png files when you stated it should be resolved but exactly the same image as the one originally posted has re-appeared. Please see http://www.midlifedad.me.uk/weather/radar.php
Andy
Sorry to say that the same image re-appeared at 19:00 and 19:15 UK. I deleted all my png files when you stated it should be resolved but exactly the same image as the one originally posted has re-appeared. Please see http://www.midlifedad.me.uk/weather/radar.php
Andy
(Edited)
- 5 Posts
- 0 Reply Likes
I also am having the same issues. It seems that at random intervals, the image and timestamp are not accurate, with the image seemingly coming from a "cached" point in time.
I have the same random behaviors using PiClock as I do in the browser, with no consistency in whether I get a proper radar layer or timestamp (UTC vs. EST). When did the fix get implemented, so I can monitor through out the day?
EDIT: I just looked at the screen, and the time stamp for the "region" is in UTC, while the "city" timestamp is in EST. The radar layers "seem" accurate and agree, although the UTC timestamp is indicative of a forthcoming "cached" image set coming.
I have the same random behaviors using PiClock as I do in the browser, with no consistency in whether I get a proper radar layer or timestamp (UTC vs. EST). When did the fix get implemented, so I can monitor through out the day?
EDIT: I just looked at the screen, and the time stamp for the "region" is in UTC, while the "city" timestamp is in EST. The radar layers "seem" accurate and agree, although the UTC timestamp is indicative of a forthcoming "cached" image set coming.
(Edited)
- 5 Posts
- 0 Reply Likes
Well, after running for a day, I would qualify the radar images as unreliable. It seems for every good set I get, I go through a 15-20 minute cycle of inaccurate images.
Is there a parameter or some sort of sanity check I can look at to discard any erroneous returns?
Is there a parameter or some sort of sanity check I can look at to discard any erroneous returns?
- 28 Posts
- 9 Reply Likes
Tom, have been looking for the same thing. With other issuesI have seen, on forecast for example, you could quite easily spot a rogue file , always a low amount of bytes or same so you could write a small script to detect the file and call the api again until a file size greater than the criteria was met. Unfortunately with the radar png it’s not constant, my rogue image is around 10k and even this varies slightly for the same image. Problem is you can get a valid image with roughly the same size, depending on how much data is in the image so it’s difficult to spot the rogue one.
Can’t think of any way to spot them.
Can’t think of any way to spot them.
- 1 Post
- 0 Reply Likes
I'm using a similar pull process and getting an old static overlay several times during the day. Sometimes it'll be as often as every other refresh.
- 2 Posts
- 0 Reply Likes
Still happening and is always the exact same radar image, but with new timestamp.
- 2 Posts
- 1 Reply Like
Hi I am running PiClock on a RPI 3 - it uses a WU API and it too is still showing the same rogue radar image every hour or so - possibly less frequently now in line with Brendan's update (this started about three weeks ago). I do not see a change in the time stamp it seems to be correct (UTC running a series of images up to about 5 minutes behind the actual time). So better but still not as it use to be - I have used PiClock for about a year without an issue until now.
Brendan Hayes, Official Rep
- 962 Posts
- 124 Reply Likes
It seems that this situation seems much better now. If there are more issues, please submit the URL of the radar API
- 5 Posts
- 0 Reply Likes
Looks better. I will submit URL's if things get squirrelly again.
- 28 Posts
- 9 Reply Likes
I got one rogue image around 13:00 GMT so before above post from Brendan but none between then and now (22:30 GMT). I will keep track on it for a few days and let you know if I see any further ones. However, 1 out of 48 frames is much improved. Thanks. Andy
- 5 Posts
- 0 Reply Likes
Back into the error cycle again.
http://api.wunderground.com/api/<key>/animatedradar/lang:EN/image.gif?maxlat=39.1192945599&...

http://api.wunderground.com/api/<key>/animatedradar/lang:EN/image.gif?maxlat=39.1192945599&...

- 28 Posts
- 9 Reply Likes
Sorry to say I am still getting the same issue. I got the same images at 00:15, 02:30, 05:00, 05:45, 08:15, 10:45 and 11:15 (All GMT). All images in between seem to be ok but there isn't much rain around at the moment :-) My URL for the call is: http://api.wunderground.com/api/API_KEY/radar/image.png?minlat=52.54&maxlat=53.38&m...
I also see the same happening on my brothers system, this time at 03:00, 04:30, 07:15. Its always the same image, but different to mine. Here is that URL:
http://api.wunderground.com/api/API_KEY/radar/image.png?minlat=53.435&maxlat=54.255&...
Hope it helps finding the issue.
Andy
I also see the same happening on my brothers system, this time at 03:00, 04:30, 07:15. Its always the same image, but different to mine. Here is that URL:
http://api.wunderground.com/api/API_KEY/radar/image.png?minlat=53.435&maxlat=54.255&...
Hope it helps finding the issue.
Andy
(Edited)
- 1 Post
- 0 Reply Likes
I have the same issue, see difference for frame 3 and 4 for the same location.
Note that the displayed time is also suddenly for a different time zone.


Note that the displayed time is also suddenly for a different time zone.


(Edited)
- 3 Posts
- 0 Reply Likes
I am experiencing this issue as well, despite numerous times being told that the issue had been fixed.
- 2 Posts
- 0 Reply Likes
I've been experiencing the same issue, within .Net I casted the byte[] to an image and checked the frame timings property to make sure they matched the delay I asked for in the query string, if it did not I had it wait a second and retry up to 5 times, this seemed to work until the issue is resolved.
Brendan Hayes, Official Rep
- 962 Posts
- 124 Reply Likes
We are trying again to address the problem. There seems to be 2 issues, black background and "old" frames. Keep supplying example URLs please so we can continue to investigate
- 5 Posts
- 0 Reply Likes
http://api.wunderground.com/api/%3Ckey%3E/animatedradar/lang:EN/image.gif?maxlat=39.1192945599&m...
Two different pulls, separated by a second seem to pull vastly different overlays. I have not seen the black overlay, only incorrect timestamps and an overlay that is not related to the GPS coordinates I sent in.
Two different pulls, separated by a second seem to pull vastly different overlays. I have not seen the black overlay, only incorrect timestamps and an overlay that is not related to the GPS coordinates I sent in.
- 2 Posts
- 0 Reply Likes
These 2 have consistent problems:
http://api.wunderground.com/api/{key}/animatedradar/q/GA/Rome.gif?newmaps=1&timelabel=1&time...
http://api.wunderground.com/api/{key}/animatedradar/q/WI/Stevens_Point.gif?newmaps=1&timelabel=1...
The following seems to be pretty stable and returns correctly:
http://api.wunderground.com/api/{key}/animatedradar/q/WI/New_London.gif?newmaps=1&timelabel=1&am...
http://api.wunderground.com/api/{key}/animatedradar/q/GA/Rome.gif?newmaps=1&timelabel=1&time...
http://api.wunderground.com/api/{key}/animatedradar/q/WI/Stevens_Point.gif?newmaps=1&timelabel=1...
The following seems to be pretty stable and returns correctly:
http://api.wunderground.com/api/{key}/animatedradar/q/WI/New_London.gif?newmaps=1&timelabel=1&am...
- 28 Posts
- 9 Reply Likes
As I opened the original post I thought I would pass back an update. I have had no rogue images from either of my API calls for a few weeks now so as far as I can see this issue appears to have been resolved. Thanks.