Google's "iLost" Motorola ad faked an address to "lose" iOS 6 Maps

In a marketing ploy not unlike Nokia's faked camera shots to promote features of its new Windows Phone 8 models, an ad promoting Motorola's Droid RAZR M is portrayed being able to locate an address that iOS 6 Maps directs to a wrong road name in what appears to be the wrong city.

"Looking for 315 E 15th in Manhattan?" Motorola Mobility posed on its Google+ site. "Google Maps on DROID RAZR M will get you there & not #iLost in Brooklyn."

Droid, aren't these the ones you are looking for?

The problem, as noted by reader AMD Pettitte, is that 315 E 15th Street is not an actual address in Manhattan. A public park sits on that side of the street, making none of the block's odd numbers a valid address. The number will never be a valid address in Manhattan. This is indicated by looking closely at the picture, but none of the thousands of people sharing the false address lookup ad seemed to notice this.

So why would anyone actually be "looking for 315 E 15th" in New York? The only reasonable reason would be to locate an actual address that does exist in Brooklyn (which is also part of New York City), in an area where a series of numbered streets between East 11th and E 16th now have assigned names.

What was apparently once the 300 block of East 15th Street is now named Marlborough Road. Five blocks away, Marlborough Road turns into E 15th Street, where numbers begin on the 800 block. So Apple's Maps returning a location on Marlborough Road when searching for East 15th Street isn't nearly as absurd as Google's ad portrays.

If you're looking for an actual address in Manhattan, say 318 E 15th, the apartment building across from Google's fictitious address in the park, Apple's Maps can correctly locate it (below).

If you're not sure of the address, but you do know that it is in Manhattan, you'd naturally enter the correct borough rather than searching all of New York City, especially if you were being returned an actual valid address in Brooklyn instead. If you insist upon finding an address that can't really exist in Manhattan, Apple will locate it for you, with or without satellite images (below).

And if you enter an address that actually could exist in multiple places in New York, iOS 6 Maps will offer you a choice of potential targets (below). But if you're searching for an phony address that doesn't actually exist, you're already lost. You can't blame Apple, and neither should Google.

Why is Google looking for problems that don't actually exist?

Apple's new Maps service certainly isn't without flaw, making the fake address goose-chase that Google invented to create its Droid "iLost" advertising even more surprising. Why not just point out a real address that Apple's Maps can't actually locate?

It's easy to come up with an address that isn't correct enough to locate. In testing "whats wrong" in iOS 6 Maps, I tried looking up a hotel in my contacts located in Sapporo, Japan, which the new Maps failed to locate it. However, I can't read Kanji. It turns out, as a reader "Success" commented, the address was formatted wrong.

The Japanese address had been generated for me by Google Maps, after I first looked up the address in English. When entered correctly in Kanji, iOS 6 Maps could locate the hotel (below), although it could not find it when searching in English, an actual problem for tourists. Apple does need to keep improving Maps's general search savvy.

But I also experienced experienced problems with Google Maps in correctly locating Japanese businesses via English queries. Google frequently returned irrelevant, paid placement advertising spots in response to real queries for hotels or landmarks, without providing useful results.

Looking for problems that do actually exist

I looked up a series of local and international addresses in my Contacts (a mix of private homes, hotels, music venues and businesses) from Copenhagen to Berlin to Bern to Barcelona to Madrid to Milan to Lisbon to Prague to Seville to Tel Aviv to Vienna. Across the dozens of real international addresses I checked, Apple's new map service only failed to locate one of them in Copenhagen. Even when I manually located the spot, dropped a pin and copied the reported address into the search field, iOS 6 Maps refused to locate it for some reason.

In locating a friend's house about a hour south of Vienna in rural Austria, I noticed that when zooming down to the detailed street level with sattelite photos on, the aerial images shifted from color to black and white, but they were still detailed enough to clearly identify houses.

Comparing iOS 5 Maps, the same address had no satellite images at all below city detail. I could actually zoom through five levels of "no images" titles supplied by Google. So in some areas, Apple's satellite coverage is actually much better than Google's, just as Apple's Flyover is superior to Google Earth and Apple's directions are in some cases legal and safe while Google's are not.

The only U.S. addresses that I found to stump iOS 6 Maps (I tried dozens, from tiny rural towns to large cities and newly constructed suburban areas) were local ones here in San Francisco where I'd just entered cross streets: "8th and Folsom" didn't return any results in the new maps. When the search was changed to "8th & Folsom" iOS 6 Maps correctly pinpointed the intersection. However, "and" addresses that just supply cross street are also a problem for Google Maps.

Searching for "8th and Folsom" in the Google-powered Maps running on iOS 5 jumped me to "8 Folsom, PA," a two day journey of 2880 miles away from San Francisco, where the map was centered. That's not a phony address invented to make Maps "iLost." it's a real address that Google offers to find directions for me in obviously the wrong place.

Of course, I didn't start driving for two days. I simply corrected the query to "8th & Folsom" and iOS 5 Maps correctly found it via Google's maps servers, just like the new version of Maps powered by Apple's servers. Which is exactly what users in New York would do when searching for an incorrect, ambiguous street address that returned something other than the expected result.