Delivery & sharing

Handing the work to someone else: an API, an app, a link that keeps working.

The line where a dataset leaves your machine and somebody else’s constraints begin. past this line it is somebody else’s budgetyour machine32 GB, a fast disk,all the time in the worldthe wiretheir browsera few hundred megabytes,one thread, and no patienceeverything here is about what you send, not what you haveTiles, paging, simplification and caching are all the same answer to the same constraint

Everything in this section happens on the far side of a line. Up to that point you have your own machine, your own memory and all the time you want. Past it, somebody else’s browser has a few hundred megabytes, one main thread and no patience, and every byte you send has to cross a network you do not control.

Tiles, paging, generalisation, caching and precomputed aggregates are all the same answer to that one constraint: send less, and send only what was asked for. The interesting decisions are about where the reduction happens — in the database, at the API, at build time, or in the client — and what it costs in freshness.

Two topics: serving features, tiles and imagery over HTTP, and the interactive applications that consume them.

Topics in Delivery & sharing

Each topic page brings that subject's concepts, how-to guides and fixes onto one page.

Other areas

🧱 Fundamentals 📐 Geometry & space 🛰️ Imagery & point clouds 🔬 Analysis 🧠 Modelling & prediction 🏭 Production 🛡️ Governance & trust 🧰 Tools