Historically, to make sense of that scenario, the ubiquitous solution was server-side tile imagery. In a nutshell, it divides the entire planet into a recursive grid of squares. At level 0, one square covers the entire planet. At level one, we get 4, and so on. Tiles are uniquely identified by a triple of coordinates x/y/z, one denoting the level and the other denoting the normalised position in the grid. Each of the tiles is typically of the same size regardless of the level, they use the desired map projection (almost always Web Mercator) and are served as RGBA images that can be directly overlaid on the map and presented to the user:



This solution has many benefits; it brings all of the data sources into one common standard; it allows dynamic, on demand downloads of images for the requested area and produces images that always look sharp, because the increased zoom levels use more pixels for the given global area. It also makes rendering quite simple and as such is supported as a built-in method in most map packages such as Mapbox and Maplibre.
‍
The limitations of this method become quite obvious, however, once we introduce yet another dimension into the picture - time. As long as we’re only interested in data for one given moment, and can spare the waiting time to switch to another one, it’s perhaps satisfactory. If the goal, however, is a fluid motion between timeframes, suddenly the problem becomes much harder. It’s very easy to try it out for yourself; fire up your weather app of choice, and see how many react well to timeline changes. Most will debounce the slider, avoiding even attempting to solve this. In all other cases, the data will be pre-rendered as a video feed and simply played over, start to finish, to produce motion, typically as a composite of all layers necessary.



We weren’t satisfied with any of this. We wanted full interactive behavior, instant reaction to time changes, smooth animations and control over each layer individually.

The first thing that needed to change was the data delivery. Waiting for dozens of request for every screen, every time wasn’t going to be practical, especially considering we serve more than one layer at a time. Trying to preload tiles quickly filled up the system memory while failing to produce satisfactory quality. The reason for that is very easy to understand; at maximum zoom we would want to support, say 13, there would be 2^13 x 2^13 = 2^46 tiles in total to download. However, the original, underlying dataset isn’t nearly as large. The size stems from the fact that at those zoom levels, the client, especially with a 4K screen, needs a lot of pixels to present a sharp representation of the underlying values, and the server generated a lot of filler on demand.

What we decided to do instead was to limit the entropy over the wire by sending the actual data points from the original source. This guaranteed that we preserved the ground truth information as long as possible, before it was presented on the screen. One such data snapshot was larger than equivalent tiles to cover just one screen, but since it had all the resolution needed for zoom levels, this amortizes very quickly during application use.

Even though our method has been well tested in production already, receiving stellar feedback from the users, we didn’t stop there.

Firstly, we integrated more and more data sources. Even on modern GPUs, hours of past weather data can quickly fill up the entire memory. We used many methods, such as texture compression and supercompression(1), as well as virtual sparse textures to minimize the memory footprint while keeping the data availability high.

To reduce the network bandwidth even further, we experimented with cutting-edge compression algorithms such as AV1 and VP9. They required careful fine-tuning to strike a balance between size and quality, since the default settings are meant for completely different frame content. Additionally, we were able to leverage hardware decoding to minimize the memory pressure of the JS engine even further.

In the current day and age, it’s almost expected that every sufficiently advanced body of work discloses generative AI use, both for credibility and for informational purposes. For the original research and algorithm implementation, using LLMs wasn’t particularly useful. Even though they could directly produce specific implementations when asked for them, they couldn’t find solutions on their own or propose optimizations or improvements. As such, they were mostly useful in refactoring and moving code around.

Even though there were a few preexisting related implementations (dealing with e.g. map projections), after evaluation they came with bugs or unacceptable limitations, and attempts at translating those solutions with LLM similarly wasn’t successful. In the end, the most crucial code was almost entirely designed, written, tested and profiled by hand.