Introducing v4.0
Published in
9 min readApr 3, 2017


by Ib Green

We’ve just released a new major version of, so this is a good time to share some information about the improvements that went into the new version the rationale behind them, and provide some hints on our thoughts about the future of

What Motivated the Release?

When we did our first external announcement of in November 2016 (announcing the v3 release), we also stated our intention to improve and expand’s layer catalog in future releases. This is a major part of what we are doing now through the v4 release. v3 saw rapid adoption across a number of internal data visualization applications here at Uber, and it didn’t take long before an impressive list of new layers had been developed to support these applications. For layers that were reused between multiple applications, it became clear that open sourcing them in a new official release would likely benefit both internal and external developers.

In v4, the core layer catalog in effectively doubles in size to over a dozen layers. These layers are carefully audited, tested and documented, and cover a significantly wider array of geospatial visualization use cases.

Obviously, while the new layers are the big stars of the release, v4 includes more than just the layers. It stems from almost five months of intensive development, and incorporates improvements addressing a long list of comments, suggestions, bug reports and feature requests, from both internal and external users. If you are already a v3 user, you will find few areas in v4, whether in terms of APIs, documentation, examples or actual code, that haven’t received some level of additional polish.

Why a Major Version Bump?

We take backwards compatibility of very seriously. follows semver versioning rules, which require that any change to existing functionality, no matter how small, is accompanied by a bump of the major version number, from 3 to 4 in this case.

Obviously, the addition of a set of new layers would not by itself change any existing functionality, and thus only require a minor version bump (e.g. v3.1). However, as part of the release preparations, we conducted an extensive API audit of both the new v4 layers and the existing v3 layers and found that doing a small set of changes to existing v3 layer APIs would allow us to make the APIs of all layers considerably more consistent and the whole framework more cohesive and logical, which was clearly the right long-term choice.

In spite of the major version bump, v4 remains highly compatible with v3, both in terms of public APIs and the way layers work. Also, to ensure a smooth transition, we provide an upgrade guide and we expect the upgrade effort for applications to be minimal.

A Growing Layer Catalog

From the very beginning, has always been a geospatial data visualization framework, and geospatial use cases will always be our top priority. The new layers added to the layer catalog are widely used in geospatial data analysis within Uber and we hope they will help solve the problems that users face every day.


The GeoJsonLayer is designed to render geometry primitives in the widely-accepted GeoJSON data format. GeoJsonLayer itself is very powerful as it renders multiple types of geometry primitives, including points, lines, multilines, polygons and multipolygons all at once. Moreover, it can render polygons and multipolygons in different styles, currently supporting filled and outline styles in non-extruded (2D) mode, and filled and wireframe styles in extruded (3D) mode.

The flexibility of GeoJsonLayer combined with’s high rendering performance makes it possible to render large amounts of data on the city or even the worldwide scale, as shown in the GeoJsonLayer example on our demo site.


The PathLayer is created to render a path comprising multiple line segments, specified by a sequence of coordinates. The path drawn has customizable width and mitered or rounded line joints.


The PolygonLayer renders general flat or extruded polygons specified by a “closed” sequence of coordinates, following the GeoJSON specification for polygon features. Polygons can be rendered as filled or outlined in non-extruded (2D) mode and filled or wireframed in extruded (3D) mode. This layer supports rendering convex, concave and “donut” polygons (with holes).


The IconLayer allows the user to render customizable markers on top of the base map. Multiple icons can be used in a single layer through a texture atlas and a configuration object in JSON. The size of the icons can be separately controlled and bounded with user-specified values.


The PointCloudLayer is designed to visualize 3D point cloud data, usually generated from sensors like LIDAR and stereoscopic cameras. Point cloud data can contain position, normal and color values to control the style of rendered points, which are “billboarded” towards the user.

GridLayer and HexagonLayer v4 introduces two new “auto-aggregating” layers that complement the ScreenGridLayer from v3. The GridLayer and HexagonLayer draw equal-area rectangular or hexagonal cells. These layers go beyond directly displaying the supplied data on the map, in that they don’t draw one cell per data point, like most layers do. They first aggregate (or “bin”) the user-provided data points into cells, and then draw the cells using the aggregated values to control properties like color and height, effectively rendering grid-based heatmaps.

Aggregation is an exciting new direction for as we want to not only provide layers that are visually compelling to our users, but that are also smart.

Finally, note that the new GridLayer and HexagonLayer are different from the existing ScreenGridLayer as both the rendered geometry and the aggregation boundaries are in world coordinates rather than screen coordinates. Another difference is that the new layers also support both flat (2D) and extruded (3D) cells.

Layer extrusion and lighting

As mentioned in the previous sections, some layers now support extrusion. Extrusion can be enabled by setting the extruded property to true, if available. Users can provide a getElevation accessor to control how much each individual element should extrude.

