Our Thoughts as MapboxGL JS v2.0 Goes Proprietary

This week, Mapbox announced that they were changing the license of their MapboxGL JS library as part of their latest v2.0 release. The library has gone from an Open Source BSD license to a proprietary one. As of version 2.0, Mapbox GL JS cannot be used without accepting new Mapbox service terms.

This move has produced shockwaves in the geospatial industry. Many organizations are using Mapbox GL JS directly or fork from it. This library is responsible for the visualization of the so-called basemap, the cartography layer that underpins most maps. Previously Open Source, MapboxGL is a great solution, and could be used with many different data sources, so it became the de facto way to render basemaps.

This change highlights a very important consideration that we at CARTO have been actively promoting for some time: basemap neutrality.

Basemap Neutrality

Basemap neutrality means that you can use the CARTO platform, and easily create apps, with a variety of different basemap providers, be that Mapbox, Google Maps, HERE, TomTom, MapTiler or our very own CARTO basemaps that are derived from OpenStreetMap.

And why is this important?

Well, first of all, different geospatial projects have different needs. For example, a project might require the use of Google Maps because of the superb POI database it provides. Another project might choose Mapbox to make the most of their new 3D visualization capabilities. Sometimes there is an underlying business reason, such as the user having an existing commitment with a given provider. It’s just not feasible to force users to use a single basemap provider across all projects.

But there is a second reason. Maintaining basemap independence means our users are not locked into a single provider, and that can be quite important in situations when the provider adjusts pricing or their licensing arrangements.

But how can we achieve that independence? Let’s start looking at how a map is usually made.

Separating the map sandwich technology

A web or mobile map is usually created by using several layers, but for the sake of simplicity you have:

• Your data layer: That's where you visualize your data, your locations, whatever you put on the map.
• The basemap layer: the underlying cartography provided by a basemap provider.

Mapbox has not only baked some great cartographic capabilities into their MapboxGL JS library, but also visualization capabilities. The idea is that you use their library for both layers of the map sandwich to optimize performance. If you use Mapbox GL JS to visualize your data layer, then it is going to be really hard for you to change to a different basemap provider, if you so wish.

So how can you do that?

One of the key reasons why we are investing heavily in the Open Source project deck.gl is to give CARTO and our user base a data visualization library fully independent from the basemap provider. We want the library to be Open Source and protected by the appropriate governing body that ensures no single entity owns the library. deck.gl fulfils this philosophy and more.

So, consider these alternatives:

The key difference is being able to build your map entirely on the basemap JS library or by using deck.gl, having the option to change basemap provider painlessly.

By keeping the map sandwich separation it’s easier to ensure the “health” of the stack. Collaborating with many companies on deck.gl means a healthy Open Source community and a library that gets better and better for users, without the risk of any licencing changes.

So where next? More deck.gl

CARTO will continue investing in basemap neutrality. We are very excited to bring the great new capabilities of MapboxGL 2.0 for those users that want them, and we are equally excited by the upcoming Google Maps Vector capabilities.

In the short term we are going to support one of the key initiatives to maintain a fork for Mapbox GL JS v1.13, like other companies will be doing, to ensure there is continuation of support for current CARTO basemaps used in deck.gl and existing applications. Check out this example.

But in the long term we are also actively consulting with different partners to see if we provide a full solution within the deck.gl ecosystem as part of the Urban Computing Foundation.

Potential direction: to extend the MVTLayer class to support better cartography so that you can create a “basemap” layer from MVT sources.

Check this out example. This is deck.gl with 2 layers, one for data visualization and the other an MVTLayer reading an OpenStreetMap basemap.

There is no basemap library used here at all, just deck.gl all the way.

This is not an easy task. Handling labels and producing great cartography for basemaps is really difficult, and clearly shows the huge investment made by Mapbox on their Mapbox GL JS library.

So, to be clear. It is unlikely that deck.gl will ever have the depth of support for basemaps that MapboxGL JS or Google Maps have, but for most users it will be more than enough and could prove more convenient. And for those users that need or want to unlock the full capabilities of their basemaps, they will continue to have the option of using a basemaps library and provider of their choice.

Overall, the order of decision-making when building a spatial app should not start with which basemap to use, but rather to focus on what visualization functionality you need and then the basemap layer to display it on.

Oh, and finally, did we mention that deck.gl already supports 3D terrain layers?

Ready to share your feedback?

Our goal is to enable CARTO and deck.gl users to seamlessly use Mapbox basemaps, Google Maps, CARTO OpenStreetMap basemaps, their own basemaps, Azure Maps, Maptiler, HERE, TomTom ,and any other technology they choose. It is about giving freedom of choice and not locking users in.

There are already a lot of combinations available within the deck.gl ecosystem: deck.gl + Mapbox, deck.gl + Google Maps, deck.gl + CARTO basemaps, etc. And it’s easy to switch between providers with just one line of code!

We think deck.gl has huge potential to become the foundation for spatial application development and having the right relationship with different basemap providers will be key.

Finally, we’d really like to hear from you! What options do you want available? Should we invest more on MVTLayer inside deck.gl and more abstraction of basemaps? We think this is a great opportunity for the community to fundamentally change our relationship with basemaps. So please reach out to us and let us know what you think!