Google Maps announces a 400 year advantage over Apple Maps
UPDATE September 24, 2012: The Comment Cycle for the following entry is now closed. Thanks to everyone who has contributed.
I had a call from Marc Prioleau of Prioleau Advisors this morning and speaking with him prompted me to look into the uproar over Apple’s problems with its new mapping application. So, this column is Marc’s fault. Send any criticisms to him (just kidding). While you are at it, blame Duane Marble who sent me several articles on Apple’s mapping problems from sources around the world.
In my June blog on Apple and Mapping , I postulated that the company would find building a high quality mapping application very difficult to accomplish. Among the points I made were these:
• However, it is not (mapping) San Francisco that will give Apple heartburn. Providing quality map coverage over the rest of the world is another matter completely.
• Currently Apple lacks the resources to provide the majority of geospatial and POI data required for its application.
• My overall view of the companies that it (Apple) has assembled to create its application is that they are, as a whole, rated “C-grade” suppliers.
• Apple seems to plan on using business listing data from Acxiom and Localeze (a division of Neustar), supplemented by reviews from Yelp. I suspect that Apple does not yet understand what a headache it will be to integrate the information from these three disparate sources.
• While Apple is not generating any new problems by trying to fuse business listings data, they have stumbled into a problem that suffers from different approaches to localization, lack of postal address standards, lack of location address standards and general incompetence in rationalizing data sources.
• Apple lacks the ability to mine vast amounts of local search data, as Google was able to do when it started its mapping project.
Unfortunately for Apple, all of these cautions appear to have come true. So much for the past.
In this blog, after setting the scene, I will suggest what Apple needs to do to remedy the problems of their mapping service.
Given the rage being shown by IOS 6 users, Apple failed to hurdle the bar that was in front of them. I have spent several hours poring over the news for examples of the types of failures and find nothing unexpected in the results. Apple does not have a core competency in mapping and has not yet assembled the sizable, capable team that they will eventually need if they are determined to produce their own mapping/navigation/local search application.
Perhaps the most egregious error is that Apple’s team relied on quality control by algorithm and not a process partially vetted by informed human analysis. You cannot read about the errors in Apple Maps without realizing that these maps were being visually examined and used for the first time by Apple’s customers and not by Apple’s QC teams. If Apple thought that the results were going to be any different than they are, I would be surprised. Of course, hubris is a powerful emotion.
If you go back over this blog and follow my recounting of the history of Google’s attempts at developing a quality mapping service, you will notice that they initially tried to automate the entire process and failed miserably, as has Apple. Google learned that you cannot take the human out of the equation. While the mathematics of mapping appear relatively straight forward, I can assure you that if you take the informed human observer who possesses local and cartographic knowledge out of the equation that you will produce exactly what Apple has produced – A failed system.
The issue plaguing Apple Maps is not mathematics or algorithms, it is data quality and there can be little doubt about the types of errors that are plaguing the system. What is happening to Apple is that their users are measuring data quality. Users look for familiar places they know on maps and use these as methods of orienting themselves, as well as for testing the goodness of maps. They compare maps with reality to determine their location. They query local businesses to provide local services. When these actions fail, the map has failed and this is the source of Apple’s most significant problems. Apple’s maps are incomplete, illogical, positionally erroneous, out of date, and suffer from thematic inaccuracies.
Perhaps Apple is not aware that data quality is a topic that professional map makers and GIS professionals know a lot about. In more formal terms, the problems that Apple is facing are these:
Completeness – Features are absent and some features that are included seem to have erroneous attributes and relationships. I suspect that as the reporting goes on, we will find they Apple has not only omissions in their data, but also errors of commission where the same feature is represented more than once (usually due to duplication by multiple data providers).
Logical Consistency – the degree of adherence to logical rules of data structure, attribution and relationships. There are a number of sins included here, but the ones that appear to be most vexing to Apple are compliance to the rules of conceptual schema and the correctness of the topological characteristics of a data set. An example of this could be having a store’s name, street number and street name correct, but mapping it in the wrong place (town).
Positional Accuracy – is considered the closeness of a coordinate value to values accepted as being true.
Temporal Accuracy – particularly in respect to temporal validity – are the features that they map still in existence today?
Thematic Accuracy – particularly in respect to non-quantitative attribute correctness and classification correctness.
When you build your own mapping and POI databases from the ground up (so to speak), you attempt to set rules for your data structure that enforce the elements of data quality described above. When you assemble a mapping and POI database from suppliers who operate with markedly different data models, it is unwise to assume that simple measures of homogenization will remedy the problems with disparate data. Apple’s data team seems to have munged together data from a large set of sources and assumed that somehow they would magically “fit”. Sorry, but that often does not happen in the world of cartography. Poor Apple has no one to blame but themselves.
1. Unfortunately for Apple, they need to take a step back and re-engineer their approach to data fusion and mapping in general.
2. I suspect that the data and routing functionality that they have from TomTom, while not the best, is simply not the source of their problems. Their problem is that they thought they did not have a problem. From my perspective, this is the mark of an organization that does not have the experience or know-how to manage a large-scale mapping project. Apple needs to hire some experts in mapping and people who are experienced in mapping and understand the problems that can and do occur when compiling complex spatial databases designed for mapping, navigation and local search.
3. Apple does not have enough qualified people to fix this problem and needs to hire a considerable number of talented people who have the right credentials. They, also, need to develop a QA/QC team experience in spatial data. They could establish a team in Bangalore and steal workers from Google, but if they want to win, they need to take a different approach, because this is where Google can be beaten.
4. Apple appears not to have the experience in management to control the outcome of their development efforts. They need to hire someone who knows mapping, management and how to build winning teams.
5. Apple needs to get active in crowdsourcing. They must find a way to harness local knowledge and invite their users to supply local information, or at least lead them to the local knowledge that is relevant. This could be accomplished by setting up a service similar to Google Map Maker. However, it could also be accomplished by buying TomTom, and using its MapShare service as part of the mapping application to improve the quality of data. I think something like Map Share would appeal to the Apple user community.
6. Speaking of acquisitions, Apple could buy one of a number of small companies that integrate mapping and search services into applications for use by telephone carriers. The best of these, Telmap, was snapped up by Intel earlier this year, but other companies might be able to do the job. Perhaps Telenav? Hey, here is an interesting idea – how about ALK, now being run by Barry Glick who founded MapQuest?
7. I suppose Apple will want to hire Bain or some other high power consulting group to solve this problem. That would be the biggest mistake they have made yet, but it is one that big business seems to make over and over. As an alternative, I suggest that Apple look to people who actually know something about these applications.
There is no really quick fix for Apple’s problems in this area, but this should not be news to anyone who is familiar with mapping and the large scale integration of data that has a spatial component.
Of course there appears nowhere to go but up for Apple in mapping. I wish them the greatest of success and suggest that they review this blog for numerous topics that will be of assistance to them.
If you want to know more about map data quality see ISO (International Organization of Standardization), Technical Committee 211. 2002. ISO 19113, Geographic Information – Quality principles. Geneva, Switzerland: ISO. Available online from http://www.isotc211.org/
And, I urge Apple to keep a sense of humor about these problems, as have some of its users. I had a great laugh at a comment about Apple’s mistaking a farm in Ireland as an airport. The comment was “Not only did #Apple give us #iOS6… They also gave us a new airport off the Upper Kilmacud Road! Yay!”
Until next time.
UPDATE on September 24, 2012. I have closed the comments period for the Apple Maps Blog. Thanks to all who have contributed.