tags:

views:

208

answers:

6

I'm writing a geocoding component for an app I'm building, and I decided to use Yahoo Maps. I wrote the geocode API wrapper and some unit tests and called it a day. Came back the next day, ran the tests, and found that the latitude and longitude had changed. Mind you, the change was small enough not to matter to me, but it was significant enough to affect the rounding to 4 decimal places that I was using in my unit test to compare the result.

I've never heard of changing latitude and longitude before. Is this something I should expect / account for? Can anyone explain why?

+4  A: 

Continental Drift?

chris
+1 - LOL - that's very, very funny
Reed Copsey
It could be global warming.
rein
Oddly, my first thought was precisely that. Then I slapped myself and said "Self, there's no WAY yahoo is that good." :D
Chris
+4  A: 

Geocoding, especially when done from addresses, is rarely 100% accurate. There are many companies who do nothing but compile the street data used for geocoding purposes.

The data is not accurate, but is frequently updated to improve address matching. When this happens, you'll get a different result. My guess is that one of two things happened:

1) Yahoo updated their source data.

2) You got a result from a different server with a different set of source data.

Reed Copsey
I thought about the potential for #1, but that would be a freaky coincidence. #2 actually sounds more likely, but then, the test ran fine all day yesterday and it runs fine now that I've amended the value to compare against. I'm beginning to think the calculations on Yahoo's side are affected by date somehow.
Chris
My guess is that they, being a web service, are running this across an entire farm of machines. If they have a slightly different software version or data version on some of their machines, you'll get subtlely differring results. This is one HUGE advantage of commercial geocoding - you control when the updates occur, plus they tell you how "good" the match was (ie: to zip, census tract, census block, street, exact, etc)
Reed Copsey
+1  A: 

The algorithms that geocoding uses are necessarily imprecise. They make certain guesses. In addition to the information given above, checkout this whitepaper:

http://www.urisa.org/files/goldberg.pdf

Which talks about those algorithms.

Christopher
I understand imprecise calculations, but imprecise does not imply inconsistency. I would expect the same imprecision to persist from one day to the next, wouldn't you?
Chris
A: 

It sounds like it could be rounding error on the calculations being performed.

Are the results consistent now or are you still getting slightly different results?

ChrisF
Consistent now. I'm wondering if some calculation on the Yahoo! side is affected by date. I'll try again tomorrow and see if the test fails.
Chris
If the data is consistent from now on I'd go with a database update at the Yahoo end.
ChrisF
A: 

The map is not the territory

Something that's really easy for us, as programmers, to lose track of is that the data represent the world, they are NOT actual aspects of the world.

You've got other answers saying the same thing in more detail, specifically about geocoding, but it's worth remembering in general as well....

RolandTumble
RolandTumble
Please be aware that a downvote doesn't necessarily come from the question asker. I didn't touch your answer.
Chris
I am aware of that--sorry that I wasn't clear that my question was to the downvoter, whoever it was....
RolandTumble
A: 

Interesting.

Looks to me very like the things that happen when one compares 'real' numbers for equality. Usual solution to this 'problem' is to calculate Abs[x-y] < tol where x, y are your real numbers (or floats, or doubles) and tol is some small number which represents your criterion for deciding that the numbers are close enough to be considered equal for your purposes.

Regards

Mark

High Performance Mark