Seams, labels and edges

Where the grid fights the geometry

A tile map works by cutting the world into a grid of equal squares, each rendered or served independently. That independence is the whole point: tiles cache, parallelise and stream with ease. But features do not respect the grid. A river, a rail corridor, a national border — any linear geometry that crosses a tile edge must be handled by two separate tiles, each of which knows only its own square of the world.

For raster tiles the problem is largely solved at render time. The renderer sees the full dataset, draws everything, then slices the image into tiles. Lines and polygons cross seams without incident because the cut happens after drawing. Visual continuity is guaranteed; no special logic is required at the boundary.

Vector tiles are the hard case. Each tile contains only the features that fall within — or intersect — its bounding box. A feature that crosses the edge is clipped to the tile boundary, and its neighbour tile clips the same feature to its own boundary. Render both tiles side by side and the geometry rejoins. Render one tile alone and you have a polygon open on one side, or a line that stops dead. This is not a defect; it is how the format must work. The responsibility for visual continuity shifts from the data preparation stage to the client renderer.

The seam problem compounds at tile corners, where four tiles meet. A polygon vertex that falls exactly on a corner can vanish from all four tiles or appear in all four, depending on how the clipping logic handles shared edges. Careful tile generation uses a buffer — a margin of geometry slightly beyond the tile boundary — so that stroked lines and filled polygons overlap cleanly when the client assembles the grid. Without that buffer, hairline gaps appear between tiles at certain zoom levels, especially on high-density screens where sub-pixel rounding is unforgiving.

Plate 2

A cut mark fixes a height by agreement. Revise the agreement and every level surveyed from it moves with it.

Photo: Ordnance Survey cut mark with bolt · Wikimedia Commons

Labels are worse still. A city name spanning thirty pixels cannot be split across a tile boundary and reassembled. Tiled label placement must suppress any label whose anchor point or text box would straddle an edge, then rely on the client to deduplicate labels that legitimately appear in adjacent tiles. The result is that labels near tile boundaries are the last to appear and the first to be dropped — which tends to mean labels near the edges of the user's viewport, exactly where they are most likely to be seen as the map pans. Solving this cleanly requires the client to batch label placement across a neighbourhood of tiles simultaneously, not tile by tile.