As I noted last time, User Generated Content could be the data gathering tool that lets Google surpass NAVTEQ and TeleAtlas in quality of data and spatial coverage. The potential “fly in the ointment” is “How “good” does the map data that Google is collecting need to be? This “fitness for use” question is difficult for an outsider to answer, but we can make some assumptions. Presumably, Google considers the data in the Google-Mapbase to be fit for mapping, routing, navigation and route guidance. If not, why would it have dumped TeleAtlas?

On the other hand, the data in the current version of the Google-Mapbase appears to me to be of lesser quality than that provided by TeleAtlas and a wider gap may exist between Google and NAVTEQ in terms of map accuracy, especially in the currentness of map attributes. How should we think about this issue?

Perhaps this conundrum is an example of the situation that other pundits are referring to as “good enough” in reference to their belief that the navigation market may be driven to produce map databases of less accuracy than the “high precision map databases” that will be needed to support Advanced Driver Assistance Systems (ADAS) targeted at driver safety and the advanced Energy Management systems (EM) targeted at efficient use of the power/drive train in vehicles.

I guess this recently exposed “good enough” argument means that Google got rid of the data from its supplier of navigable map databases (TeleAtlas) so they could collect and publish inferior data. You know, more people should read this blog.

Google, by its own admission, could not find a way to get its supplier (TeleAtlas) to actively work to enhance the quality of its map database and resolve the inadequacies that Google had been complaining about over a lengthy period. Although Google parted ways with NAVTEQ for strategic reasons after Nokia acquired NAVTEQ, it was quite clear that Google was unimpressed by the quality of NAVTEQ’s data during the period it was a licensee of NAVTEQ.

Clearly, Google took a run at creating a navigable map database in order to improve the accuracy of their maps, navigation and route guidance capabilities. Does anyone honestly think that the company will not industriously endeavor to enhance the Google-Mapbase? Really!

Another group of pundits is claiming that now that they have had an opportunity to really examine the Google Maps Navigation application (a beta) that it is “behind” on several features and that Google will need to update its application to be competitive with features offered by other providers of navigation services. Give me a break. Does anyone honestly think that Google is going to stop its cycle of continuous improvement? Google’s application will improve and Google will continue to deliver innovative products and concepts as part of programs designed to enhance its ability to deliver targeted advertising to its customers wherever they may be on whatever device they may be using, even when they switch between devices.

It is my opinion that the “good enough” argument and the “inferior application” arguments reflect a lack of understanding of the potential revolution that Google is attempting in the collection of map data for navigation quality databases. Google’s current applications may not have all of the features of PNDs or even other navigation systems on phones. The reasons they are lacking these features is that Google does not yet have the attribute data that would allow them to provide posted speed limits, avoid toll routes, take scenic routes, or other features that are data dependent. So, the really interesting question is “Does Google have the right approach to maintaining a navigation quality map database?” In essence, “Can Google overcome the 25 year head start enjoyed by NAVTEQ and TeleAtlas?” Of course it can.

We looked at my proposed model of Google data revision activities last time and now will discuss more details on the model.

I noted that User Generated Content (UGC) will become the “quarterback” of Google’s data collection efforts. My belief is that UGC, in the form of customer complaints, map corrections, map additions, business listing updates, probe data, Google Map Maker and Street View Advertisements, will help focus Google on the weaknesses of their map database and proscribe where Google needs either to mine its Street View data or send its Street View vehicles to gather additional data. Alternatively, Google could use UGC as a diagnostic indicating where it needs to search for and, then, conflate better attribute data than it used in its original pass through a geographic area.

The potential use of “billboard” space in Street View images appears in a patent issued to Google recently and could benefit Google by enhancing its address database and business listing database through improved communication with business owners and neighborhood interest groups likely to use this advertising service. (Some may not know this, but Google AdWords has a branch that makes online advertising available to charitable institutions in an effort to help these groups publicize their charities. Imagine all of the good local information Google might be able to learn by assisting charities with their “local” advertising activities using Street View as inventory.)

Mining the “collective intelligence of Google users” is a longer term play for the company, but one that will reap substantial benefits when the Google Maps Navigation application succeeds in convincing users of phones equipped with the application to use Google rather than other navigation alternatives. If the price (free) were not enough of an incentive, users will likely find that Google’s database is more up-to-date and more accurate than the databases provided by others in the marketplace. This argument takes us back to the notion that Google doesn’t have better algorithms, it just has more data to mine and more data mining means improved navigation data, over time.

UGC, however, is generally unstructured in a spatial sense, meaning the user controls the changes and selects that area where change data is reported. In essence, when UGC is an “active” process Google responds to the changes reported, but has no ability to direct the geographic tendencies of their map error reporters. This is opposed to the field efforts of several mapping companies in which the company actively directs its field teams to canvass geographic areas based on reports of errors and, also, on the basis of a comprehensive collection process that attempts to re-canvass all map coverage over time.

It is here that we need to remember that UGC works best when it is governed by the law of large numbers – when you reach the tipping point, all bugs become shallow or, in respect to the present topic, all map corrections become shallow. The most important advantage that will accrue to Google in updating its Google-Mapbase is its future use of probe data, based on the potential input of the predicted number of users of a free navigation service available on the Android platform.

Probe data (following the bread-crumb trail of GPS signals registered by and locating your phone in space) can best be thought of as a change detection generator. When roads are closed for construction, probe data will immediately reflect the situation. When new roads are opened, probe data will immediately reflect this change by providing traces of movement in areas previously empty of such traces. If a traffic artery has been converted to one-way, probe data will immediately reveal the absence of the previously normal two-directional traffic. While probe data is not the sole panacea for improving map revision practices, it is a mechanism that will take much of the guess work out of where Google should deploy field collection assets, like Street View, to create improved map data.

Of course, the law of large numbers may work to Google’s disadvantage, especially if a large number of users object to having their paths tracked and saved in a Google data center. Even today, TomTom/TeleAtlas, whose MapShare program benefits from probe data collected from users who have opted-in to the service, strips the first two and last two minutes of travel from the probe paths they capture, to provide some degree of anonymity to the contributors of their data. While the data is contributed anonymously, it is clear that the only person leaving 6 Sesame Street each morning and returning to 6 Sesame Street each evening is likely a resident of that address. We will have to see how this issue plays out, but if it plays out in Google’s favor, it will be a game changer, especially when added to the other practices they use to gather map data.

Other Initiatives

I fully expect that Google will soon consider paying a select group of its UGC contributors for the data corrections they provide. Google, by creating an effective and feedback-equipped UGC map correction system, has enlisted the efforts of a large group of people known in the industry as those suffering from Cartosis! These poor folks are map-a-holics who just cannot get enough cartography. They love maps and would like nothing better than to spend their day editing the darn things. (Believe me, as former Chief Cartographer for Rand McNally, I was inundated with their letters demanding corrections, additions, deletions and various insights on our cartographic practices, as well as my personal lineage).

Every article I read on Google’s mapping efforts suggests that Google is benefitting from the contributions of these geo-specialists in ways that are eluding others in the map database field. Google is earning the good will of these people by incorporating their comments and making the changes they contribute visible on Google’s map displays in a relatively short time. If Google can harness the good-will of these folks, perhaps by a modest stipend – or simply an acknowledgement, they just might become the company’s best mapping-buds. While this may sound humorous to some, these people are very good at knowing their local area and sometimes exhibit significant levels of familiarity with broad geographic areas.

I suspect you are wondering why I am spending so much time on this group. Well, the one big problem for Google is that they do not really have a field collection force to gather data in areas where they know they are weak. Yes, they can send out Street View vehicles, but this is an inefficient way to resolve spatial problems that can be solved by local people. If I were Google, I’d be thinking very hard about how to incentivize their UGC data pros.

And Now, Apple?

How about this for a change in direction? Now that Apple has released their iPad (what an awful name), maybe they will turn to thinking about how they are going to use PlaceBase, the small mapping company they acquired last year. PlaceBase did some nice data integration and was known as for its data visualization efforts. However, the company did not support routing directly, although its API provided hooks for integrating routing from other services. It seems to me that Apple needs to work on mapping, routing and geography in general, but no one seems to know what they might be doing with PlaceBase. Any ideas? And don’t suggest the PlacePad, but maps on the iPad – now that’s a good idea.

Last time, I stuck the term “Ground-truth surrogate” into the list of terms that I felt we needed to define in order to move forward with our exploration of Google and map database updating. The definition of this term is – “Reference source of sufficient completeness and/or accuracy that may be substituted for field verification when measuring the completeness and/or accuracy of map database features, attributes or properties.”

The problem for producers of map databases is that there isn’t an available source of information comprehensive enough to be the catch-all that can be used to verify the completeness and or accuracy of all features, attributes and properties across the compiled map database – other than the earth itself. In turn, the traditional approach to verifying a compilation of information comprising a database created for mapping, navigation and route guidance is by field checking the quality of its content and usability. While field checking is undertaken to reveal specific errors and misinterpretations in the database, such efforts also reveal the shortcomings of the sources, sensors and methods used to create the database.

I think we need to evaluate the techniques and data sources that were used to compile the Google-Mapbase. More specifically, I will discuss their limitations, as this will help us understand what Google will need to do to remedy these lacks. (For those of you who have joined this blog recently, we covered the sources used to create the Google base here.)

What are the weaknesses of the techniques used by Google to create the Google-Mapbase?

Limitations of Satellite and other aerial imagery

Lack of uniformity – collected using variable specifications and imaged with platforms exhibiting different imagery characteristic.
Not up-to-date – collected at different points in time.
Obscurations and Obstructions preclude accurate mapping – coverage used by Google can be obscured by clouds. Road detail sometimes difficult to sense (manually or automatically) due to difficulties in object discovery and identification resulting from obstructions in line of sight (including leaf-on photography).
Spatial resolution inadequacies
Spectral resolution inadequacies
Heterogeneous approach, since the imagery varies in quality, specification, and up-to-datedness.

Take a look at some of these problems – all can be found on Google Maps.

