He already did. We know that the part of the API he used was reverse geocoding via the CLGeocoder class:
Good to know, and thank you for explaining how that link was relevant.
He may have found the evidence, but he hadn't presented it yet. Linking to something with no explanation isn't the same as presenting evidence. Had the link had any text which explained its relevance to the discussion at hand, that would have been fine. Unfortunately, it didn't, and I'm not a mind-reader.
"Determined that Apple Maps uses the CLGeocoder Class by peeking at the iPhone's debug console in Xcode while doing live searches in Apple Maps"
Source:
http://www.mtonic.com/applemaps/
We also know that the CLGeocode class results is hopelessly inaccurate
in iOS 5 (
http://stackoverflow.com/questions/11614721/clgeocoder-geocoding-is-hopelessly-inaccurate) compared to the Google maps API reverse geocoding. Note that this post was from before iOS6 came out.
A user on Stackoverflow states that CLGeocode hasn't been using Google as a data source for about a year:
http://stackoverflow.com/questions/...oding-using-clgeocoder-vs-google-geocoder-api
So, since iOS 5 Maps and iOS 6 are using this same API call, and apparently *neither* gets data from Google, what accounts for the difference in accuracy?
That's my point. The same API call may well get data from different places, but if neither one is getting the data from Google, the differences still need to be explained somehow.
That seems to be the only reasonable explanation for the bad results.
The analysis from Tabini documents that the CLGeocode class returns inaccurate results in iOS 6 as well.
However, when you do a normal search in Maps you search for a town and then get the results. You normally don't input coordinates and then get a list of towns nearby. So in reality these tests shows us nothing about the quality of iOS5 maps vs. iOS6 maps. Reverse geocoding simply isn't a good test for comparing the two applications.
Or, maybe we're still talking about two different aspects of the results of that study.
The analysis is flawed on a basic level as you can see above.
I don't necessarily think the CLGeocoder results explain away all of the test results, since the iOS 5 APIs (which did still use Google for their data) apparently often returned locations *outside* Canada (sometimes on different continents) for the locations of landmarks *inside* Canada.
As I understand it, the reverse geocoding was used to help determine whether the results from *either* iOS version results were 'close' to the actual location. If I'm wrong, then it being 'known bad' in both versions doesn't explain the differences at all.
If that data was 'bad' in both versions of iOS, then it calls into question the lookups which were judged to be 'close enough' on both versions, but it doesn't change the results for the significant outliers (locations outside Canada, or no result found, respectively).
I agree completely. The guy from the second Stackoverflow entry do claim that
"I found out of a SVGeocoder Wrapper for google geocoder API. I am testing it now, It indeed brings much for detailed results."
That is not particularly rigorous, though.
What we can conclude from the analysis is this:
1) Reverse geocoding is just as bad in iOS5 compared to iOS6
2) Nobody (or very few) actually use their maps application that way.
What we can conclude from the Stackoverflow posts is this:
1) Reverse geocoding works better using the Google Maps API directly
2) I follows that Apple didn't use the Google Maps API directly for reverse geocoding when these tests were made. Neither in iOS5 nor in iOS6.
Even if, for the sake of argument, we accept your position (stated earlier) that the use of a 'bad' reverse geocoding API for *both* versions of the iOS Maps app completely invalidates the results of the study, then we're back to the scenario where the *only* evidence of good/bad for either is cherry-picked anecdotes both ways.
This isn't the same as evidence that one is better than the other. It puts the situation back to the state of no concrete data to refute an argument presented with a lack of concrete data.
What's needed to make a valid comparison is a test that simply compares the results of a Google Maps lookup to the results of an Apple Maps lookup, *and* to a list of known-good coordinates, all mapped to identical search terms. I think we can both agree on that. The trick is to generate a computer-readable list of known-good coordinates along with reasonable search terms for those locations.
A base-line statistical comparison could probably be done with a few thousand randomly chosen locations world-wide, but to make it useful to people, there'd need to be at least a few hundred or thousand in any given country. The trick is to come up with the list of locations *without* referencing either system, because if we used one to put together the master list then we'd be comparing the results of one to itself.
----------
is that the best a typical Apple fan boy can come up with? To argue that they are both "wrong" means one is not inferior than the other, but we all know Apple's map is worst than Google's.
I'm saying that in the scenario where *both* systems pull back an incorrect result, arguing which incorrect result is better is absolutely pointless.
If that makes me a 'fan boy', then so be it.
On the other hand, you seem to be arguing that one system is worse than the other because "we all know" it is. You're arguing from a position of authority, even though you don't actually *have* a position of authority, but you're using the circular 'proof' of your opinion as evidence that your opinion is correct. Forgive me for no taking your argument seriously.