Before to start

A brief history

The arrival of Google Maps in 2005 was a revolution for the world of the web mapping. It offers to the world the opportunity to explore their environment, opening the eyes to the people to understand the importance of the location, and gives to the developers a tool to create thousands of new map uses. A new era began.

Nowadays location is almost everywhere. It is common to see companies websites using a small map to show where they are located or companies offering location based services, for example, to store your geo-tagged vacation photos.

For years the visualization of geographic information resided on powerful desktop applications, also prepared for analysis, transformation and edition, but Google Maps started the revolution of the web mapping applications demonstrating the browsers, and JavaScript, can play an important role in the world of the Geographic Information Systems (GIS).

At the same time of the web mapping libraries born another important revolution took place in the GIS industry: the standardization. Projects like GeoServer or MapServer becomes serious competitors to proprietary GIS servers. Both open source, with powerful features and, more important, implementing many of the standards defined by the Open Geospatial Consortium (OGC), like Web Map Service (WMS), Web Feature Service (WFS), Web Map Tile Service (WMTS), Simple Feature Access (SFS), Geography Markup Language (GML), Styled Layer Descriptor (SLD), etc.

Born of OpenLayers

OpenLayers appears in the middle of 2006 as an open source alternative to Google Maps and other proprietary API providers, but it starts gaining more attention in 2007, when the growing OpenStreetMap project adopts it for its website.

The popularity of OpenLayers has grown with the years, evolving and improving with the addition of new features. Nowadays, it is very mature project and probably the most complete and powerful open source web mapping library to work with geographic information.

One of the key aspects of OpenLayers is the fact it implements many of the Open Geospatial Consortium standards so it becomes the perfect candidate to work against geographic information servers.

After years of feature additions, improvements, evolutions and bug fixes OpenLayers begun to show its age. The technology available seven years ago to build a toolkit are not the same than nowadays. On that time new projects has appeared and consolidated for front-end development: DOM manipulation or UI creation (jQuery, Dojo Toolkit or ExtJS), a new HTML version (HTML5) has been released with many awesome features implemented by many modern browsers (like Canvas or WebGL) and the evolution and performance improvement of JavaScript language. All these factors, among others, has determined the need to create a new version of OpenLayers from scratch.

OpenLayers3

OpenLayers is a JavaScript web mapping toolkit that offers all the required components to work with geographic information in the browser side.

The complexity of a solution that satisfies all the needed requirements goes beyond the simple idea of visualize raster and vector data in the browser. We need to request data from (or store to) many different data sources, from map servers implementing OGC standards to simple plain files. We need to read from (or write to) many data formats: GML, KML, GeoJSON, etc. We need to work with data in different projections. We need the concept of layer where to place different kind of data and we need to play with these layers: hiding or showing, raising or lowering on each other. We need to style the features depending on its attributes, for example we can render cities as points with different radius depending on its population.

Hopefully, OpenLayers satisfies all these and much more requirements.

As developers, our duty is to understand how the tools we use work and how they are made. Understanding how OpenLayers3 is designed is a crucial step before start working with it.

I encourage the reader to explore the OpenLayer3 source code. It is the best place to learn in depth how this great library was designed and works.

Features

OpenLayers3 is a completely rewritten version of the project, centered to make it a really up to date project and offering mobile support out of the box.

The API has suffer in depth changes and the programming style has changed to avoid long namespaces, avoiding those extremely long sentences required in previous versions.

The weight of the library has been reduced drastically and it is much more lightweight than in previous versions. In OpenLayers3 the production ready version is about 300kb containing all the functionalities.

The renderers has been updated to make use of WebGL, Canvas or DOM elements depending on the browser capabilities. Renderers are the piece of code responsible to draw points, lines, polygons, tiles, etc on the screen. So it is important this action has a great degree of performance to run faster in mobile and desktop applications.

