Globe Trotter: 4D Time Series Big Data Visualization at GPU Scale

The hardest problem in geospatial visualization isn't rendering a map. It's animating a map through time — where every pixel, every hexagon, every track has a value that changes across hundreds or thousands of moments. The moment you add a temporal dimension to big geospatial data, every existing framework either collapses under the data volume, forces painful server-side infrastructure, or sacrifices interactivity for scale. Today we're open-sourcing Globe Trotter — a GPU-accelerated 4D globe engine and binary format architecture built from the ground up to make time a first-class dimension, at any scale, without servers. See who it's built for →

The Flex Format Architecture: GPU Zero-Copy Time Series

The reason Globe Trotter handles this scale at interactive frame rates is not clever rendering tricks — it's the Flex binary format architecture. Flex formats are the foundational data layer of the entire engine, and the foundation of a broader big data engineering platform. They are not compression wrappers around GeoJSON, nor are they tilesets generated by a tile server. They are GPU memory layouts — designed so that every byte of the file corresponds directly to a value that will be read by a GPU shader, with no intermediate parsing, transformation, or CPU-side data manipulation required.

What GPU Zero-Copy Means

Traditional geospatial formats — GeoJSON, Shapefiles, GeoPackage, even Parquet — are designed for interchange and analysis, not for GPU upload. Loading them into a WebGL or WebGPU pipeline requires a CPU-side parsing stage that extracts coordinates, builds index buffers, flattens nested structures, and marshals values into typed arrays before they can be uploaded to the GPU. For small datasets this is fine. For 1.47 million features across 1,440 time epochs, it's the bottleneck that makes interactive visualization impossible.

Flex formats eliminate this stage entirely. The pipeline is:

The Flex encoder runs when you generate your dataset — either as a one-time offline batch job or a continuously running pipeline for datasets that update in real time. The resulting binary file is then served from any static host — a GCS bucket, S3, Azure Blob Storage, a CDN — and loaded directly into GPU memory by the engine. There is no server-side rendering, no tile generation at query time, and no CPU-side data processing in the browser. The CPU's only job is to call writeBuffer().

This architecture also eliminates the traditional user-scaling bottleneck. Conventional geospatial platforms centralise work on the server: every concurrent user triggers a tile-render job, a database query, or a processing pipeline. That model caps out quickly — more users means more backend load, more infrastructure, and higher cost per viewer. By moving all computation to the encode step and serving static binary files from a CDN, Globe Trotter decouples viewer count from server load entirely. A visualisation that handles one user handles one million — the CDN absorbs the traffic and each viewer's GPU does the rendering independently. There is no query server to overload, no tile cache to warm, and no per-user cost to amortise.

Three Formats — One Architecture

Globe Trotter ships three Flex formats, each purpose-built for a different shape of geospatial time series data:

Generating Flex Data — The Data SDK

Globe Trotter ships a Node.js data SDK with encoders for all three formats. Any source that can produce a row-oriented dataset — CSV, Parquet, BigQuery, PostGIS, a REST API — can be encoded into Flex format with a short script. The included mobile demand simulation generates a complete, realistic H3Flex + GeoFlex + MetricFlex dataset entirely from synthetic data, with no external dependencies:

import { H3FlexEncoder } from '@globe-trotter/data-sdk';

const encoder = new H3FlexEncoder({
  resolution: 5,          // H3 resolution (res-5 ≈ 252 km² cells)
  epochs:     1440,       // 24h at 1-minute resolution
  metrics:    ['demand_mbps', 'supply_mbps', 'utilization'],
  encoding:   'auto',     // sparse or RLE, chosen per shard
});

for (const row of rows) {
  encoder.add(row.h3index, row.epoch, row.metric, row.value);
}

await encoder.write('./public/data/demand.manifest.json');
// → demand.manifest.json + demand.shard.{metric}.h3f per metric

The encoder automatically selects sparse vs RLE encoding per shard based on value density, applies gzip compression, writes a manifest JSON that the engine uses for on-demand shard loading, and pre-computes the H3 mesh geometry so the engine never re-triangulates at runtime. For a 1.47M hexagon × 1,440-epoch × 3-metric dataset, the full encode runs in under two minutes on a laptop.

Plugging Flex Into Your Visualization

Once your data is encoded, wiring it into a globe visualization requires only a YAML config update — no code:

basemap:
  style: satellite
  token: env:VITE_MAPBOX_TOKEN

camera:
  center: [39.0, -98.0]
  altitude: 12000

time:
  enabled: true
  speed: 60      # 1 real second = 60 simulated minutes
  loop:  true

layers:
  - name: Mobile Demand
    type: h3f-sharded
    url:  /data/demand.manifest.json
    metric: demand_mbps
    style:
      type:      ramp
      domain:    [0, 500]
      stops:     ["#0D1A80", "#1ABF59", "#F23319"]

  - name: Flight Tracks
    type: gfb
    url:  /data/flights.gfb
    style:
      type:      categorical
      attribute: airline

Why Scale Is the Differentiator

Most geospatial frameworks hit a hard wall around 10,000–50,000 GeoJSON features before frame rates drop below interactive thresholds. The community has developed workarounds — server-side tile generation, data aggregation on the fly, pre-rendered video — but each workaround reintroduces infrastructure complexity and sacrifices the key property that makes a visualization useful: the ability to interactively explore time.

