Google is asking for feature requests for the Google Maps API. One request is for ‘Compatibility with other map APIs‘.
Following the lead of Google several other vendors are now also offering web map APIs. All these javascript based APIs have similar features but are unfortunately incompatible with each other. A switch from one vendor to the other requires rewriting most of the mapping code in your application. There are open source projects like mapstraction or myMap that try to solve this problem with adding an additional layer on top of Google, Yahoo and Microsoft.
Wouldn’t it be better if the map API vendors (Google, Microsoft, Yahoo, Mapquest and even the open source API openlayers) could directly agree on a common API? With a common API you could switch from one map vendor to the other by simply changing a single javascript import statement.
You are investing a lot of time in writing code for the Google Maps API and your application depends on it, what are you going to do if Google changes the licence and you are no longer able to use it? If you want to support the request for compatibility between mapping APIs put your name in the requested by field.
GeoNames Blog 
[…] this article at the geonames blog I found the ‘API Feature Requests’ […]
I disagree. If a mapping API vendor is required to (or tries to) stay within an agreed upon ‘standard’ API, then that could stifle features/innovation. They would have to all agree on a standard to, say, add polygonal overlays, or moving objects (e.g. tracking realtime position of other vehicles)
However, when this ‘abstraction of API’ is relegated to other projects (as you point out Mapstraction, OpenLayers, and MyMap do this, they don’t just attempt it) then each of them can decide if they are a minimal set implementation (only allow what all allow), or a maximum set, or somewhere in between.
What is better if they just support mapping using data format standards. They should all consume open/non-partisan standards such as GPX, GeoRSS, GML, etc. That way someone doesn’t necessarily need to know the entire API if they can just load and map their common data source.
Is there a way to vote for the anti-request. 🙂
You have a good point Andrew but I don’t think they mapping apis would ever stop trying to innovate. If they can agree on a common minimal set, that would accomplish a lot .. hey maybe even mapstraction calls could be supported natively 🙂
For good measure, I added a feature request for GeoRSS support to that Gmaps-api group.
[…] at Geonames points out that Google has a request for feature requests their mapping API. He supports the ‘Compatibility […]
For what its worth I agree with Andrew, if the API vendors tried to work to an agreed standard, it would stifle innovation and stagnate development. Even having an agreed minimal feature set, could be quite restrictive in that would be it harder/messy to add unique features.
Innovation is certainly a valid point, but a standard does not mean vendors are not allowed to offer more features than the standard specifies. Relational databases comply more or less with the SQL standard and this does not prevent some databases to add geospatial features not yet covered in basic SQL and it does not prevent the OGC to specify additional GIS options for SQL.
According to the 80/20 rule it should be possible to cover 80% of the use cases and applications with only 20% of the API.
The google Map API has come a surprisingly long way in an amazingly short time and I believe web mapping is now ready for prime time. Prime time also means that the API has to be stable and basic functionality cannot be changed in order to add an exotic feature only 0.001% of users are interested in. Innovation not only happens on the vendor side, innovation happens also or even more so on the application side using the API.
Goog has the lead, so I think it’s up to non-Goog mapping platforms to support the Google standard. I realize that means API calls like GMap, but that’s the price of not being the leader.
We could all pretend G stands for Graphical.
G stands for Geospatial, what else?
If Google allows the other vendors to use what you call the google standard, this is fine with me. But we have to ask Google to allow this, otherwise any other vendor using this namespace will risk running into legal problems.
[…] this article at the geonames blog I found the ‘API Feature Requests’ […]