Some things OpenLayers Shouldn’t Do

One of the things that sets me apart from other OpenLayers users and contributors at times is the strong belief that it is not the responsibility of OpenLayers to be everything for everyone. I’ve often been faced with a situation where a user will say “Well, OpenLayers doesn’t have this functionality: doesn’t that mean it should?”

Just this morning, Eric made a similar argument: In response to my saying that OpenLayers is not for everyone, h responded if OpenLayers isn’t for everyone we gotta do something to change the situation, I think.

I completely disagree with this statement, and I think that anyone who thought about it would also disagree. There are some things OpenLayers is not meant to do, which other mapping tools are in a better position to do.

  • OpenLayers is not a 3D spinning globe — we will probably never have support for rendering 3D globes inside of OpenLayers itself.
  • OpenLayers is the ideal tool for browsing 3D panoramas: we are likely not the best tool for doing something like Google Streetview.
  • OpenLayers is not a full GIS application: We will likely never ship as part of OpenLayers itself a full UI for doing GIS editing against some server.
  • OpenLayers should not have as one of its primary goals creating user interface elements for complex functionality.

These choices might seem obvious, but I bring them up specifically because they are things that I have seen people state OpenLayers should do, and I think it’s important for any project to identify goals and seek to solve those goals.

There are also other things which are less obvious that I think OpenLayers is unlikely to do, which other mapping APIs have chosen to do.

  • OpenLayers should not abandon support for Internet Explorer: One of the moves I’ve seen recently is to create applications which abandon support for Internet Explorer, since supporting IE takes more effort than supporting other platforms. Although that is reasonable for many platforms, I think it would not be the right path for OpenLayers. Building a library which supports more platforms will have side effects: OpenLayers has IE support baked into some of its core functionality, like event handling, so it will always have some minimal impact on things like download size, and there are some things we may choose not to do because doing so would make supporting IE more difficult. Internet Explorer may be close to becoming a non-majority browser, but it’s still going to be very important to OpenLayers users for years to come.
  • OpenLayers should not remove support for commercial layers, even if supporting these types of layers requires a more complex architecture: Supporting commercial layers is one of the key components of OpenLayers, and I think that it is important to continue to support using commercial layers, even though this does, at times, make the OpenLayers code more complex. This problem is thankfully getting somewhat better with newer APIs from Bing and Google for direct tile access, but there exist other APIs out there that aren’t as advanced, and continuing to support the types of APIs we need to make that happen is something I feel is central to OpenLayers.
  • OpenLayers should not remove support for direct WMS access. One of the things that some other mapping APIs have chosen to do is to limit their target audience, and as a result, they do not worry about adding WMS access or other similar functionality for accessing data through means other than laying out X/Y/Z tiles on a map. Supporting WMS and other OGC web standards is something that takes some non-trivial portion of OpenLayers developer time. If we were to abandon anything other than support for OSM or XYZ style tiled layers and vector layers, we could certainly concentrate on a smaller API — but I don’t think that is something OpenLayers should do, even if it would mean a better overall API.
  • OpenLayers should not remove support for fetching via various protocols, parsing via various formats, and choosing what to do with that data via various strategies: I have seen an argument that the more recent work with formats, strategies, and protocols is confusing to users, and should simply be removed in favor of letting that be handled at the application level. Most of the APIs OpenLayers is being compared to do not have this kind of support. This is another thing I strongly disagree with.
  • OpenLayers should not remove support for dealing with data in projections other than Spherical Mercator. Many other libraries simplify user experience by picking and sticking with a single projection; I think that is impractical for OpenLayers.

Now, I think it is completely true that it would be possible to rip out 80% of the functionality of OpenLayers, create a smaller, easier to maintain library, and hit a use case that could solve interesting problems. I will agree that OpenLayers is a large codebase — after all, we have more than 200 *thousand* lines of code, compared to just under 20,000 in Polymaps, 60,000 in Mapstraction, 9,000 in Leaflet. This is the ‘big daddy’ of mapping frameworks — no one is denying that — and it has a lot of technical debt built up the same way any Open Source project has happen over 6 years of development without a rewrite.

Some of that code is cruft, and should be removed. No one is denying that. In fact, there’s a fair amount of already-deprecated code; controls that have been deprecated or non-default for more than 4 years are still part of the main OpenLayers trunk release. However, I’d put the amount that is cruft at closer to 20% than 80%: the much bigger portion of the OpenLayers code is the broad support for the many different ways of interacting with remote data. In our formats alone — things which are generally designed to do only one thing, read and write from an external string to an OpenLayers resource — we have 69 files with 20,000 lines of code. That’s right, our format parsing — for everything from OSM to GeoJSON, GeoRSS to ArcXML to CQL to KML — is larger than several other entire mapping libraries.

