Ephem · debris feed methodology · v1.0
Published 2026-08-05. This document describes the catalog, propagator, error bars, and refresh cadence that produce the numbers at https://ephem-api.YOUR-SUBDOMAIN.workers.dev/shell/density/{alt}.
The nightly propagation reads the CelesTrak active catalog (GROUP=active&FORMAT=tle). At the time of writing this covers ~10,000 objects — the union of every active-payload, rocket-body, and tracked-debris object in the public NORAD catalog for which USSF/USSPACECOM publishes an unclassified two-line element set.
Excluded: classified objects, objects with epoch older than seven days at pull time, and objects flagged as decayed. Objects propagated to altitudes below 200 km or above 2,000 km are dropped from the shell binning (below 200 km they are effectively re-entering; above 2,000 km they are MEO or higher and fall outside the LEO congestion question).
SGP4 as implemented in satellite.js version 5.x. SGP4 is the standard general-perturbations model for LEO propagation against two-line element sets; it is the same model USSPACECOM publishes their TLEs against. We do NOT re-fit orbits or use a different force model — the whole point is that any competent analyst can reproduce our numbers from the same public catalog with the same open-source library.
Propagation epoch is the moment the nightly cron fires (03:17 UTC). Every object is propagated exactly once per run; we do not interpolate between epochs. The resulting state vector is converted to geodetic coordinates (WGS-84) via the eciToGeodetic transform in satellite.js.
Each propagated object is assigned to one shell of 10 km radial thickness (floor to the nearest 10 km). Within the shell, latitude and longitude are binned to 5° × 10° cells. Density is objects per km³ within the cell, using the exact spherical-shell volume element:
V(cell) = r² · Δr · Δlat · Δlon · cos(lat_centre)
r = 6371 + altitude_km
Δr = 10 km
Δlat = 5° = π/36
Δlon = 10° = π/18
Bin volume varies with cos(latitude); polar cells are smaller and therefore denser at equivalent object counts.
The propagator runs at 03:17 UTC ± 1 hour every day. Density envelopes are published to Cloudflare KV under shell:{alt} and served with a 24-hour cache TTL. A diff envelope (added / removed / shell-crossed objects vs. the previous run) is published to shell:diff:latest and served at /shell/diff.
If the CelesTrak fetch fails on a given night, no new numbers are published — the previous night's envelope continues to serve. Callers can detect this by comparing fetched_at in the envelope against the current time. This is deliberate: stale-known-good beats fresh-but-partial for a feed enterprise customers make decisions from.
SGP4 accuracy against a same-day TLE is typically ±1 km along-track for LEO objects; error grows roughly linearly with time from epoch, on the order of 1 km/day for a stable object and much faster for objects with high solar-radiation-pressure susceptibility or drag-perturbed decay. Because the propagator uses fresh TLEs (max age at pull ≈ 24 hours), the radial error is essentially always within the 10 km shell width used for binning. Latitude and longitude errors of ±1 km at 500 km altitude correspond to less than 0.01° — well within the 5° × 10° cell.
The dominant uncertainty is therefore catalog completeness, not propagation error. Small debris (<10 cm) is under-catalogued and Ephem inherits that gap. We do not currently ingest ESA MASTER or NASA ORDEM model outputs to fill the sub-catalogue population; if a customer requires those, the Enterprise tier can extend the feed with a licensed model overlay.
The nightly diff envelope reports:
Anyone can reproduce a given night's numbers with three inputs: (a) the CelesTrak active catalog as of the fetched_at timestamp — CelesTrak retains history, or one can pin a snapshot via archive.org; (b) satellite.js at the pinned version (5.0.0 as of v1.0 of this methodology); (c) the binning parameters above. A reference reproducer is at https://github.com/Nemi-swami/ephem-site under apps/api/src/shell/propagator.ts.
Ephem Ltd. publishes and stands behind these numbers. Questions from academic or regulatory reviewers to naraxcel.studio@gmail.com; we will respond in writing within one business week.