History of Rendering Web Maps
Class 2
We’re going to take a journey deep into the history of map-making and how it led us all the way to the whiz-bang mappy miracles we see in modern maps today.
Ok, maybe not quite that far back...
Let’s start with print maps (you’ve probably made a few of these in your mapping career already).
What are the basic steps to making a map?
With static and print, there is one extent and one scale to style for (generally speaking, of course).
Add data
👇
Style data at specific scale and extent
👇
Export to PDF/image
This is not to say that print cartography is easy...
...but rather that it is straightforward compared to cartography for world-scale interactive maps.
When designing an interactive, multi-scale map, you have to design for many possible extents and scales.
The solution to this problem, employed by early webmaps and still common today, is to create a bunch of static maps at predetermined scales and extents.
Early web maps:
In the first iterations of this approach, every “pan” of the map was really a new, pre-created image loading on the page (static maps forever).
Tiled web maps:
Instead of a loading a static map for a limited number of extents, the tile era allowed users to set their own extent and the map client would handle loading just enough tiles to make the map look good.
The standardization of the tile led to a mini explosion of growth in the mapping world…
...including a product called TileMill and a company called MapBox
🤔 Remember the three basic steps to designing a print map:
Add data
👇
Style data at specific scale and extent
👇
Export to PDF/image
For multi-scale interactive maps, it’s the same steps, but with some twists:
Add all the data you might possibly need
👇
Style data at a specific set of scales and extents
👇
Export a billion (approx) tiny tiles
Mapnik is the monster that eats data and stylesheets and poops out map tiles with the exact right extents, at the exact right zoom levels, stored in the exact right structure.
Cool! 🤓
But the magic of TileMill happened beneath the surface.
TileMill is a visual interface for interacting with a much more powerful tool: Mapnik.
In TileMill, users defined styles with a special styling language called CartoCSS that defined how each data layer should be displayed at each zoom level.
CartoCSS is cool, but we won’t be getting into it further. Just know that it was around to help cartographers style their interactive maps.
TILEMILL RECAP:
TILEMILL RECAP, ctd...
There’s a catch, right?
Several!
2. Size
Storing tiles for the entire world, at 16+ zoom levels, and in multiple style flavors takes up a TON of space.
3. Malleability and updates
What happens when features change? You have to re-render the entire world, which could take a long time.
In an ideal world, you could create map tiles on the fly based on desired image quality and styling rules.
Enter the Mapbox Vector Tile Specification!
Vector tiles are similar to the map tiles we’re already familiar with:
The world, in a grid.
But they contain vector data instead of images.
🙋♀️ Why does this matter?
Why do you think? Hint: think back to the TileMill shortcomings we discussed earlier?
🙋♀️ Why does this matter?
Vector tiles separate data storage from map rendering.
Because you’re only storing data and a list of the rules for how the map should look, rendering only needs to happen at the very end of the process.
💽 A note about vector tile formats
Tiles that conform to the Mapbox Vector Tile Specification (the most common VT spec you’ll run into) are usually served with one of a few extensions:
Mapbox released Mapbox Studio (now called “Classic”) to focus on this separated data/style paradigm.
Convert your vector data (GeoJSON, shapefiles, etc.) into vector tiles.
Create stylesheets to determine how your map will look.
SOURCE
MODE
STYLE
MODE
The process for creating a map with Mapbox Studio Classic was kind of confusing.
(you don’t need to know this stuff. We’re just talking about it to illustrate why things are better today 🙂)
The Gist:
As opposed to a big ol bucket o tiles (TileMill), the output of Mapbox Studio Classic was:
No raster tiles are created at all...
GAH
😖
Until you ask for them...
😨
Raster tiles are rendered on the fly, only when they’re needed. This solves the three problems we talked about earlier:
Client side:
🦗
Server side:
Super dope rendering on the fly super fast and great.
💻 Moving to the client
With Vector Tiles and Mapbox Studio Classic, styles and sources were separate things that got smashed together into tiles on-demand, right? What if you could make it even more on-demand?
Mapbox GL is a way to render maps with vector tiles in the browser rather than as images on the server.
💻 Moving to the client
🚂 Render on the server with Mapnik. Vector tiles are combined with CartoCSS styles (both of which are stored on the server), fed to Mapnik, and raster tiles are created and served to the browser.
🚅 Vector tiles and style documents are stored on a server and both are served to the browser. As a final step, the map is rendered in the browser with the help of your device’s graphics processing unit.
This makes map loading super fast. It also means you can do cool stuff like:
So, how does this work?
💗 At the heart of the process is Vector Tiles, those little squares filled with data from earlier.
🎨 But because those tiles are just data, your browser needs guidance on what to draw and how to draw it.
Enter the Mapbox GL Style Specification!
(yes, another spec!)
The stylesheet contains all the information needed to draw your map, including:
Mapbox GL Styles
Style rules are defined in the spec as layers: styled representations of data.
Styles are written as JSON. Each layer has a number of properties that describe where it should go, how it should look, and what data it should reference.
But no one wants to write a bunch of JSON by hand. 😬
This is where Mapbox Studio comes in!
Mapbox studio is a visual interface for creating GL stylesheets!
Hands on time!
Hands on time:
🙋♀️ What did you discover?
Map rendering recap
TileMill
Mapbox Studio Classic
Mapbox Studio