OpenLayers Blog

All the maps that are fit to blog

Why are we building OpenLayers 3?

November 14th, 2012 by Eric Lemoine · 8 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.

→ 8 CommentsTags: Future

Crowdfunding OpenLayers 3

November 1st, 2012 by Tim Schaub · 1 Comment

We’ve been getting great feedback on our OpenLayers 3.0 fund raising
effort, and to help ease contributions from individuals and smaller companies we’ve just launched a crowdfunding campaign on Indiegogo. We’re looking to raise at least $20,000 from users of OpenLayers, to complement larger contributions from big organizations who love OpenLayers.

There are a number of ‘perks’ you can receive for donating, including limited edition OpenLayers t-shirts, your name in the release notes, and participation in the final OpenLayers 3 sprint. If you’ve ever had your work helped by OpenLayers then now is the best possible time to give back.

And please get in touch with ol3-funding@googlegroups.com if you want to help attract larger organizational sponsors to OpenLayers. We’ve got a prospectus for organizations that give them ‘perks’ as well, like their logos prominently featured as supporters and even one year of commercial support on OpenLayers 3.0.

→ 1 CommentTags: Future

OpenLayers 3 – Call for Funding

October 17th, 2012 by Tim Schaub · 9 Comments

We’re excited to be embarking on a major development effort towards OpenLayers 3. Previous posts have detailed our progress through two concentrated sprints. At this point, we’re confident in the new design and are ready to start porting over existing OpenLayers functionality. We intend for the new library to have the same breadth of functionality as OpenLayers 2 with improvements based on the 5+ year history of the project.

To support the development of OpenLayers 3, we’re kicking off a fundraiser. We’ve already received a generous contribution from a major government mapping agency, and are looking to raise an additional $250,000 by November 30.

OpenLayers 3 leverages the latest in browser advancements, with a full WebGL map renderer and a DOM/CSS based renderer where WebGL is not available. OpenLayers 3 will build on the vector rendering and editing functionality in the current version, supporting standards and community formats and protocols. The new version of the library will focus on performance, with a lightweight build optimized for mobile browsers, and usability, with an overhauled website and learning resource center. We’re excited to be giving OpenLayers a design and performance facelift while maintaining the breadth of functionality that OpenLayers users depend on.

Please get in touch at (ol3-funding@googlegroups.com) if you’re interesting in being involved.

→ 9 CommentsTags: Future

OL3 Vienna Code Sprint Report

September 28th, 2012 by Eric Lemoine · 2 Comments

With the OL3 Vienna Code Sprint coming to its end now is probably a good time for a recap on what we’ve achieved. We have done a lot of work on consolidating the architecture and project infrastructure, and have also added new functionality along the way.

spacer

The above image is screenshot of one of our examples. This example includes two maps, a WebGL map and a DOM map. Both maps are synchronized, when one moves the other moves, when one rotates the other rotates, etc.

Infrastructure

We can now generate the API documentation using jsdoc3. The generated API documentation is very “raw” right now, and would definitely deserve some love. But we at least have a tool that is compatible with the Closure Compiler, with plans for even better compatibility in the future. The API doc is available online.

The Jasmine framework is used for testing. Jasmine provides a nice language for describing test specifications. In addition, Jasmine makes it easy to run tests “headlessly”, i.e. outside any browser window. This allows for Continuous Integration, which we feel is very important given out ambitions and expectations for the project. We need solid foundations from the very start of the project.

We rely on the Travis CI (Continuous Integration) service. Each time new code is pushed to the repository Travis fetches this new code, runs the linter, compiler, and the test suite. Breaking changes are thus immediately identified. Check out the OpenLayers 3 Travis page.

Architecture

We have worked on a flexible system for constraining resolutions and rotation angles. This system allows for easily specifying what the possible resolutions and rotation angles can be. The system is flexible to allow for other types of constraints in the future, for restricting extents for example.

We discussed and worked on the API again. We’re not ready to commit to a final API now, so we’ve focused our efforts on the low-level API we’ll eventually build on, providing conveniences as we go.

