OpenLayers Blog

All the maps that are fit to blog

Bing Tiles for OpenLayers

December 18th, 2010 by ahocevar · 18 Comments

As of today, OpenLayers has a new layer type: OpenLayers.Layer.Bing. “Why that” you may ask, “there is OpenLayers.Layer.VirtualEarth already”. So why is this new layer type so special? It is the first time that we access tiles from a commercial service directly. Others (e.g. Google Maps) do not provide direct access to their tiles, but Microsoft does through the Bing Maps Web Services. We from the OpenLayers community appreciate this a lot, because it has several advantages over accessing commercial tile services through their JavaScript APIs:

  • No need to include extra JavaScript in your application
  • Better integration with OpenLayers, because things like dragging, transition effects or tile buffer are directly controlled by OpenLayers
  • Better performance because tiles are accessed as image resources, and not through an external JavaScript API

Recent experience with the Google Maps v3 API has shown that using external APIs in OpenLayers can be error prone:

With direct tile access, Bing Maps is now the best choice of commercial map tiles for OpenLayers. And the usage is simple:

  1. Get an API key at This API key is not bound to an application url or domain.
  2. Create a map with an OpenLayers.Layer.Bing instance, configured with the API key. Below is a minimal example.
var apiKey = "your api key here";

var map = new OpenLayers.Map( 'map');