Eric followed up by pointing out that of course he didn’t mean to suggest OpenLayers shouldn’t do everything, but that OpenLayers should have an easier API to hit simple use cases — something which is better documented, easier to use, and less confusing to users. I find it a bit amusing that this is an argument someone feels they need to make to *me*, since I feel like I’ve been pushing that argument for years now within the project. :) However, since it may not have been clear, let me clarify:

The OpenLayers API is difficult to get started with for many simple problems. It can be hard to use, confusing to start, and difficult to understand for solving simple problems. It pushes details that very few users care about in the face of users who don’t know what to do with them. It is crucially important to supporting the future use of the project to make the easy things easy, while maintaining the ability to make the hard things possible.

Some areas where this is most apparent: difficulty in working with projected coordinates for the purposes of interacting with OSM or other spherical mercator layers. Difficulty in setting up a simple request to download a file from a server and render it — even *I* can’t configure that from memory, and I’ve done it dozens of times. These are real problems that users run into all the time and simplifying them would be a huge step forward in usability for solving the simple problems. (Note that I’m saying this in a blog post rather than in code, which also shows that I don’t think this is a trivial problem: the reason these things are not done is in part because coming up with a solid way to do these things in a helpful way is not trivial.)

I just want to clarify that there will always be some things OpenLayers shouldn’t do. Some of the decisions we’ve made have increased our overall technical debt: Maintaining support for IE, even for relatively advanced features like rotated client-side graphics in VML, was a cost that we could have saved if we chose a narrower supported platform range. However, I think that some of these decisions are important: a key component of OpenLayers is its broad support for loading data of any kind, in a wide variety of browsers. That was the core idea when OpenLayers was started, and I think that it is an extremely important to maintain part of our legacy.

Some of the competing mapping frameworks target a narrower use case. As a result, they can concentrate their developer time on better examples and documentation for a subset of functionality that OpenLayers has. This is great for the users of those tools, and will likely make those tools more attractive, short term, to some users. Competition is good: it encourages innovation, and pushes the limits, especially when the competition is open source and can collaborate across teams. If another tool is better for users than OpenLayers, it is in their best interest to use it. In the end, I hope that OpenLayers can continue to expand the set of users for which it is the best tool, and there is a lot of work that can be done there — and I look forward to continuing to see competition and collaboration between the various mapping projects out there to maximize user success.

