Optimizing WGS84 vs UTM for low-memory IoT gateways

This guide solves one narrow but recurring decision: on a Linux IoT gateway with a hard memory ceiling (under 128 MB RSS, often a Raspberry Pi Zero 2 W or an industrial ARM Cortex-A board), should your Python telemetry service keep coordinates in WGS84 (EPSG:4326) or project them to UTM (EPSG:326xx/327xx) before doing any spatial math? Within the Core Edge GIS Fundamentals framework — and specifically the patterns established for Coordinate Reference Systems at the Edge — the answer is dictated less by cartographic correctness and more by RAM allocation, CPU thermal envelopes, and upstream sync latency. The wrong call here either thrashes a constrained gateway under projection-library bloat or burns cycles on geodesic trigonometry that a planar grid would make trivial.

Why a planar grid wins inside the constraint envelope #

WGS84 stores coordinates as floating-point latitude/longitude pairs. The format is compact (16 bytes per point as two float64 values) and universally accepted by GNSS receivers, but spatial operations require trigonometric evaluation. Distance, bearing, and area calculations on WGS84 demand iterative geodesic algorithms that consume 3–5× more CPU cycles than planar math. On ARM Cortex-A gateways running at 1.2 GHz, continuous geodesic computation can push thermal throttling thresholds, degrading packet processing rates and increasing MQTT/LTE transmission jitter.

UTM projects the ellipsoid onto a 2D Cartesian grid using a Transverse Mercator transformation. Coordinates are stored as easting/northing pairs (also 16 bytes as two float64 values), but spatial operations collapse to Euclidean arithmetic — the same reduction that makes downstream on-device geometry filtering cheap enough to run per-message. The computational advantage is substantial, but UTM introduces two edge-specific liabilities: zone-determination overhead and projection-library bloat. Standard geospatial stacks bundle global geodetic grids, datum-shift files, and CRS metadata that can consume 15–40 MB of RAM on import alone. On a board with 256 MB total system memory, that footprint is unacceptable.

The selection rationale, then, is not “UTM is better” — it is “UTM math is cheaper, but only if you refuse to import the machinery that normally carries it.” This page picks UTM and pays for it with a stripped, static, standard-library-only projection: no pyproj, no GDAL, no datum-shift grids, just hardcoded WGS84 constants and a per-batch zone pin. For deployments that genuinely cannot tolerate any projection cost — bare microcontrollers rather than Linux gateways — the companion approach in CRS transformations on ARM Cortex-M devices goes further into fixed-point territory.

Projection path with a polar passthrough guard and per-batch zone pinning.

A self-contained, database-free UTM projection #

The module below is the complete implementation: a memory-constrained UTM forward projection that avoids heavy CRS databases, uses only the standard library, and resolves zones from a static lookup table. It is designed for micro-batch processing on gateways with aggressive RSS limits, and it is CPython-friendly — the hot loop allocates only short-lived tuples, so the cyclic garbage collector never has to walk a large object graph. It is intentionally synchronous; the integration section below shows how to push it off an asyncio event loop.

# edge_utm_lite.py
# Memory-optimized UTM projection for constrained IoT gateways.
# Target RSS: < 15 MB | Python 3.8+ | Standard Library Only
# Threading model: synchronous + CPU-bound. Run inside a thread/process
# executor (see integration snippet) so it never blocks an asyncio loop.

import math
import time
import tracemalloc
from typing import List, Tuple

# Static zone parameters — central meridian for each zone 1-60.
# Formula: central_meridian = (zone * 6) - 183. Computed once at import,
# so no per-point branching or table I/O in the hot path.
UTM_CENTRAL_MERIDIANS = {
    z: -183.0 + (6.0 * z) for z in range(1, 61)
}

# WGS84 constants (hardcoded — no datum-shift grid, no CRS database).
A = 6378137.0          # Semi-major axis (m)
E2 = 0.00669437999014  # First eccentricity squared
EP2 = E2 / (1 - E2)    # Second eccentricity squared
K0 = 0.9996            # UTM scale factor

def _get_zone(lon: float) -> int:
    """Determine UTM zone from longitude. Returns integer zone 1-60."""
    return max(1, min(60, int((lon + 180) / 6) + 1))

def _project_utm(lat: float, lon: float) -> Tuple[float, float]:
    """
    Lightweight Transverse Mercator forward projection (Snyder series).
    Accuracy: ~0.5 m within 3° of central meridian; degrades near zone edges.
    """
    zone = _get_zone(lon)
    cm = math.radians(UTM_CENTRAL_MERIDIANS[zone])
    lat_r = math.radians(lat)
    lon_r = math.radians(lon)
    dlon = lon_r - cm

    sin_lat = math.sin(lat_r)
    cos_lat = math.cos(lat_r)
    tan_lat = math.tan(lat_r)
    n = A / math.sqrt(1 - E2 * sin_lat**2)
    t = tan_lat**2
    c = EP2 * cos_lat**2
    a = dlon * cos_lat

    # Meridional arc (Snyder Eq. 3-21)
    m = A * (
        (1 - E2/4 - 3*E2**2/64 - 5*E2**3/256) * lat_r
        - (3*E2/8 + 3*E2**2/32 + 45*E2**3/1024) * math.sin(2*lat_r)
        + (15*E2**2/256 + 45*E2**3/1024) * math.sin(4*lat_r)
        - (35*E2**3/3072) * math.sin(6*lat_r)
    )

    fe = 500000.0
    fn = 10000000.0 if lat < 0 else 0.0

    easting = K0 * n * (
        a + (1 - t + c) * a**3 / 6
        + (5 - 18*t + t**2 + 72*c - 58*EP2) * a**5 / 120
    ) + fe
    northing = K0 * (
        m + n * tan_lat * (
            a**2 / 2
            + (5 - t + 9*c + 4*c**2) * a**4 / 24
            + (61 - 58*t + t**2 + 600*c - 330*EP2) * a**6 / 720
        )
    ) + fn

    return easting, northing

