OpenLayers Blog

All the maps that are fit to blog

Why are we building OpenLayers 3?

November 14th, 2012 by Eric Lemoine · 21 Comments

A recent blog post by OpenGeo provides one explanation of why the OpenLayers community is working towards OpenLayers 3. On behalf of the OpenLayers development team, we’d like to give a few more details.

OpenLayers 2.0 was released six years ago, and the library has been under continuous development since. It is solid, flexible, and easy to extend. The most recent OpenLayers 2 releases leverage some of the latest browser advances like touch events, CSS transitions, and offline caching. OpenLayers 2 is widely used and provides the features people need for their web mapping applications. Leaflet is another very popular library. Its first version (0.1) was released a year and a half ago. It provides an easy-to-use API, supports mobile and has leveraged CSS 3 from day one.

The point is that these libraries work well for people, and cover their current needs. So why are we doing OpenLayers 3? What are our motivations? Where does OpenLayers 3 fit exactly?

First of all, there are things that we don’t like about OpenLayers 2 — things we want to see fixed in the next major OpenLayers version. One example is the base layer/overlay dichotomy. It is often a challenge to know how and where to set resolutions, maxExtent, etc. for the map. Projection handling between map and layers and the interplay between projection and properties like maxExtent and center are complicated at best. Even power users may be confused at times.

So it’s no surprise that we want to fix these design and API flaws with OpenLayers 3. But we actually want a lot more than that. We’re looking at new functionality, new platforms, and new technologies. In particular, we’re targeting 3D, at least some form of 3D. For example, we’d like to support displaying terrain and building elevations with oblique views. That by no way means we’re forgetting about “simple” 2D use cases, nor are we dropping support for less capable browsers. OpenLayers 3 needs to be a high-performance, easy-to-use toolkit that works in as many browsers as possible, gracefully degrading when necessary.

WebGL is the emerging standard for 3D in the browser. So OpenLayers 3 will leverage WebGL from the very start of its development — it already does actually. We’ve started developing a map renderer abstraction, allowing different map renderer implementations. Currently there are two map renderers: a traditional DOM renderer and a WebGL renderer. A canvas 2D map renderer is planned. Taking advantage of WebGL we want to support very large vector layers, client-side re-projection of vector and raster data, 2D tilted/rotated views, and 3D terrain in local projections.

We also aim to integrate with virtual globes like Cesium. Implementing a virtual globe is currently out of OpenLayers 3′s scope, while providing useful integration with Cesium definitely is within scope. We believe that 2D and 3D worlds should converge, with seamless transitions between them.

It’s also possible that there will be integration points between OpenLayers 3 and Leaflet. For example, OpenLayers 3 packages could be built for reading and writing of vector formats, and these packages could be adapted as Leaflet plugins. It could even be that OpenLayers 3 packages would provide an OGC compatibility layer for Leaflet – providing OGC protocol or format support for people who already use Leaflet and want broader interoperability (or vice versa).

It may be obvious that OpenLayers 3 isn’t going to be a micro-framework. Instead, OpenLayers 3 will be a large collection of modules with automated tests and continuous integration ensuring that they always work well together. We think this brings huge benefits to application developers, particularly for the maintenance of long-lived, large-scale projects: being able to update a single, tested, integrated library is much easier than tracking several different plug-ins from different sources and having to deal with dependency management and integration problems manually.

OpenLayers 3 is based on the Closure Library, and we rely on the entire Closure tool suite. Our ambitions, in terms of both functionality and quality, require high-quality tools for code verification and optimization. Closure provides quite unique tools in this space. For example, the Closure Compiler produces extremely compact, high performance JavaScript through advanced optimizations like variable and property renaming, unused code removal, and function inlining. JSDoc-style annotations allow the compiler to do type checking, helping developers (us) to produce JavaScript code that has fewer bugs and is easier to extend and maintain. We plan to provide a hosted build tool that will enable people to easily create custom optimized profiles of the library for their application.

We hope this post makes it clear what we have in mind, and why we’re working towards OpenLayers 3 and making it very different from OpenLayers 2.

Tags: Future