Functionality

OpenLayers 3 needs to work on touch devices. Panning the map now works correctly on Android and iOS. The pan performance still needs improving. The zoom control’s + and – buttons are responsive in touch devices, as described in this article and elsewhere.

The DOM renderer now displays interim tiles while new tiles, at a better resolution, are loaded. This prevents getting a blank map while tiles are loading. This change revealed bugs in the DOM renderer code, and required major refactoring.

The WebGL renderer supports map rotations, and we have starting adding this support to the DOM renderer. This is based on CSS3 transforms.

Thanks

We’d like to thank the Research Group Cartography of the Vienna University of Technology again. The venue they offered us turned out to be a perfect place for the sprint.

Note: if you’re interested in the development of OpenLayers 3, please have a look at the roadmap and subscribe to the ol3-dev google group.


Our task tracking tool for this sprint:

spacer

→ 2 CommentsTags: Uncategorized

OL3 Sprint #2

September 24th, 2012 by ahocevar · No Comments

This week, four developers (Eric Lemoine and Tom Payne for Camptocamp, Tim Schaub and Andreas Hocevar for OpenGeo) are getting together in Vienna to focus on OpenLayers 3 again, in a code sprint together with developers from GeoServer.

During a 1-week sprint with seven developers in June and in follow-up discussions, an agreement has been found on the flavor of the external API and the general architecture of OpenLayers 3. This week, we can build on the core that we already have. The main goal in addition to implementing features is to create a project infrastructure with a simple build process and good documentation, so other developers can more easily look at and work with the new code, and start to contribute.

You can follow our progress on github.com/openlayers/ol3.

A big THANK YOU goes out to the Research Group Cartography at the Vienna University of Technology, for hosting the sprint. And another one to Camptocamp and OpenGeo for sending developers and covering travel and accommodation costs.

→ No CommentsTags: Uncategorized

OL3 Sprint

June 21st, 2012 by Eric Lemoine · 4 Comments

We are a group of seven people working on a new major version of OpenLayers this week:  Marc Jansen (Terrestris), Mike Adair (DM Solutions), Petr Pridal (KlokanTech / MZK), Tim Schaub (OpenGeo), Andreas Hocevar (OpenGeo), Tom Payne (Camptocamp), and myself (Eric Lemoine, Camptocamp).

Our goal for this sprint is to lay the foundations of what will be OpenLayers version 3. We have been talking about the high-level architecture, the API, and the tools we want to use for developing, building, and documenting the library. The first day was really about sharing ideas and knowledge, and eventually agreeing on a number of things.

We want to support different rendering mechanisms/technologies. We’re envisioning having two built-in renderers in OpenLayers 3, one that works with img/SVG/VML/Canvas (as OL 2), and the other that works with WebGL (Canvas 3D). The WebGL renderer will allow client-side manipulations and transformations of raster and vector data. Eventually it should be possible to tilt the camera, and see things in perspective. The OL 3 architecture will allow adding new renderers in the future, for example to provide some integration with 3D virtual globes.

Supporting multiple renderers requires an appropriate architecture, when the rendering-related code is isolated in specific objects, as opposed to being scattered across the library. (In OL 2 the DOM is omnipresent.)  The architecture we’ve come up with defines three core types: Map, Renderer, and Layer. The map is central, it is the main object with which the app developer interacts with. The map has a renderer, to which it delegates the rendering of the data. When the map is requested to move (either through a user action or programmatically) it sends a “draw” order to its renderer – “draw these layers for this center and resolution”. The renderer will then get data from the layers and render this data on the screen (or <imagine>any other media the renderer supports</imagine>). Layers are really data providers, they’re the interface/facade between the data services and the renderer.

Another thing we’ve been spending time on is the API. We want to provide an elegant and easy-to-use API. Here are a few examples

map = ol.map({
    renderTo: 'map',
    layers: [ol.layer.osm()],
    center: [5, 45],
    zoom: 10
});
Or, written differently:

