Loading…
Product Visit
Visit tomorrow's products today
Google maps for the entire solar system
Space Map is a real-time, real-scale, fully continuous map of the solar system, mapping 1.6m objects and 16k surface features as of July 2026.
Click the images to open
Space Map computes positions at any date, using orbital elements from NASA, ESA, JAXA, and the US Space Force:
| Type | Count | Source |
|---|---|---|
| Planets | 8 | NASA SPICE kernels (NAIF) |
| Dwarf planets | 10 | NASA JPL Horizons |
| Moons | 466 | NASA JPL Horizons |
| Asteroids | 1.5m | Small-Body Database |
| Comets | 4k | Small-Body Database |
| Spacecraft | 27k | CelesTrak, Space-Track, NASA (JPL Horizons, NAIF, PDS), ESA SPICE Service, JAXA DARTS |
| Satellite debris | 40k | CelesTrak, Space-Track |
| Surface features | 16k | Gazetteer of Planetary Nomenclature (IAU/USGS/NASA) |
Each of these is displayed at its current position, and shown at its real size (when known). Click any object to focus it.
Space Map's frontend is built with SvelteKit and Three.js (WebGL), and is hosted on Cloudflare Workers. Three.js has 32-bit precision for positions. To make a continous solar system work at all scales, the map uses camera-based rendering: the world's origin coordinates is the camera. Objects that are very close to it exist in an area where lots of precision is available, and precision is not wasted on far-off objects. When this goes wrong, the effects are very visible. The positions for most asteroids & comets are computed in web workers: that's what makes real-time positions possible with 1.6m objects.
The data pipeline is built in Python. It downloads each dataset, joins them in a SQLite database, and exports them to static files. Those static files are served as static Cloudflare Workers assets: there's no backend for most of the app. This has drawbacks, but allows serving lots of data very fast, at very low cost. In particular, maintenance is very easy: all "endpoints" are served once, so there's no risk of runtime backend errors. The export format is documented (written by AI). Search is provided by a Meilisearch database running in a VPS.
The export pipeline compresses orbital elements from ~100GiB down to 1.9GiB, and splits them in chunks so the frontend can propagate the current position quickly. The loss in accuracy is significant, but very small for major objects: planets, moons, and important small objects, and spacecraft are typically off by meters to hundreds of meters compared to high-accuracy tracking data.
Sources for these major objects are spice kernels, which can contain tracking data at regular intervals. This is great for irregular orbits, but scales with shorter orbital period. A satellite in low orbit will take a lot of space, but those orbits tend to be stable. The pipeline will convert this heavy format into light keplerian elements, including precession when it results in an accuracy improvement. Those elements do go stale, the pipeline time-chunks elements. The results are very good: the Mars Reconnaissance Orbiter (MRO) goes from 10GiB to ~0.28 MiB, with a P95 accuracy loss of only 134.4km at the edge of chunks (worst case). Not science grade, but good enough for visualization.
Important objects (famous probes, planets, major moons) have a higher size budget, so their positions will be more accurate.
For earth satellites, positions are computed with SGP4 with satellites.js. Orbital elements are exported weekly from the US Space Force, with a historical archive from 1959.
Orbital elements for Asteroids & comets are retrieved from the JPL Small-Body Database, which only provides static current orbital elements. Positions for these 1.5m objects will be less accurate the further from the current date you go.
