Vector Tiles generation. Do’s and don’ts
Esri has been supporting and providing vector tiles for years. During the past year, I have had clients requesting help moving their old raster-based caches to vector tiles. The goal is usually to keep their base maps current as the data get updated daily by their ETL processes.
Going from raster tiles to vectors is more than just changing the format of your caches. You have to change your mindset. What you used to do to optimize your data for vector tiles is not relevant anymore. It might even be detrimental.
In this article, let’s dive into what you need to stop doing when going from raster tiles to vector tiles. We will also investigate what you need to do to your input data to make your vector tiles packages smaller.
The basics
Raster tiles are the oldest type of map cache you can create. Your map gets split into image tiles for each level of detail (LOD) you want to support in your web applications. While you can have complex symbols in those map caches, the drawback is they take a long time to generate. It is a major problem for a country the size of Canada.
Vector tiles services serve data in vector format. Your data is broken down into tiles as well but what the web client receives from your web server is a set of points, lines, geometries, and a style. This has many advantages: the style can be edited separately. Vector tiles generation is also insanely quick. However, it does not support advanced cartography the way raster tiles can.
The don’t
Stop generalizing for smaller scales
One of the common features in maps prepared for raster tiles is to have different representations at multiple scales. It is quite frequent that the data is simplified for smaller scales. The example below provides an example of what the data might look like at different scales. We don’t display the road network at first. As we zoom in, the freeways appear first, then the arterials, until we see the entire road network when viewing the data at a local scale.
It is a common practice that the data at small scales is simplified, to speed up the cache generation. However, it is not a good idea when working with vector tiles. The reason is, that the vector tiles generation process has its own generalization algorithm. Adding your own generalized feature class for smaller scales actually makes your output vector tile bigger.
Let’s do a demonstration. I will create 2 vector tiles from two identical maps. The only difference is that the road network in one map will be generalized using a tolerance of 3 meters, except at the largest scales. Anything at scale 1:2,500 and beyond will still be using the original, non-generalized data.
As you can see, the map that references the raw data at large scales, and the simplified data at smaller scales creates a larger vector tile. This is not good for your end-user. Let the vector tiles generation algorithm handle the generation for you.
Is it bad to generalize my data then?
It is okay to generalize this data once and use that data source at all scales. What you don’t want to do is generate multiple versions of the same dataset simplified for different scales. It conflicts with the generalization algorithm of the vector tiles generation.
The dos
The name of the game with the does is to reduce the number of vertices in your output tile. Beyond a certain point, you will get too many vertices in a tile, and performance will suffer. There are several ways to reduce the number of vertices.
Remove unnecessary line splits
Depending on some of the datasets you are using for roads or waterways there might be quite a few vertices that are created because attributes differ between segments. This is particularly true in roads network as new segments get created as soon as the number of lanes, the speed limit, or the type of pavement changes.
In the example below, we have a road that has been split into different segments just because the speed municipality changes. We don’t care about that in our cache: what we care about is having fewer vertices.
Luckily those segments can be dissolved using the right geoprocessing tool. Those coordinates used for each endpoint now are stored only once as one vertex.
The result of applying this process is a smaller road network. My vector tile goes from 114 MB to 111 MB. You can then use the simplification tool to remove those small vertices if they do not bring additional spatial resolution to your cache.
Do not display small polygons at small scales
Small objects do not belong to small scales. When the user zooms out, anything that is on the map that is too small to see is waste. Let’s take two examples.
You can filter out this data by using display filters in ArcGIS Pro. The return on investment can range from a few kilobytes to a few megabytes depending on your data.
Conclusion
Don’t generalize your data for each scale. This is the way of the past. Instead, optimize your data for display-only purposes by reducing the number of vertices. Simplify the root data if needed. As you change scale, make good use of display filters. The combination of those strategies will result in smaller, more efficient vector tiles.
Resources
- Caching vector and raster tiles. Developer Summit 2020 proceedings.
- Author a map for vector tile creation. ArcGIS Pro documentation.
