API call returning limited data in Surrey BC, Canada.

  • 3
  • Problem
  • Updated 1 year ago
Both weather 'conditions' and weather 'forecasts' are not working properly. This is what I get back for a weather conditions call:

{
  "response": {
  "version":"0.1",
  "termsofService":"http://www.wunderground.com/weather/api/d/terms.html",
  "features": {
  "conditions": 1
  }
		, "results": [
		{
		"name": "Surrey",
		"city": "Surrey",
		"state": "BC",
		"country": "CA",
		"country_iso3166":"CA",
		"country_name":"Canada",
		"zmw": "00000.5.WCVBB",
		"l": "/q/zmw:00000.5.WCVBB"
		}
		,
		{
		"name": "Surrey",
		"city": "Surrey",
		"state": "PE",
		"country": "CA",
		"country_iso3166":"CA",
		"country_name":"Canada",
		"zmw": "00000.94.71706",
		"l": "/q/zmw:00000.94.71706"
		}
		]
	}
}
Photo of Clans Estine

Clans Estine

  • 3 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 3
Photo of Dan Watts

Dan Watts

  • 3 Posts
  • 0 Reply Likes
Hi,

It looks like Wunderground quietly made a change to their API - it seems to be affecting mostly (only?) non-US locations.  

The country/city format no longer works as far as I can tell (same thing here in Toronto) but the "zmw" does.  You can find the zmw value in the data returned to your call.  For Surrey BC, it is zmw:00000.5.WCVBB.

So, the following correctly returns the current conditions (if you replace <yourapikey>, of course.)

http://api.wunderground.com/api/<yourapikey>/conditions/q/zmw:00000.5.WCVBB.json

I haven't seen any confirmation from Wunderground that they changed something, but the zmw approach should continue working even if they change it back.

Regards,

Dan.
Photo of Clans Estine

Clans Estine

  • 3 Posts
  • 0 Reply Likes

Dan, Thanks for the information. However, I have found they are also dropping some of the data from the Surrey station and maybe others as well. (For instance, the weather icon now shows as ‘unknown’.) For this reason, I have switched to Vancouver and it seems the normal way of calling it (/Canada/Vancouver) still works. However, I am concerned that sometime in the future this station will also lose this addressing possibility, so, I am curious where you found this ‘zmw’ addressing mode?

 I would like to know how to get the correct addressing format for this for other stations. Can you point me in the right direction?.. I cannot seem to find anything when I Google ‘zmw’.

 

Thanks

Clan

Photo of Dan Watts

Dan Watts

  • 3 Posts
  • 0 Reply Likes
Clan,

I was wondering the same thing about the "zmw" mode - as you say, Google doesn't return anything about it, so I guess it's internal to Weather Underground.  

One way to get the zmw setting for a city is to load www.wunderground.com, enter the city name in the "Search Locations" box, then load the page for that city.  The URL will contain the zmw code. For example, the page for Surrey BC is https://www.wunderground.com/q/zmw:00000.52.71775

I suspect that the wmz format is 00000.elevation.WMOCode, and you can get the elevation and WMOCode for some cities (but not Surrey) from https://www.wunderground.com/about/faq/international_cities.asp.

Another approach that seems to work is /q/latitude,longitude.  So, this query returns Surrey BC: http://api.wunderground.com/api/<apikey>/conditions/q/49.10,-122.80.json

This information is all from trial-and-error and guesswork.  I haven't found any documentation on Weather Underground listing all the supported formats.  Maybe the latitude/longitude approach is the most flexible, but it looks like internally Weather Underground is using the zmw approach in their pages.

HTH,

Dan.
Photo of Brendan Hayes

Brendan Hayes, Official Rep

  • 962 Posts
  • 122 Reply Likes
There was a city update to add more cities and update our locations.  That is the cause of some of these issues.  For the city/country that is not working, what does that URL look like?  In some cases the addition of cities made the results ambiguous and so you need to narrow down the search parameter that is returned in the ambiguous result. 
Photo of Clans Estine

