Places

Web Cartography and Routing: From Map Servers to Open Tiles

Putting a working map on the web used to be a substantial engineering project. Not styling a map — merely serving one that a visitor could pan, zoom and search. The way that problem was solved, abandoned and re-solved is one of the more instructive arcs in web publishing, and it left a great many small map sites stranded when the ground moved.

The map server era

In the late 1990s and early 2000s, a map on a website was almost always generated on demand by a dedicated map server. The browser sent a request describing an extent and a set of layers; the server rendered a single raster image and returned it. Panning meant a new full-image request and a visible reload.

These systems were capable — they handled projection, symbology, labelling and spatial queries — but they were heavyweight, licence-bound and operationally demanding. A regional atlas or an island road map published this way depended on a specific server product, a specific version, and often a specific machine. When any of those went away, the map went with it. This is the single most common reason that map sites from that period are dead today while their text-only contemporaries survive: the text was files, the map was a service.

The interfaces were at least standardised. The OGC Web Map Service specification defined how a client asked for a rendered map image, and its sibling Web Feature Service defined how to ask for the underlying features. Those specifications are still in use, and a surprising number of public-sector map endpoints still speak them.

The tile revolution

The change that made maps ordinary was a simple reframing: stop rendering arbitrary extents, and instead pre-render the whole world once into a fixed pyramid of small square images. Each zoom level is a grid; each cell is a tile at a predictable address.

The consequences were disproportionate to the idea's simplicity.

• Tiles are static files. A tile can be cached by every layer of the internet, served from ordinary hosting, and copied. The map stopped being a service and became content again.
• Panning became continuous. Fetching the neighbouring tiles as the user drags is trivial, which produced the fluid slippy map people now expect.
• The client got the hard job. Assembling and positioning tiles moved into JavaScript, which meant the server no longer had to be clever.

Vector tiles later refined this further by shipping geometry rather than pictures, letting the client restyle and re-label without re-fetching — which is why modern maps can change theme instantly and rotate labels smoothly.

Routing is a separate problem

Displaying a map and computing a route through it are unrelated engineering tasks that got bundled together by products, confusing a generation of site owners. Rendering needs geometry and symbology. Routing needs a topologically correct network: segments that actually connect at shared nodes, with direction, turn restrictions and traversal costs.

Data that looks perfect on screen routinely fails at routing. Two roads drawn crossing at a junction may have no shared node, so no route can pass between them. A dual carriageway drawn as one line cannot express its central reservation. Bridges and underpasses that cross in plan must not connect. Cleaning a network to routable quality is usually a larger job than acquiring the geometry was.

Today the routing engine is normally a separate component — open implementations such as OSRM and Valhalla take a network extract and answer route queries independently of whatever draws the basemap. Decoupling the two is the right architecture and would have saved many of the integrated systems that died.

Projection: the thing that quietly breaks everything

Web maps overwhelmingly display in a spherical Mercator projection, while source data commonly arrives in a geographic coordinate system or a national grid. Mixing them produces errors that are subtle enough to survive review: features offset by a consistent distance, or areas and distances computed wrongly while positions look fine.

Record the coordinate reference system of every dataset explicitly, at the point of acquisition, and never rely on a default. Almost every map alignment bug is a coordinate reference system that somebody assumed.

What small publishers should do now

The lesson of the map server era is to keep the data separable from the display. Hold your features in an open, documented format that you could hand to anyone. Treat the basemap as replaceable infrastructure. If a rendering stack disappears — and they do — a project holding clean, well-described geometry re-renders in an afternoon, while a project holding only a configured server holds nothing.

OpenStreetMap changed the economics here permanently by making a global, openly licensed base network available to projects that could never have licensed one. Named places are a harder problem than the network, and they get their own treatment in point-of-interest data.