Location Different JSON vs. XML

  • 2
  • Problem
  • Updated 2 weeks ago
When doing a get for conditions specifying PWS id, I am getting different returns for observation_location:full and observation_location:city depending on whether I ask for JSON or XML (the XML is correct / the JSON is not and names a city 40 miles off).

Is this a new feature or has it always been this way? I'm a noob and need to know if I should ignore the JSON option and stick with the XML exclusively.
Photo of Fred

Fred

  • 3 Posts
  • 0 Reply Likes

Posted 3 weeks ago

  • 2
Photo of TanerH

TanerH

  • 5 Posts
  • 0 Reply Likes
I'm seeing this, too.

The XML is correct, and has the "regional"/custom name of the PWS.
The JSON has weather for an airport code that is many miles away.

I have to assume this is a bug on the JSON side?

I also am not sure if it has always been this way, or not, since I had been using XML for years, and only recently started looking at the JSON version.
Photo of Tim Roche

Tim Roche, Official Rep

  • 268 Posts
  • 19 Reply Likes
Hello, 
Can you please send an example?  This is most likely due to additional privacy safeguards for PWS owners we are rolling out.  The data will be the same, but we will no longer be displaying some specific information about the PWS locations in our API.    
Photo of TanerH

TanerH

  • 5 Posts
  • 0 Reply Likes
I did notice that. 
The Lat/Long is "exact" in the XML, but obfuscated (shortened to 2 decimal places) in the JSON.

However, the JSON has a local airport name, instead of the actual PWS name; the XML has the actual PWS name.

I don't mind "blurring" the location, but you should preserve the actual PWS name/label, IMHO :-)

XML (I blurred the exact coords, since this is my PWS) --


JSON:
Photo of Tim Roche

Tim Roche, Official Rep

  • 268 Posts
  • 19 Reply Likes
You found an edge case where our city database is a bit lacking.  Unfortunately for now, we are removing the PWS name.  This is in response to some new EU privacy rules which we are bound to follow to operate in Europe.  While taking the time to address the EU issues we decided to beef up our privacy protections for everyone everywhere.   

We want to make sure we maintain the right balance of protecting our users, and disseminating useful information, We expect this balance will evolve over time as our community of PWS owners weigh in on our stance.  
Photo of TanerH

TanerH

  • 5 Posts
  • 0 Reply Likes
Fair enough.  That said, as it stands now, the XML is accurate, and the JSON is not.

Hopefully you will consider a user-setting that allows the PWS owner to reveal their PWS name, if they so choose?

Mainly because where I live (San Diego), there are a great deal of microclimates, and diluting the accuracy of a PWS name really makes it less useful.

Case in point -- Saying "the weather in San Diego" could mean anything from 60 degrees and foggy at the coast, to 90+ and sunny inland... or even rainy in some mountain areas.

In fact, the new label for my PWS (the MCAS Miramar base) is far enough away from where I live, that the weather there is likely very different on some days.

I really hope you will consider these sorts of situations, thanks!
Photo of Tim Roche

Tim Roche, Official Rep

  • 268 Posts
  • 19 Reply Likes
We will certainly consider it!  Building a system like that isn't easy, so it has to get weighed against other initiatives so I can't make any promises
Photo of TanerH

TanerH

  • 5 Posts
  • 0 Reply Likes
Totally understood :)   I've been involved w/ software dev (and product dev) for a while - so I get it!

Thanks for at least putting it on the "consideration" radar ;)
Photo of Fred

Fred

  • 3 Posts
  • 0 Reply Likes
Tim Roche,

Question: will the XML output eventually be dumbed-down to the give the same result as the JSON? Or can we instead count on it remaining accurate?

Comment: Two digits of lat/long represents about 1.1 kilometers. The distance between TanerH's
KCASANDI210 and Miramar looks to be about 10-12 kilometers. So what's the point? I was able to deduce TanerH's station id from your own WunderGround map since there are no other WU stations within 1.1 klicks of his. The two digit accuracy of 32.94, -117.21 pinpoints him on your map. Obfuscating his town name from Carmel Valley to Miramar Marine Air Station does absolutey nothing for his privacy. His lat/long plugged into Google even gives me a street address. Pointless.

This is not an "edge" condition as you blithely state. Up here in New Hampshire, we call it "rural." This approach may work in densely populated Europe, but if adopted in the U.S it will break operability. My separation from the new reporting airport is more like 30 kilometers. As you get more rural (think Wyoming), it's going to be a lot further. Why would I want my station reported as being hundreds of miles from where it actually is, especially when your map pinpoints my location?

I think you either should approach this with different coding for Europe or adopt TanerH's approach of making it the station owner's choice.

His idea seems like the most intelligent approach. If that's still not good enough for EU regulations, then simply don't offer the Europeans the choice. Make the ability to chose privacy level available by country.

And thanks for responding to this thread by the way! It's great to get feedback on what's going on.
(Edited)
Photo of TanerH

TanerH

  • 5 Posts
  • 0 Reply Likes
I had meant to point out that their blurring was not very effective -- I (personally) was mostly concerned about the name, more than anything else.  There are a ton of community regions in my area, and so having the station incorrectly named (especially with a name of another area that is so far away) will lead to a lot of confusion.  (The WU plugin for the "Chronos" app for my phone started showing me "Miramar MCAS" the other day, and I was very confused, and spent a while trying to figure out why)

I think you jumped the gun on adding some (frankly ineffective) obfuscation, before realizing the direct impact it would have on users... 

I do realize that software dev for a widely-used API/Interface like WU will often have requirements that change and often conflict from region to region -- but I am pretty sure there is a better way to do what you're trying to do (and actually do REAL location-obfuscation if that's what the station operator wants).
Photo of Tim Roche

Tim Roche, Official Rep

  • 268 Posts
  • 19 Reply Likes
I appreciate the comments and understand the frustrations.   When dealing with regulations, not everything will make sense, but we have to do our best to understand how these regulations will be interpreted and work towards following the spirit and letter of those rules.    It is my hope that we can have a solution where the station names, or at least a better location come back to the API in the future

Regarding XML, yes, the changes will be made to the xml api as well in the near future.
Photo of Fred

Fred

  • 3 Posts
  • 0 Reply Likes
Put in that light, the approach WU is taking does make sense since those type of regulations rarely do.

One more (hopefully last) question:

The JSON and XML both have name-value pairs called display_location:full: and display_location:city:. In my case, these values are a lot closer to the actual station's location than the new values in observation_location:full: and city:.










Do you know if the display: info will remain as-is or will it change to the new nearest-airport idea also? If it stays unchanged, that'll be good enough for rural me--Moultonborough is my tiny town.

Won't help big-city TanerH though, as that station's display: info reads San Diego, even farther away than Miramar.
(Edited)
Photo of Tim Roche

Tim Roche, Official Rep

  • 268 Posts
  • 19 Reply Likes
the display location will not change.