Using Mapbox Vector Tiles in CARTO for Maps & Location Apps
Vector tiles are the building blocks for maps and location applications that need to quickly create smooth interactive experiences. When analyzing and visualizing a lot of spatial data a flexible platform is needed to process information and deploy these vector tiles quickly.
Until recently most web maps were built using raster tiles small images (usually PNG) that depict a small square area and all of the layers of data within that area like basemaps with roads buildings and other user data. Vector tiles render vector data which contain the same information as geometries and metadata like street address and points of interest.
While there are several vector tiles formats out there the team at Mapbox is leading the way with their Mapbox Vector Tile (MVT) specification.
Vector tiles have several important advantages over image tiles:
Styling capabilities: since styling happens on the client side and not on the server side it means much more flexibility when creating dynamic applications with dynamic styling. On the basemaps and the data layers.
Efficiency: vector tiles transfer the data more efficiently than image tiles enabling reusing of data at different zoom levels and avoiding requesting much more data to the server.
Interactivity: since the data is sent to the browser for rendering it means applications can interact with that data without calling the server which results in richer filtering styling and overall interactions.
WebGL rendering: using vector tiles together with WebGL renderers provides high resolution maps with smooth zoom capabilities smarter positioning of labels and greater interactivity between basemaps and data layers.
In short vector tiles are the future of web mapping as they provide better user experiences when working with data in Location Intelligence apps.
Vector tiles have been in wide use for basemap rendering including in our own CARTO Mobile SDK for the past two years but for data layers there were limitations that forced users to make use of different solutions for pre-creating them. We have heard that from many of our users and we are excited to change that.
Today we are opening up dynamic Mapbox Vector Tile support for CARTO Engine.
While CARTO has had dynamic vector support for quite some time (in the form of GeoJSON through our SQL API or Torque) we’re excited to expand this functionality with proper support to all our CARTO Engine users. By bringing together CARTO Engine with Mapbox Vector Tiles users can leverage these technologies directly from our APIs. Check out this example pulling fresh vector tiles directly from CARTO
Here are a few ways bringing MVTs into CARTO can bring your Location Intelligence applications to the next level:
NO PRE-RENDERING JUST LIVE VECTOR TILES DIRECTLY FROM SQL
The most effective way to build dynamic maps that analyze and visualize data in real-time is to work directly from the data source.
Most vector tiles need to be pre-rendered as a static tileset on desktop software before being used for web mapping. This extra step has two problems:
- It requires lot of expensive software using traditional vendors. Up to 3 products between desktop and server products.
- It makes it difficult to change in real time data or change parameters on the fly when solving business problems which drastically limits the type of Location Intelligence Apps that can be built using vector tiles.
So instead of creating vector tile packages we offer the creation of them dynamically from SQL on a single platform.
MVTs in CARTO allow vector data to come in directly from the data source upon request. Users can write SQL to retrieve live new vector tiles giving developers tremendous flexibility when applying filters transformations or performing spatial analysis.
CARTO’s geospatial backend reduces the complexity of application deployment and eliminates the need for additional tiling software or extra pre-rendering work.
This demo shows how data transformed and analyzed using PostGIS is rendered with MVTs on the fly. Check out how we are requesting vector tiles with a filter and applying a Buffer on the fly!
As is the case with all our maps the generated tiles are cached at a global Content Delivery Network (CDN) for fast repeat rendering and smart invalidations. We take care of everything automatically on the backend when new data requests are made so you don’t have to worry about servers tiling or scalability.
Additionally our Maps API lets you request from multiple data sources and incorporate multiple layers into a single tile request. That means less calls to the server a more performant experience and more flexibility for the developer.
FLEXIBILITY AND SUPPORT FOR MANY MAPPING LIBRARIES
Vector tiles are rendered client-side by your computer or mobile device as opposed to a server. That means you need a client side rendering engine that can support Mapbox Vector Tiles. The most obvious choice is MapboxGL but you can also use OpenLayers with WebGL support or continue using Leaflet. There are also plenty of options for our CARTO Mobile SDK that already supports vector tiles.
We want to give our users the freedom to choose what software they use with our platform so for example check out here OpenLayers rendering a dataset using MVT
Each implementation works differently using vector tiles so you will need to find out what works best for your use case. Let us know if you want to see examples on other libraries.
DATA RENDERING AT SCALE WITHOUT WORRYING ABOUT PERFORMANCE
Vector tiles need to be as small as possible to keep location apps performant and make sure no browsers are killed along the way from processing more data than they can handle. For example the demos you are seeing on this blog are based on a dataset of 400MB of geometries in NYC. It is not possible to send 400MB to the browser for rendering. Same goes with a point dataset with 100M points you can not send them all to the client for rendering. The solution so far has been to pre-process and package the data to make it work. If you don’t do it you might end up with tiles of 50MB in size breaking entirely the user experience.
When vector tiles are rendered in CARTO we automatically ensure the data size falls within an optimal range and adjust the geometries accordingly. So even if you have a large map or application with complex geometries or a lot of data points the user never experiences slow downs or errors. By simplifying complex geometries and flattening points located in exact same locations automatically you can be certain the user experience of your apps will be great regardless of how much data you’re working with.
These adjustments are dependent on your maps zoom level and never affect the quality of your data visualization. At closer zoom levels all the data is rendered while zoomed out maps will instead provide you information about the overlapping data. When building applications developers don’t have to worry about tile size while maintaining the ability to render heatmaps and build interactive experiences representative of their complete dataset. We provide good default values for this operations but also provide specific parameter to control how it is done.
As an example check out these images of a map where the data is being aggregated smartly by our backend for pixel perfection and another without aggregations.
As a developer when using Mapbox Vector Tiles it is your responsibility to ensure you are not overloading the client with too much data. CARTO takes care of that for you.
THE FUTURE IS IN VECTOR
This is only the first step on more and more vector support across the whole CARTO platform. We will be releasing more capabilities on the Maps API and libraries to support them. Stay tune we are very excited on these developments.
Whether you’re new to CARTO or a Location Intelligence power-user dynamic vector tiles in CARTO open a world of possibilities for location applications. If you already have access to CARTO Engine check out our documentation to get started. Otherwise don’t hesitate to contact us for a demo of this functionality for your specific business needs.
