How it works.

Rise and set times, with the mountains included

Pick a spot and a date. The page builds a 360° outline of the terrain around you: every ridge, shoulder and distant summit that cuts into the sky. Then it follows the sun and the moon across the day and finds the exact moments their discs cross that outline.

Two numbers come out of it for each body: the terrain time (when you actually see it) and the flat-horizon time (what an almanac would say). The difference is what the mountains cost you. In Zermatt on the winter solstice, it is about three hours in the morning and an hour and a half in the evening.

Five steps, all on your device

Step 2 needs the network. Everything after that is arithmetic in the browser and takes well under a second. Changing the date only re-runs steps 4 and 5, so it is instant.

What it uses, and where it comes from

No API keys, no accounts, no backend. Every source below is public and free to use with attribution.

About the elevation tiles

The Terrain Tiles are a global mosaic stitched from many national and international elevation models. Which one you get depends on where you are: SRTM (NASA's Shuttle Radar Topography Mission, ~30 m) covers most of the world between 60° N and 56° S; ArcticDEM and national models such as Norway's, Canada's CDEM or the US NED (down to ~3–10 m) fill in or improve other regions; GMTED2010 and ETOPO1 cover the gaps and the oceans. The full list is in Tilezen's attribution notes.

Each tile is a 256 × 256 PNG in which colour is height. Red, green and blue together encode the elevation in metres:

The page draws each tile onto an invisible canvas, reads the pixels back, and keeps the heights in memory. Sea floor is clamped to sea level, because water is flat.

Privacy

Nothing is stored and there is no server of mine involved. The coordinates you pick go only to the tile servers (as tile numbers), to Nominatim (for the place name), and into the page's URL so you can share the view. Your theme choice is kept in your own browser's local storage.

720 rays, and the curvature of the Earth

From your position (ground height plus 2 m of eye height, adjustable) the page walks outward along 720 compass directions, one every half degree. On each ray it samples the terrain height, works out the angle at which that point appears above or below eye level, and keeps the largest angle. That maximum is the horizon in that direction, and its distance is where the ridge sits.

The angle of each sample

For a point at distance d with terrain height h, seen from eye height h₀:

The d² / 2R term is the Earth curving away: 100 km out, the ground has dropped about 785 m below a straight line from your eye. Air bends light slightly back down around the curve, so you see a little further than geometry alone allows. The standard way to model that is to make the Earth look about 15% larger, which is the (1 − k) factor. Without these two corrections, distant ranges would look several hundred metres taller than they are.

Resolution where it matters

Nearby terrain needs fine detail and distant terrain doesn't, so each distance uses a different zoom level of the tiles:

Heights are interpolated between the four nearest pixels, so the outline doesn't step at pixel edges. A light 3-point smoothing removes speckle from individual pixels without lowering real peaks. Distances along each ray grow with range: 20 m steps near you, then 1% of the distance. That makes about 500 samples per ray and roughly 380,000 per location. It runs in about 0.7 s on a laptop.

Where they are, to a few arcminutes

Positions come from Paul Schlyter's well-known method for computing planetary positions. Each body follows an elliptical orbit whose elements change slowly over time. The Kepler equation is solved for the current position, and the result is turned into right ascension and declination, then into altitude and azimuth for your exact coordinates and moment.

The moon needs more care

The moon's orbit is disturbed by the sun's gravity. Without corrections its position can be off by about 2°, which is roughly 8 minutes of rise time. The model adds the twelve main longitude terms (evection, variation, the annual equation and others), five latitude terms and two distance terms. That brings it to a few arcminutes.

The moon is also close enough that where you stand on Earth matters. Seen from the surface rather than the planet's centre, it sits up to about 1° lower near the horizon (lunar parallax). The model corrects for this, which shifts moonrise by several minutes.

What you see, not where it is

• Refraction. The atmosphere lifts objects near the horizon by about half a degree, roughly the sun's own width. The model uses Sæmundsson's formula, assuming standard conditions (10 °C, 1010 hPa).
• Disc size. Rise and set mean the top edge of the disc, the first flash of light, so the apparent radius (~0.27° for both) is added. Both radii vary slightly with distance and are computed on the fly.

With all of this, the flat-horizon sunrise and sunset match published almanac times to within a minute. For example, Paris on 7 november 2026: 07:47 and 17:22.

Scan, then narrow down

The local day runs from midnight to midnight in the spot's time zone. That isn't always 24 hours: daylight-saving days have 23 or 25. For every 2-minute step the page computes:

Whenever the margin changes sign, the body has crossed the ridge. The page then halves that 2-minute window repeatedly until it is about 1 second wide. The reported time is accurate far beyond what the terrain data can justify, but it means rounding never adds error.

Because the scan follows the real outline, it also catches the odd cases:

• The sun setting behind a peak at noon and coming back out. These show up as “hidden behind terrain” rows.
• Days with no direct sun at all: deep north-facing valleys in winter, or polar night.
• Moonrise after moonset on the same day, or a moon that doesn't rise at all that day.

The same scan runs a second time against a flat 0° horizon to produce the comparison times. Civil dawn and dusk (sun centre 6° below the true horizon) are found the same way.

Why it is built the way it is

Architecture

• Static files, no build step. Five small scripts and a stylesheet. Any static host can serve it, and it will still work in ten years.
• Everything in the browser. Terrain analysis is usually done on a server with GDAL and a big elevation file. Here the browser downloads only the tiles around one point and does the maths itself, so there is no server cost, no API key and no queue.
• Own astronomy code. Common libraries such as SunCalc use a moon model that can be several minutes off, and they mix in refraction in ways that are hard to separate from the terrain angle. Writing the ~200 lines myself kept refraction, parallax and the disc radius explicit and testable.
• Shareable URLs. The address contains #lat,lon,date, so any view can be bookmarked or sent.

Interface

• The panorama is the centre of it. A rise time on its own is just a number. Seeing the sun's arc pass behind a particular summit explains it. The vertical scale is exaggerated (~3–4×) so a 10° ridge reads clearly; “full sky” zooms out to the whole arc.
• Map and panorama are linked. Hover over the panorama and a ray points to that ridge on the map. The rise and set rays end exactly on the ridge that blocks the light, and the dotted line on the map is the skyline itself, projected onto the ground.
• Visual identity. It follows my personal design system: warm near-black canvas, 1px hairlines instead of shadows, sharp corners, Space Grotesk for headings, Space Mono for every label, numbered lowercase sections. Apricot stands for the sun, mist teal for the moon and coral for what the terrain changes. No gradients and no emoji. There is a light theme behind the ◐ button.

Honest error bars

• Grazing angles. When the sun moves almost along a ridge instead of rising steeply over it (common in winter at high latitudes), a few metres of elevation error can move the time by several minutes. Typical cases are ±1–3 min.
• Very close terrain. Within a few hundred metres, the ~13–30 m elevation data can't see a rock band, a building or a tree line. If the blocking ridge is very close, expect larger errors.
• No buildings, no trees, no snowpack. The data is bare-earth terrain (radar surface for SRTM, which partly includes forest canopy).
• Refraction varies. Cold inversions in winter valleys can bend light more than standard conditions assume and shift a sunrise by a minute or two either way.
• Far ranges are coarse. Beyond 100 km the data is ~1 km per pixel. Only the tallest peaks matter that far out anyway.
• Above ~85° latitude the tile grid stops, so polar spots there have no terrain.

Thanks to the people who made the data free

Elevation: AWS Terrain Tiles by Mapzen / Tilezen, built from SRTM (NASA / USGS), GMTED2010, ETOPO1, ArcticDEM, CDEM, NED, EU-DEM and other national datasets (full list). Maps © OpenStreetMap contributors, OpenTopoMap (CC-BY-SA), Esri, CARTO. Search by Nominatim. Time-zone lookup by tz-lookup. Map library Leaflet. Orbital method after Paul Schlyter.

built by emile · with claude · more post-its than time.

← back to the map