Building a Vector Map from Scratch

Web Mercator Projection

To start, we should probably talk a bit about map projections, in particular the Mercator projection. It’s the standard projection you’ll see in almost all web-based maps. One thing to note, is the distance between latitudes becomes greater near the poles, so there’s a decent amount of distortion the further north and south points are.

circles indicate level of distortion near the poles.

The Web Mercator projection is a slight variation on Mercator, but the formulas still mostly apply. For web maps, the origin (0, 0) is considered to be at the top-left, with x+ increasing to the right, and y+ increasing downwards.

So we can use the projection formulas convert our latitude & longitude values to an XY value on the map. For these examples, I’m going to use code from the MercatorCoordinate class that is a part of the Mapbox GL JS library.

So if we take an example point [-73.9911, 40.7343] (NYC), we can convert it to a point in the XY space. We'll call this coordinate system the "world space". We can think of this as a single map tile at zoom level 0.

lat/lng coordinates converted to XY world space.

WebGL Clip Space

Now that we have our “world space” coordinates, we can convert them to the “clip space” coordinates that WebGL uses to render a scene. The clip space is slightly different than our world space, in that the origin is at the center, and going from [-1, 1] on the axes.

webgl clip space

So we can convert our world space -> clip space with some pretty basic math. This can also be done via a matrix transformation (which we’ll cover later), but for simplicity we can just do this conversion in our MercatorCoordinate utility.

lat/lng coordinates converted to webgl clip space.

Rendering a bounding box

Now that we have a way to convert latitude & longitude to our WebGL coordinate space, lets go ahead and draw something! We’ll start simple and draw a basic bounding box.

Since our initial view is zoomed all the way out (zoom level 0), we’ll use a box large enough to see, so we’ll bound the continental US.

In order to render a box in WebGL, we need to convert it into a set of triangles, which is the smallest primitive type for rendering a surface. A rectangle is a pretty simple shape, which can be drawn with two triangles. Since the box has 4 coordinates, we can arrange them like so to form a rectangle from two triangles.

Note: Since WebGL only supports a few primitives, this is generally where something like three.js would come in handy, as it has better abstractions for drawing shapes.

a webgl box can be formed with two triangles.

To render the triangles, we’ll convert each lat/lng from our box into clip-space, and construct an array with each of the vertices for the triangles (so 6 points in total).

Now that we have our vertices, we need to render it to a <canvas>.

Unfortunately, there is a lot of boilerplate needed to setup a WebGL scene, so I’ll document most of this in the code snippet below. But the gist is:

• Get a WebGL context from our canvas element
• Compile the shaders, and setup our program
• Convert our lat/lng’s to clip-space vertices
• Tell WebGL to render the triangles

After doing all that, you can see the rectangle in the upper-left quadrant of the grid. This is where we'd expect it to be based on the image we've been using as a reference so far. You can also toggle the map on to check that it's rendered correctly.

Show map

Adding Interactivity

To have a useful map, we’ll also want the ability to move around. We can add some basic map behaviors such as pan & zoom.

To do this, we’ll need to introduce the idea of a “camera” for moving the viewport around the scene. This differs from a traditional camera, in that instead of moving the camera around, we’ll actually move the world around the camera. For instance, if we want to pan to the left, we’ll actually move all the vertices in our scene to the right by that same amount (we’re basically inverting the behavior we’d expect).

For our purposes, the camera will keep track of the XY position, and the current zoom level. These will then be represented as vectors, that when applied to a matrix (ie. the projection matrix) will make up the final state of the scene.

We can think of each vertex on our map as vector with three points: [x, y, z]. The idea behind using a matrix is that we can multiply the vector by the matrix to get the new vector position. For instance, if we take our vertices from above and multiply them by the identity matrix, we can see we get the same result (ie. no transformation).

Note: since WebGL is a 3D interface, it expects vertices to have x, y, and z values. Since we’re only dealing with xy values, z can mostly be ignored.