Street View
Not up-to-date – two generations of sensors and specifications.
Not comprehensive – favors high-population density areas and major cities.
Resolution inaccuracies -imagery characteristics vary between early sensors and current sensors.
Cultural rejection – not all areas may accessible to the Street View platforms (cars, bikes, etc.). See this article and this for potential restrictions.

Conflation
We discussed some of the limitations of conflation in our last blog. Suffice it to say, conflating data often produces errors of one sort or another. Common problems include:
Lack of homogeneity in data quality across database
Data sets vary in data content,
Data sets vary in data quality,
Data sets vary in precision of measurement.
Mixing unique data sets potentially produces errors.

User Generated Content Related Compilation Processes

UGC is an uncontrolled ground-truth surrogate. There are at least three sources of UCG used by Google: contributed edits to Google maps, contributed maps to Google Map Maker, and probe data from persons using Google’s navigation app on cell phones.

In general, the people who contribute UGC exhibit self-selection (they update what interests them), limited spatial focus/interest, and often provide map edits for self-benefit. While none of these factors are unexpected, they do make it difficult to direct the data collectors to resolve specific problems by geographic areas.

In addition, user priorities may lead to unreliability, usability of the contributed data may be low and there may be prejudices in the responses. With enough contributors these limitations may become moot. However, there are some important questions that we cannot answer about this process. One is, “How many updates does Google receive from users of their maps?” Another is, “What is the spatial distribution of these users and their edits?”

Probe data can provide different benefits to map revision efforts, since mining the probe data provides a considerable amount of detail on the current configuration of roadways, their geometries, their flow speed and directionality, etc. However, once again, the user is self-directed and their probe-paths reflect self-focus/interest. Of course, the value of probe data will increase as the number of users of Android phones and Google’s navigation application increase, especially if that distribution is wide-spread in terms of spatial coverage. At present, the benefit to Google of probe data is likely to be insignificant for map updating.

Improving the Google-Mapbase

So, with all of these potentially flawed data gathering techniques, what is Google going to do to improve the quality of its Google-Mapbase?

Let’s, take a short step back. NAVTEQ, TeleAtlas and Google used many of the same techniques to create their map/navigation/route guidance capable databases. Google created its database faster than its two competitors by taking advantage of tools and capabilities that did not exist when NAVTEQ and TeleAtlas started compiling map database for navigation over twenty-five years ago.

NAVTEQ and TeleAtlas have had a longer period to refine their databases. In general, the belief in the industry is that NAVTEQ, who uses fieldwork both in the collection and evaluation of their data, has slightly better data quality than TeleAtlas in the United States and Europe. One surrogate for this ranking is the number of adoptions of one database or the other by manufacturers of in-car navigation systems, a field dominated by NAVTEQ.

Now, let’s turn to how Google, a newcomer, might catch-up with the market leaders. I suppose we could make the argument that Street View is a form of field collection and its results could be used as a form of field verification. I suspect that Street View will be part of the solution, but the significant event is something different. (At this point, I want to thank Allan Snell who sent me this link to Tim O’Reilly’s blog on the new Nexus-One phone from Google, as this article helped crystallize my thinking on the map updating topic.)

Let’s spend a second contemplating the source of Google’s success. In the article linked to above, O’Reilly states his belief that “Collective intelligence is the secret sauce of Web 2.0…” He includes a telling quote from Peter Norvig, Google’s Chief Scientist, who once told Tim “We don’t have better algorithms. We just have more data.” Change that quote to “We don’t have better algorithms. We just have more map-related data.” Now you have the difference between Google’s approach to map updating, as contrasted with that of the other players in the mapping marketplace.

Let’s look

Here is the layer cake that describes how Google created their Mapbase. As you may remember, I postulated that Google started its mapping efforts with satellite and other aerial imagery, added in what it learned from Street View and UGC, did some data mining to fill in the gaps and conflated new data to their geometry layer to create the Google-Mapbase.

Next, I present a figure that shows how Google will update the Google-Mapbase. (The colors used to identify a process are the same above and below, but their different positions shows the change in the importance of a category in the map revision process). Note that UCG will drive the map update process. It is my belief the UCG will be used to help Google understand the quality of its data and the spatial distribution of that quality. UCG will fundamentally influence all other map update processes for Google.

Now let’s look at an illustration of how Google will use UGC to direct their update process.

Click here for a PDF of this image (which you can zoom to your heart’s content). As noted above, UGC will become the bandleader indicating the what and where of data gathering efforts needed to improve the Google-Mapbase.

Finally, the following illustration shows why Google could dominate the map database market.

It is this UGC Tower of Power that will allow Google to progress in map update and quality faster than most people suspect. The key here is that Google has more map data collected by more people on the ground than it is possible for any existing map database company to collect, in any manner. I realize that TeleAtlas will want to argue about this, but Google either leads them now or soon will.
One more thing about the Tower of Power – remember back in grade school there was always some “brain” in the class who seemed to know more about everything than anyone else? Well, perhaps, you also remember those days when “braino” crapped out and the teacher began posing questions to the entire group about the subject.

It was this point that the magic started, as a number of people seemed to know a little different piece of information that when combined accurately described the issue of interest. Google realizes that our actions online can become a repository capable of reflecting the knowledge that we have about things that interest us in the real world. In turn, the collective intelligence of all of its users can provide valuable, authenticated, spatial information to help in the updating the Google-Mapbase. (Now you know why I don’t like the term “Volunteered Geographic Information” – much of the information we will provide Google will not what we intended to volunteer!)