map = ol.map()
    .renderTo('map')
    .layers([ol.layer.osm()])
    .center([5, 45])
    .zoom(10);
With the new API, the display resolutions, projection, and maximum extent are set on the map. The map is the master, it alone determines what projection and resolution to use. There is no longer a “baselayer” controlling these things.

Once a map is created you can, for example, do map.center() to get the center of the map (an ol.Loc object). And you can do map.center([x, y]) to position the map to a new center. We’re obviously generalizing these jQuery-style getterandsetters across the API.

Another area that has required a fair amount of discussions is whether we want to use an external lib in OpenLayers or not. We have wanted to benefit from the Closure Compiler “advanced” optimizations for a long time. And our Closure fanboys in the room have shown, and eventually convinced, the other sprinters that using the Closure Library is necessary to fully take advantage of the Closure Compiler. So we’ve decided to give a try, without totally committing ourselves to it. I should mention that we’re already observing benefits from the use of the type checker.

That’s all for now. You can follow us on https://github.com/openlayers/ol3.

→ 4 CommentsTags: Uncategorized

Promotion

May 18th, 2011 by Tim Schaub · 1 Comment

spacer
spacer

We’re excited about Erik Hazzard’s new book on OpenLayers. We also wanted to promote Till Adams and Marc Jansen’s German OpenLayers book. Both are now featured on the OpenLayers homepage: openlayers.org/

In addition, I’ve added a small donation button at the bottom of the page. Financial contributions to OpenLayers support both the OSGeo foundation and our project. Any size donations are welcome – if we get enough of a pool, perhaps we can have a documentation sprint and give the OpenLayers docs (and website) a much needed overhaul.

→ 1 CommentTags: Uncategorized

Simplified License for OpenLayers 2.11

May 17th, 2011 by Tim Schaub · 1 Comment

For the upcoming 2.11 release, we’re simplifying the license under which we distribute OpenLayers. We’ve chosen to adopt the more widely used 2-clause BSD License, also known as the FreeBSD License.

This new license differs from our old license in a number of ways:

  1. The new 2-clause license omits the non-endorsement clause. Our old license said that nobody could use the OpenLayers name to endorse products that use OpenLayers without specific written permission. There are many existing uses of the OpenLayers name in promoting software that uses OpenLayers, and in practice we were not enforcing this non-endorsement clause.
  2. The new 2-clause license doesn’t contain any language about patent rights. Our old license included language about patent rights that was not included in other common forms of the BSD. Removing this specific language aligns our license with licenses used by many other projects – reducing the chance of licensing questions that are specific to our project.

We hope that this licensing change makes it even easier for more organizations to use OpenLayers in their web mapping solutions. Let us know if it raises any concerns.

→ 1 CommentTags: Release

More work on mobile and 2.11

April 2nd, 2011 by Eric Lemoine · 31 Comments

Three of us, here at Camptocamp, sprinted three days on OpenLayers. Our goal was two-fold: close tickets for the upcoming 2.11 release, and improve our mobile story, following up on the work done during the mobile sprint (see the previous posts on this blog).

Day #1

