BoundlessLogoWhite

Stay Connected with the Boundless Blog

Visions for OpenLayers 3, a Geospatial Data Software

OpenLayersLast week, a group of OpenLayers developers gathered in Chambéry, France to lay the groundwork for a new major version of OpenLayers. This was an ambitious undertaking – OpenLayers provides a huge range of functionality, is deployed very widely, and has a long track record of well-tested, backwards compatible releases. Throughout the OpenLayers 2.x history, we’ve learned a lot from how people are building browser based mapping applications, and browser capabilities have evolved radically. Our goals for this week were to make use of those lessons learned while leveraging new and upcoming tech.

Convenient API

Because we’re allowing backwards incompatible changes with OpenLayers 3, we took some time to design a consistent, convenient API.

Whereas before you might have used the following syntax:

var map = new OpenLayers.Map({ 
    div: "map", 
    layers: [new OpenLayers.Layer.OSM()], 
    center: [-12245144, 5621521], 
    zoom: 4 
}); 

In OpenLayers 3, this will look like the following:

var map = ol.map({
    renderTo: "map",
    layers: [ol.layer.osm()],
    center: [-110, 45], 
    zoom: 4
});

The obvious difference is the use of short factory names (ol.map) instead of longer constructors (new OpenLayers.Map). This sort of change adds convenience, but could be done in a wrapper of the 2.x API without breaking backwards compatibility. The more significant (and backwards incompatible) change is in the handling of the map center.

Previously, an OpenLayers map defaulted to geographic coordinates and sort of allowed users to override defaults by providing a base layer in another projection. This lead to difficulties when you wanted to change one setting and didn’t know what other defaults were coupled (projection, maxResolution, maxExtent, units, etc.).

In OpenLayers 3, the map displays in Spherical Mercator by default and the user provides and receives geographic coordinates. This “user projection” is configurable, and you can provide other configuration settings with predictable results (no more coupled defaults).

In addition to the handy factories, the new API exposes chainable getter/setter combo methods (as in jQuery). The whole API is clearly separated (in the source JavaScript and tests) from the internal interface. During the sprint, we affectionately referred to the public API as the Hipster Programming Interface (HPI – pronounced hippie). See the API test spec for more details on how it works.

Renderers Galore

One very slick aspect of OpenLayers 2.x is the flexible rendering of vector layers. Depending on your browser environment, vector data may be rendered using SVG, Canvas, or VML without you having to choose. In OpenLayers 3, we’ve extended this flexible rendering to the whole map – vector data, raster data, overlay controls, popups, and more will all be rendered differently depending on the capabilities of your browser (or other execution environment).

Where WebGL is available (via the Canvas element’s 3D context), all map layers and data can be rendered in a way that takes advantage of hardware acceleration, and access to the map’s camera object can provide oblique perspectives. Where WebGL is not available, the same layer configuration will be rendered with a composite layer renderer using image mosaics, SVG, Canvas, or VML as appropriate.

Completely separating out the renderers broadens the possibilites for using OpenLayers in other contexts. A PDF renderer, for example, could be written to render a map on the server (e.g. with Node JS or Rhino) – providing a simple print server using the same map configuration and same layer code to fetch the tiles and vector data.

Let’s Get Small

OpenLayers 3 is being written in a way that best leverages the advanced compilation capabilities of Closure Compiler. In addition to resulting in smaller hosted profiles of the API, this will allow us to provide a service for users to build custom profiles with just what they need from the library. Users of this service should be able to check items in a form specifying what they want (no Internet Explorer, just tiled layers, mobile webkit only, etc.) or alternatively to upload their application code and let the compiler strip out everything from the library that is not accessed. As of this writing, a build of the library that includes a navigation and zoom control and displays WMS, OSM, and other XYZ type layers weighs in at 14K (gzipped).

What’s Next?

We’re excited about the upcoming OpenLayers 2.12 release, and can anticipate a number of additional releases in the 2.x series. In the meantime, we’ll be continuing to port functionality from the 2.x library to the new 3.x style – working to refine the design and make sure the architecture is solid. When OpenLayers 3 is ready for primetime really depends on the resources put toward it. Please get in touch or dive into the source if you’re interested in contributing to the effort.