10 Responses to “Some things OpenLayers Shouldn’t Do”

  1. Paul Spencer Says:

    I agree wholeheartedly with your assessment of “should do” and “should not do”. OpenLayers plays a very significant role in the web mapping ecosystem and is the go-to library for many developers and organizations, but that doesn’t mean that it needs to be everything to everyone. It is very important for a project to understand its scope and limit itself to that scope in order to actually achieve its goals.

    Other web map libraries are important parts of the ecosystem too, and application developers who work with web maps should have a couple of them in their toolkit because each one provides distinct advantages for any given solution. Always relying on OpenLayers to provide a solution to every problem will only lead to frustration.

    Something that occurred to me reading this post was that the format reading/writing parts of the library could perhaps benefit from being pulled out and published as a separate library and used in much the same way that OpenLayers uses Proj4js to handle projection support outside of the built in projections. The format capability is very extensive, well architected and could easily live its own life as a separate library. Of course, doing this would also incur a “technical debt” - since its possible to exclude any unneeded components through the build system, time might be better spent elsewhere in the code base.

  2. Tom MacWright Says:

    Pretty much agreed here: it’s very useful for OpenLayers to be very broad in support but not do things obviously outside the reach of itself, or even current Javascript engines.

    I agree with Paul about splitting out some of the format implementations. I’ve often found that the OL implementation was basically ‘the implementation’ that was easy to port to other things, and in that way that part of the library has been extremely useful. If this stuff were nicely separated out and available to other libraries and to server-side stuff that’d be wonderful.

    The point about spherical mercator is also valid, but there are things that OpenLayers misses - straightforward configuration of zoom levels, reasonable defaults projection defaults, better feedback when it’s asked to do things it couldn’t do (like reproject raster data).

  3. John Cowan Says:

    The majority view seems to be that IE ceased to be the majority browser worldwide sometime in the fall of 2010. (Chrome is the majority browser in Albania: who knew?)

    However, keeping support for IE does not necessarily mean keeping support for IE6 and earlier. China is a hotspot with 33.9% share, with South Korea in the twenties and India and Vietnam in the teens, but everywhere else in the world IE6’s share is less than 10%, and only 2.3% in the U.S. So if there’s a lot to be saved by ripping out some of that support, it should perhaps be on the horizon if not yet scheduled.

  4. Eric Lemoine Says:

    About pulling out the formats: I would fear incompatibility issues. Right now OpenLayers has no dependency and that makes things easier to manage. But having the formats work in other environments, e.g. in node.js, would indeed be a good thing. As Tom mentioned it, we’re not too far from that.

  5. crschmidt Says:

    I think that we stopped looking seriously at IE6-only bugs as showstoppers a while back. Most of our work is in getting things to work on IE7 (which is still important to a lot of users) — I think a lot of our IE technical debt ends up being just in maintaining VML as well as SVG, which we don’t get to stop doing until IE9 is everywhere.

  6. crschmidt Says:

    Certainly I’ve put some time into using the formats in other environments. I wouldn’t be totally against working to make it easier for other people to use those components of OpenLayers, so long as it doesn’t tie us to someone else’s whims for what should be ‘required’ to use the code :)

  7. Patrick Hayes Says:

    I certainly agree with the idea of trying to spin off as many stand-alone component pieces as possible into other stand alone projects. I can imagine lots of other projects that would appreciate these libraries. For example, I can imagine doing a mapping app in node.js could make great use of it.

    The converse is also true - OL has built a lot of it’s own infrastructure for events, renderings, and I/O (ajax and the like). Perhaps moving to jQuery for the event system and the I/O, and moving to jQuery UI for all the display stuff could shrink the core OL codebase.

    I’d also be curious to see if OL could make use Raphael (http://raphaeljs.com)

  8. crschmidt Says:

    Patrick: While I’m in support of doing things that create a better overall Open Source environment, it is worth keeping in mind that splitting out the OpenLayers format, geometry, etc. code is a pretty big project — after all, formats are nearly 1/3rd of our actual library code, more if you include the geometries they depend on. Additionally, the OpenLayers project would likely get almost no benefit from it even on the timescale of years.

    I think an excellent example of this is libgeotiff. GDAL uses libgeotiff. Other people do as well. It’s an external library. However, it is maintained almost entirely by the GDAL project, and it is included in the GDAL source tree directly to save people the difficulty of having to treat it as an external library; there is almost no gain to the GDAL project for having libgeotiff be a separate library, despite the fact that that’s been the case for more than a decade.

    So, splitting out our component pieces is a fine ideal; it’s just one that has to be balanced with the goals of the OpenLayers project, and it doesn’t seem to be a net win at this point for OpenLayers, which makes it hard to make a serious start on.

    As far as moving to jQuery events: Keep in mind that OpenLayers has specifically moved *away* from tying itself to a given library, because no matter which one you pick, some people will not want to use that library. (Telling the GeoExt users that in order to use OpenLayers they now have to include Ext *and* jQuery would probably not go over well!) However, building ‘adapters’ — that is, components of OpenLayers which replace this functionality with links to existing libraries — and then having OL maintain its own library with the approrpiate adapter, is something we have considered and discussed, and would be in support of. This would let you take advantage of saving space on whichever components are duplicated in your particular Javascript library, without tying the project to just one.

    Raphael is very strongly tied to DOM interactions. Especially with our move towards better support of Android, Canvas is becoming an increasingly important component of our vector rendering strategy. I do not think Raphael has anything in particular to offer OpenLayers at this point because of that difference in rendering approaches. (Though I definitely wish Raphael had been around when we started the vector work — it probably would have saved a lot of time!)

  9. Matt Priour Says:

    I absolutely agree that THE strength of OpenLayers is the Formats and Protocols support along with the VAST support for nearly any kind of mapdata layer. The layer type support is truly mind blowing. Look at the range of data supported:
    - simple single georefenced image
    - full blown WMS
    - CSV
    - KML
    - full blown transactional WFS
    - Senor Observation Service
    - WKT
    - GeoRSS (in all of its variants!)
    - And many more

    I’ve got projects I worked on that solved hard user-interaction with geospatial data problems for 4-5 years ago, that I still could not think of how to possibly solve with any other mapping library.

    I also agree that the simple things should be simpler. Also out-dated, fully deprecated layers/controls/etc should be clearly and blatantly marked in the API and the examples.

    I look forward to helping build the external library adapters for OpenLayers 3. That way, if people want to use jQuery events or YUI or ExtJS or some specialized vector drawing library then they can do so much more easily. But, OpenLayers still maintains all its ability to stand on its own and to handle the hard problems along with the simple ones.

  10. Imran Says:

    OL has come so far..it will not be nice if its not flexible enough to integrate awsome frameworks such as Raphael JS ..

Leave a Reply