Technical notes
Technical Note

Terrain map system notes

How the 3D destination map is structured around local data, relief treatment, labels, and static fallback output.

June 11, 2026 4 focus areas
MapsThree.jsTerrainVerification

Goal

The map is designed to communicate the feeling of a mountain place, not only the location of labels. The useful version combines terrain, water, routes, landmarks, and camera treatment into one readable scene.

Data model

The 3D map uses a compact local terrain payload. Elevation samples, water bodies, routes, and place labels are generated ahead of time and served from the same site. That makes the map self-contained and cacheable.

The terrain uses a 1.25x relief treatment. That is enough exaggeration to make shape and scale legible without making the map feel like fantasy terrain.

Runtime scene

The browser scene uses Three.js for terrain geometry, roads, rivers, trails, lift lines, water surfaces, projected labels, and a controlled camera. Labels are not baked into a screenshot. They are projected from map coordinates so the scene can remain data-backed.

The map also has a static export path on the same page. That keeps the story available for lightweight pages, printable guide layouts, and offline publishing outputs where a full interactive scene would be unnecessary.

Static map rendering

The static map is not a screenshot of the 3D scene. It is rendered at build time from the same payload: a latitude-corrected projection so shapes are true at 51 degrees north, shaded relief computed from the local elevation grid and embedded as a small image, and curated trail, road, lift, water, and label layers drawn over it as plain SVG.

Routes are defined as sparse tour stops in the source data, so the build snaps each one to the real trail and road network with shortest-path routing before drawing it. The lines on the static map follow actual switchbacks instead of cutting across terrain, and the page still ships with no map library and no runtime JavaScript.

Verification

The map has a Playwright verification script that checks both desktop and mobile viewports. It confirms that the canvas is not blank, enough color variance exists to prove the scene rendered, labels remain in bounds, and the reset interaction works.

That testing is not decorative. Interactive visual work fails in ways normal type checks cannot catch, so the site treats rendered output as something worth verifying.