To make extrusion appear natural and visually pleasing, v4 now has an experimental lighting module that provides basic shading of 3D layers. It has very straightforward APIs and users should be able to understand them simply by looking at the examples that come with It’s worth mentioning that since they’re experimental, the public APIs might change in the future release of

Interactive Documentation’s documentation has been significantly improved and reorganized in response to user feedback. In particular, every layer now has an interactive layer browser allowing users to tweak all properties of the layer and see how they affect the final rendering of layers while reading the docs. It also serves as an intuitive tool for users to select appropriate layers for their use cases.

Stand-Alone Examples v3 came with what was essentially a single example interleaved with the complicated build scripts and extensive package dependencies of the main library. This has been called out by many entry-level users, so the team decided to provide multiple stand-alone examples with minimal configuration files. These examples should jump start the learning process of and developers can easily copy them out and bootstrap their own apps from them. These examples are located in the example folder in’s main repository.

Interoperability Examples

To leverage your data visualization knowledge with the tools you are familiar with, we also provide examples to demonstrate the interoperability between and regular SVG-based visualizations. For example, one can use the modularized d3-* utilities for layout calculation, and have take care of the rendering, thereby avoiding heavy DOM manipulation and enabling GPU-accelerated rendering of up to millions of elements.

What’s Next? v4 is an important milestone for us, but what’s next? While we haven’t finalized any plans for a possible v4.1 or v5 release yet, we have many ideas about improvements and directions we would like to evolve along. Some examples are:

More and Better Layers

Layers are how creates value for most users, so adding more layers is on the top of our list. We will always keep improving support for the geospatial visalizations while also considering support for abstract/non-geospatial visualizations in the InfoVis area.

We also encourage all users and developers to consider sharing your fancy new layers with the community (github pull requests are welcome). If your layers help address some common needs and/or accomplish tasks common across multiple areas of data visualization, they might even end up being included in the core layers catalog of in the next release!

Text Rendering Support

Text provides crucial information in many data visualization applications and can be implemented in various ways depending on specific use cases. Using WebGL to render text labels or geometries is both performant and versatile, but can be non-trivial to implement. In v4 we are not providing any official support for text rendering besides a basic sample layer called “LabelLayer”. This is an area we are actively exploring.

Expanding and Improving Aggregation

The new aggregating layers in v4 are only scratching the surface of what can be done in terms of adding data processing intelligence to More advanced aggregation algorithms are being researched, and will be implemented if they are useful for our internal or external customers.

More Data Processing (possibly on GPU) for Geospatial Data Analysis

As we march forward in the geospatial data analysis field, it’s obvious that the single-threaded Javascript engine in our browsers will soon be overwhelmed by computation-intensive tasks. We can solve this by seeking help from the backend, but not without its own limitations. The recently-released WebGL 2.0 standard provides a way for front-end developers to access powerful GPUs on every desktops and laptops that was not possible in the past. With features like transform feedback, we might be able to vastly accelerate many computational tasks in geospatial data analysis.

We have already started experimenting with those powerful features in WebGL 2.0 to do not only rendering, but also data aggregation on the GPU.

Improved Layer Composition

In the new v4 release of, some new layers like GeoJsonLayer and HexagonLayer are what we call composite layers, as they are actually built by composing other core layers. Composite layers have their own props but also leverage underlying layers for their capabilities. This kind of composition greatly reduces the effort required for creating new layers and makes the internal structure of many layers much cleaner. In future releases, we will continue making composite layer development easier by decoupling different sets of layer functionality and continuously improving our guides and docs.

More Advanced Picking Support

Picking (i.e. mouse selection) is one of the most common tasks of interactive data visualization applications and is a core functionality we provide with We have ideas for improving picking by adopting better picking boundary arbitration (bigger pick targets), supporting square or polygon area picking, etc.


Performance is always at the front of our minds as, from the first day, was designed to be a high performance visualization framework. Many under-the-hood performance improvements went into the v4 release, including a 3.5~4X faster scatterplot layer, faster 64-bit maths, and ~2X performance boost in picking, etc. In the future, we are considering implementing a better WebGL state manager that faciliates resource sharing and reuse, a better layer manager that manages and updates resources in a smarter way, and a better rendering engine that only allows necessary data to hit GPUs from the very beginning.

Final Words

Finally, just to dispel any doubt from our users, we would like to reiterate our commitment that will remain a “geospatial visualization first” framework. The non-geospatial use cases we are working on will not compromise our focus on maintaining and improving the geospatial visualization aspects of To the contrary, as we mentioned earlier in this article, users can expect see even more “advanced” geospatial processing functionalities to the future releases of

Contributors v4 was created by the Visualization Team at Uber. It is the result of a collaboration between a number of amazing contributors, including: Nicolas Garcia Belmonte, Xiaoji Chen, Balthazar Gronon, Shan He, Shaojing Li, Eric Socolofsky, Yang Wang and many others.

Originally published at on April 3, 2017.