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!