If we wanted to pan the map to the right, we need to translate all of the vertices by the same amount the mouse has moved (in this case, in the x+ direction). So if the map was panned 20 pixels to the right, we’d convert that 20px to clip-space (0.92), and can represent the translation with the following matrix.

Similarly, if we wanted to apply a zoom, we can add a scale factor that gets multiplied to the vertices. For zooming, that factor is 2^zoom. So if we at a zoom level of 1, our scale factor is 2.

One other caveat with zoom, if we want to zoom in on the mouse position, we'll need to grab the pre & post transformation positions of where the mouse is, and translate accordingly. There's a great article at webglfundamentals.org that covers this in depth, so I won't go into too much detail there.

The matrix containing the scale and translation values is what we’ll then pass into our vertex shader, so these vertex computations can be done on the GPU.

Once we setup the event handlers and update our matrix, we should be able to pan & zoom the bounding box. I'm using the glMatrix library to handle the matrix math.

Rendering GeoJSON

Let’s now take a stab at rendering something a little more complex than a rectangle. For instance, this polygon of Washington state (my home state!)

geojson polygon for washington state

Like the rectangle, we’ll also need to divide the shape up into triangles, though it’s a little less obvious how to do that for a shape of this complexity. Fortunately, there are a number of libraries that do just that. We’ll use Mapbox’s earcut, since it has support for GeoJSON geometries out-of-the-box.

To use earcut, we’ll first need to flatten the polygon into a single array of coordinates, and then pass that into the earcut for triangulation. The result is an array of indices for how to draw the triangles. One thing to note, each point in triangles array is for both the latitude & longitude, so you’ll need to get the vertices from vertices[i] and vertices[i + 1].

Now that we have our vertices, let’s swap that out for our bounding box from earlier. We'll also need to set the initial camera position to be closer to the actual geometry. We can see the triangles by changing the primitive type to gl.LINES.

And if we want to do render a MultiPolygon, we can just combine the vertices from each polygon into a single array.

At this point, we have a pretty solid foundation for our map. We can pan, zoom, and render complex geometries. In Part 2, will cover adding vector tile support.

Part 2: Vector Tiles

In Part 1 we created a map that can render GeoJSON polygons. While this is fine if you’re rendering a handful of geometries, it doesn’t scale well if you want to render many more layers, and across the whole planet. For instance, if we wanted to display every building in the US, we'd need to load and render millions (or hundreds of millions) of vertices for the scene.

This is where tiling comes in. I cover this a bit in previous articles, but the idea is the world is broken down into a grid at each zoom level, so we only need to load the data visible in our viewport.

For these examples, we'll be using a tile size of 512px (meaning each tile is 512 X 512 pixels).

Determine Visible Tiles

The first thing to do, is figure out which tiles are in view given our viewport. To do this, we can figure out the lat/lng position of each corner of our viewport (we’ll need to do some conversion math to go from the screen pixel to lat/lng). Once we have a lat/lng and zoom level, we can use that to determine which tile it’s in.

Mapbox has a nice utility library tilebelt for doing these lookups. We can use pointToTile to lookup the min & max tiles once we know the bounding box of our viewport.

One thing to keep in mind, is our viewport might be larger than 2 tiles (> 1024px) so we’ll probably want to consider all tiles between the min and max as “in view”. For example, we could have something like the image below, where the viewport bounding box spans 12 tiles, even though they aren't all fully in view.

As we move the map around, the tiles in view should update. Panning left & right should change the tiles in view once we cross a border.

Zooming in & out though is where the real “magic” of a vector map comes into play. Instead of jumping between discrete levels (1, 2, 3 etc…) we can just scale the geometries according to the zoom values in between integers (ie. 1.25 … 1.98). Once we cross into a new zoom integer, we’ll need load a new set of tiles based on that level.

The best way to see how this works in action is to render the tile boundaries as we move around the map. We can use the code above for finding the tiles in view, and run them through tilebel.tileToGeoJSON to render them on the map.

Note: the demo here is using a 256px tile size for demonstration purposes.

Load Vector Tiles

Now that we have a way to determine which tiles are in view, we can go ahead and fetch the vector data from a tileserver.

