Navigating the World of Digital Mapping

To the cursory observer, online map services like Google Maps or Bing Maps may seem like simple tools, simply placing a searchable compilation of points of interest on a scrolling set of map images. In reality, it’s a very complex business with immense potential going forward, with demand coming from transport electrification, autonomous cars, consumerization of ground logistics (UPS -> Uber/Lyft), and broader use cases for unmanned aerial vehicles, among other areas.

Mapping entails digitizing the physical world, so every map service at its root needs access to mapping data. This consists of the actual imagery – satellite images, aerial photos, and street level photos, for instance – mapped to a digital overlay of roads containing all manner of metadata (e.g. street name, type, traffic direction, speed limit, toll road). Collecting these data is an immensely labor-intensive on-ground task that is never complete (as roads and buildings keep changing), so there are really only a few global players in this space that almost all map-based services ultimately get their map data from – namely HERE (originally Navteq; recently sold by Nokia to Daimler/BMW/VW), Google, and TomTom.

There are a few hybrid players – e.g. Microsoft sources map data from HERE and others, but also had a hundred employees building out their own map data via street vans, aerial imagery, and such (a division recently sold to Uber), and Apple, which recently entered the mapping space with Apple Maps, gets its data from TomTom but is also building out a fleet of its own mapping vans.

On top of map data, you need routing algorithms, address and point-of-interest data, search, and lots more.

Below I will start with an anecdote about my introduction to the world of mapping and then discuss some opportunities in the space today.

TA Maps and Google

After college, I shipped out to India to work at Mahindra, which is India’s largest automaker (and also the world’s largest farm equipment manufacturer, among other things). After moving into my apartment in Mumbai, I realized a few things—one, the Google Maps app, which back home in the U.S. I used quite extensively on my phones at the time, an iPhone and an HTC HD2 (running Windows Mobile 6.5), had incomplete data in some parts of the city, so pretty often I’d be switching between Google and other map apps. Then I upgraded to an HTC HD7, running Microsoft’s rebooted-from-scratch Windows Phone 7 OS (whose story I’ve written about), and there was no Google Maps app in the store at all.

Windows Mobile had earlier conquered the pre-iPhone high-end PDA/smartphone market, crushing Palm OS with a remarkably feature-packed and open OS. So if Google wanted its mapping service in high-end mobile users’ hands, it had to be on Windows Mobile (just as it had to be on iOS later). Yet as many large tech companies often do (e.g. MS ceasing development on Internet Explorer after IE6, having beaten Netscape, only to be woken up later by the upstart Firefox project), Microsoft was busy running a victory lap when the iPhone launched and took a while to respond, by jettisoning Windows Mobile completely in favor of the ground-up Windows Phone 7. Meanwhile Google’s acquisition, Android, launched as a very Windows Mobile 6-like response to the iPhone. By the time Windows Phone launched, Google felt it could forego its biggest rival’s platform entirely and thereby perhaps gain a competitive advantage for Android.

So, with an incredibly smooth Windows Phone 7 device that I wanted to use daily, and no Google Maps in front of me, I sought to fix the problem by writing my own mapping app – TA Maps – that would initially serve as a Google Maps client and then expand to include multiple map sources, thereby solving the constant switching problem I had with Google Maps on iOS and Windows Mobile 6.x. To do this, I sourced map tiles from Google (and later Bing, OpenStreetMap, and others), plugged into their point-of-interest search and directions APIs, and then handled a bunch of curiously complicated tasks like reverse-engineering Google’s compression algorithm for map polylines (e.g. route lines on a map for directions).

With multiple data sources, I solved my own navigation problem and others’ too (e.g. building in OpenCycleMap for bicyclists). In the process, I put the app up on the app store and gained thousands of free and paying customers across the world, learning a ton about mapping in the process (e.g. when customers in China all reported the map as being off by a certain distance, I found that the Chinese government had at some point built a location offset from the (US military-run) GPS system, as a rudimentary security measure ensuring that all non-China-specific maps would be off unless they specifically compensated for the offset).

Then Google began to restrict access to its map data, deprecating old versions of its API and forcing users onto its new API, which required 1) authenticated tokens that identified the particular client requesting map data, and 2) agreeing to ever-narrower usage terms. When the API was updated to essentially ban native third-party navigation clients from using Google Maps, I received a not-so-friendly email from the Google Maps team – not quite a takedown notice yet, but clearly on the way. At that point, I decided to just take down the app (it still had standalone value sans Google, but I was too busy with my actual job to maintain it). Around the same time, another app emerged, as a pure-play Google Maps client that was even (egregiously) called “gMaps” and used a modified version of Google’s own Maps icon as its own. The difference? Those developers were in Russia and had no qualms agreeing to terms that they’d then explicitly violate (and then fight a technical cat-and-mouse war around Google’s API access blocking).

Google clearly saw map services as a tool to gain a competitive advantage in other areas of its business. For instance, when Motorola – then one of the top Android phone manufacturers – decided to use the services of the startup Skyhook Wireless to provide its users better location sensing than Google could provide, Google’s top executives responded with fury to the threat of losing consumer location data, forcing Motorola to switch course on Google’s supposedly “open” Android platform.

A couple years later, in January 2013, I and some others online discovered that Google had begun to specifically block Windows phones from accessing its own Google Maps website—presumably trying to get users to switch to Android. Google somewhat absurdly claimed that this was because Google Maps only worked well on browsers built on Webkit (i.e. Chrome, Safari) – strange, as the site worked fine on desktop Internet Explorer, Firefox, etc.

