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.
But hearing "our way or the highway" coming from a Googler is making the argument for me to try DDG again, so thanks. :)
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.
So yeah, trolling then.
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.
At best, you could stick an <IFRAME> in the page and point it at a user configured maps site, only you don't know if it is going to return a maps result. What if the query isn't for a location? Or what if the user's third party map supplier doesn't have the location? Then you get a big empty <IFRAME> with nothing in it, and a bad user experience. You'd also increase the perception that the Google search results are slow because it would take longer for the page to finish loading.
Allowing pluggable providers on the client for launching URL intents makes sense, I don't think it makes as much sense for search engines to federate queries in this way, there are much more difficult performance and privacy issues with such a model.
The Portal/Portlet model of "search" has been tried before and users didn't really like the experience.