#map apis

Revolutionize your Fuel Management with Lepton Maps Fuel API

Mapstraction is a library that provides a common API for various javascript mapping APIs to enable switching from one to another as smoothly as possible. Developers can code their applications once, and then easily switch mapping provider based on project needs, terms and conditions, and new functionality.

Chris wrote an article about "Perceived Flaws of OpenLayers", which did a decent job of discussing some of the things that are driving people away from OpenLayers as a general platform. I think he hit some of the better points and did a good job addressing them. There's more to say about the topic, though.

A few points:

The main comparisons should be made between OpenLayers, Polymaps, Modest Maps, and Leaflet. Unfortunately, neither Leaflet or Modest Maps entered the ring here, and I think that seriously hurts the power of the comparison, because Polymaps is operating on a different level from the others - it's derived from and built to be a drawing framework that draws maps, and expects smart users. That makes it awesome, but very different.

A side-point: I don't understand the continued inclusion of Mapstraction in comparisons of mapping frameworks. Like Polymaps, it operates on a different level, but in a place that's no longer relevant.

General architecture? I think the arguments that Chris is dealing with here aren't the ones users usually have. Here are a few other ones:

Where does control of the map come from? The baselayer? The map object? Both?

The resolutions system in OpenLayers is only useful for the five or ten users who know both projection math and need it. For everyone else, it's a cripplingly complex, confusingly implemented system that's irrelevant for the general task of 'putting maps on pages'. Want to configure zoom levels? There are at least three ways (hardcoded levels for commercial layers, serverResolutions/resolutions for TMS, resolutions for WMS, maxZoom (and, absurdly, no minZoom) for XYZ layers. Try to understand the documentation for setting resolutions... [4]

OpenLayers has its own events system: something that's decently necessary, since map interactions don't line up well with browser interactions. But, this introduces 'yet another API' which is different than the $.proxy and other apis in jQuery or anything else (or in pure Javascript) that people are used to.

OpenLayers has its own HTML/styling system, that's just built-out enough to be terribly limiting to anyone who wants controls to look nice, and uses anywhere from 40% to 60% hardcoded styles. 

Default look and feel:

"Panels are styled by CSS"? They might be, kind of... but, as of 2.9.1 (correct me if this is wrong by 2.11 or whatnot), some controls are still images, and not sprites, and not styled by CSS, but by hardcoded styles generated by the styling system - and positioned by that system, etc. Sure, I can do !important on every CSS style, but, should that be necessary?

Another thing with the theming system... OpenLayers tries to derive theme file locations from its location, which it derives from finding its own script tag in the head of the document. This is much like the resolutions system of OpenLayers - the API making complex guesses within itself which only make configuration less predictable. Case in point is correctly configured maps breaking when Javascript collection and compression is turned on because the location of OpenLayers.js moves.

See Leaflet's controls: they look nice. See Modest Maps's controls: there aren't any, because designers will make prettier ones.

Note that we created an OpenLayers theme [1], and you can use it. It's pretty enough. But, note a few things:

The configuration of the theme requires a line of straight-imperative code that sets a global variable. What if you want a different imgpath for different maps? Shouldn't this be a per-map setting?

We're only styling the controls that can look decent: notice that there is no styling for popup boxes. There's too much hardcoded for OpenLayers popups to ever look okay: ever. This is a serious problem with the styling framework.

The blah-looking theme that comes with OpenLayers is part of a systemic problem: an assumption that you already know the scope of the library and the parts that you can customize. Case in point is the non-antialiased often-down homepage map on OpenLayers.org. Most users will think this map *is* OpenLayers and turn back at that point. Swapping it out for even OpenStreetMap (not a looker by its own right) would change users minds quite a bit.

Other problems? Sure:

The growth of OpenLayers is addressed by code compression, not by changing the code, ever. This reminds me of Drupal's performance: all performance problems are addressed by caching. That means one thing: the performance problems and the size still exists. The problem is even crazier when the compression tools don't even accept OpenLayers as input online because it's too large. [6] Compression is not an answer, it's killing a symptom: the bloat of OpenLayers and its ever-more-complex API is the core problem that shows no signs of changing.

While Polymaps and Modest Maps are great drawing frameworks, OpenLayers is an abysmal one. Try to get individual tiles from a drawn map? No way. Interact with anything on the map like a DOM element? Nope. "Unbind" the map from the HTML element it "owns"?

A problem that all Javascript mapping frameworks have: imperative configuration. Pretty bad with OpenLayers. While a map with controls and layers is configuration, you need tons of imperative code and lots of new operators to do anything. It makes OpenLayers annoying to use with big sites.

While other mapping libraries allow for a nice amount of terseness, OpenLayers never lets you forget that you're dealing with OpenLayers.Layer.WMS, or that you're dealing with Java classical inheritance reimplemented in Javascript. Polymaps doesn't even use the new keyword [7], and at least most of the others let you use some chaining in common operations. New-style Javascript isn't there in OpenLayers.

Recommending GeoExt/MapQuery is a good idea for people building RIAs, but it's the opposite of that for most others. What people want (people, as in, me, and people building things on mapping frameworks) is a lower-level, simpler API, rather than a higher one.

The ability to make slim builds of OpenLayers (something we've also done, with openlayers_slim[5]) hasn't been trumpeted nearly to the level that it should have been. That would certainly help out with the 'perception' of OpenLayers. I've always hoped that the openlayers.org guys would just copy OpenLayerer [2], fix all of my terrible bugs in it, and do something about my patch [3].

The part where I'm not mean to OpenLayers:

It would be silly to claim that OpenLayers isn't successful. It's hugely successful. It's the granddaddy of all of the frameworks that came after it. Leaflet was inspired, and so was pretty much everything else. It does a lot of very hard things - making complex parts accessible and mixable on the same map. And it's got a ton of users.

The claim is never that "nobody uses OpenLayers" or that it can't do a certain thing. Everyone knows that it's huge in userbase and totally capable. The problem is that there are two kinds of users it is totally failing:

1. People who totally want maps

2. People who want to do cool things with maps

People who want WMS layers and don't care about prettiness: OpenLayers rocks. And I assume that there are millions of these people, and tons of very important applications that have exactly that spec. But that isn't all users, and it isn't vocal users anymore, or interesting users, or users who have blogs to write silly mapping API commentary (hi, I'm Tom).

[1]: http://support.mapbox.com/kb/mapping-101/openlayers-themes

[2]: http://openlayerer.appspot.com/ / https://github.com/tmcw/OpenLayerer

[3]: http://trac.osgeo.org/openlayers/ticket/2260

[4]: http://trac.osgeo.org/openlayers/wiki/SettingZoomLevels

[5]: https://github.com/developmentseed/openlayers_slim

[6]: http://blog.allanglen.com/2011/02/using-google-closure-compiler-with-openlayers - the API is limited to 1MB, which OpenLayers is over.

[7]: http://polymaps.org/docs/