Yet Another Mapping API
Just read James‘ post on the ESRI JavaScript API, so I decided to take a look. Here’s what I think:
Wow, pretty slick. No kidding. They provide you with a multitude of approaches (SOAP, REST, etc.), AND they are supporting the OGC OpenLS specification — way to go ESRI on this one!
Having said this, as a developer, I now have yet another mapping API to deal with. With Google, Yahoo, ESRI (I’m sure I’m missing a few here) all publishing very slick APIs on displaying maps, a developer has to create custom handlers for each of these APIs if they want an integration application from multiple sources. What happens if an API goes defunct, or evolves with drastic changes? This can result in some major code upgrades on the client side.
What would be really nice is if each of these services additionally provided a standards-based interface (OGC:WMS for maps, OGC:WFS for features, OGC:WMC for bookmarking maps). Then, a unified standards-based toolkit (like mapbuilder) can be rapidly deployed. With each new standards-based service published by providers, this would simply be another binding to feed the application, instead of writing another custom handler for a particular API.
Am I just an interoperability zealot? I’d be interested in hearing what others in the community think. It seems to me that we’re moving backwards here. If there is functionality in these APIs which are above and beyond OGC specifications, then let’s at least have some defacto agreement on them and save everyone alot of coding.