Generate, Configure, Share

Globe Trotter collapses the entire workflow — from raw data to a shareable interactive globe — into three steps:

Embed in Any Application

Globe Trotter ships as a framework-agnostic JavaScript library. The dist build is a single ES module — no dependencies, no peer packages — that drops into React, Vue, Angular, Svelte, or a plain HTML page without modification. The entire engine, rendering pipeline, and UI are contained in one import.

# npm / yarn / pnpm
npm install @globe-trotter/core

Initialising the engine takes three lines: create a canvas, instantiate the engine, load your config. Everything else — basemap, camera, time controls, layer rendering — is driven by the YAML config or the programmatic API.

import { GlobeTrotterEngine } from '@globe-trotter/core';

// Any <canvas> in your application — size it however you like.
const canvas = document.querySelector('#globe');

const engine = new GlobeTrotterEngine(canvas, {
  mapboxToken: import.meta.env.VITE_MAPBOX_TOKEN,
  basemap:     'satellite',
  autoStart:   true,
});

// Load layers, camera, and time from a YAML config …
await engine.loadConfig('/globe-config.yaml');

// … or drive it programmatically from your application state.
engine.setTime(epochSeconds);
engine.setMetric('demand_mbps');

Because the engine is just a class that wraps a <canvas>, it integrates into component lifecycles naturally. In React, instantiate it in a useEffect and call engine.dispose() on unmount. In Vue or Angular, the pattern is identical. There is no virtual DOM involvement, no special renderer, and no opinion about how your application manages state — the globe is a GPU surface that responds to the method calls you make.

GPU Engine — Built to Feed the Flex Pipeline

The Flex architecture dictates the engine design. Because data arrives GPU-ready, the engine can focus entirely on rendering rather than data management:

Pure WebGPU, Zero Dependencies

Globe Trotter has no runtime dependencies — no Three.js, no Babylon.js, no Mapbox GL renderer under the hood. Every GPU buffer, shader, and matrix multiply is written from scratch. The globe, tiles, H3 layers, GFB tracks, and chart overlays all render via WebGPU with WGSL compute shaders and instanced draws. WebGPU is required; browsers without support receive a clear WebGPURequiredError.

Compute-First Rendering — Serving the Time Dimension

Every frame, the WebGPU pipeline runs compute before render. A scatter compute shader reads the epoch index uniform and writes the current epoch's hex values from a storage buffer into an R32F texture in under 1ms — replacing what would be a 130ms CPU strip-upload loop in WebGL2. The render pass then reads the texture directly. Epoch transitions are imperceptible. A histogram compute shader bins 1.4M values via atomicAdd in <0.1ms, driving live GPU charts without blocking the main thread.

GPU Performance at Flex Scale

• 150× fewer tile draw calls — all visible satellite tiles render in a single drawIndexedInstanced() call via a 256-layer texture 2D array.
• >100× faster epoch transitions — WebGPU compute scatter vs WebGL2 amortized strip upload (sub-1ms vs ~130ms).
• ~40× faster histogram computation — GPU atomicAdd bins 1.4M cells in <0.1ms vs ~4ms blocking CPU loop.
• Zero per-frame GC pressure — pre-allocated scratch buffers for all uniform writes eliminate ~500 KB/s of garbage collection overhead.

GPU-Accelerated Chart System — Wired to Flex Data

Globe Trotter includes a full GPU-rendered chart system on a transparent WebGPU overlay canvas — no DOM elements, no Canvas2D, no external library. Six chart types are supported: histograms, heatmaps, CDFs, boxplots, bar charts, and time-series. Because chart data is read directly from MetricFlex buffers already in GPU memory, there is no separate data fetch for charts — they update in sync with the time scrubber automatically.

Agentic-First by Design

"Agentic-first" is not a feature added on top of Globe Trotter — it is the architectural philosophy that shaped every decision from day one. The entire codebase was vibe coded with Google Antigravity, Google's advanced agentic coding platform. Every line — the GPU engine, Flex format encoders, compute shaders, chart renderers, symbology dialogs, and all documentation — is AI-authored, Subject Matter Expert reviewed and verified. More importantly, Globe Trotter is designed to be operated by AI agents: from receiving a raw dataset and a natural-language description of what to visualise, through to encoding the data, writing the YAML config, and publishing a live interactive globe — with no human intervention required at any step.

Embedded Agent Skills

Globe Trotter ships with 10 embedded workspace agent skills, each one an invocable slash command. An AI agent working inside Globe Trotter loads complete expert knowledge for any subsystem on demand — without reading source code or documentation manually.

Data Automation

Beyond development skills, Globe Trotter ships one end-to-end data automation pipeline that drives the full workflow from raw data to a live published globe:

Extend Globe Trotter Into Your Own Workflows

The skills and workflows architecture is an open extension point, not a closed system. Any team that embeds Globe Trotter into a larger platform can add domain-specific skills and workflows to the .agents/ directory — giving their own AI agents expert-level knowledge of their specific datasets, naming conventions, deployment targets, and organisational patterns. An agent working inside a telecommunications platform can load a skill that knows that platform's H3 resolution choices, regional naming schema — and invoke a workflow that re-encodes the latest epoch and pushes it to the CDN — without a human in the loop. Globe Trotter's agentic architecture scales from a single developer running a demo to a production platform where AI agents maintain a live global visualisation system end to end.