I covered setting up a vector tile server in a previous article, so I’m going to reuse the existing tile server from there. We just need to replace the x, y, and z values in the URL to fetch the correct tiles.

You’ll notice the URL ends with .pbf, so we’ll be getting the data back in Protobuf format. This is a binary format, that we’ll need to deserialize into an object that we can use. Fortunately mapbox has a library that does this for us. @mapbox/vector-tile can deserialize PBF data into a VectorTile object according to the vector tile spec.

If we inspect a tile, we can see a .layers field, which contains all the different layers we can potentially render for that tile.

You’ll notice VectorTile also has a toGeoJSON function that we can call on each feature in the layer. As we demonstrated in Part 1, we have the ability to render a GeoJSON polygon using earcut. Given that, we should be able to render tiles using the following process:

• Detect changes to tilesInView
• Fetch each tile in view from the server
• Convert the features to GeoJSON
• Render the feature

If you’re familiar with New York City, you should be able to make out the outline of the waterways and the parks. You’ll also notice some flashing, and lag when maneuvering around some of the more complex shapes. This is still a pretty rough implementation, and we’ll cover some performance enhancements and optimizations in Part 3.

Part 3: Optimization and Cleanup

Part 2 of this series left off with a working map that can render geometries from a vector tile server. However, the experience is still rather laggy and has some unpleasant flashes of content. Up to this point, we’ve also just been writing the map code as one-off scripts, with most the values hard-coded.

In this part, we’ll address these performance issues, as well as refactor our code into a more generic, reusable library.

Adding a render loop

Up to now, we’ve just been re-rendering the map whenever there is an interaction, such as a pan or zoom. While this does save us some CPU cycles to not have the canvas constantly re-drawing, it does have some UX implications, especially when it comes to loading the tiles asynchronously.

Rather than calling draw() whenever a state change happens, we’ll just use window.requestAnimationFrame to let the browser render the frame when ready. So when panning & zooming, we’ll just make updates to the camera & matrix values, and those changes will get picked up in the next loop.

A similar approach can also be used for loading the tiles. Instead of awaiting for all the responses to complete and blocking the loop, we can just update the tile data for each request as it completes. So tile requests that are quicker, will get rendered earlier.

Now that we’re loading the tiles concurrently, you'll notice the flashing happening on a per-tile basis, rather than all-at-once. However, you might have got into a state where the map was killed (trying not to crash your browser!).

Since we’re now calling draw many times per second (ideally 60), we are making a ton of calls to shuffle data into GPU. For instance, here are the stats for the most recent frame that was rendered:

// last render stats
no. of gl draw calls: undefined
no. of vertices: undefined

That means for each frame, it needs to buffer data into WebGL times. Which is (probably) a lot, considering we're trying to aim for 60 frames per second.

To fix this, we can cut down the number of times we're buffering data into the GPU.

Reducing WebGL buffer calls

In the current approach, we’re storing the vertices for each individual feature, for each layer, for each tile. In other words our tileData, which is storing the data per-tile, looks something like:

tileData: {
  '1/1/1': {
    layer_1: [
      feature_1 vertices,
      feature_2 vertices,
      …
      feature_n vertices,
    ],
    … // more layers
  },
  '1/1/2': {
    …
  }
  … // more tiles
}

Since all the features for a given layer are rendered the same (ie. same color), we can just combine all of the feature vertices into a single array for the layer. This will cut down the number of times we need to reset the buffers and call gl.drawArrays to once per layer, per tile. So our new tileData structure will look something like:

tileData: {
  '1/1/1': [
    { layer: ‘layer_1’, vertices: […] },
    { layer: ‘layer_2’, vertices: […] },
    …
  ]
  …
}

And the updated code that processes the tile:

You’ll notice the frame rate is consistently much higher, and navigating is much smoother. In fact, the jump in performance was high enough that we easily added an additional buildings layer (the brown-ish rectangles rendered at high zoom levels).

// last render stats
no. of gl draw calls: undefined
no. of vertices: undefined

Even though the frame rate is higher, we’re still getting some flashing when loading the tiles, so let’s address that next.