OpenLayers3 is based on the Closure Library and rely on the entire Closure Tools suite. The Closure Compiler minimizes the code, producing an extremely compact and high performance version through advanced optimizations (like variable and property renaming, unused code removal or function inlining). On the other hand, the Closure Library is a general purpose JavaScript library which allows create modular application, handle module dependencies, DOM manipulation, etc.

A great project requires a great documentation, because of this OpenLayers3 makes use of the JSDoc tool. JSDoc is a JavaScript API documentation generator that offers an extensive syntax notation to put on the source code and, automatically, generate the project API documentation.

OpenLayers3 offers 3D capabilities in the browser, based on the Cesium project. This means the same map could be rendered using 2D or 3D views, opening new possibilities to developers.

When a wrote this lines 3D support is not implemented yet, but there is the promise to add it.

Getting ready for programming with OpenLayer3

There are many ways to organize a JavaScript application: folders structure best practices, modules, asynchronous loaders, etc. All these concepts are beyond the scope of this book but, obviously, anyone can need them on a real application.

Use OpenLayers3 on your application requires basically two steps:

  • Include the JavaScript file, typically ol.js, with the library implementation.
  • Include the CSS file, typically ol.css, with the styles for some the elements of the library, like the map or the controls.

Depending on your needs, the files can be hosted and provided by your own server or be provided by a Content Delivery Network (CDN). Each solution has its pros and cons.

Serving the files from your own servers implies more data must be transfered to every client which must be token into account on sites with big traffic. On the other hand, getting the files from an external server can leverage the bandwidth issues but implies you are dependent of an external service you may can not take control, if the service is down, your application will not work.

Basic code structure

For the examples that accompany this book, we have follow some simple best practices for small web applications that can be summarized as: put CSS at top and JavaScript at bottom.

The next code shows the basic structure:

 1     <!DOCTYPE html>
 2     <html lang="en">
 3         <head>
 4             <title>Our app title</title>
 5             <meta charset="UTF-8">
 6             <meta name="viewport" content="width=device-width">
 7 
 8             <!-- OpenLayers CSS -->
 9             <link rel="stylesheet" href="http://ol3js.org/en/master/build/ol.css\
10 " type="text/css">
11             
12             <!-- Our app styles -->
13             <style>
14             </style>
15         </head>
16         <body>
17             <!-- Our app HTML tags here -->
18 
19             <!-- OpenLayers JS-->
20             <script src="http://ol3js.org/en/master/build/ol.js" type="text/java\
21 script"></script>
22             
23             <!-- Our app code -->
24             <script>
25             </script>
26             
27         </body>
28     </html>

In addition, the samples uses Bootstrap framework to define the layouts and better style the components, because of this you can see the use of CSS classes like row, col-md-6 or btn. Do not worry about that. The goal of the samples is to explain the JavaScript code related to OpenLayers3 and not to become a great web designer.

How to debug an OpenLayers3 application

Often, at development time, it is needed to see what is happening at our code: check variable value, function context, loops, conditions, etc. For this purpose, most modern browsers offers tools to allow not only to debug our JavaScript code (setting breakpoints, watchers, …) but also helping with CSS (visualizing, editing on the fly or computing the properties of an element) and HTML (allowing to modify on the fly the code).

On FireFox browsers FireBug is a well known tool, although latests versions includes a built in tool called the Firefox Developer Tools). Similarly, Chrome browser has the built in tool called Chrome DevTools.

Previous tools allows us to debug the source code of our application, but what if what we need is to analyze the OpenLayers3 source code? For me, this is the best way to learn how OpenLayers works: how it process remote data and transform into features, how map renders layers, etc.

Fortunately for us, OpenLayers3 is distributed in two different versions:

  • ol.js, contains all the OpenLayers3 source files concatenated and minimized using the Google Closure compiler (which reduces file length renaming variables and properties, removing unused code, …). It is specially designed for production environments because its lightweight.
  • ol-debug.js, contains all the OpenLayers3 source files concatenated. It is suitable for debug purposes because we can navigate step by step through the OpenLayers3 internal code.

So, if you never need to study the OpenLayers3 source code, the ol-debug.js file is the right file to be linked in your application.