def process_telemetry_batch(
    raw_points: List[Tuple[float, float]], batch_size: int = 256
) -> List[Tuple[float, float]]:
    """
    Micro-batch UTM projection with memory guardrails.
    Input: list of (lat, lon) tuples. Output: list of (easting, northing) tuples.
    Points with |lat| > 84° pass through as (lon, lat) — UTM is undefined at
    polar latitudes, so we degrade deterministically rather than emit garbage.
    """
    if not raw_points:
        return []

    processed = []
    for i in range(0, len(raw_points), batch_size):
        chunk = raw_points[i:i+batch_size]
        chunk_out = []
        for lat, lon in chunk:
            if abs(lat) > 84.0:
                # UTM undefined above 84°N / below 80°S; pass through raw coords.
                chunk_out.append((lon, lat))
            else:
                chunk_out.append(_project_utm(lat, lon))
        processed.extend(chunk_out)
        del chunk
        del chunk_out

    return processed

# --- Diagnostic runner: measures Python-heap RSS and per-point latency ---
if __name__ == "__main__":
    tracemalloc.start()
    start = time.perf_counter()

    # Simulate 10k telemetry points around New York City.
    test_data = [(40.7128 + (i * 0.001), -74.0060 + (i * 0.001)) for i in range(10000)]
    results = process_telemetry_batch(test_data)

    elapsed = time.perf_counter() - start
    current, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()

    print(f"[DIAG] Processed {len(results)} points in {elapsed:.4f}s")
    print(f"[DIAG] Peak RSS (Python heap): {peak / 1024:.1f} KB")
    print(f"[DIAG] Avg latency/point: {(elapsed/len(results))*1e6:.2f} μs")

Constraint validation #

Every line item in the table maps a hardware limit to the design choice in the code above. These are the numbers to hold the implementation against when you profile it on the target board, not on a workstation.

Gotchas and edge cases #

Polar bounds are a hard cliff, not a soft one. UTM is mathematically undefined above 84°N and below 80°S. When a GNSS receiver reports a fix beyond ±84° latitude — or when HDOP spikes and coordinates drift into that band — the Snyder series produces large, plausible-looking errors rather than failing. The code switches to a WGS84 passthrough as (lon, lat); downstream consumers must be told that tuple is geographic, not projected. Emit a structured degradation event so upstream analytics bypass planar math for that window: {"event": "crs_fallback", "reason": "polar_bounds", "lat": 84.12, "ts": epoch_ms}.

Zone edges silently lose accuracy. The ~0.5 m accuracy claim holds within roughly 3° of the central meridian. A telemetry fleet crossing a zone boundary will see projected coordinates from two different grids that do not share an origin — distances computed across the seam are wrong. If a device roams across zones, pin the zone per batch (as the code does via _get_zone) and re-tag the batch with its zone integer; never mix eastings from different zones in one geometry operation. This is the same precision contract enforced in Spatial Data Precision Standards.

Hemisphere and false northing. Southern-hemisphere fixes need the 10,000,000 m false northing (fn) the code applies when lat < 0. Forgetting it puts points 10,000 km off. If your deployment is single-hemisphere and fixed-region, hardcode fn and strip the branch.

Float precision upstream, not in the math. Keep the projection itself in float64 — truncating mid-series amplifies the polynomial error. Quantize to float32 only at the wire boundary, where ±0.1 m of rounding is acceptable and you halve the LTE payload.

Integrating with the ingestion pipeline #

The projector is synchronous and CPU-bound, so calling it directly inside an asyncio ingestion loop would stall every other coroutine — including the MQTT keepalive. Run it in a thread executor and stream results so the parent pipeline never materializes the full batch in RAM:

import asyncio
import gc
from edge_utm_lite import process_telemetry_batch

async def project_stream(queue: "asyncio.Queue", sink, ceiling_mb: int = 96):
    """Drain the WGS84 ingest queue, project off the event loop, push to sink."""
    loop = asyncio.get_running_loop()
    while True:
        batch = await queue.get()              # list[(lat, lon)] from MQTT/UART
        # CPU-bound work runs in the default thread pool, not the loop.
        utm = await loop.run_in_executor(None, process_telemetry_batch, batch)
        await sink.send(utm)                   # e.g. delta-sync staging buffer
        queue.task_done()
        if _rss_mb() > ceiling_mb:             # back-pressure guard
            gc.collect()                       # reclaim freed batch buffers

From here the projected easting/northing stream feeds the gateway’s store-and-forward layer — typically the staging buffer that the delta sync for GPS coordinate streams pattern reads from when the uplink returns. Cap the process with ulimit -v 98304 before service start and watch RSS drift with pidstat -r -p <PID> 1; any swap activity on an edge node is a signal to drop batch_size to 128 rather than let the OOM killer reap the service.

Related #

• Coordinate Reference Systems at the Edge — the parent guide covering deterministic CRS handling, datum-grid trimming, and FFI overhead on constrained gateways.
• How to handle CRS transformations on ARM Cortex-M devices — the microcontroller sibling: fixed-point UTM where there is no FPU and no Linux.
• Device Constraints & Resource Limits — the RAM, thermal, and flash budgets that decide whether projection cost is affordable at all.
• Reducing RAM usage for GeoJSON parsing on Raspberry Pi — companion memory-discipline pattern for the same class of board.