Eight Blocks of Boulder, CO are Missing!

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.

Technorati Tags: , , ,

  • Great analysis! You’ve solved the mystery around why none of the Pine St. home sales show up in my Boulder Deed transactions map (http://valeski.org/BoulderDeeds.html ; yeah yeah… poor-man’s Zillow (we’re solving two different problems in reality though, and I came out a few months before they did anyway)). Sure enough, they all show up on the “wrong” Pine St. way up in the mountains.
    I was at the Where 2.0 conference in San Jose, CA last week, and the topic of bad map data came up a few times. Once in this panel discussion led by Tim O’Reilly, in which deCarta was represented (http://conferences.oreillynet.com/cs/where2006/view/e_sess/9355 ) (slides: http://conferences.oreillynet.com/presentations/where2006/fennell_kim.ppt ). Tim asked the panel when the feedback loop would get more interesting (as you point out, 9-18 months is pretty standard, and sad, right now); everyone kinda looked down at the floor and only one guy responded with “we have a link on our website to report bad data.” It’ll be interesting to see how “OpenStreetMap” evolves; perhaps it can take on the big guys and provide better data: http://wiki.openstreetmap.org/index.php/Main_Page
    As an aside, I heard an interesting datapoint recently that NAVTEQ derives approx 5% (five-percent) of it’s annual revenue from its mapping website backend data contracts (e.g. MapQuest and Google (among several others)). That’s an incredibly small number for what we, as consumers, view as the front-end to NAVTEQ. Apparently the vast majority of their dollars come from in-vehicle NAV systems; something like a few hundred dollars per vehicle system sold (auto-manufacturers pay this; then mark it up for consumers), and $50-$100 per annual upgrade (which no-one actually does, statistically speaking).
    As for Zillow accuracy, they actually overlay municipality-level planning department polygons which are rooted in lat/lng coords. So, they overlay city block grids which skips over the problem you’re seeing (presumably in conjunction with your thought around real-estate transaction relevancy).
    Welcome to Boulder!

  • I have a similar issue in Boulder. We recently bought a home in North Boulder in Dakota Ridge on a new street which does not appear in most mapping programs. We live on Granite Ave, but it turns our there is a Granite Dr up in sunshine canyon somewhere and our address always gets auto corrected to Granite Drive. We have had the issues with people getting to our house but we also have had issues with companies billing us to the wrong address. Even xcel doesnt know where our house is and there billing system refuses to accept Granite Ave as a valid billing address.

  • Does zip code work to dismbiguate?
    Perhaps there are a large number of commercial deliveries up that mountain road. (Have you discovered a secret military base? 🙂 So, for some high-paying set of NAVTEQ customers, it may make sense to prefer the ‘other’ Pine. Or maybe not, just a theory.

  • I founded and was the CTO of a public safety company here in Colorado. Our customers called us all the time to complain about bad address sections in their city, similar to what you’re experiencing. We used multiple data suppliers in our dispatch system, including NAVTEQ.
    You talked about delivery trucks not finding you. In Boulder county (and 500+ other cities), the EMS operator uses the system we developed. Do yourself a favor and call the public safety dispatch office and ask if you can make a test call to 911 to validate that your location is correctly geocoded. They’re often pretty bored in Boulder usually (unless there is a “dog in street” call going on), so they may have no problem with this. 😉
    You just don’t want an ambulance or policeman going to the wrote place one day when it really matters. These systems are pretty automated, and a bad geocode can be disastrous in the wrong situation. Worth checking out.