I spent last week in Boston, attending an annual code sprint for C-based open source geospatial projects.  I’ve been doing this every year since 2008.  Since getting back, I’ve had to explain the event to several people, technical and non-technical, since the concept isn’t obvious at all.

Open source development of characterized by some features that differ a great deal from traditional work environments:

• the developers work asynchronously, often in different time zones, usually in different locations,
• the developers coordinate exclusively using text tools, like e-mail, issue tracking systems, and sometimes instant messaging

Because there is no need to be in the same space with other developers, either physically or even temporally, the barriers to entry to a project are lowered. More people can participate than otherwise.

However, there are disadvantages to working asynchronously and with text communications.

• asking for help when you get stuck can be time consuming, because your colleagues might be asleep at the moment when help would be most useful
• issues of subtlety or complexity take a great deal of text to describe, and any misunderstandings on the part of a reader take even more text to correct
• discussion of emotional issues can lead to conflict due to the limited emotional nuance in text communication

A code sprint is a chance to work for a time with your open source colleagues “the old fashioned way”, face to face, on the same clock.

Because everyone is together, and communications are high-bandwidth and high-fidelity, a code sprint is a great time for:

• planning and designing large scale changes to the code
• designing new APIs or new user interfaces, and
• triaging ticket lists to prepare for release

I usually spend the first half of a sprint on communication-heavy tasks like the ones above. The second half I usually spend heads down on a hard piece of code.

If the right experts are around, code sprints are an excellent time to attack a new piece of code you don’t quite understand. Learning how a module works from the expert who wrote it is far faster than doing it alone at home.

And finally, having lunch and dinner and socializing usually provide the social space for unexpected topics to slip out and get a discussion, whether they be uncomfortable issues like dealing with a difficult team member or just a crazy feature idea that turns out to be not so crazy at all when discussed with the group.

If you have a chance to participate in a code sprint on a project you contribute to, don’t pass it up!

Often during sprints the developers at OpenGeo team up with other organizations, other times we stick a few of our folks together in a dark, dank basement and put our noses to the grindstone. Regardless, someone always has to travel, but this time it wasn’t me! Early this month my colleagues Matt Priour, Ivan Willig, and Rob Marianski came to Fort Collins (my home town) for a weeklong GeoNode sprint. Marc Pfister, who took a break from his regular dairy routine, also joined us. It was fun for me to take a break from traveling and play host for the week. Best of all, we made a good deal of progress on GeoNode development.

We hit the ground running at my regular co-working space and began by assessing what we aimed to accomplish for the week. By mid-week, after setting priorities and beginning work, Fort Collins was hit by a surprisingly heavy storm (it’s been rather dry lately). This storm gave us a cool double rainbow (see below) but also flooded the electrical system in the office! We relocated to my house where I really got to play host.

We completed much of the following efforts for the GeoNode development branch:

• Use staticfiles tags everywhere to enable far-future expires for web resources
• Extract and refactor search functionality developed in http://mapstory.org and add unit tests that teased out some errors
• Extract and organize JavaScript embedded in templates and use require.js to simplify templates and deal with requirements in a sane way

We’ll be finishing these efforts and merging them into the development branch soon. Thanks again to Ivan, Matt, Rob and Marc for coming to Colorado!

Last 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.

Back in January we discussed how eager we were to sponsor the GeoExt 2 code sprint and hoped that others would join the cause. Thanks to the generous support of Camptocamp, Mapgears, Terrestris and OpenGeo, we had a productive week at Terrestris’ office in Bonn, Germany.  Twelve developers from the sponsoring organizations were joined locally by developers from OccamLabs and remotely by representatives from m-click.

Together they tackled a well-known problem: GeoExt 1.1 is based on Ext JS 3 and thus not compatible with Ext JS 4. The aim was to port as much functionality from GeoExt 1 to GeoExt 2 and make it compatible with Ext JS 4. The result? GeoExt 2 code that’s ready for an alpha release.

OpenGeo is proud to have contributed to GeoExt 2 and encourage you to try it out. As the sprinters work to tie up loose ends and create the official alpha release, we need help testing and reporting bugs. Code contributions and bug fix pull requests on github are always welcome.

For more details on the GeoExt 2 sprint check out the GeoExt blog. Thanks again to all the sponsors of the code sprint!