Web Map API Standard

March 4, 2007

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.

About these ads

9 Responses to “Web Map API Standard”


  1. [...] this article at the geonames blog I found the ‘API Feature Requests’ [...]


  2. 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. :)

  3. Mikel Maron Says:

    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.


  4. [...] at Geonames points out that Google has a request for feature requests their mapping API. He supports the ‘Compatibility [...]

  5. Barry Hunter Says:

    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.

  6. marc Says:

    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.

  7. AdamD Says:

    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.

  8. marc Says:

    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.


  9. [...] this article at the geonames blog I found the ‘API Feature Requests’ [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 34 other followers

%d bloggers like this: