Computing Planetary Aspects: Ephemeris Data and Precision Requirements

Any serious cycle analysis that involves planetary positions, whether for the Bradley siderograph, Gann time cycles, or long-range rainfall forecasting, depends on accurate planetary ephemeris data. The calculations are only as good as the positions you feed them.

This guide covers the practical side: where to get ephemeris data, what precision you actually need, and the common errors that invalidate analysis even when the methodology is correct.

What is a planetary ephemeris?

An ephemeris is a table of planetary positions over time. The word comes from the Greek for "daily", historically, ephemerides were published as daily tables giving the positions of planets in the ecliptic coordinate system.

Modern ephemerides cover positions in multiple coordinate systems: - Geocentric: planet positions as seen from Earth's centre - Heliocentric: planet positions relative to the Sun - Ecliptic longitude/latitude: angular position on the ecliptic plane - Right ascension/declination: angular position on the celestial equator

Different cycle analysis methods use different coordinate systems. The Bradley siderograph uses both geocentric declinations and geocentric aspects. Gann's time projections typically use geocentric longitude. Long-range rainfall analysis (the Inigo Jones tradition, see our Crohamhurst Observatory post) historically used heliocentric positions.

The Swiss Ephemeris

The de facto standard for computational ephemeris work is the Swiss Ephemeris, developed by Astrodienst. It is based on the JPL DE431 planetary and lunar ephemerides from NASA's Jet Propulsion Laboratory and covers positions from 13,000 BCE to 17,000 CE.

Accuracy for major planets (Jupiter through Pluto) over the period 1800–2200 CE is better than one arc second. For inner planets (Mercury, Venus, Mars), better than one arc second back to 2000 BCE.

The Swiss Ephemeris is available as a C library with Python bindings (pyswisseph or swisseph). It is free for open-source use. This is what Crohamhurst.app uses for all planetary calculations.

The alternative for Python users is the astropy library, which uses ERFA/SOFA routines. Astropy is accurate to milliseconds of arc for current and near-future dates. For historical work extending back more than a few centuries, the Swiss Ephemeris is preferred.

Geocentric vs heliocentric: which to use?

This is a genuine methodological question with no universal answer.

Geocentric coordinates measure planetary positions as seen from Earth. This is what you observe from the ground and what traditional cycle analysts, including Bradley, used. The geocentric aspects between planets change as Earth moves in its orbit relative to the other planets.

Heliocentric coordinates measure planetary positions relative to the Sun, removing Earth's annual motion from the calculation. Some analysts prefer this for long-period cycle work on the grounds that it reflects the actual geometry of the solar system rather than the apparent geometry from Earth.

In practice, both coordinate systems are used in published cycle research. The right choice depends on which empirical correlations you're testing. For the Bradley siderograph, geocentric is required by definition. For long-range climate cycle work, some researchers find heliocentric positions give better results; others find no difference.

What precision do you need?

For financial cycle analysis, the precision requirements are modest. The Bradley siderograph calculation is sensitive to planetary positions at roughly the one-degree level. Gann time projections typically work at the one-day precision level. For these applications, any modern ephemeris accurate to one arc minute is more than adequate.

For long-range rainfall forecasting at seasonal resolution, the precision requirements are even looser. You're asking whether Jupiter is in the first or second quadrant of its orbit relative to Saturn, a question that doesn't require arc-second accuracy.

Where precision matters is in aspect calculation, specifically, the exact time at which a planet is at 0°, 90°, 180°, or another target angle. If you're claiming that a market turning point occurred at a particular planetary aspect, and you're computing the aspect time to within a day, you need your ephemeris accurate to better than one arc minute per day of planetary motion.

For Jupiter, which moves roughly five arc minutes per day in geocentric longitude, one arc minute precision keeps your aspect timing within half a day. That's adequate for daily financial data.

Common errors

Using wrong epoch coordinates: Planetary positions shift by about 50 arc seconds per year due to precession of the equinoxes. An ephemeris using J1950 coordinates will differ from one using J2000 by about 50 arc minutes, enough to introduce errors in aspect timing. Always specify the epoch (J2000 is standard for modern work).

Confusing tropical and sidereal longitude: Tropical zodiac longitude is measured from the vernal equinox (which precesses). Sidereal longitude is measured from a fixed reference point. Modern Western astronomical work uses tropical. Some traditional Indian astronomical systems use sidereal. The difference is currently about 24°. Mixing the two in a single analysis produces garbage.

Ignoring helio/geo distinction: A geocentric Jupiter-Saturn conjunction occurs when the two planets appear at the same ecliptic longitude as seen from Earth. A heliocentric conjunction occurs when they're at the same longitude relative to the Sun. These don't happen simultaneously. Analysis that conflates them is wrong by definition.

Using out-of-print almanac tables: Historical almanac tables (pre-computer) can have errors of several arc minutes per day, which compounds over long periods. For any historical analysis beyond 1950, verify against the Swiss Ephemeris or JPL Horizons rather than printed tables.

Practical workflow

For a complete aspect calculation pipeline in Python:

import swisseph as swe
from datetime import datetime, date

swe.set_ephe_path('/path/to/swisseph/ephe')

def get_planet_longitude(planet_id, dt):
    jd = swe.julday(dt.year, dt.month, dt.day,
                    dt.hour + dt.minute/60.0)
    result, _ = swe.calc_ut(jd, planet_id)
    return result[0]  # ecliptic longitude in degrees

# Example: Jupiter longitude on 1 Jan 2026
lon = get_planet_longitude(swe.JUPITER, datetime(2026, 1, 1))
print(f"Jupiter: {lon:.4f}°")

The Swiss Ephemeris planet IDs are: swe.SUN (0), swe.MOON (1), swe.MERCURY (2), swe.VENUS (3), swe.MARS (4), swe.JUPITER (5), swe.SATURN (6), swe.URANUS (7), swe.NEPTUNE (8), swe.PLUTO (9).

Crohamhurst.app provides a pre-built planetary data environment that handles the ephemeris setup, coordinate transformations, and aspect computation. For users who want to run their own calculations, the Swiss Ephemeris Python bindings are straightforward once the ephemeris data files are in place.

Related: Bradley Siderograph Complete Guide | Gann Square of Nine 2026 Guide | Inigo Jones and the Crohamhurst Observatory