Building Astraea Atlas

August 1, 20267 min read

Astraea Atlas started with a table that was difficult to feel. The NASA Exoplanet Archive contains an extraordinary amount of information, but most of it arrives as rows, columns, and abbreviations. I wanted to make that catalogue easier to enter without wrapping it in a layer of invented scores or dramatic scientific claims.

Reading note

A clearer write-up of the product thinking, system choices, and tradeoffs behind the build.

In this post

The visualisation should make the data easier to approach, not more certain than it is.

Astraea Atlas design principle

Start With The Catalogue

The first version was deliberately grounded in the NASA Exoplanet Archive. That gave the project a useful constraint: every visible fact needed to come from a returned record, and every missing measurement needed to remain visibly missing. The point was not to simulate a solar system or rank worlds. It was to help someone explore a real catalogue with a little more orientation.

That distinction shaped the product language. Astraea Atlas can show a planet's host star, discovery year, detection method, orbital period, radius, mass, distance, and recorded sky coordinates where they are available. It cannot tell a user that a world is habitable, promising, or important just because a visual treatment makes it look interesting.

From Orbit Metaphor To Sky Map

The early visual direction used orbit rings around a central data sun. It was inviting, but it quietly suggested relationships the dataset was not claiming. The more honest next step was a celestial globe: place records using right ascension and declination, then let the user rotate the view themselves.

NASA TAP -> bounded records -> normalised fields
                         |
                 RA / Dec validation
                         |
                 rotatable sky globe

The route from archive row to rendered marker

The globe is still a designed interface rather than a literal simulation. Marker position is based on recorded sky coordinates; it does not represent distance, orbit, or a shared physical system. That caption matters because good visual design can otherwise make an interpretation feel like a fact.

Colour Needs A Clear Job

Colour is useful here because the map has more records than a person can inspect at once. The generator allows one measured field at a time: discovery year, planet radius, planet mass, system distance, or detection method. Numeric fields use a continuous scale, categorical methods use distinct restrained accents, and missing values use a neutral treatment.

Position answers: where is this record in the recorded sky?
Colour answers: which measured field am I looking at?
The index answers: which records are available even when a marker cannot be placed?

The Small Version On This Portfolio

The full atlas is a live deployed project, but the portfolio only needs a small invitation into it. I added a limited sampled globe to the homepage: a few named worlds, a colour toggle, a gentle rotation control, and a selected-record readout. It is intentionally not a second live data product. The interaction is there to show the feel of the work, then get out of the way.

That trade-off feels right for a portfolio. The full project can carry the data route, fallback state, filtering, and accessibility detail. The homepage preview only has to create enough curiosity for someone to open the case study or the live atlas.

What I Want To Learn

The next useful test is not whether more controls can be added. It is whether people understand the difference between a coordinate-backed position and a visual grouping, whether the selected fact panel helps them stay oriented, and whether the globe makes the archive feel more approachable without encouraging overinterpretation.

Open Astraea Atlas on GitHub Visit the live atlas