Tile caching

The tile flashing is a relatively simple fix. In our updateTiles code, we just need to check if we’ve already loaded that tile at some point, and just re-use the data if it already exists (instead of fetching it from the server).

As we move around, we can see how many requests we're saving by not refetching tiles already loaded. There's still some flashing the first time a tile is loaded, but cached tiles should render seamlessly when moving between them.

tiles loaded: undefined
cache hits: undefined

Buffering tiles

Now that we’ve solved the issue of repeatedly flashing tiles, let's clean up the flash on the initial load, that can sometimes be seen when moving the map quickly.

We know that cached tiles will render seamlessly when moved back into view, so we can actually pre-load tiles that are near the viewport (ie. tiles we will likely navigate into).

We just need to configure how much we want to buffer. For now, let's just load an additional tile in each direction (min - 1, max + 1) to make sure the nearest tiles are covered for panning, as well as the parent (tiles above). We'll talk about the child tiles in the next section.

With the exception of zooming in/out really quickly, the flashing should be greatly reduced when moving around. But we can take it a step further by scaling the data we already have to fill in missing tiles.

Scaling Tiles as a Placeholder

The last thing we’ll do to prevent the flashing you see when zooming, is to just keep scaling the data that we already have in place of tiles that are still downloading.

Take zooming in for example. If we’re on zoom level 8, we will keep scaling the tiles up until we hit zoom level 9, at which point we render the level 9 tiles in view. But if those aren’t done being downloaded and parsed yet, we’ll see a white square in its place. So what we can do, is continue to scale the level 8 tile up in its place, until we have the data for the correct tile (ie. we’ll still be rendering the level 8 tile at 9+).

Similarly with zooming out, we can render all of the children for a tile if the one at the lower level isn’t available. This one is a bit more noticeable, since as we zoom out, we might only have partial children available for a parent tile. Take the screenshot below for instance, notice that not all of the child tiles are available. So while still not perfect, it’s slight improvement on the whole tile being blank.

rendering a tile with partially loaded child tiles

To accomplish this, we just need to introduce some fallback behavior for when tile data from tileInView is not available. We’ll favor the case where the parent tile is available, since that will always cover more area, but we can still fallback to the child tiles in cases where we’re zooming out.

We can leverage the tilebelt library again for determining the parent tilebel.getParent and children tilebelt.getChildren tiles.

And adding this fallback behavior to our code, should provide a smoother experience (ie. fewer flashes) as we move around the map.

One issue with the current approach, is the CPU overhead of running lots of requests concurrently, and parsing the geometries (which is a CPU blocking operation). For instance, the initial load of the map fires off ~30 requests to load all the buffered tiles.

tiles loaded: undefined
cache hits: undefined

Since a lot of this is work that can happen in the background, we can offload it to a Web Worker to free up resources on the main thread.

Using a Web Worker

The most resource heavy part of our code right now is probably the HTTP request to fetch a tile, followed by converting the geometries to vertices & triangles. Luckily, both these tasks are part of the same operation (fetch then parse), so we can pretty easily move this code to a WebWorker, which leaves the main thread free to handle the render loop, and other map interactions.

If we abstract a way the fetching / parsing code into a fetchTile helper, our worker is pretty simple:

And then when looping through our updated tiles, we can hand them off to the worker for processing

The results aren’t that indistinguishable from the previous buffered example, probably due to the bottleneck being the latency on the http request, which is the same regardless. We could probably measure the difference in CPU, but it’s likely negligible given we’re only rendering a few layers.

Wrapping it all up

Up until this point, I’ve been using a one-off JS script for every map. While this is fine for quick prototyping, it’s not very reusable, and makes it difficult to configure settings on-the-fly since most values are hard-coded.

The last piece, is wrapping this all up into a reusable library with a standard map-like interface than we can instantiate with our configuration, and easily update.

You can find the code for it at webgl-map on Github as well as the demo-page built with the library.

If you’ve followed along, I hope you’ve enjoyed, or at least found it helpful. If you have any questions or comments, feel free to get in touch.