My wife and I just bought a new home on Pine Street in lovely Boulder, CO. It is a recently remodeled 1921 Craftsman in an old historic district called Mapleton Hill. It may be on one of the nicest residential streets in Boulder, but it has one glaring problem: the major online mapping services don’t know where it is! In fact, eight entire blocks of Pine Street in Boulder, Colorado do not map correctly on Google Maps, MapQuest or Yahoo Maps. (I’ve shown them accurately here using intersections, rather than street addresses, in order to illustrate the blocks in question.) I know that Boulder is very protective of their historic districts, but keeping eight blocks off the internet is ridiculous!
OK, so the problem does not lie with the city of Boulder. It is actually a problem with the back-end data provider to all of these services: NAVTEQ. Now, to be fair, the major map sites bear some responsibility because they default to taking the user right to the location they deem most relevant, based on relevancy scores returned when they query the NAVTEQ data. Microsoft’s MapPoint actually lets me choose between two possible addresses, while Zillow.com gets it right the first time, presumably because it is using additional real-estate transaction data to determine that my address is probably the most-relevant one for the query. But the fundamental problem lies with the underlying data provided by NAVTEQ.
About 14 miles away up a windy mountain road (about a 37 minute drive) there is another Pine Street, presumably still within Boulder County, though not in Boulder proper. Mapping any address from 400 Pine Street to 1299 Pine Street will bring the user to this remote (and sparsely populated) road. Starting at 1300 Pine Street, the mapping services will take the user to the “correct” place. Certainly the discontinuity between 1299 Pine Street and 1300 Pine Street is a bit odd, as is the fact that the mapping sites actually show that there are one thousand valid addresses on a remote stretch of road in the foothills. Though I haven’t been there myself, I seriously doubt that there are a series of monster apartment buildings up there. To summarize, eight blocks of Pine Street in downtown Boulder, starting at the 400 block and ending with the 1200 block, all map to this doppelgänger Pine Street outside of town, but starting with the 1300 block, the mapping sites take the user to the place the average user might reasonably expect.
There might be a handful of people who live on this other Pine Street, but there’s eight blocks worth of residents who live in Boulder whose homes cannot be properly mapped with the dominant mapping services online. While fixing the problem might negatively impact the few who live on this alternate Pine Street, far more people would benefit if this problem were to be corrected in favor of the eight in-town blocks of Pine Street.
And before you think that I am complaining about an insignificant problem free of anything but cyber consequences, consider the fact that the previous owners’ moving truck arrived at the wrong location because of faulty geo-data and wound up appearing two hours late. Or that Comcast never showed up to install high speed internet during their generous four-hour appointment window last week because their truck rolled to the wrong place. And I’m sure I’ve got many botched furniture deliveries and missed meetings with tradespeople in my future because of this issue. Hopefully the fire department and the police aren’t relying on NAVTEQ’s data.
The helpful folks at deCarta (a Mobius portfolio company which powers Google Maps, among others) explained that the problem is with the backend data from NAVTEQ. They do provide a form for victims of bad data to submit corrections, but the NAVTEQ site makes no guarantees it will correct the problem, and even if they do, it can take six to nine months, though the folks at deCarta tell me eighteen months is a more realistic timeframe. I’m hoping that complaining publicly to the world at large about this problem will spur NAVTEQ into action sooner rather than later.