From Pixels to Planet

A satellite photograph and a globe you can rotate in a browser are separated by more engineering than either extreme suggests. The photo is a flat rectangle of pixels, usually too large to move over a network and drawn in a projection that has nothing to do with a sphere. The globe expects small, predictable pieces that arrive instantly, no matter where in the world the viewer is looking. Everything described below exists to close that gap — and each stage exists because the stage before it created a problem the next one has to solve.

01 — Ingestion: arriving as a claim, not a fact

A file that lands in the system is a claim about the world, not yet a fact about it. Before anything is stored, it has to be checked against geography itself.

An uploaded image comes with metadata asserting where its corners sit on the earth — four latitude/longitude pairs. That assertion can be wrong in ways that are invisible until rendered: corrupted dimension fields, corner points listed out of order, or a shape that quietly crosses the antimeridian, the 180th meridian where longitude flips from +180 back to −180. A footprint that straddles that line looks, to naive coordinate math, like it stretches nearly the entire way around the planet the wrong direction. Catching that at ingestion — rejecting or flagging the crossing before it becomes a stored asset — is far cheaper than debugging why a globe suddenly renders a continent-wide smear months later.

Geography doesn’t fail loudly. A bad coordinate doesn’t throw an error — it just draws the wrong thing, confidently.

02 — Translation: many dialects, one internal shape

Nothing arrives in the system’s native tongue. A survey crew exports a drawing, a field team shares a placemark file, a satellite operator delivers a scene as a tagged raster — each format built by people solving a different problem than “render this on a globe.”

Every incoming format has to be read for what it actually is before it can be treated as geography:

Drawing exchange formats carry lines, polylines, and arcs the way a drafting tool sees them — precise geometry, but frequently in a local, arbitrary coordinate system with no inherent tie to latitude and longitude. Before this geometry means anything on a globe, it needs a real-world reference frame stitched onto it, often from control points supplied separately.

Earth-markup formats — plain-text placemark and path documents, and their zipped form bundling that same document with its icons and overlay images — already speak in real coordinates. The work here isn’t reprojection, it’s unpacking: pulling individual geometry and style records out of what was authored as one browsable document, and separating the referenced images from the coordinates that place them.

Tagged raster imagery embeds its own affine transform and reference frame directly in the file’s header, so it mostly arrives self-describing. It’s the closest any input gets to the internal shape already — what’s left is normalization, not translation.

Elevation data is the format that looks like the others and isn’t. A terrain grid is structurally identical to any other single-band raster — read naively, it’s just a confusing grayscale picture. Read correctly, each pixel is a height measurement, and that distinction determines everything downstream: whether the globe ends up with a photograph pasted onto a flat plane, or ground that actually rises and falls under the camera.

Every dialect converges on one of two internal shapes — drawable geometry, or a height field that has to stay a height field.

That last distinction carries all the way to the tiling stage: imagery gets cut into a pyramid of pictures, but a terrain grid gets cut into a pyramid of simplified 3D meshes, so a renderer can physically lift the ground rather than merely texture it. Along the way it’s common to derive slope and orientation from the same grid — not for storage, but to shade the terrain convincingly before a single tile is ever requested.

03 — Processing: trading fidelity for reach

A validated image is still the wrong shape for distribution: often oversized, in a format built for archival fidelity rather than transport.

This stage normalizes the asset — downscaling oversized rasters, recompressing into a transport-friendly format, and correcting metadata that survey and camera equipment routinely gets wrong (mirrored dimensions, missing orientation flags). None of this is aesthetic polish; it’s the difference between an asset that can be requested a thousand times a day and one that can only ever be opened once, slowly, by a single viewer.

The output of this stage is a clean, canonical source image — the last point at which the entire asset exists as one contiguous file.

04 — Tiling: cutting the world into requestable pieces

A single canonical image still can’t be sent whole. A viewer looking at one city block shouldn’t have to download imagery for an entire continent to render it.

Tiling solves this by pre-cutting imagery into a pyramid: at the widest zoom level, the entire dataset fits in one small tile; at each level deeper, that tile splits into four, each covering a quarter of the area at double the detail. A viewer only ever requests the small handful of tiles that intersect its current view at its current zoom — never the whole dataset, at any zoom.

z0  [ full dataset ]
z1  [ NW ][ NE ][ SW ][ SE ]
z2  [ ... ][ ... ][ ... ][ ... ] × 4
         viewport requests 4 tiles

Each zoom level quarters the tile size — a viewport only ever pulls the tiles it can actually see.

Rasters and vectors both go through this, but they diverge in what a tile contains. A raster tile is a finished picture — pixels, already drawn, cheap to display and expensive to restyle. A vector tile is closer to a set of instructions — roads, boundaries, points — left undrawn until the moment of rendering, which is what lets a globe re-theme itself (day/night, satellite/schematic) without re-fetching a single byte from the network.

05 — Serving & caching: answering the same question fast, twice

Tiling makes each request small. It does not make the request free — someone still has to look up which file answers “give me tile z/x/y,” and do it fast enough to feel instant.

A tile server’s job is mostly bookkeeping: knowing which sources exist, matching an incoming coordinate to the right file or database row, and reacting when new data shows up without needing a manual restart to notice it. Under any real traffic, though, the same handful of tiles — the ones near a capital city, the ones at the world’s default starting view — get requested over and over. A cache sitting in front of the lookup turns those repeats from “recompute or re-fetch” into “hand back what’s already in memory,” which is the difference between tens of milliseconds and a response a user can perceive as lag.

The harder problem caching introduces is knowing when a cached answer has gone stale — when the underlying data changed and the cached tile is now confidently wrong rather than confidently right. A cache with no invalidation strategy is just a very fast way to serve outdated imagery.

06 — Rendering: drawing a sphere from a grid

The last stage takes flat tiles and a flat coordinate grid and reconstructs the illusion of standing above a curved planet.

A 3D globe renderer projects each tile onto its correct patch of an ellipsoid, blends neighboring zoom levels as the camera moves so resolution changes feel continuous rather than sudden, and layers atmosphere, lighting, and sky treatment on top so the result reads as a place rather than a wireframe. Where the earlier elevation grid was kept as a height field instead of a picture, this is the payoff: the renderer displaces the ground mesh itself, so imagery drapes over real relief instead of sitting flush on a sphere. It also has to be honest with the viewer: if a tile being displayed is known to be stale — superseded by newer data still propagating through the pipeline — that uncertainty belongs on screen, not hidden behind a picture that looks exactly as authoritative as a fresh one.

The globe is the only stage the viewer actually sees. Every stage before it exists to make this one look effortless.

---

None of these stages is optional, and none of them is interesting in isolation — a validator that only checks coordinates, a compressor that only shrinks files, a cache that only stores bytes. What makes the system work is that each stage’s output is shaped by exactly what the next stage needs, and nothing more. That’s the actual design principle underneath a spinning globe: not any single clever technique, but a chain of narrow, honest handoffs from a raw photograph to a place you can trust.