21 responses so far ↓

  • 1 Tom MacWright // Nov 14, 2012 at 5:54 pm

    It’s been great hearing about the OpenLayers 3 work. As a historical critic of the project, the fresh start – both code-wise and the break in API compatibility – is great news.

    I’m skeptical of the 3D angle; it’s something that has been hotly contested by mapping giants but has no clear value to consumers, and there are simpler problems that still need solving.

    It’s disappointing that this states so clearly that OL3 has no plans to be a microframework. While I don’t think anyone is expecting it to be as simple as Modest Maps et al, the approach that the project has taken in the past to have deep interdependencies and an all-in style is more and more a ‘bad thing’.

    The individual parts of OpenLayers – its support of many formats, solid integration with complex services, and so on – are things that would be tremendously useful as near-zero-dependency blocks of code. If OpenLayers doesn’t make these parts usable by other projects, the wheel will be reinvented yet again, and likely with just the same battles against bugs and corner cases.

    Closure is certainly a nice toolkit, but it’s important to consider that it comes with a significant tradeoff: the rest of the Javascript world will lose a lot if there’s no way to use one part of OpenLayers without going all-in.

  • 2 Tim Schaub // Nov 14, 2012 at 6:32 pm

    Thanks for the feedback Tom. I’m very compelled by the idea of “tremendously useful … near-zero-dependency blocks of code.” This is why I added the bit about potential integration points with Leaflet in working with Eric on the post. Perhaps it didn’t come across clearly enough (and I acknowledge it’s not yet possible with the current OL3 lib), but I’ll say again that it’s a goal of mine at least to have parts of OL3 be reusable in many different contexts.

    A concrete example of this would be to have OpenLayers’ internal feature/geometry model be based strictly on GeoJSON. This would allow vector data readers/writers to work without the output/input needing to be instances from OL3 constructors.

    It’s also worth noting that while you may be skeptical of the “3D angle,” the feature set for OL3 is being driven by real “consumers.” I think it’s fair to say that the design ideas for OL3 are being informed by the collective experience of library developers working on the project for its lifespan and that the feature set is being informed by a very real collective of “consumers” or application developers. In any case, I believe that even the 3D skeptics should be able to use the library without being bothered by extra functionality that they don’t need.

  • 3 ThomasW // Nov 14, 2012 at 7:40 pm

    As we’re currently working on building some application around OL2, I must say the thing I’m most thrilled about is a clean restart which hopefully will result in an OL3, where it is no problem to have a layer stack, where all layers can be moved around like in a “real GIS” and where we don’t need to care any longer for baselayers stamping their nature on the map and other “misterious” behaviour :-)

    Simply great to hear about this and all the other plans!!!

  • 4 Vish // Nov 15, 2012 at 9:39 am

    Great to hear about the new work. Excited to see the results.

    I do share the same opinions as tmcw about having the individual pieces in ol3 like the vector readers/writers being reusable, which I get is already in the works.

    The closure thing should be great as long as ol3 comes with its own extern file. Users not using closure can always use the ol3 library minimized without the advanced flag.

    Would also love to see integration with the jsts topology suite if possible.

    Thank you,
    Vish

  • 5 Steven Wade // Nov 15, 2012 at 9:51 am

    Great to hear guys! OpenLayers is an AMAZING tool and I can’t wait to see what the future for it holds!

  • 6 Tom Payne // Nov 15, 2012 at 1:27 pm

    Just to correct a couple of things:

    1) ol3 is already designed so that you can re-use formats etc. in other applications. An example of this is all the data sources (see src/ol/source/*.js). These are completely decoupled from the ol3 presentation layer, and are explicitly designed to be reusable in other projects. Right now, we only have tile sources implemented, but the plan is to use the same approach for vector sources.

    2) Re Closure. If you use ol3, it’s entirely your choice whether you use Closure or not. You can use ol3 as a standalone library, just like any other. The API is the same, and you Closure is used to make the ol3 library as small as possible. You can pick and choose which components you want for a custom build. Or, if you want to use Closure for your application, then you can build your application with ol3 and you’ll get a perfectly optimized custom build for your application – the Closure Compiler will automatically specialize and optimize ol3 for your application.

  • 7 Vladimir Agafonkin // Nov 15, 2012 at 2:05 pm

    Great work guys, keep it up! I’m really happy to hear about your plans for closer Leaflet integration/collaboration and will be glad to help, so feel free to contact me.

    I was actually quite impressed with what you have achieved so far, after watching the demo by Tim and looking through the code. While we move in different directions, you do a really nice job and there’s definitely a great room for collaboration there.

    By the way, very nice to see Leaflet being mentioned on OpenLayers blog directly instead of referring to it as “some recent competition” — thanks. :)

    Cheers!
    Vladimir, Leaflet creator

  • 8 Imran // Nov 16, 2012 at 1:23 am

    Great to see you commenting here Vladimir. It is good to know that you anticipate some form of collaboration.

  • 9 OpenLayers o Leaflet - MappingGIS // Dec 5, 2012 at 4:04 am

    [...] Why are we building OpenLayers 3? [...]

  • 10 Ernst Knees // Dec 13, 2012 at 5:19 pm

    I would just like to counter the assertion that 3D has no clear value to the consumers. I have several large customers who are explicity asking (impatiently!) for 3D, terrain and virtual globe support in browser applications on a GeoServer/OGC compliant stack. This can’t come soon enough for them or us.

    For situation awareness applications integrating air and surface objects, this is a must.

  • 11 J. Husk // Jan 10, 2013 at 7:00 pm

    Looks great! Is there an approximate timeframe that OL3 will be available?

  • 12 Jahresrücklick (2) – GIS « PataGonia // Jan 13, 2013 at 12:54 pm

    [...] Version für Windows (siehe auch Postgis 64-Bit Version), pgRouting für Windows oder auch für OpenLayers 3 [wobei ich hier nicht nur auf OpenLayers 3 gespannt bin, sondern auch auf das versprochene T-Shirt [...]

  • 13 What’s new with JavaScript and geospatial – wrapup from the js.geo event « 懒得折腾 // Jan 24, 2013 at 11:30 am

    [...] various reasons that OpenLayers 3 was needed – you can see further discussion on its aims here. It’s important to be aware that OpenLayers 3 will not be compatible with OpenLayers 2, [...]

  • 14 The Look of Map APIs | GeoVisual // Jan 27, 2013 at 4:51 am

    [...] OpenLayers:因为是纯粹的API,而且是开源的,所以可以支持各种各样的地图服务,从ArcGIS到Google Maps等等,也可以自己写扩展。OpenLayers是FreeBSD许可,基本可以随便拿来用,天地图的API就是在这上面改的,所以自主知识产权之类的事情还是少谈点安全。OpenLayers发布的很早,大概有5、6年来,类库显得有点凌乱。而且功能上也有点跟不上时代节奏了,特别是HTML5的趋势。OpenLayers 3将是一个完全重构的新版本,很期待。我例子中调用的是OpenStreetMaps的服务,很简单。 [...]

  • 15 Jeremy D. // Feb 19, 2013 at 6:43 am

    To echo my predecessor: any updates?

  • 16 AgroTIC » En route vers OpenLayers 3 // Mar 22, 2013 at 1:15 pm

    [...] Plus d’informations disponibles sur la page du projet : http://openlayers.org/blog/2012/11/14/why-are-we-building-openlayers-3/ [...]

  • 17 Content Matters Interview: An Interview with David McClure of the Neatline Project | The Signal: Digital Preservation // Jun 3, 2013 at 10:53 am

    [...] approaches. For example, we’ve been really excited to watch the early stages of development on OpenLayers 3.0, which we’ll integrate into Neatline as soon as it gets to a stable [...]

  • 18 MapBox, Cesium, OpenLayers … tutto in 3D! | Cesare Gerbino GIS Blog // Jun 5, 2013 at 6:57 pm

    [...] tutto in 3D! 6 giugno 2013 cesaregerbino Lascia un commento Go to comments Già nell’annuncio di OpenLayers 3 era stata dichiarata l’integrazione con Cesium, una libreria Javascript per la creazione di [...]

  • 19 Carlos // Jul 8, 2013 at 11:19 am

    Tim, On the OL website it says:

    “The OpenLayers community will also integrate the new Cesium library to enable full 3D spinning globe capabilities directly into the 3.0 release.”

    You say:
    “We also aim to integrate with virtual globes like Cesium. Implementing a virtual globe is currently out of OpenLayers 3′s scope”

    I’m confused. Are we going to have a cesium globe or not?

  • 20 darethehair // Jul 21, 2013 at 10:32 am

    I echo the same curiosity as Carlos. I am waiting for OL 3.0 specifically for the ‘virtual globe’ feature, so its presence (or not) is very relevant to me.

  • 21 ahocevar // Jul 29, 2013 at 2:56 pm

    Cesium integration is out of the scope of the initial 3.0.0 release, but the architecture of the library allows for such integration. Tim’s statement just means that this is low priority at the moment.