// Bing's Road imagerySet
var road = new OpenLayers.Layer.Bing({
    key: apiKey,
    type: "Road"
// Bing's Aerial imagerySet
var aerial = new OpenLayers.Layer.Bing({
    key: apiKey,
    type: "Aerial"
// Bing's AerialWithLabels imagerySet
var hybrid = new OpenLayers.Layer.Bing({
    key: apiKey,
    type: "AerialWithLabels",
    name: "Bing Aerial With Labels"

map.addLayers([road, aerial, hybrid]);
map.addControl(new OpenLayers.Control.LayerSwitcher());

OpenLayers.Layer.Bing uses the Bing Maps REST Services to retrieve metadata that is required to access the tiles. The “type” config option for OpenLayers.Layer.Bing can be any of Bing’s imagerySets, except for those with Bird’s Eye imagery.


The idea to create this layer type was born during a “NYC work week” hosted by OpenGeo, when Tim Schaub and I discussed problems with the Google layers in OpenLayers that collegues from OpenPlans had made us aware of. Unfortunately we were too busy to implement it during that week, but I created a patch for it the following weekend. Thanks to Justin Deolivera from GeoServer for providing Sierra Nevada Pale Ale and the UFC stream from Montreal, which gave this coding task a recreational setting. Yesterday the patch was reviewed and made even more solid by Tim. Now it is available in OpenLayers trunk, and will be shipping with the next OpenLayers release.

→ 18 CommentsTags: Features · Future

OpenLayers in Barcelona

August 6th, 2010 by Tim Schaub · Comments Off

The one month countdown has begun for the FOSS4G 2010 conference. As with previous conferences, OpenLayers features heavily in the program. Here’s this year’s list of selected presentations mentioning OpenLayers in the titile:

If yours is one of the presentations on that list, start preparing! If not, register for the conference and we look forward to seeing you there.

The workshops are a great way to get hands-on experience with OSGeo software. The OpenLayers workshop just filled up.

FOSS4G 2010 Workshop

If you didn’t get signed up in time and bang on the door really hard, I’ll see what I can do about getting you in :)

Comments OffTags: Conferences

Google Maps V3 for OpenLayers

July 10th, 2010 by ahocevar · 75 Comments

As of today, the OpenLayers development version supports Google layers served by the Google Maps V3 API. This is not only Google’s latest and greatest Maps API, it also makes life easier on the OpenLayers side because no API key is required. To use the new Google layer, application developers just have to include this script tag on their html page:

<script src=""></script>

When creating OpenLayers.Layer.Google instances, the only difference to the V2 API is the way the layer types are configured:

var gphy = new OpenLayers.Layer.Google(
    "Google Physical",
    {type: google.maps.MapTypeId.TERRAIN}
    // used to be {type: G_PHYSICAL_MAP}
var gmap = new OpenLayers.Layer.Google(
    "Google Streets", // the default
    {numZoomLevels: 20}
    // default type, no change needed here
var ghyb = new OpenLayers.Layer.Google(
    "Google Hybrid",
    {type: google.maps.MapTypeId.HYBRID, numZoomLevels: 20}
    // used to be {type: G_HYBRID_MAP, numZoomLevels: 20}
var gsat = new OpenLayers.Layer.Google(
    "Google Satellite",
    {type: google.maps.MapTypeId.SATELLITE, numZoomLevels: 22}
    // used to be {type: G_SATELLITE_MAP, numZoomLevels: 22}

Work on the V3 API support for OpenLayers started in February during the NYC Sprint hosted by OpenGeo. At that time, the v3 API did not allow us to pan the map without a built-in smooth animation, resulting in ugly dragging behavior with overlay layers. After this issue was starred by many OpenLayers users, Google finally changed the API’s setCenter method to not do a pan animation any more.

Now that Google has also deprecated the V2 API, it was about time to give OpenLayers users a new Google layer for the future. Speaking of future, OpenLayers.Layer.Google.v3 comes pre-configured with a working Spherical Mercator setup, like OpenLayers.Layer.OSM. This means that the new layer type can be used without configuring map options like projection, maxExtent, units or maxResolution. Developers only need to transform coordinates to the EPSG:900913 projection when setting center or extent of the map.

The recommended entry point for getting started with OpenLayers.Layer.Google using the V3 API is the new google-v3.html example, which should make clear how to migrate existing applications.

For existing applications that continue to use V2, the only caveat is that due to separating V2 and V3 specific code out from the OpenLayers.Layer.Google class into a mixin, OpenLayers.Layer.Google.prototype calls may need to be modified. This is explained in the release notes for the next release, which will ship with the new Google V3 layer.

→ 75 CommentsTags: Features · Future

WMTS Support in OpenLayers

July 2nd, 2010 by Tim Schaub · Comments Off

The OGC recently ratified the Web Map Tile Service Implementation Standard (WMTS) and OpenLayers followed up with a WMTS layer and capability parsing support. The layer supports both the “RESTful” and “KVP” request encoding (terms from spec), and the capabilities parser greatly helps in creating layers with the correct properties.

There are several tickets with patches that will bring additional WMTS functionality to the library. The first makes layer creation from a capabilities response easier, the second improves handling of the advertised matrix definitions, and the third brings in a control to issue GetFeatureInfo requests for WMTS layers. When these are completed and reviewed, I’ll post an update describing their use.

Big thanks to August Town, who submitted a terrific patch with the WMTS layer and capabilities parser. Additional thanks to the Danish National Survey and Cadastre and Grontmij | Carl Bro for sponsoring enhancements and fixes to the WMTS components.

Comments OffTags: Features · Standards

OpenLayers 3 on GitHub

June 30th, 2010 by Tim Schaub · 2 Comments

In recent discussion on the OpenLayers development list, we decided to start working towards the next major version of OpenLayers. During a subsequent meeting on irc, we chose to use git for working towards v3 and are hosting a central repository on GitHub. Anyone interested in helping us in the OpenLayers 3 effort is encouraged to fork the repository, make changes, and send pull requests (we will likely formalize this process as development proceeds). As with all repositories on GitHub, if you prefer svn to git, you can read from and write to the repository using Subversion.

We’ve got solid set of goals for OpenLayers 3. The list below is summarizes the fundamental ideas:

  • Trigger custom application events from the map.
  • Streamline the drag flow.
  • Map properties rule. Layers derive projection and related properties from the map.
  • Layers advertise their ability to render in a projection.
  • Location is the future, and it is smart. Geometry comes from Location, and is also smart. LonLat is gone.
  • Layer visibility can be mutually exclusive within a group.
  • Improve performance of hot code (stuff that is executed a lot).
  • Create a simple core set of utilities and provide adapters for people that are using other JavaScript libraries that duplicate this functionality (reducing the amount of redundant code that has to be loaded).
  • Look for ways to refactor the code so things can be excluded in applications where it is not needed (e.g. advanced geometry operations).
  • Provide a simple set of widgets (like the layer switcher) but make it easy for people to use other widget libraries of their choosing.
  • Facilitate mobile browser support.

How’s that for ambitious?

During development towards OpenLayers 3, we will continue to work on the 2.x line of development. We’re excited about some good new features and fixes in the next release (2.10).

Thanks for any help in the effort to get to OpenLayers 3.0.

→ 2 CommentsTags: Future · Release

OpenLayers Sandswarm

November 18th, 2009 by Tim Schaub · 2 Comments

OpenLayers owes much of its functionality to sandbox innovations in the repository.  At the FOSS4G conference in Sydney, I played a short animation representing commit activity in the OpenLayers trunk.  As a way of acknowledging all of the great work done by sandbox developers, I wanted to post a similar animation that shows sandbox commits as well.

Here’s the video on Vimeo. Trunk commits in orange/red and sandbox commits in blue/green (with apologies to the color blind). Credits to code_swarm for the animations.

→ 2 CommentsTags: Features

OpenLayers at the FOSS4G code sprint

October 26th, 2009 by ahocevar · 1 Comment

Several OpenLayers developers and volunteers gathered after the FOSS4G conference to participate in the Saturday code sprint. And guess what: a lot was accomplished! Here is a quick overview:

  • Mike Adair (DM Solutions) and Julien Lacroix (Mapgears) finished Mike’s work on a graticule control, which also brings label positioning and a utility function to format coordinates
  • Julien also started looking closer at the Refresh strategy that Kris Geusebroek (Xebia) had originally contributed.
  • Robert Coup (Koordinates Ltd.) dug deep into memory leaks and came up with several patches, all of them with memory tests. He is still working on more leak fixes, based on an original patch from Kris.
  • Klokan Petr Přidal provided a small but effective patch to support tile grids with truncated tiles at the bottom and right grid edges. This is necessary to support layer types like Zoomify, for which another patch is awaiting review.
  • Marc Jansen (Terrestris) started cleaning up the examples: he added more keywords, made improvements to descriptions and made notes about deprecated practices that some of the examples still show.
  • Volker Mische (LisaSoft) put some efforts into making it possible to drag OpenLayers maps with the moving mouse cursor leaving the map viewport (like e.g. in Google Maps). There is still some work required, but I will help Volker and this fix should be in trunk soon. On a side note: this issue is very old – ticket #39
  • Roald De Wit (LisaSoft) made the pink tiles for unavailable image tiles configurable with CSS.
  • Roald and Volker also went to the drawing board with me, and by looking at the slider of the PanZoomBar control we found a way how a new control base class could separate the UI from the map interaction. There was not enough time to do a proof-of-concept implementation, but Roald and Volker are about to do this in a sandbox. Expect more discussion on this on the dev list in the near future.
  • Eric Lemoine (CampToCamp) made an older patch that makes the LayerSwitcher configurable with CSS ready for trunk.
  • Bart van den Eijnden (OSGIS) and Eric and reviewed some tickets that were in the pipeline and put the fixes into trunk.

Having developers of several projects sitting in the same room also leads to synergies: Klokan Petr Přidal (known from MapTiler), as he was sitting next to Mike Adair (known from proj4js) coded a quick example of raster reprojection with Canvas and proj4js.
OpenLayers Code SprintKlokan Petr Přidal showing Mike Adair and Marc Jansen that proj4js can do more than just vector reprojection.

I (Andreas Hocevar, OpenGeo) did my best to support everyone who participated. Apologies if I wasn’t able to help with all issues during the sprint, but I will be available with support and advice for all the good work that was started, so it can be finished successfully.

→ 1 CommentTags: Conferences · Features · Future

Update from FOSS4G

October 22nd, 2009 by Tim Schaub · 2 Comments

We’ve seen a good bit of OpenLayers activity at the conference so far.  Last night, a crowd of 25 or so gathered at the OpenLayers Birds of a Feather session.  It was a good opportunity to hear how people were using the library in their applications.  We got plenty of suggestions on ways to improve things.  Among them:

  • More OpenLayers.Console.warn and error calls for better diagnostics in debug mode.
  • Clean up examples: more consistent coding style, remove examples of deprecated behavior (or archive them separately), organize examples by category and make them more easily discoverable.
  • Finish moving style declarations to CSS (pink tiles first!)
  • Work on separating GUI from controls, more event driven design.

We hope that people have a chance to dig into some of this work at Saturday’s code sprint.

→ 2 CommentsTags: Conferences · Features

OpenLayers Down Under

July 20th, 2009 by Tim Schaub · 2 Comments

If you’re planning a trip to Sydney this year for FOSS4G, you’ll find plenty of opportunities to hear about OpenLayers in presentations and workshops.

Presentations (that mention OpenLayers in the abstract)

Workshops (mentioning OpenLayers)

(Update: Workshops list linked to abstracts.  Thanks Shoaib.)

→ 2 CommentsTags: Conferences

Snap & Split

March 11th, 2009 by Tim Schaub · 5 Comments

We’ve been advancing the editing capabilities of OpenLayers with each release since the initial inclusion of the vector feature rendering in 2.4.  The upcoming 2.8 release will bring two new enhancements that I’m particularly excited about: snapping and splitting.

The snapping example demonstrates some of the configuration options of the snapping agent.  This control can be set up to work with any number of target layers.  Modified features in a source layer are snapped to eligible features in target layers based on tolerance settings.  Snapping options for nodes, vertices, and edges can be independently configured.

The split feature example uses the new split control to generate temporary sketches for splitting existing features.  The control can also be configured to listen for edits on an existing layer and split features on any target layer.

The snapping and split controls can be used together to provide an editing environment that maintains some basic topology rules.  Both controls trigger events that let the application designer customize exactly what happens before, during, and after snapping and splitting.  You can find documentation and additional examples for both of the controls in the growing prose documentation.

Thanks to Sweco for supporting this work.  We’re excited to have it in the trunk.

→ 5 CommentsTags: Features · Release · Vector