Clans Estine

  • 3 Posts
  • 0 Reply Likes
The calls to /Canada/Surrey are now showing 2 cities in Canada with the name :Surrey. The problem is that no one knows how to address a specific city in a specific province. Nothing seems to work. Should be something like, /Canada/BC/Surrey
Photo of Dan Watts

Dan Watts

  • 3 Posts
  • 0 Reply Likes
Ah, OK, at least I know now that it's not a bug that will be fixed.

So the API wasn't changed, but there are now 2 Canadian Surreys in the database.

In my case, the URL that used to work was:

http://api.wunderground.com/api/<apikey>/conditions/q/Canada/Toronto.json

This now returns:

		{
		"name": "Toronto",
		"city": "Toronto",
		"state": "ON",
		"country": "CA",
		"country_iso3166":"CA",
		"country_name":"Canada",
		"zmw": "00000.1.71639",
		"l": "/q/zmw:00000.1.71639"
		}
		,
		{
		"name": "Toronto",
		"city": "Toronto",
		"state": "PE",
		"country": "CA",
		"country_iso3166":"CA",
		"country_name":"Canada",
		"zmw": "00000.37.71350",
		"l": "/q/zmw:00000.37.71350"
		}
		
The one I want is the first one. 

I don't know what the correct format for a three-level locator would be - is that documented somewhere?  I've tried various combinations and hyphenations, like /q/Canada/ON/Toronto or /q/Canada/Toronto-ON, but haven't found one that works yet.

As mentioned, the zmw format works, and I guess that's never going to be ambiguous, so I'm OK with changing to that format.

Thanks,

Dan.
Photo of Brendan Hayes

Brendan Hayes, Official Rep

  • 962 Posts
  • 122 Reply Likes
Taking the new step to the "l" value is the right way to step through the ambiguous results.  ZMW will work for a long time, but its good to verify them once in a while as well in case any of the zip codes update.  The USPS updates zip codes more often than you'd think.
Photo of WeatherVor

WeatherVor

  • 38 Posts
  • 4 Reply Likes
Brendan, I think it is more messed up than that. 
"New York, NY" is pretty unambiguous in my opinion but it returns no data if certain languages are used.

Does not work with German, both Chinese,  Korean, Russian, Finish, Greek etc:
https://api.wunderground.com/api/key/lang:DL/pws:1/geolookup/astronomy/conditions/hourly10day/foreca...

But works with English, French, Swedish 

ZMW is not even documented feature.

When are you going to fix this?
Photo of moater11

moater11

  • 49 Posts
  • 8 Reply Likes
Hi, was this fixed? I would think a reasonable fix would be: if more stations are returned for one particular City, just display the data for the first one in WU list. At least is something.

Cheers,
M.
Photo of Diogo Cardoso

Diogo Cardoso

  • 2 Posts
  • 0 Reply Likes
I started watching this happen in the last couple of days. I was using the format:
http://api.wunderground.com/api/<apikey>/conditions/q/<country>/<city>.json and I was able to get data for pretty much every city in my country.
For example, making a request for Porto, Portugal would get me the data from one station. Now, I get an array of 4 stations. Im wondering whats the best practise here. I was thinking of making a call to the same url, save the "l" value, and make another call with that value to get the weather data. But this implies making twice the calls I was making.

I agree with @moater11 's idea. Just choose a "default" station and then people change it if they have to.

Also, the process of adding stations (as mentioned) has affected a lot in Portugal. I use WU everyday to check the weather on 2 cities and the stations chosen are both wrong. (when I say wrong, it's geographically wrong)
Photo of Diogo Cardoso

Diogo Cardoso

  • 2 Posts
  • 0 Reply Likes
There's definetly something going on with WU. The same array of 4 stations show up when I search Porto, Portugal on WU's website too. 3 of the 4 stations are wrong. They are not in Porto, Portugal. This isn't only an issue with the API. Someone fuckd up big time. Im testing other api's because this makes no sense.
(Edited)