Real-time GIS: WebSockets and streaming TLEs

Real-time is not optional in serious space GIS. A launch detection that takes 5 minutes to appear in a user's browser is much less valuable than one that appears in 5 seconds. This week you build the WebSocket pipeline that makes this possible.

WebSocket vs polling vs SSE

Three options for getting server data to a browser in near-real-time:

• HTTP polling — client fetches once per N seconds. Simple, works through any proxy, but inefficient for high-frequency updates and high latency (you're at most 1 polling interval behind reality).
• Server-Sent Events (SSE) — server pushes events over a long-lived HTTP connection. Works through proxies and CDNs (it's just HTTP), simpler than WebSockets, but one-way (server → client only).
• WebSocket — bidirectional persistent TCP connection. The right choice when you need server → client at high frequency AND occasional client → server messages. Most space-domain live trackers use WebSockets.

FastAPI as a WebSocket server

FastAPI (fastapi.tiangolo.com) has first-class WebSocket support — declarative, async, type-checked. The skeleton:

from fastapi import FastAPI, WebSocket, WebSocketDisconnect
import asyncio, json
from skyfield.api import EarthSatellite, load, wgs84

app = FastAPI()
ts = load.timescale()
sats = [EarthSatellite(l1, l2, name, ts) for name, l1, l2 in tle_catalog]

@app.websocket("/ws/positions")
async def positions(ws: WebSocket):
    await ws.accept()
    try:
        while True:
            t = ts.now()
            payload = []
            for sat in sats[:100]:
                sp = wgs84.subpoint(sat.at(t))
                payload.append({
                    "name": sat.name,
                    "lat": sp.latitude.degrees,
                    "lon": sp.longitude.degrees,
                    "alt_km": sp.elevation.km
                })
            await ws.send_text(json.dumps(payload))
            await asyncio.sleep(1.0)  # 1 Hz throttle
    except WebSocketDisconnect:
        pass  # clean disconnect — nothing to do

The browser side

The browser's WebSocket constructor opens the connection. On each message, update marker positions. Throttle DOM updates if needed (1 Hz to the server is fine; rendering at 60 fps in the browser is overkill — animate-tween between samples for smoothness):

const ws = new WebSocket('wss://launchdetect.com/ws/positions');
ws.onmessage = (ev) => {
  const positions = JSON.parse(ev.data);
  for (const p of positions) {
    const marker = markers.get(p.name);
    marker?.setLngLat([p.lon, p.lat]);
  }
};
ws.onclose = () => setTimeout(reconnect, 1000 * Math.min(retryCount++, 30));

Throttling and back-pressure

10,000 satellites × 60 Hz = 600,000 updates/second. No browser will keep up; no server should send that. Realistic limits:

• Server: 1–4 Hz aggregate update cadence is typical. SGP4 is fast (microseconds per satellite), so the server can compute. The bottleneck is network bandwidth and client capacity.
• Client: roughly 1,000 marker updates per frame is the ceiling on modern hardware. For 10,000 satellites at 1 Hz, the client needs to spread updates across multiple frames or batch them via WebGL.

Reconnection

WebSockets disconnect for many reasons: WiFi flap, server restart, mobile network switch, load balancer hiccup. A production client must reconnect with exponential backoff (1 s, 2 s, 4 s, 8 s, ..., capped at 30 s) and detect close vs error events. Socket.IO (socket.io) bundles reconnection, namespaces, rooms, and HTTP-polling fallback — at the cost of a heavier wire protocol. For pure server-to-client streaming, raw WebSockets are usually enough.

The lab

You'll build a FastAPI WebSocket endpoint that streams positions of 100 satellites at 1 Hz, and a MapLibre client that receives the stream and updates marker positions in real time. Handle disconnects gracefully with exponential backoff. This is the architecture LaunchDetect uses to stream live detection events to the browser — minus authentication and selective subscription, which are Track 5 topics.