How much improvement and how long it will take to realize the benefits of “collective intelligence” are another issue. Let’s talk about the details behind these diagrams next time. (I may be on the road next week (talk about waiting for last-minute contracts), but I will do my best to get the next blog out to you while I am on the road.

Oh, there is another fly in the ointment for Google. Seems that Microsoft is proposing creating a new, comprehensive, imagery base of the United States at a resolution of 1 foot. It is attempting to pull in states as its partners and will allow them the use of the data for an extremely attractive one-time price. Now why, do you suppose, Microsoft would be interested in having a homogeneous, current, large-scale imagery base of the United States? Hmmmm. Maybe because no one else has one! At least, not yet.

If you have not taken a look at Microsoft’s new Bing mapping package, it has some great features. Perhaps of more importance, their imagery base in Europe is much better than that currently provided by Google. Maybe something fun is shaping up?

We have previously spent some time discussing how Google compiled its Google-Mapbase and now turn to the how Google intends to update it. Just to make this all flow easier, we will use the following definitions, based on ISO 14825, the International Standard for Intelligent Transport systems – Geographic Data Files (GDF) – Overall data specifications. (It’s expensive to purchase, but if interested you can find more info here).

The information in quotes below is from the ISO GDF Standard.

“Accuracy – Closeness of results of observations, computations or estimates to the true values or the values as accepted as being true.”

“Up-to-dateness – Closeness in time of the geographic data to present reality.”

“Completeness – Extent to which the specified features are present.”

“Ground-truth surrogate – reference source of sufficient completeness and/or accuracy that may be substituted for field verification when measuring the completeness and/or accuracy of map database features, attributes or properties.”

“Attribute – characteristic of a feature which is independent of other features.”

“Feature – database representation of a real world object.”

“Property – combination of attribute and relationship values which pertain to a feature and which together define a certain characteristic of the feature.”

“Relationship – characteristic of a feature involving other features.”

So, let’s get started.

As you know, I ran a test around my neighborhood and found that its representation in the Google-Mapbase was inaccurate, not up-to-date and incomplete compared to its competitor NAVTEQ. It is my opinion that the numerous stories in the news about mistakes in the Google-Mapbase reflect these same inadequacies.

It is hard to be more specific about the limitations of the Google-Mapbase, since I do not have access to the complete Mapbase dataset. My experience in mapping tells me that Google’s map data likely suffers from incompleteness in terms of the features represented across the map coverage they provide and inconsistency in the attribution of map features within that coverage. Google used imagery from satellites and other aerial platforms to create their geometry layer and conflated other data to their geometry in an attempt to create the attribution necessary for cartographic display and the use the database for purposes of navigation and route guidance.

While conflation can be a useful tool, it is one that produces inconsistency, since these data are collected from variety of sources whose data accuracy specifications and data collection needs (attributes) reflect their objectives in creating the data, but not necessarily those of Google. In effect, the Google-Maps base might look like the distribution of feathers inside of a down comforter, with data globbed-up (it’s a technical term) in some areas and spread very thin in other areas. In addition to the problems of data compatibility exposed by conflation, we need to acknowledge that the sources of the data conflated by Google are spatially disparate, do not produce a uniform quality of data and likely update their data on variable schedules. In other words, I expected the initial Google-Mapbase to be non-homogeneous in terms of accuracy and completeness and it appears to have met this expectation. I am sure that this was what Google expected, although they might not have realized that the initial data quality would be as low as it has been reported.

So, what Google needs to do is to find a method to update their data that will remediate these problems and provide them a better mousetrap than that used by NAVTEQ and TeleAtlas Some would say that they will, also, need to have a better product than Open Street Map. Hmmm.

In order to appreciate Google’s approach to updating the Google-Mapbase, we need to think about the strategy that Google is trying to optimize by creating their own mapping and navigation data. My belief, as stated previously in this blog, is that Google believes that it requires more accurate map and address information in order to be able to deliver customers to its partners who advertise their business or service through the Google Network using the Google AdWords product. In addition, Google is interested in improving the quality of its map database and navigation tools in order to be able to deliver relevant, spatially targeted advertising to people using mobile phones. Google’s Automotive Division will try to expand this sphere of influence to in-car communication systems, while the Google Mothership tries to use these same map and navigation data to geotarget advertising to online users of its browser and other cloud-based products.

These use requirements indicate that the Google-Mapbase needs to include all transportation arteries (higways, county road, streets, etc) mapped correctly (position, classification etc.) and all of the address information describing the location of houses and business along the street face attributed correctly (street name, street addresses, address position, street geography – which neighborhood, city, county, state, country, etc.), including additional attributes defining the businesses along any street segment in terms of name, contact information, business classification and other identifying variables.

Note, that Google’s focus on navigation and route guidance means that it is playing in a different ballpark than OSM. At the present, OSM seems comfortable producing cartographic data for map presentation, but does not compile all of the routing attributes needed to create an industrial quality navigation database capable of providing route guidance. In turn, there is reason to suspect that, at present, the weakest link in the Google-Mapbase is the lack of significant detail describing features and transportation artery attributes that are required to successfully navigate an active vehicle along a path from origin to a destination.

Well, let’s take a look at standard updating practices and see what Google might do to save the day.

Many mapping companies that create purpose built geographical databases (rather than simply re-use those created by others), collect the first compilation of the data based on a clear and unambiguous set of specifications for data accuracy, up-to-dateness and completeness. Data that do not meet the compilation specification are re-collected or prioritized and placed in the update queue depending on the nature of the problem their inaccuracy presents. In addition, companies involved in data collection canvas the world to see if there are any existing data sets that might be adapted to complement their data collection efforts.

While many organizations collect spatial data on a special purpose basis, it is unlikely that any of these entities will collect data that mirrors the specification being used by the company determined to create a navigable database. It is relatively easy to find cartographic data that will allow you to put together a database for purposes of simple mapping, but entirely a different issue to collect spatial data that is attributed in a manner that will allow navigation and route guidance.

Most programs to update the data of critical importance in cartographic and navigation-quality databases are geared to improving data quality based on a practice of systematically working through or “touching” the entire map coverage over some reasonable period of time. Often, this process is based on fully updating large geographical extents each year, progressing towards complete revision of the map database during a three of four year cycle. The effort we are describing here is known as a “planned update cycle.”

Overlaid on top of this stepwise, comprehensive update is an effort that implements various “change detection” measures to prioritize map data changes that dramatically impact product quality, especially in fast growing urban areas. User feedback (usually complaints) form an important part of this activity, but the greatest asset here is the use of current imagery from an aerial platform that can quickly show the synchronization between the imagery and the map database views of the real world.

The next conceptual overlay in the update process is known as “opportunistic updates” that take advantage of the discovery of new or updated collateral data sources that can be used to enhance a “planned update” cycle. Most commonly, this activity results from the discovery of a new data source that operates on a government level, such as a city or a county that has created a GIS databases for planning or development purposes. These data are evaluated for fitness of use and, if qualified, are imported or conflated to a master database that normally contains accurate geometric representation of transportation features in a specific geographic area, but may lack the attribute data as accurate or comprehensive as that available in the new data source.

Companies involved in updating databases used for navigation and route guidance actively work to harmonize these data and success in managing this task often distinguishes the players from the pretenders in the map database world. Harmonization is the database builders attempt of manage data quality to meet specific requirements to qualify the data as fit for specific uses, in this case mapping, navigation and route guidance. Companies that actively work to harmonize their data are attempting to produce “controlled data” that is generally verified by some method of field observation. Geographic data that has been compiled based on external specifications is considered uncontrolled data and its inclusion is a process that results in a hybrid database whose accuracy and harmonization is considered less reliable than that of a controlled database.

NAVTEQ provides the purest, most controlled map and navigation database. TeleAtlas, since it acquisition by TomTom, sits firmly in the hybrid camp, relying on MapShare and probe data for a significant amount of its data validation. Google also falls in the “hybrid” category, but is this category by design and intent. The question that we need to pursue looks like this “Is it possible to manage the data quality of hybrid databases for mapping, navigation and route guidance to meet specific accuracy requirements?”

It is my belief that Google looked at the map data quality provided by its old suppliers NAVTEQ and TeleAtlas and decided that these data did not meet the specific accuracy requirements required by Google for success in its markets. My sources tell me that Google believed that the geographical data supplied to it were out of date, inaccurate, incomplete and inconsistent.

Before NAVTEQ was acquired by Nokia, I analyzed the financial reporting information that they were required to provide as a registered public company, so that I could determine, to the extent possible, their expenditures related to updating their map and navigation database. My calculation was that NAVTEQ may have spent over $300,000,000 in 2007 on updates and database extensions. I was not able to specifically nail down costs, as the expenditures reported in the public documents were not categorized in the same manner over the reporting periods I examined. If my analysis of the NAVTEQ financial data is only directionally correct, it is clear that spending lots of moolah may not be an effective way to improve the quality of map updating.

It is my belief that Google came to believe that the solution to improving the quality of map databases was more related to method than to spending. Further, the method that Google is betting on to produce this improved quality is “collective intelligence”. Yep, Google is betting on the Borg. What is even worse, is that they may be making the right bet.

Well, let’s look at the role of collective intelligence and map updating in the next borg – I mean blog. Just to get you ready for next time, look at this modest update of the map database production cycle. Google is determined to turn this on its head, but supplementing what they are doing with traditional approaches, just in case. Tune in next time for the real expose.

To see a larger version of the image, click here.

We will provide a detailed, but very different model next time.

I know that I promised to share my thoughts on the types of strategies that Google might be using to update their map database of North America. The topic is complex and I have been working my way through several models, but am not yet satisfied with my efforts.

In addition, I have been sluffing around doing the kinds of family things that seem to pop-up at Christmas. Today, however, I was shocked out of my reverie, by an email from my friend Duane Marble that contained a link to an article from PC World Online about the folks that relied on the GPS to get them home to Reno from some place in Oregon, only to wind up lost and imperiled on a snowy, local road. Ok, so now you know – this is a Rant!

The article that brought this on was trivial, but the contributions of the pundits who decided to comment on the blog caused me to seriously consider finding a method to euthanize them. Somehow, without the benefit of formal study, a group of technology experts has evolved who want to tell us how technology works, how maps work and how GPS works, without any of them actually possessing an in-depth understanding of any of the subject matter areas involved in the process.

The first item to catch my eye was by a guy who claimed he used his Droid cell phone for navigation because it would always have new maps and the maps on his Garmin were old. He thought the Droid was a better idea because the cloud would always contain the most up-to-date data. I guess that would be true, but the latest, up-to-date map data does not mean correct, navigable map data that is fit for use in routing engines designed to provide turn-by-turn directions.

Well, the same fellow especially liked his Droid since he could use Google Maps’ Satellite View to see what the route looks like before taking the suggested path.
Apparently he believes that Google has its own satellites that they redirect to take a new photo each time you request a view – especially so you can see if it has snowed. Well, they do, …don’t they?

I guess he probably believes that Google also has its own cellular infrastructure that works anywhere in the world, so that their Droid phones will always be able to access Google to retrieve those new maps and those up-to-the-minute satellite images. In addition, he might even think that Google has launched its own GPS satellites in a larger constellation, with better coverage and stronger signal strength than that provided by the Department of Defense, allowing the $2 high-quality GPS receiver in his phone to unerringly access GPS for PTN calculations (Position, Timing and Navigation).

OK. So none of this is true – no Google satellites, imaging systems or cell network. Instead Dingerbob needs to be told that cell phone reception coverage quality is variable and in some locations non-existent. GPS signals are weak and signal reception can be negatively impacted by weather conditions, foliage, and obstructions to the signals, including topography, among other variables.

Satellite imagery can be more out-of-date than paper maps and in heavily wooded areas you may not even be able to see the roads. While everyone would like to have imagery that reflects leaf-off conditions and clear, cloudless days, there are tons of images that do not meet these conditions. Moreover, you never get a leaf-off conditions in forests composed of evergreens – like those so common in Oregon. Finally, the way that Google and everyone else seam images together, you might not be able to “see” anything on the images and, to add to the problem, the imagery used by Google and Microsoft rarely is properly registered to the geometry of the map bases which they overlay. Can we say “Orthorectified”, Mr. Rogers?

Of course, some of the pundits who responded to the PC World blog clearly thought that the problem in the report was that these two old fogies did not understand the technology and should not have been paying attention to the GPS.

Oh, please! The “You should have known better argument” sounds like the one used by Garmin (whose device was in the car being driven by those who became ”lost”). Quote the Garmin Spokesperson (you can find these comments in a graphic attributed to Garmin on ABC News “…Drivers must always remember that GPS devices provide route suggestions; they do not cause drivers to make driving decisions.” Say what?

Crafted by a lawyer I guess. And, I must agree that neither my TomTom nor my Garmin have ever actually reached out and taken control of my vehicles. To be honest, I had not realized that if my PND told me to turn right at the next corner that, when I arrived at the next corner and made sure that I could turn right (hmm, street is available to the right signal is green, no pedestrians, no obstructions, no vehicles in lane), I should ignore the $300 device and just keep going. Wait, why did I buy a PND? Wasn’t it something about navigation? I suppose Garmin will now be rebranding its products with the tag “GPS – Gets People Somewhere”.

Apparently the spokesperson for Garmin has come up with a new and unique definition of turn-by-turn directions. Read my lips – OK read my writing instead. People buy Personal Navigation Devices to help them navigate roads in areas with which they are unfamiliar. Often, the people who buy PNDs are the same people who are not very good at reading maps, which is exactly why they want a device that can perform map-use functions. If PNDs do not perform a wayfinding function, what possible use do they have in this universe?. Unlike paper maps, they are too rigid to be used as toilet paper and too large to be used as a suppository. Gosh, I think their only use is, now let me get this just right, as a PERSONAL NAVIGATION DEVICE. How quaint. You mean these things are really supposed to work? If that is the case, Garmin’s and TomTom’s stock prices will never recover.

Of course, the Garmin spokesperson may also be the person who supplied the comment in the PC World blog that “GPS Systems are fine. Some people, however, can be really, really, clueless.” Of course. User error! How convenient.

In the formal statement actually made by the Garmin spokesperson, the quote continued “It is the responsibility of drivers to exercise common sense at all times when driving, including deference to the posted road signs and road conditions.” Perhaps the Garmin spokesperson should have added “No, our devices do not work when you need them to do so. We suggest that you throw the friggin thing out the window when it doesn’t work.” Or, perhaps, the spokesperson should have said “Wadda ‘ya expect for 300 bucks, something that works as well as a two-buck map?”

Before all of you go off in the wrong direction (Yuk, yuk – it has taken entirely too long to use that gem in this piece), what we are talking about is “Fitness for Use”. Consumers have a right to expect that devices they buy perform the task that the manufacturer represents it as performing. Companies that create flawed products that don’t deliver the advertised functionality can be sued for non-performance. Better yet, products that fail in their intended operation usually fail in the marketplace.

But enough of my rant. The interesting question is “Why does a PND fail to calculate the correct route?” I think the answer is relatively straightforward and believe that the problems are on the data side more than on the algorithmic or hardware side of the product. My list of Fail Factors, in order of decreasing importance, is as follows:

Map data incomplete
Map data out-of-date
Map data incorrect
Map data ambiguous
Routing algorithm bugs/inefficiencies/tuning
GPS receiver inefficiencies
GPS signal degradation (weather, foliage, obstruction, etc.)
PND hardware design inefficiencies
PND software design inefficienies
User error (always a possibility – rarely the root problem)

If you are a frequent reader of this blog, you know my belief that most navigation problems result from map data that is inadequate for navigation, address finding or the solution of other problems that depend on data related to the position and description of geographical features. That is why creating a viable and effective map updating process is so important.

It is clear that the models used by NAVTEQ and TeleAtlas result in the provisioning of less than satisfactory navigation data. However, before NAVTEQ and TeleAtlas started compiling navigable map databases twenty-five years ago (or so), the situation was even worse. Both NAVTEQ and TeleAtlas have spent a great deal of time thinking about the map update problem and have spent considerable sums of money trying to improve the quality of their map databases. I think they have made great strides towards solving many of the problems that plague compiling accurate and up-to-date navigable map databases.

Google, however, was not satisfied with their efforts and thinks that it may have discovered a better way to improve the quality of these databases. I think Google is headed in the right direction, but anticipate that it does not have the experience to remedy the problems it so freely criticized before it became a producer of navigable map databases. But more about that next time.

My best wishes for a Happy New Year and may next year be your best year ever.

Mike

I was looking around for a good way to start this series, one that would let me provide a little history on map updating and commercial mapping that would help put a context around the next several blogs I have planned. Luckily, someone saved me the trouble – so here we go.

I received an e-mail this morning from Mike Blumenthal on a blog he had written regarding a change he corrected and submitted, which Google corrected in 30 days (an address change). I was reading some of the comments on the article by his readers and one caught my eye. The sentiment expressed was that if people have been living without map updating for years, a few weeks isn’t going to make a big difference. The note concluded that if you don’t like the quality of Google maps, you should tell your readers to use Bing, Yahoo or another provider.

Hope Mike’s reader is not in marketing. Perhaps more importantly, the author of the comment seems oblivious to the fact that the strategy behind Google Maps is not focused on producing map views. Instead, Google switched from its previous suppliers of map data to providing its own Google-base in an attempt to enhance its ability to successfully find real world addresses and correctly map their locations. Finding the “correct” location, is a key indicator of success for Google, as is creating viable routes to these locations for its on-line users or turn-by-turn navigation directions to these locations for users of Android-based smart phones.

While it is true that paper maps were not updated often (perhaps once a year), these maps were not designed to and did not provide either the routing function or the more demanding turn-by-turn navigation function. If you wanted to use paper maps for routing, you had to learn how to read and use maps and then preplan your route, often drawing on top of the map. If you wanted to use your paper map for a navigation function, you had to have someone who could read maps sit in the passenger seat, correctly orient the map and tell you the correct set of maneuvers to reach the destination (although in point of fact, this situation resulted in more divorces than any other cause).

In fact, based on the uses to which maps were put, users of paper maps simply did not demand higher accuracy and more current updates from the map publishers. In turn, paper map publishers did not update their products in a timely manner because the costs of product creation, printing an inventory and distributing that inventory required that the inventory had to be sold through in order to make a profit.

You did notice the word “sold” in the last sentence? Yep, consumers actually had to pay for these maps, even if they were out of date. On the other hand, the paper map did not need batteries and the image was persistent or at least it lasted until the folds wore out, the staples failed, or it blew out your car’s window. The purpose of all of this reminiscing is to indicate that comments about map updating frequency based on presumably outdated media and distribution methods may not be remotely applicable to today’s environment and this notion has a bearing on why Google created the Google-base and promised try to update errors in it within 30 days.

Modern navigable map database suppliers (NAVTEQ and TeleAtlas) have what can be considered a one-item inventory – their Master Database. At present, most database providers distribute copies (sometimes on physical media) of that database to clients who, then, use it to create derivative products wrapped around a core that is the navigable map database.

When Google was using TeleAtlas and Navteq data, it was forced to import data from its suppliers, integrate these data with its mapping platform and then distribute the data on a demand basis to its users. When the data contained errors, Google had to collect the details of the errors, convey the details of the errors to the supplier who would then log the error and research it as part of their company’s normal map updating process. Fixing the errors was at the database producer’s discretion. Sometimes even if fixed, the change may have been entered in the queue to late to be included in the quarterly release.

Managers at Google Maps were quite vocal about their unhappiness with the quality of the map coverage that the company received from its suppliers. One concern was that the navigable map databases were not up-to-date, as many newer (and some older) land developments were not represented in the databases provided by NAVTEQ or TeleAtlas on as timely a basis as Google required. Second, the data from the map suppliers did not meet the quality levels required by Google for its intended applications, as address ranges, the locations of addresses, the locations of street, highways, other roads and Points Of Interest (POI’s) appeared to be erroneous or not in their correct spatial position either in a relative or absolute sense. Next, the data were not uniformly comprehensive, as the quality and number of elements used to describe the mapped data varied across the coverage area. The most problematic issue for Google was the length of time the map providers required to research and correct errors based on the details that were supplied to them by Google.

By producing its own navigable map database, Google has removed the “middleman” from their map creation system. By compiling their own map data from independent sources, Google hopes to improve the accuracy of the data they use for mapping, routing and navigation. In addition, Google hopes to gain an ability to enhance, expand and update their navigable map database in much less time than that taken by their former suppliers.

It is my contention that all suppliers of navigable map database suppliers desire to distribute their database in as close to real-time as possible. Doing so allows them to provide their best quality, most up-to-date map data as soon as is practicable. NAVTEQ, for instance, has long desired to deliver their data over live feeds, rather than by delivering physical media. Even better, NAVTEQ and TeleAtlas might prefer to deliver live routes, rather than databases, just as Google is now doing. While there are many efficiencies to be gained from delivering routes and the associated map, rather than delivering complete databases, the main reason for moving in this direction is to enhance the ability to provide accurate and reliable routing and navigation services that will allow the user to locate and travel to the address to which they desire to travel based on providing directions (routing) or maneuvers (navigation) that are both legal and possible.

In respect to Google, we should reword the statement above into this strategy – To be successful in Local Search advertising Google needs to deliver the potential customers of its advertisers to the physical location of the advertiser so that a transaction can result. If the advertiser’s advertising dollars do not result in sales because the potential customer cannot find the location of the advertiser’s business, then, Google is the partner who will be blamed for this discrepancy. A related factor is that even when there is no advertising/advertiser involved in the local search, if users cannot find businesses that were represented in Google’s index and routed to using Google’s map service, they will have less confidence in Google’s capability as a information provider and potentially consider using other mapping services. While not everyone might be concerned about this potential mismatch, it is the issue that caused Google to dump TeleAtlas and create the Google-base.

It is important to note that in 2008 Google and TeleAtlas signed a five year agreement for TA to supply a navigable map database to Google. Even though Google is now providing its own map navigation data in the United States, it is still paying TeleAtlas and apparently intends to honor its five-year commitment while paying for data it does not use.

The truth of the map licensing market is that neither NAVTEQ nor TeleAtlas has ever made a “living” licensing their data to online providers of mapping and routing. The reason for this is that the cost of collecting, compiling and updating the data contained in their navigable map databases has required significant spending. NAVTEQ and TeleAtlas were built to service the needs of the in-car navigation market, the one that pre-dated PNDs. Indeed, PNDs and online mapping/routing were not part of the original sales strategies of either company, although both of these market segments became important over time.

In turn, the amount that Google paid for its data licenses pales in comparison to what is must have cost to build the Google-base. In my opinion, building and updating a map database is like borrowing money from the broken nosed goon in the bad sports coat – the paybacks just never end.

On the other hand, we all know that Google thought through these issues and still believed that it had found a better way to create and update navigable map databases. So, the question becomes, “Is this a case of new technologies causing great firms to fail (as described in Clayton Christensen’s Innovator’s Dilemma), or has Google missed the mark on this one?” Let’s think about that as we begin to discuss the specifics of map updating.

In my last blog, I wrote about the accuracy of the Google-base in my neighborhood and it appears that Google Maps clearly missed the mark. The comparable map data from NAVTEQ and TeleAtlas were superior to those provided by Google. I suspect this does not come as a surprise to Google and believe that they have problems similar to the ones I reported almost everywhere. However, there the issue of interest to me is “How is Google going to remediate this problem?”

NAVTEQ clearly feels that data mining is a great way to build a database, but also believes that you need to have research teams in the field, if you want to build an accurate and reliable database. TeleAtlas also believes in the efficiency of data mining, but believes that probe data (data from GPS units that records the paths users take while driving motor vehicles) and other User Generated Content can help to increase the accuracy of their database while decreasing the expense of field research. And Google? Well, I’ll spend the next couple of blogs diagramming what I think they are doing in map updating. Hopefully, I’ll have some diagrams of how the process works ready for next time.

By the way, it appears that several VC’s are thinking about funding companies who could become the next NAVTEQ or TeleAtlas. Better point them at my next few blogs before they invest your hard earned dollars.

The other day I had an appointment in Newport Beach, CA (yes, it is a tough life, but somebody had to visit the suntanned set). The address was 510 Superior Ave and I was amused that the proprietor of the business chose to give its position as “on Superior between Placentia and 17th Street, a distance that spans about a mile, with 5 streets intersecting Superior between the two endpoints. Why so vague?

To resolve this ambiguity, I looked at Google Maps and found to my surprise that Google had the location quite a distance south of the general area indicated by the business owner. I tried the maps at Yahoo, Bing and several others and all suggested that the 510 Superior address was north of where Google placed it and all located it in approximately the same place. What to do? Sounds like field research to me. As it turns out, Bing, Yahoo and MapQuest were right and Google was wrong. See figure below.

Sometimes wrong is even… wronger! Yep, the route to this location is a howler and one that makes it difficult to get back to the correct location, especially at peak traffic times.

The very next day friend of mine from Chicago sent a link to an article in the Chicago Tribune Business section titled “Google Maps inexplicably mixes Chicago’s past, present.” The article was another howler and evidence that Google Maps is now producing some of the best humor in the US (although, perhaps, not as interesting as Tiger). Google had positioned a college on the map at the location it occupied over 50 years ago and portrayed another college with the name it had 20 years ago, when it was acquired and its name changed. In addition, several neighborhood names and street names across the map were incorrectly labeled.

Somewhat humorously, the Google spokesperson contacted about the problem is quoted as saying that the information for Google Maps comes from a “wide range of public and authoritative data sources.” Good to know those public data sources are not considered authoritative by Google. On the other hand, it appears that even the authoritative sources they are using may not be “authoritative!

As you may remember, I recently suggested that Google better change gears and get a spokesperson who can speak cartographese (virtuous cartography), rather than mumble cartosis (silly replies about the map making process like the one above).

Of course, the trip to Newport Beach renewed my love of field research and I decided to continue my effort and see how accurately the new Google-base-US (GBU) had mapped my neighborhood.

Well, things seemed to have changed in my neighborhood since the last time I looked (at least according to Google), so I got out the Geotagger One and field checked the Google Map. Yep. I drove the streets, read the street signs and stopped at that – except for a couple of obvious geocoding problems. Below are a series of screen shots that show what I found (and did not find).

By the way, I zoomed Google’s map to its highest level of detail to determine whether a street was unnamed or if the name was not showing only at lower “magnifications”. Where I have shown a street name in red in the illustrations, Google did not provide a street name for that street segment. In other cases, I have drawn a red line through the Google street name when it was incorrect and placed the correct street name (as indicated from the street signs in the community) somewhere near the street.

Hope you don’t live on Poinsettia or Carlson, because Google won’t find you.

Also hope you do not live on Rolling HillS, Fair Court or Elder Brook. Golden Rod is a cul-de-sac that is unnamed on Google, although they have incorrectly renamed the rest of Magnolia as Golden Rod.

Camino Capistrano is not located on the left-side of the image, but, not to worry, is correctly located by Google at the right-hand edge of the image. In fact, the Camino Capistrano shown next Cabot Road runs along the edge of a flood control basin. The dirt path Google has improperly named Camino Capistrano (next to Cabot) is gated at both ends and is an access road for maintenance trucks, even though Google shows the path having an address range.

As you can see from this photograph, it would be hard to confuse the real Camino Capistrano will the one Google placed in the flood basin. Perhaps the erroneous location was based on using some of that “public” data.

Whoops. Seems like Google (or is it Garble?) has some problems with geocoding. I am sure the owners of Luisa’s Café know that success in the restaurant business equates with location, location, location and food quality. I suspect that is why their café is located on Cabot rather than the back edge of the warehouses, as shown by Google.

If you look at the first image showing Camino Capistrano, you will notice the shop for the mechanic who takes car of my car is located in the flood control basin. I guess this indicates either that Google is not using parcel maps for address geocoding or that the parcel maps they are using may not be “authoritative”. (You do remember my 6 part blog on “Authority in Mapping” don’t you? Well, it had 6 parts because the notion of “authoritative” sources is very important.)

Clearly my little test tells us nothing specific about the quality of Google’s coverage across the United States, but I believe that the type and number of errors described above are directional predictors of what Google users can expect to find when using Google maps at any location in the United States.

I compared Google’s mapping effort in my neighborhood with Bing Maps (database supplied by NAVTEQ) and found that the NAVTEQ map did not exhibit the problems I found in the Google map, although NAVTEQ missed one tricky road name change that Google caught. If Google built the Google-base to remedy the accuracy problems they were experiencing with NAVTEQ and TeleAtlas maps, they seem to have missed the mark, at least on their first attempt.

I think the interesting question, as I have stated before, is how will Google update the Google-base? While my own research sample shown above indicates that crowd sourced data could correct many of their mapping blunders, who might want to take the time to make these corrections? If Google cannot get these corrections from crowd sourcing, can they get them from map data in the public domain? Will either of these sources prove to be authoritative? Next time I will start with my thoughts on the updating conundrum facing Google.

By the way, Kevin Dennehy who writes on LBS for GPS World asked for my comments on Google’s purchase of NIM (Networks In Motion). You can find my comments in his article titled “Did Google’s Market Grab Spur TCS’ Purchase of NIM?”

Ouch – this is really a long one, but on a very interesting topic. Get two cups of coffee and have a go!

Last time, I began reporting about the session I chaired on ADAS and Vehicle Energy Management at last months TeleMapics Update Conference in Europe. Just to refresh your memory:

The panel I chaired consisted of two representatives from companies interested in supplying high accuracy 3D road geometry data (Intermap and TeleAtlas), one automotive OEM (Ford), and one Tier 1 supplier (Continental) to the automotive industry. I thought that this mix of perspectives would provide a variety of opinions during the 40 minutes available for discussion. The panel assembled to discuss the topic included myself as moderator, Eric DesRoche, Senior VP of Automotive (Intermap), Christian Ress, Technical Expert, Telematics & Navigation (Ford), Christopher Wilson, Director of Strategic Research (TeleAtlas), Wieger Engbrenghof, Project Manager TeleMatics (Continental). In addition to his role at Ford. Christian Ress is the new chairman of the ADASIS Forum. Finally, NAVTEQ was invited to participate, but declined. Several members of the NAVTEQ team were in the audience for the presentation, but did not ask questions during the audience participation section of the discussion.

I prepared and shared 5 questions with the panel members well in advance of the meetings. Although I tweaked the questions a little the night before the discussion to make them less academic and more interesting, I did not change the nature of the queries.

So let’s see what was asked and answered. (Note: the following report is based on my notes from the meeting and these notes are directional, not comprehensive. If any of the participants happen to read this blog and want to add anything, please feel free to make a comment.)

Question 1 (a softball to start)
“What is your perspective on the advantages that high accuracy 3D Map Data might bring to Automotive Safety and Energy Management applications?
For Ford and Continental – if you have a positive outlook on the use of 3D Road Data, when might we see Automotive Safety or Energy management applications, supported by 3D Road Databases, available in vehicles?”

Discussion
All panelists felt that high accuracy 3D Map Data was a critical component of future automotive safety and energy management applications. It was noted that these enhanced map data could be used to supplement and extend existing sensors used in safety systems and that there were other applications that would depend on these data as a primary input.

The speakers from the automotive industry indicated that the question was not whether these products would be brought to market, but when. As you know, getting a feature into a car takes a three year cycle and safety applications require more complex testing than some additions. However, it was clear that there was intense interest in testing these data for use safety and energy management applications. In other words, no surprises here!

Question 2 (A fastball)
“Does a 3D roads database need to be comprehensive across all of the functional classes of roads from Autobahn to minor local roads?

For Continental and Ford – Is it possible to produce a viable product restricted to major roads carrying high volumes of traffic? Or perhaps more directly – at what level is the map coverage of transportation network adequate to meet your goals for safety and fuel efficiency applications?”

Discussion
There appeared to be a difference of opinion between Intermap and TeleAtlas about the need for comprehensive road coverage. Eric DesRoche, Intermap, indicated his company’s position was the all classes of roads needed to be included in a 3D Road Geometry database, since safety and fuel efficiency applications should work on all classes of roads, not just on major roads. He added that Intermap was collecting 3D road data for all road classes across the geographic areas they covered. Conversely, Chris Wilson, TeleAtlas, indicated his belief that the initial 3D Geometry databases might be focused on major roads, with roads of less carrying capacity added at a later date.

Christian Ress from Ford was adamant that all classes of roads needed to be included in a database of 3D Road Geometry to be used for automotive safety and energy management applications. For instance, he indicated that, according to his research, Function Class 5 roads (minor roads) accounted for approximately eighty percent of Europe’s drivable roads. In addition, he noted that these roads are often narrow, hilly, curvy and unsafe. At the end, he seemed to twist the dagger, a little, indicating that “Roads are there for a reason.”

Wiegar Engbrenghof, Continental, concurred with his colleague from Ford, but noted that today no one map database vendor has all of the data (both 3D and other road attribute data) needed to support these applications and urged to vendors to cooperate and work together to support the automotive industry. My belief is that this plea reflected the current state of the data available to the automobile vendors. It is likely that they are conflating data from the vendors in hopes of creating comprehensive data sets needed for these advanced applications and finding that it is a very difficult task. Instead, they feel that the vendors should cooperate to provide the industry with the comprehensive data needed. This is a topic that I will discuss later in this blog.

As the discussion continued, I was surprised to hear the participants from the automotive industry indicate that while they preferred full coverage of all road classes in the 3D Road Geometry database, they fully expected that accuracy/quality would likely not be sufficient at the start, but would improve in due time. I had not expected a concession to quality at the introductory stages, but perhaps this reflects the automotive industry’s understanding that supplying the uniformly high level of data accuracy required is going to be a challenge for the mapping industry.

Near the end of the discussion, Eric DesRoche told that audience that Intermap had already released 1.4 million kilometers of 3D geometry data that included data for all roads throughout Germany. As panel moderator you can see what interests the audience and when Eric announced this tidbit, half the audience grabbed their pens and wrote notes about it.

Question 3 (a fastball)
“There appears to be various ways that 3D Map data might be made available to safety and fuel efficiency applications.

Do you see an industry preference for 3D Road Data being integrated with Navigation Data?”

If you read my 3-part article (starting here) on NAVTEQ, ADAS and MPE, you know why I asked this question. In October 2008, NAVTEQ introduced a strategy for a Map and Positioning Engine (MPE) that would provide a path for cars not equipped with navigation systems to use high accuracy map data for ADAS and other applications. It was my opinion, at the time, that NAVTEQ was looking for a lower cost path to support safety applications than one that required a navigation system as a base before safety applications could be added. Since I wrote my articles on MPE, I have heard very little about it in the market, although NAVTEQ is clearly working on populating their database, even though they have restricted it to the largest roads (function classes).

Discussion
As might be expected, both Intermap and TeleAtlas indicated that they would support either stand-alone or navigation system supported applications. However, it was clear that representatives from Ford and Continental simply did not have a preference either for integrated or stand-alone databases to support their safety and energy management applications. In fact, they were more interested in testing comprehensive 3D Road Geometry data and once again urged the vendors to begin working together to provide the required data – as noted, a theme I will return to towards the end of this blog.

Question 4 (a slider)
“Automotive safety and fuel efficiency applications appear to be aimed at values important to consumers (personal safety and fuel economy at a time of rising fuel prices), yet these applications appear to be slow in rolling out and many are targeted only at high-end vehicles.

Will the success of this industry depend on government regulations rather than consumer demand?”

Discussion
Christian (Ford) and Wiegar (Continental) described this as “A difficult question.” It was clear to me that the automotive industry is keeping a wary eye on CO2 standards (Europe) and Café standards (US) and that it would prefer to be less regulated than more regulated. It seems likely that safety applications will attract more government interest in the future. Although both Intermap and TeleAtlas were non-committal on the question, I suspect that government standards would benefit Intermap and TeleAtlas, as well as NAVTEQ, especially if safety applications requiring 3D map databases were to be mandated at the federal level in the EU and US.

Question 5 (A Spitball)
“TeleAtlas has announced that 1.25 million corrections to their most recent MultiNet (2009.09) database were based on crowd-sourced information derived from TomTom’s MapShare or from the use of the company’s PNDs functioning as probes.

Do you have an opinion on the use of crowd-sourced map data and its potential contribution to automotive safety and fuel efficiency applications?”

Discussion
I started the responses with Chris Wilson of TeleAtlas, who is a huge proponent of the use of crowd sourced data (especially probe data) in creating not only navigation databases but for adding ADAS-quality attribute data to navigation databases. Chris did not disappoint and described some of the areas where he thought User Generated Content could be of great value. As I expected, Eric DesRoche of Intermap challenged Chris by indicating that he could not see how crowd sourced data could be used to meet the accuracy standards required for automotive Safety or the slope data required for energy management applications.

I was surprised that Christian Ress, Ford, was not supportive of the concept of crowd sourced data. He, and other members of the panel (with the exception of Chris Wilson), raised issues concerning the accuracy, reliability, coverage and ownership of crowd sourced data and how these were problems for use in advanced applications focused on automotive safety and energy management.

I, too, have my doubts about using crowd sourced data for safety applications requiring high accuracy geometry and spoke to Chris after the session about this concern. Chris was very helpful and indicated that the probe data being used by TeleAtlas avoids many of the questions raised by the panel. In addition, he felt that some (but not all safety applications) could be assisted through the use of databases built on top of probe data. We agreed to disagree about whether UGC could provide the coverage and accuracy required for the advanced automotive safety and energy management applications. I think we will need to visit this topic in the near future.

Analysis
One of the important issues that we did not discuss during the session was the strategy of map vendors partnering to meet the stated needs of the automotive industry. It is clear to me, based on what I heard the vendors say in our session at TeleMatics Update that they want the data now! In addition, the representatives from the automotive world were saying “Stop making this so hard. Find a way to cooperate, conflate your data, and let us get on with creating advanced safety applications.”

It appears that neither NAVTEQ nor TeleAtlas currently have the technology to create the comprehensive 3D Geometry databases needed for automotive safety and energy management applications, but they do have highly attributed navigation data. Conversely, Intermap seems to be creating the required high accuracy 3D Geometry data at a much faster pace than either NAVTEQ or TeleAtlas. On the other hand, Intermap, appears not to have all of the road attribute data that are needed by the automotive industry to create comprehensive solutions for all automotive safety and energy management applications.

It seems to me that there should be some partnering discussions going on here and it is clear that this is exactly what the automotive vendors were telling the map vendors at the conference. Obviously, TeleAtlas and NAVTEQ are not going to partner. Presuming that Intermap’s data passes the accuracy test, the real question seems to be “Will TeleAtlas or NAVTEQ choose to partner with Intermap?”

Of course, since this is a table-turning type of year, perhaps Google might partner with Intermap to further its interests in navigation?

Google, by the way, was at the TeleMatics Update Conference (as was Yahoo, but not Microsoft) and I now know that Google has an Automotive Division responsible for delivering cloud-based services to the automobile. Google’s goal is to get their apps in the car, but not to be involved in their design (describing that as the purview of the manufacturers). I am sure this came as a disappointment to the major automobile manufacturers, many of whom seem interested in creating a walled-garden within their cars, by controlling connectivity. Some people never learn! Hope the map vendors do!

Well, I’ve finally returned from my working vacation in Europe. Seventeen days and I only saw the sun for about twenty minutes, which is hard to take for a resident of Southern California. On the other hand, Austria and Germany are beautiful at this time of year and we had most of the attractions we visited to ourselves, so the timing was a good choice.

As I mentioned in my last blog, I was in Europe to chair a session hosted by Intermap Technologies at the TeleMatics Update conference in Munich. As you may know, Intermap is a company that produces digital elevation models, orthorectified radar images and a host of geospatial enabled products based on their proprietary, airborne Interferometric Synthetic Aperature Radar (IFSAR).

Over the past year, Intermap’s Automotive Division has been focusing its efforts on the application of their technology to solving problems of interest to the automotive industry. The company has been making nice progress in licensing its accurate 3D terrain and elevation data for 3D In-Dash Visualization purposes. However, it is my guess that the biggest opportunity for the company is in the areas of energy management and vehicle safety (better known in the industry as Advanced Driver Assistance Systems).

As you have probably guessed by now, Intermap has come up with a proprietary process to extract 3D Road Geometry for road networks from its IFSAR-based imagery (i.e. extracting from their high-resolution, controlled imagery database of coverage the horizontal position of a point on a road and the elevation of a road centerline at that position in a highly accurate manner). This 3D Road Geometry database is the asset that Intermap hopes will help it become a leading supplier to those companies in the automotive industry interested in advanced energy management and safety applications.

It is important to note here that while the world seems to be focused on Google’s recent announcement of its proprietary navigable map database for the United States, the ADAS and Energy Management markets are focused on map data that are created at significantly higher levels of positional accuracy (both horizontal and vertical) than commonly found in data supporting routing and navigation applications. For example, Navigation and routing assume that the vehicle must be located on and operating on a road and depend on map-matching algorithms to rectify the situation when it appears that cars are not being driven on a road. In a simplified sense, if the GPS reading describing the position of a car is not on a road described in the map database, map-matching will find the road or street described in the database that is nearest to the car, assume the car is positioned on the road (until a GPS reading or maneuver leads it to change that assumption) and proceeds with its navigation or routing calculation. Although NAVTEQ and TeleAtlas are very tight lipped about the accuracy of the navigation databases, the general agreement in the industry is that the positional accuracy is within plus minus 15 meters (absolute) and plus or minus 5 meters (relative).

Advanced Energy Management and Automobile Safety Applications require a significantly higher degree of accuracy in the map databases used to support their mission critical functionality. Although the industry has not agreed on a standardized definition, it appears that many applications are focusing on horizontal accuracies of plus or minus 3 meters or less (absolute) and vertical accuracies better than 1% of the distance traveled (rise/run). As a consequence, the mapping industry is beginning to tool-up new methodologies for capturing road geometry and elevation data at higher levels of accuracy than in the past. (For more information you might be interested in reading my article on ADAS and 3D Map Databases that can be found here.)

Navteq, for instance, is reputed to be driving roads using vans equipped with inertial navigation units and other precision measurement devices to collect the data needed to meet the needs of ADAS and Energy Management applications. TeleAtlas is relying on crowd-sourced probe data to collect high accuracy, positional and elevation data, while Intermap has opted to use precision remote sensing as the source of its high accuracy 3D Database.

What is intriguing to me is that gathering this new generation of data will involve clearing at least two backbreaking hurdles. First, is the issue of coverage. For instance, it took nearly two decades for NAVTEQ and TeleAtlas to provide a relatively comprehensive, reasonably complete road databases in order to support the target markets for their navigation databases (roughly speaking this means covering Europe (the EU), the United States and sections of Canada). The second hurdle, as noted is the ability to create map data across these large coverage areas that uniformly meets the accuracy needs of the industries comprising the target markets for these data.

While NAVTEQ’s approach to gathering 3D map data is tried and true, it is also slow and expensive. Using this methodology, NAVTEQ will likely focus its coverage efforts on the road classes that move the most traffic, but at the sake of comprehensive coverage of all roads. For example, it has been rumored in the industry that NAVTEQ does not plan to collect all road categories (e.g. those that NAVTEQ classifies as Functional Class 5 – see this official website for more details on the NAVTEQ classification). Road functional classes are a construct developed by NAVTEQ, although the term is now widely used in the navigation industry, to describe both the mix of road types in a transportation network and their numerousness. While the number of functional road classes used to describe a transportation network varies between map companies, NAVTEQ employs five functional classes to describe all roads.

ALthough I have no specific numbers I can quote you, it is my belief that the relative frequency of road classes in Western Europe and the U.S. chart as shown below. Not collecting accurate 3D data for roads in, say, Funtion Classes 4 and 5 makes it impossible to provide safety and fuel efficiency applications that could be applied across the geographies of these markets. NAVTEQ has yet to decide how to approach this challenge, but it is likely that driving all the roads in its feature classes would take many years and retard its success in the market.

TeleAtlas appears to be depending on crowd sourced data at the expense of field collection. While crowd-sourced data can provide many advantages in collecting attribute data for road vectors in a navigation map database, it is less clear that crowd sourced data will ever meet the positional accuracy and elevation requirements needed to define road vectors for safety and fuel efficiency applications. A second problem with crowd sourced data is that it appears to be spatially autocorrelated with population density. Where you have large agglomerations of people, you will likely receive adequate input from the crowd. Conversely, it is less obvious that crowd sourced data will provide any significant contributions in rural areas since crowd sourced observations may be too low in volume to provide reliable data.

Intermap has taken an alternative approach by using remotely sensed data and appears to believe that its production platform can provide both the accuracy and coverage (including all road classes) that the markets require and to be able to accomplish this feat over a relatively short time frame. The company has been quietly developing its 3D Map Database product at its facility in Jakarta, Indonesia and Intermap has recently released its database of Germany for testing by interested parties.

Hopefully, the information above helps you to understand why I was interested in accepting Intermap’s invitation to chair a session at TeleMapics Update on “3D Road Geometry Requirements and Advanced Automotive Applications.” The development of databases of the quality and coverage to support both automotive safety and energy management applications is the next big test for the mapping industry and I, for one, am very interested in seeing how it will play out.

The panel assembled to discuss the topic included myself as moderator, Eric DesRoche, Senior VP of Automotive (Intermap), Christian Ress, Technical Expert, Telematics & Navigation (Ford), Christopher Wilson, Director of Strategic Research (TeleAtlas), Wieger Engbrenghof, Project Manager TeleMatics (Continental). Navteq was invited to participate, but they declined. In essence, the panel consisted of two representatives from companies interested in supplying 3D Map data, one automotive OEM, and one Tier 1 supplier to the automotive industry, which, I thought, would provide a good mix of opinions across the 40 minutes available to us for discussion. In addition, Christian Ress from Ford is the new chairman of the ADASIS Forum, which added to the value of the deliberations by the panel.

I presented the panel with a series of 5 questions of interest to me (and, I think, to the industry). Next time I will present the questions as well as the interesting answers provided by the panel. In addition, I will provide a brief overview of other insights I gained at the conference. (Now, if I could just get over this jet lag!)

(Editor’s note: I usually print my blogs and edit them before they are posted. However, I do not have access to a printer while on the road in Europe – so please forgive the typos I did not catch. I started sketching out this blog in Vienna last week. I kept cycling back to Google and their mapping program. I wrote some notes in the middle of the night and have put this blog together in Munich, where I had to pay 18€ for the Internet connection that I used to send it to you. I hope you enjoy it.)

Over here in Europe you do not hear about Google maps every day and I guess I am having some sort of withdrawal. Just in the nick of time my friend Duane Marble sent me a blurb from the Las Vegas Sun indicating that Google had misnamed Henderson, Nevada, calling it Rochester. One of the comments on the article said the location was neither of those names and should be called Hidden Valley Ranch. Oh, Google, how could you have gone so wrong so quickly?

If Google wants to be in the mapping business, it better develop a thick skin and hire an authoritative spokesperson to handle the public relations fiascos that are ahead. As many of you know, I was Chief Cartographer at Rand McNally for over a decade and read and responded to many of the consumer letters we received about real or perceived errors on the company’s cartographic products. Ouch!

From a cartographer’s perspective I am interested in examining the compilation process behind the new Google-Base (my term for their navigable map database available for the United States), since modeling their compilation process may tell us a lot about the integrity of the Google-Base and the problems that may lie ahead of Google in respect to map updating. As you know, Google is incredibly secretive. For that reason, I propose a model of the Google Map Compilation Process that I am developing just for the fun of it.

Background

Let’s start this examination by looking at Figure 1. I do not have any inside information on what Google is actually doing in map compilation to support the Google-Base, but I suspect that they are following the path shown in the illustration. My intuition and experience tell me that the boxes in the illustration are in the correct sequence. In addition, note that each successive stage is used to augment the information provided in the previous stage and to correct any errors that are resolvable using their algorithmic approach to map compilation.

Algorithms? Yep, you are not going to find any warehouses full of people digitizing maps for Google – at least that’s the corporate story. I suspect however, they are creating an increasingly large stable of the type of non-algorithmic map editors known as humans. However, the question that surrounds Figure 1 is “Has Google managed to create a virtuous map compilation cycle that is as accurate and automated as is practicable at this time?” It is going to take a lot of noodling to come to a conclusion on this question and we won’t get to the total answer today. However, let’s make a start.

Most map compilation processes are similar to cutting trees, then producing lumber, followed by storing and aging the lumber in warehouses prior to distribution. Unfortunately, spatial data should be regarded as a perishable product that starts aging once it is collected. The faster a company can get spatial data into the distribution channel in the form of products, the better for all concerned, especially the end-user of these data.

As an example, many Personal Navigation Devices are provisioned with a new extract from a navigation database when the PND model is created and the map database is never updated again. Paper maps are even worse, as the data is usually collected six months before the product hits the distribution chain and the maps sit in a rack, sometime for years, before anyone buys them.

Due to problems of integrating navigation data with other data used in an application, some navigation system providers release updates only quarterly and others even less frequently. It has long been the goal of NAVTEQ to find a way to provide real-time date to its customers, so that they could have the latest updates as soon as the new updates were committed to the master database. NAVTEQ has had difficulty in achieving this goal, as their customers apparently do not see the value, or perhaps reward, of updating the data in their product that frequently.

Now, stage left, Google enters the scene. From a simplistic point of view, Google can be thought of as a company that has realized NAVTEQ’s goal. Google serves the best data they have from the “cloud” and can refresh it, augment it, correct and extend it whenever they feel a need to do so. Unlike NAVTEQ, Google controls its distribution mechanism. I think Google may be the first provider of navigable map databases, or even map databases, to completely control its own distribution network. While this may not sound the least bit interesting to you, it changes the game for everyone!

In a sense, Google is a new paradigm in mapping and navigation, since the company has created a new notion about how to update maps and has implemented new and unique technologies to support their vision. To Google, mapping and navigation are all about selling advertising and, as we have seen from their most recent financials, selling ads is big business. This is important because Google has, presumably, decided to spend tons of money getting the map compilation process just right.

Now Back to the Model

So, let’s return to general comments on Figure 1. While the use of high resolution aerial imagery (including satellite) is the first step in Google’s compilation process, the data derived from this process will require enhancement and Street View is the likely source for augmenting and extending these data, at least where Street View coverage exists.

Next, it seems likely that Google must turn to sources that it regards as “authoritative” to fill-in the areas where its imagery base is lacking (in terms of coverage, detail and content). It is likely that the preferred sources are national mapping agencies (e.g. the U.S. Geological Survey or other federal agencies (e.g. the U.S. Bureau of the Census) that create map databases as part of their mandate. Google also solicits data from state and local governments that are widely regarded as the authorities on data that is more local than national in scope and scale.

As you can imagine, the data from the sources used by Google exhibit a wide variety of accuracy, comprehensiveness and age. Note that access to some of these data is based on collaborative agreements; while other relationships are based on contractual licenses from vendors specializing in specific types of data (e.g. parcel boundaries as related attributes). I suspect that in some countries Google has or will have to create joint ventures, under the guidance provided by national governments, to create map databases (not to mention navigable map databases).

Google’s compilation process ingests the data from these various sources using a process called conflation that is optimized/trained to match road and street geometries and other positional information between the Google-Base and the data source, as a precursor to evaluating, assigning and transferring these detailed attributes (e.g. road class, street address, boundaries including road segments, road attributes, navigation attributes, etc.) to Google’s road geometry.

After the conflation process has completed, Google likely evaluates the match between its store of user generated content and the Google-Base that has resulted from the first three stages of the process shown in Figure 1. All of these inputs (suggested corrections, Google Map Maker, probe data from Android phones, etc.) get mixed into the Google-Base subject to some set of quality assurance procedures and fed into applications that require mapping, routing and navigation.

So, let’s start again at the top with a little more detail -

I have reasoned that Google must be leveraging its image database to create the geometry for the road networks in its map database. As far as we know, Google has not yet launched its own satellite for imaging and must be relying on suppliers (licenses) or public domain imagery to create the street and road geometry for its map database. Those of you who have spent some time with Google Maps and Google Earth realize the enormous variability in the quality (accuracy and resolution) and the age of the imagery used by Google to represent geographies across the world. What this means from compilation perspective is that Google cannot create all of the road geometry it needs (coverage) at the level of detail it requires from satellite or other aerial imagery everywhere it desires to provide maps that are owned by Google.

You can detect a limited set of cartographic attributes from satellite and other aerial imagery, if the imagery has a high enough resolution (and control). Road geometry may be a given, but street names, highway designations, road classes and other important information cannot be extracted from these sources. As a consequence, it is likely that Google is using Street View to provide some portion of the “missing attributes”, at least in the locations where they have Street View coverage available.

Another reason that a Street View-like process is beneficial is that the satellite or aerial imagery (e.g. rectified orthophoto quadrangles or the like) used by Google (and everyone else) is out-of date by the time the images are initially processed. I am not picking on Google, but the datedness of imagery reflects the nature of its acquisition process and the delays between mission planning, sensor tuning, image collection, image processing and the availability of the product to the user community (i.e. Google). The optimal solution is to own your own satellite and task it with imaging a specific area to remedy a conflict in your data sources. However, even the CIA can’t afford to do that for everyday problems and neither can Google.

Next, imagery is not always of the desired quality. While leaf-off and clear days are the optimal times to image, image capture does not always occur under these conditions. When the images are non-optimal (leaf on, cloudy), you cannot always see the roads, determine road width, see that a link is a cul-de-sac and does not connect to the street on the other side of the leafy tree, or notice a variety of critical attributes that are occluded in the imagery. What is unknown here is whether a Street View-like process can add value to a map update process once the initial data have been collected and require revalidation.

I suspect Google is applying image processing and image recognition software to extract street and road names from signage (and other road furniture), as well as other attributes (address ranges, directionality of the street, turn restrictions, etc.) from Street View imagery. Of course, the coverage from Street View is not comprehensive in a spatial sense, so the map data that Google acquires directly needs to be augmented by conflating the attributes of other data sources to the geometry captured by from its image base and Street View. It is important to note that the Street View data is, also, out-of-date as some function of collection date and the elapsed processing time that occurs before it is available for map compilation and augmentation.

Street View may capture data from roads/streets and other visible sources that are not available from the “imagery base” described in stage 1 (e.g. streets and roads not visible in the imagery or constructed after the imagery was “flown”). As a consequence, the location information that is gathered by the Street View instrumentation can be used to accurately position the geometry of these “new” streets and roads to match the data extracted from the Google image base (i.e. the gantry that is used to collect the Street View image and its associated instrumentation allow the capture of GPS, cell tower strength, Wi-Fi network strength and other location information from its three laser scanners). Street View is a powerful addition to Google’s satellite and other aerial imagery, since it can be used to provide many of the attributes required to create a navigable map database.

Given that address information is not always shown on street signs, or even on building surfaces, Street View is likely an inadequate source for providing a comprehensive address framework that would allow for geocoding. In general, geocoding can be thought of as a process for creating a map coordinate pair (e.g. Longitude, Latitude) from a postal address, allowing the address to be plotted in the correct location on a map – and a route to be calculated to the correct location of a destination identified by an address. The Google compilation process depends on conflation to provide the bulk of the addressing information they use, whether that data originate with public sources or from licensed parcel information. It is my belief that the quality of address information will plague Google and the problem will become more concerning as they expand their Google-Base outside of the United States.

But There’s More

The skeptics among you have realized that there is an enormous amount of map data that is not visible and cannot be sensed with satellites, Street View or any other imagery-based sensor now known. For example, it is not possible to fully determine city boundaries from street signs. It is not possible to determine neighborhood boundaries from street signs, or census tracts, property parcels, vanity addresses (One Miracle Mile) and a host of information that is required to produce not only a map data base, but one that can be used for purposes of navigation.

Of course, that is the reason that Google uses conflation and has a variety of agreements with data sources it considers reliable. However, if these contacts are not reliable, Google is betting that its use of User Generated Content will catch these errors and help them find the right solution. Hmmm. I think the Google is on the right path here, but suspect that they will experience lots of heartbreak before they understand how to manage UGC to their benefit.

Map Updating

While Google is now basking the pleasure of having created a navigable map database of the United States, they have also crossed the Rubicon and will have to support updating the Google-Base. I think they will find being in the game as provider is much more difficult than being in the game as a licensee.

One of the aspects of map updating that was practiced by paper map publishers was to update maps where the most people were likely to travel. Why is that? Well, where people travel is where your errors are going to be noticed. While this is humorous in some ways, it is instructional in that the databases created by paper map publishers did not have the accuracy or currentness requirements necessary for creating navigable map databases. Faced with these stringent requirements NAVTEQ and TeleAtlas concluded that they could not create navigable map databases using only data sources that relied on imagery and conflation. This notion is why NAVTEQ and TeleAtlas have field research teams. While we can argue that Street View and UGC are the field research teams of Google, it appears that both of these sources are biased by population.

More to the point, did you know that Feature Class 5 Roads (as defined by NAVTEQ), which are neighborhood streets and local roads in the countryside, make up an astounding 77% to 80% of the road network in Europe and about the same percentages in the United States? Do you suppose those Street View vans are being driven on all of these road miles? Do you suppose that the federal and local data used by Google to conflate these streets and roads to the Google geometry layer is up-to date? Do you suppose that the majority of those contributing UGC are rural residents or, more likely, urbanites?

Now the clinker! Know where most accidents with fatalities occur? Yep, those roads that most sources ignore – Feature Class 5 roads.
Has Google done a better job than those who came before? Maybe.

Has Google done a better job than NAVTEQ or TeleAtlas? Don’t know. However, Google apparently believes that its data is better than that of NAVTEQ or TeleAtlas since it has spent more creating these data than it could ever have spent licensing them from TA or NT.

However, since all three companies create navigation databases that are used to provide real-time maneuvers/directions to people driving moving vehicles we hope they are getting this right. How to determine the superiority of one solution over another seems like an interesting project – I’ll have to think about how to do that in a satisfactory manner.

Finally, let’s add one more concern and call it a day. When you combine the reservations described above with the notion that map sources used for conflation are not updated daily and in most cases not even annually, you just might begin to suspect that conflation may not be able to solve all map updating problems for Google. Consider this – at least historically, the U.S. Census has not updated the Tiger files until they began the cycle of preparing for the next census. Similarly, some USGS quadrangles have never had a complete revision since they were originally created – in the 19th century. If your sources are not up-to-date, how can your conflation-based map be up-to-date? Hmmm.

Well, now I’d like go back to my vacation. However, before I can do that I need to chair a session on the application of 3D Road Geometry to advanced vehicle applications at the TeleMatics Update Conference in Munich. It sounds like an exciting conference and I’ll fill you in when it’s over. Also, I plan to continue my examination of Google and map updating in the near future.

Until next time – Mike

As the entire world now knows, Google has introduced a navigation package; I guess that literally is yesterday’s news. Today’s news was the TomTom and Garmin stocks were hammered as a result of the Google news, both dropping double digits, although TomTom’s warning about falling prices for PNDs contributed to the plummet of both stocks. Many news sources indicated that they felt that the PND market may be in a terminal decline. I suspect this is somewhat of an overreaction.

The turn-by-turn navigation market is certainly one that will continue to grow in terms of user uptake, but one does have to wonder about revenue growth. As I am sure you noted, Google’s navigation package will be priced at a very compelling $0.00, finally something even TeleMapics can afford! Of course, what’s good for me in the short run may not be good for me in the long run – but more about that later.

Google’s move into navigation is being based on a three-fold (at least) strategy. First, they want to ensure a competitive position for cellular phones provisioned with Android. Second they want to give Nokia a “whuppen” while giving Apple something else to think about. Perhaps more important than the other two, Google realizes that egocentric spatial search harnessed by applications capable of delivering the true richness of geospatial data to cellular phones will become one of the main engines for Google’s amazing advertising revenue machine.

For those of you wondering “What’s egocentric spatial search” – you don’t know how long I have been waiting for you to ask. All things wireless (and perhaps all things informational) are destined for greatness only if they cater to the thought “It’s about me”. Yes, the future of advertising and services is about “ME”. It’s about things around “ME”, how I can get to them or they can be brought to “ME”. We now live in an egocentric world where many consumers feel that there is no one who has more to accomplish in less time than “ME” and these folks are quite reasonably asking their suppliers “So what are you going to do to help “ME” with my problems?.

I suspect you have found the last few sentences somewhat obnoxious. Get used to it. Marketing today is about personalization, communication is about personalization and so is product development. People want things the way they want them and free is a good way to start – something that Google realized quite some time ago. Google does not want your money directly, it wants to woo you with free services and it will help you get things done by providing information containing advertising targeted at where you are and what you likely want to accomplish at that location. As juicy as this all is, however, it is not the point of this blog

It appears that the only ones who will be making direct profits from the Google Navigation product are the networks who will sell both the phones and the data packages to support them and possibly the phone manufacturers, such as Motorola. I suppose it is prudent to wonder if those data plans will increase in price to reflect the amazing rate at which new data gobbling applications are being introduced. Perhaps, “all-you-can-eat (AYCE)” data plans will become a thing of the past.

Those of you who have tried to use your iPhones anywhere near the Financial District in New York City know how the system works when phones that gobble data try to connect to a resource constrained infrastructure (aren’t they all?). Most of my friends in NYC have given up trying to use their iPhones, except at night, when they might be able to squeeze a call or two out of the network before they get disconnected. If the wireless carriers have to upgrade their infrastructures to service data intensive applications, how long do you think data plans will be all-you-can eat or available at the same bargain prices for which they are available today?

One of my acquaintances from Europe (John Craig of Intermap), raised the issue that nothing’s free if you are traveling and your cell phone is roaming. He is located in Germany and noted that even the “AYCE” plans do not allow roaming in other countries. He concluded that using the Google Navigation service could be prohibitively expense for business travelers in Europe who those who commonly travel between countries. I have heard the horror stories of people based in the U.S. who have taken their iPhones to Canada or Europe, forgot to turn on airline mode, forgot to turn off international roaming, forgot to disable email and the auto check function for email and received bills approaching a thousand dollars for a few days on the road. Ouch. Guess even free things like Google Navigation aren’t really free. But that isn’t the main point I am interested in either.

There may be a hidden cost in the potential success of the Google Navigation application and the one of interest to me is related to the influence that Google’s map-based applications will have on the other providers of map and navigation data and competition in that market. If, as many writers have suggested, PNDs are in a death spiral, where does that leave TeleAtlas? If Android becomes more popular than Nokia’s offerings, where does the leave NAVTEQ?

It is clear that neither NAVTEQ nor TeleAtlas ever made significant revenues from licensing their databases to Google, Yahoo, Microsoft of anyone else in the online world, so losing the online market is not the biggest financial setback that either provider could experience. In fact, the largest proportion of NAVTEQ’s revenues depends on in-car systems ranging from integrated in-dash navigation systems to Advanced Driver Assistance Systems. However, the company also benefits from a reasonable revenue stream from licensing their data to PND manufacturers and providers of cell phone-based navigation systems. If Google’s Android and its navigation software are a huge success Navteq and TeleAtlas may be in for a world of hurt.

Yes, we can all argue about how satisfying consumers will find navigation services delivered from a “cloud” across the spotty coverage of wireless networks to devices containing inadequate GPS systems. But I think spending time on that argument is wasteful. Communications technology will improve, enhanced GPS chips will evolve and in time, phone based systems will win the market.

On the other hand, it is unlikely that Google will ever play a role in the high accuracy world of 3D Road Data for ADASEM (Advanced Driver Assistance Systems and Energy Management), which may provide a significant future revenue stream for companies capable of providing high accuracy spatial databases. ADASEM has been an interest of mine for some time and I am headed to Munich for Telematics Update where I will be chairing a panel discussion on “3D Road Geometry Requirements and Advanced Automotive Applications” that is being hosted by Intermap Technologies. I am sure I will learn a lot and I intend to use the conference to see where the future of mapping (at least the one that isn’t Google) might be headed. Of course, I would be delighted to see you there.

By the way, I am departing for Europe on Sunday and will be taking some personal time in Austria b before heading to Munich and the conference. After the conference, I will be touring parts of Germany. So, yes, I will be playing and it might be hard to squeak out a blog or two – but I will do my best, because I want to finish up what I have started here. In addition, I think we need to look at the User Generated Content thing again and try and figure out how much Google is going to depend on it for map updating. And if not map updating, how much is Google going to depend on conflation? There are no warehouses full of digitizing tables in GoogleLand – if it can’t be done algorithmically, it’s just not worth doing – and it probably doesn’t earn you any promotion points if you are software engineer who suggest a labor intensive solution to map updating. Ah, it’s a new world for mapping – isn’t it?