Exploring Local
Mike Dobson of TeleMapics on Local Search and All Things Geospatial

Do Data Flows Tell The Story (Part 2)

November 19th, 2008 by MDob

Last time I noted the usefulness of products in developing a powerful strategy for incorporating UGC into map compilation. Let’s take a look at some generalized “data flows” that I use to examine how the two major players in the map navigation database market are adapting UGC to their advantage.

The data flow currently utilized by TomTom is shown below. (Click here to download a PDF with the three main images for this blog. )

UGC data flow using a TomTom PND enabled with MapShare

The key ingredients in the success of this model are 1) MapShare, which is used to collect UGC, and 2) the presence of the navigation map database locally on the user’s PND. In essence, the navigation database is available to the user when he/she desires to male a correction or augmentation. Because the PND is GPS-enabled, it “knows” the user’s specific location at the time the correction is being made. Editing maps using this position data and the additional information input by the user should make correcting “blunders” quite easy and not require significant new compilation. Corrections that are complicated will require more significant compilation efforts to support their resolution, but these should be much less onerous than they would be without the assistance of UGC.

A second important point here is that the MapShare interface is capable of capturing “passive” UGC information. We use the term “passive UGC” for the data collected when the users of the TomTom PNDs agree to allow the company to track their paths and use the PNDs of these individuals as network “probes”. The benefits of “passive UGC” are enormous – just think of the information you could derive about a network and its environment, based on examining the paths of numerous users across a local network. (Maybe we should blog about passive UGC in the future.)

One of the important issues here is that the tracking method is simplified due to the data storage capabilities resident on a PND, which allow these paths to be stored until they can be communicated back to the mother ship. (Do you suppose this is why my TomTom 920 could not store the new databases in its original memory? – Oh, wait, that was another blog, wasn’t it?) Communicating the voluminous path data has always been a problem that has hobbled the utility of systems based on active probes. However, in this case, the need to communicate the probe data is not immediate, at least in terms of database compilation, and waiting for it to be uploaded by the user does not impose significant penalties for the database providers.

Finally, another benefit that makes the TomTom approach to UGC a virtuous cycle is the all around advantages of the process to the TomTom user. Aside from the obvious advantages of having more rapidly updated street information (either TeleAtlas verified or not), TomTom users can customize their local database to reflect their driving, eating, and playing preferences (eliminate streets to avoid driving on slow roads, add clubs for nightlife, favorite places to eat, new locations of interest, etc) and keep them private, share them with friends only, or share them with the world.

The personalization of the database is an important part of the social networking aspects of TomTom's market strategy

(This figure is the second image in the PDF you downloaded earlier or click here to download now.)

In essence the area shown on this illustration in the violet dashed line is that part of the system that is customizable and sharable (if desired) by the user. While this may not seem important to many of you, it is an important component of social networking and personalization will increasingly become an important part of navigation and navigation systems.

In sum, being able to change your map (and perhaps the maps of your friends) as shown below

Interface to change data on a TomTom PND

is much more useful (and cooler) than having to do this,

Screenshot of the Navteq Map Reporter

which is particularly unsatisfying since the correction/addition goes into the map factory and who knows when it might come out? In other words, there is no incentive and little reward, either immediate or long term, for those who submit map changes using an online UGC collection system.

Next time, let’s take a look how you could collect UGC using cell phones, presuming that this is what Nokia prefers as its UGC strategy. While it is likely that Nokia will take a multi-pronged approach to implementing UGC (acquisitions of Gate5 and Plazes), their focus will be the wireless Internet. Can Nokia/Navteq put together a phone-based system for UGC that has the advantages that TomTom offers their PND customers?

Nokia is interested in advertising and the acquisition of Navteq should be considered a marker of how they intend to leverage location and advertising. It is clear that Nokia’s management see benefits in owning a map company that can be advantaged by UGC and advantage advertising in return. You can see my thoughts on what the phone dataflow might look like – it is the third illustration in the downloadable PDF. (Click here if you have not yet downloaded the document.)

Let’s follow up on this next time. It is likely that the out-of-the box model for phone-based UGC will not be very satisfying. However, there are a number of ways to fix that and perhaps, win the game.

If I do not write the next segment before Thursday, enjoy the holiday.

Bookmark and Share

Posted in map updating, Mapping, Navteq, Nokia, routing and navigation, TeleAtlas, TomTom, User Generated Content


(comments are closed).