As I wrote here, if you changed the user agent (UA – a piece of identifying text by which the browser tells websites about itself and the device it’s running on) of Google’s own desktop Chrome browser to pretend that it was running on Windows Phone, it would no longer load Google Maps, and conversely, when a different UA was used on a Windows phone, the site loaded perfectly fine. Eventually the mainstream tech media picked up the story, and having been caught red-handed, Google was forced to re-allow access to its site. (incidentally, so much for “Don’t be evil”)

HERE, Uber, and Waze

Last year, Nokia put its market-leading maps service on the market, by then rebranded from Navteq / Nokia Maps to HERE. This was part of its exit from consumer-facing businesses (selling its best-known mobile phone unit to Microsoft, whose then-CEO Steve Ballmer apparently also wanted to buy HERE, but was turned down by a board so skeptical of any Nokia deal that Ballmer essentially sacrificed his job for it, agreeing to a timetable for stepping down as CEO in exchange for board approval on the Nokia phone deal).

A bidding war ensued for HERE, in which Uber battled a consortium of the German car manufacturers – Daimler, BMW, and Volkswagen. Why would either of these parties be interested in what might seem like off-core-competency offerings for either? The answer is simple – the future of transportation will depend on distributed data collection.

An Israeli startup, Waze, was an early entrant on the consumer side of this space, with the basic premise that if you collected position and speed data via a smartphone app running inside consumers’ cars, and had enough users, you could get a good idea of real-time traffic flows (better than existing sources of traffic data, such as government-installed highway car counters that at best can estimate traffic at particular locations) and use this to provide better traffic-adaptive routing. Waze executed exceedingly well and was acquired by Google for $1 billion.

Waze is dependent on a smartphone running inside a car, though. What if one thought of the car itself as a device—as an increasingly sensor-laden rolling connected device? Every car on the road could provide all of what Waze sees and much more (e.g. road grades, potholes, lane markers, more precise positioning, etc.)? Herein lies the problem for carmakers—platform companies like Google (Android Auto), Apple (CarPlay), Microsoft (Windows Embedded Auto), and BlackBerry (QNX) have designs on moving beyond where they currently play – in-dash infotainment systems – and into the car as a data platform.

Carmakers hate the thought of being reduced to commodity device builders like the no-profit world of Android smartphone/tablet manufacturers. Hence the German automakers’ interest in HERE, to preemptively build out the car as a digital platform and avoid getting marginalized by Google (which is the second largest mapping player and now, with Waze, also the leader in crowdsourced road data). HERE has its own infotainment platform, but more importantly, soon every Mercedes, BMW, and VW (meaning VW, Audi, Porsche, etc.) will provide Waze-like data to HERE, building up a strong, Google-free Waze alternative. HERE’s ambition is to power both tomorrow’s cars and location-based applications of all sorts.

Meanwhile car dispatch apps like Uber, Lyft, Didi Kuaidi, Ola, and such are essentially in the logistics business. The better they can route cars, the faster customers and drivers meet, the more transactions the companies process, and the more they profit, consequently. The business of route optimization, previously limited to delivery companies like UPS (whose in-house routing famously avoids left turns at almost all costs, reducing wait time in turning lanes and avoiding accidents), is now squarely within the sights of Uber and its ilk. Uber’s driver app on Android (but not iOS) currently bounces drivers out to Waze by default for optimized routing. But that’s a ton of useful data that Uber’s feeding to Google instead of itself, and at the same time, Google’s looking to directly encroach on Uber’s terrain (with its own car sharing service), so for Uber, becoming Google-free as quickly as it can is a priority.

One route was for Uber to buy HERE and have a full-fledged mapping business on its hands. With its huge market cap, Uber could probably afford to outbid the German automakers too (which itself is something worth reflecting on). Yet Uber eventually lost that bid and opted for another strategy, which was to make a deal with Microsoft. Under CEO Satya Nadella, Microsoft is focusing heavily on cloud-enabled services and treating everything below that in the stack as a commodity (its own offerings there will eventually just be demand drivers). Part of that is a new strategy for its map services (such as Bing Maps) in which, rather than driving imaging vans around the world, Microsoft will have strategic deals with map vendors like HERE to source imagery while focusing on higher-end services (such as 3D mapping and integrating mapping into other services). So Uber and Microsoft struck a deal by which Microsoft is transferring its surface imaging unit (and the technology entailed) to Uber, and Uber will integrate deeply into Microsoft services like Office and Cortana. With this, Uber can eventually turn its global network of drivers and riders into a huge source of map data that’ll be of value for its own routing but potentially also to others.

Looking Forward

At Mahindra, I eventually headed strategy and tech planning for the electric car venture, Mahindra Reva (a startup in Bangalore that we had acquired). One of my focus areas was building out a vision for the connected car, and as part of that, I looked at areas in which we could build EV-specific experiences. One idea that came to mind was in mapping— electric powertrains are drastically more efficient than internal combustion engines (ICEs), so when looking to improve efficiency and maximize range, one starts to look at things like aerodynamic drag and road grade much earlier than with ICEs (where these things only really matter for racing cars).

Could we create map routing that would optimize energy consumption by, say, sticking to flat or downhill roads? I met with map vendors and realized the idea would be a bit challenging to implement because most navigation apps calculate the crow’s flight distance (i.e. if the land were all flat from a top view), not a 3D-mapped altitude-sensitive true distance. Further, in some regions, grade data were not available at all. We would’ve had to develop grade-sensitive navigation routines in-house, which was beyond our core competence, but the opportunity here remains significant.

There are lots of potential applications in robotic navigation as well – how would an Amazon delivery drone best navigate an urban environment (FAA rules permitting), for instance?

Clearly, much remains to be done in mapping, and it’s quite an exciting field today.

By: Ashish Bakshi