That will display a map, but it won't display the local business listings which is part and parcel of Google's Knowledge-Graph driven maps listings. Also, the <IFRAME> will add non-trivial amounts of latency to the page display.

When you type in something that generates a map these days, you get Knowledge Graph entries, Maps, Related places and people, and a bunch of other ancillary things. How can Google simultaneously iterate and evolve their search, and at the same time, provided a fixed API for federating this stuff?

This is one of those things that works much better in theory than in practice. I'd rather Google federate social and login before messing with search answers.

Sure, but you're assuming that I want Google-like results. I don't. I don't really want Knowledge Graph-driven business listings. I just want a map which shows roads in different colours rather than all-white (and a host of other cartographic howlers) which Google doesn't currently offer me.

But hearing "our way or the highway" coming from a Googler is making the argument for me to try DDG again, so thanks. :)

First, I don't work on Search, I work on open-source stuff, and this is just my private opinion.

Secondly, I am for the idea in theory, I just don't think it is practical to do in a way that adds a lot of value. You also have to worry about the legal/privacy ramifications of funneling everyone's queries out to third party providers, I'm pretty sure that would cause a large blowup.

Third, there were already services that sort of did what you ask, for example, MetaCrawler, which was around way before DDG, would federate out queries to multiple search engines and combine the results. It wasn't very pretty.

I'm not sure IFRAMEd results really add that much value for a user, but one could easily conduct the experiment by making a Chrome/Firefox extension that replaces Google Maps results with OpenMaps.

In an ideal world, one wouldn't need fleets of cars and people to make maps databases. There's be some kind of standard, like http://acme.org/geo.json or maybe KML where crawlers would crawl the web to get accurate business listings, indoor maps, photos, menus, hours of operation, and other stuff. And then anyone could write a little bit of JS that could be registered with the browser like <link rel="geopanel" href="geopanel-fancy.js" type="application/business-data">, and when Google or Bing when to show a business listing, they'd just need to output the json record, and any registered providers could render it.

I'd be all in favor of a fully federated world, I'd spoken about it at length in the past (http://timepedia.blogspot.com/2008/05/decentralizing-web.htm...)

But I think one has to be realistic that the the fully open, federated solutions often do not compete favorably with vertically integrated solutions from a user experience point of view. They often can only do so once the underlying features have been fully commoditized.

> But hearing "our way or the highway" coming from a Googler is making the argument for me to try DDG again, so thanks. :)

So yeah, trolling then.

The problem with the iframe approach is that Google's geocoding service TOS explicitly states that the output of the geocode operation can only be displayed on a Google map.

Google's geocoding service is underpinned by a lot of third party datasets which would have to be (very expensively) relicensed if Google started passing the results out to maps under the control of other organisations.