We started out by reviewing patches, and closing tickets, for 2.11. We closed a dozen tickets, getting us much closer to the 2.11 release. Some of the new features now in trunk include:

  • New icons for the navigation toolbar, see the navigation toolbar example (patch from Xavier Mamano).
  • Support for OpenLS (Location Service Utility), see the OpenLS example (patch from Bart van den Eijnden).
  • Remove dependencies between scripts to be able to produce smaller single file builds (patch from Frédéric Junod.

Day #2

On Day #2 we spent some more time on bug fixing (and ticket closing) for 2.11, and then switched to improving our mobile support.

  • We spent a great deal of time on many (not so) small Android WebKit-specific issues. The browser often reacts to user actions, causing nasty effects like flashes if no proper action is taken in the JavaScript code.
  • We started reviewing Tim Schaub’s Canvas Hit Detection patch. This patch will give us feature selection on Android, it isn’t committed into trunk at time of this writing but Tim will certainly do it in the coming days.
  • We worked on feature drawing, refactoring code and tests, making feature drawing more solid in every supported mobile browser. See the draw feature example.

Day #3

Day #3 was mainly about mobile again.

  • And mainly about Android again… we committed patches preventing Android’s default behavior, and researched why Android “flashed” the map when two quick taps, apart from one another, occur. There’s stil some work left for a perfect Android story, but code and knowledge have improved a lot.
  • We finished reviewing Tim’s Canvas Hit Detection patch, and reviewed and committed other patches for 2.11.
  • We completed “select feature” support, and added support for “drag feature” and “modify feature”. We modified the mobile drawing example to be able to demo these new features. Go check out the mobile drawing example. (in Android or iOS)!

So, overall, lots of progress on the mobile front, and just a few tickets away from OpenLayers 2.11!

→ 31 CommentsTags: Uncategorized

Mobile Sprint: Day Five

February 25th, 2011 by Tim Schaub · 9 Comments

We’ve officially wrapped up the OpenLayers Mobile code sprint. This week has brought a very welcome infusion of energy to the project. I think it is safe to say that all involved have felt we have achieved the goals we set out for ourselves at the start of the week. In addition to significantly enhancing the capabilities of the library (and perhaps more importantly), the project got an infusion of new lifeblood. We want to express our gratitude to to Cédric Moullet and Claude Philipona for organizing the event, and thank those who sponsored the event for bringing us together:

  • Canton of Zürich
  • Canton of Neuchâtel
  • Canton of Jura
  • City of Uster
  • City of Vevey
  • Geoportail Luxembourg
  • EPFL
  • Schweizmobil
  • Swiss Open Systems User Group
  • Swisstopo & geo.admin.ch
  • Swisscom
  • OpenGeo
  • Nokia
  • Camptocamp
  • Terrestris

Today we were able to able to pull in a number of enhancements that had been cooking for the past few days. In order to improve map navigation performance, OpenLayers now limits the pixel to map translations that occur during dragging. This provides a noticeable gain on both older devices and large display touch devices (iPad). Give one of the mobile specific examples a try on your touch device to see how it feels (and compare to an example from our last release to see how far we’ve come).

While OpenLayers will still not have any dependencies to external libraries, we want to showcase how well OpenLayers works with existing frameworks for mobile application development. The jQuery Mobile and Sencha Touch examples show how mobile specific frameworks can be used in building applications with the newly developed OpenLayers functionality.

A typical OpenLayers application will use a small fraction of the functionality available in the library. In order to build responsive OpenLayers applications, it is important to assemble a limited build of the library – with just the components that your application needs. In the spirit of practicing what we preach, we’ll soon be hosting examples of limited builds for the mobile examples, and the OpenLayers build tool will allow you to use the Google Closure Compiler to create your own minified builds.

As demonstrated in the examples above, we’re also excited about the inclusion of pinch-zoom functionality in OpenLayers. On multi-touch devices, you can now smoothly zoom around in your OpenLayers applications by using the touch navigation control (this will likely be enabled by default in the standard navigation control before the next release).

In addition to the features already in the OpenLayers trunk, this week produced a number of enhancements we’ll be working into the trunk over the upcoming days. Soon (likely before you start work on Monday), we’ll have support for editing vector features on mobile devices. In addition, we bring in a vector layer protocol for local storage of vector features while offline.

I think it is fair to say that for all those involved, this week’s OpenLayers code sprint was a resounding success. Our only regret is that the week has come to an end – and we hope to find another opportunity to come together again. We’re particularly grateful to our sponsors who assumed some risk in bringing us together without any guarantee about what we could deliver. In the end, we’re proud of what we have accomplished, and want to thank the sponsors for helping us bring mobile support to the broader community of OpenLayers users.

→ 9 CommentsTags: Features · Sprint

← Previous Entries
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.