> Hm, I see, so this can output the virtual miplevels quickly? Yes: when you see the tiles on (say) http://www.nanocubes.net/view.html#twitter http://www.nanoc

> Hm, I see, so this can output the virtual miplevels quickly? Yes: when you see the tiles on (say) http://www.nanocubes.net/view.html#twitter http://www.nanocubes.net/view.html#twitter, what you're getting is not a precomputed tile: the server is actually visiting the datastructure every time (and I hope I can convince you that at that speed, it is not touching 210 million points :). The reason you can't precompute all choices is simply that there's too many of them and you'd run out of bits in the universe (the paper, http://www.nanocubes.net/assets/pdf/nanocubes_paper.pdf http://www.nanocubes.net/assets/pdf/nanocubes_paper.pdf, has details). > Also, would it work with a "full" dataset (i.e. no empty cells)? Not exactly. We get away with an in-memory data cube exactly because in many practical cases the data is sparse over the address space. With dense data you'll take a much more significant memory hit (but it's one you'll have to take with any aggregation scheme. The paper, again, has details) > Also consider miplevel interpolation, makes the transitions between levels much easier on the eye (doesn't work well with nearest sampling). That's fair, although again we're hoping to keep the WebGL version feature-compatible with the leaflet.js version (that does canvas-only, and has no zoom transition at all); the smooth version looks nicer, as you can see in the (bit on the PR-heavy side, sorry) following video https://www.youtube.com/watch?v=8P9QA6TJwys#t=69 https://www.youtube.com/watch?v=8P9QA6TJwys#t=69