Derived data · measured, with its limits printed
The tiles that never existed.
This behaves like a map. Drag it, zoom it, and it answers. There are no tiles anywhere: each one is worked out at the moment you ask for it, from 67 kB of corner values and the arithmetic that says which corners to use. A stored pyramid of the same tiles runs to gigabytes, and every one of those tiles would be a copy of something already implied by the 67 kB.
What is actually held
- The store
- 16,641 corners
- Its size
- 67 kB
- Pyramid to this zoom
- 0
- Difference
- 0x
- Zoom
- 1
- Tiles on screen
- 0
- Tiles made so far
- 0
- Time to make one
- 0 ms
- Cache
- off
What is going on
The store is a grid of corner values. Any point between four of them is a bilinear patch, and the only part of a bilinear patch that bends is the x·y term, so four numbers fix the whole square. Finding which square a point is in is a division. That is the entire method: one division to say where, four numbers to say what.
Why the pyramid is redundant
A tile pyramid stores the same field once per zoom level, and the deeper levels are mostly the shallow ones interpolated. If the field is smooth, every tile at every zoom is already implied by one small store. The counter beside the map is that comparison, live: at zoom 10 a stored pyramid is about 92 GB against 67 kB here.
And it is not slower
Against the largest materialised version that fits in memory, a 4096 by 4096 grid, reading a point from corners took 0.033 µs against 0.054 µs, on 1,008 times less memory. The arithmetic is identical either way, so the difference is the memory: a 128 MB grid misses cache on every random read and 130 kB of corners does not.
not claimed That this replaces a real map's tiles. A real map is not smooth. It has roads, coastlines and buildings, which are edges, and no four corners describe an edge. This replaces the part of a pyramid that is smooth, which on terrain is most of it, and the rest has to be kept as an exact remainder. Zoom in far enough here and the note beside the map will tell you when you have passed the last thing the store actually knows.
Where it stops
Three limits, all of them visible on this page rather than described.
- It runs out of detail. The store has a fixed amount in it. Past the zoom where one tile covers less than a corner, you are looking at the space between measurements, smoothly filled in. That is not new detail and the page says so as it happens.
- It is wrong by a measurable amount. Press the button and it measures itself against the field the corners were sampled from, on whatever is on screen. It does not report a number it was told; it works one out.
- It cannot tell you where it failed. This is the important one. A rule has no way of reporting its own error, so the places it gets wrong have to be found by measuring and then kept as an exact remainder. Two separate experiments landed on this today, and it is why every scheme on this site is a rule and a remainder rather than a rule alone.
The whole case, with the benchmarks Run the benchmark on your own file