# Geopuesto v2 — Spherical Geometry Architecture & Feature Plan Planning notes, 2026-05-24. Captures the chat session expanding Geopuesto from a single-feature antipode tool into a full spherical-geometry playground. Critical framing: **v1 already has a rich data-enrichment pipeline** (Wikipedia, Street View, satellite, sea traffic, radio stations, plus adjustable distance ring + city-size filters along the orthodrome). v2 extends this same pipeline to N points instead of 1. Nothing v1 has gets stripped; everything generalizes. Topics covered: one-point and two-point structures on a sphere, the perpendicular bisector great circle, inscribed and circumscribed polyhedra (full taxonomy across Platonic/Archimedean/Catalan/Kepler-Poinsot/compound/prism/geodesic/Fibonacci/star-polygon families), the topology of the sphere (hairy ball theorem, Euler characteristic, why exactly 5 Platonics), spherical harmonics and the Earth-grid debunking opportunity, geodesy (sphere vs ellipsoid vs geoid), and the longitude problem as a separate tangent. --- ## Core insight Going from 1 point to 2 points on a sphere upgrades you from "latitude only" to a full coordinate frame. The number of fixed reference points determines how much of the sphere's rotational symmetry you've broken. - **0 points** → bare sphere, no frame. - **1 point P** → polar axis fixed, meridian free. Rotational symmetry around the P↔−P axis. Latitude only. - **2 points A, B** → full lat/lon frame. Rotational symmetry fully broken. - **3 points (non-collinear)** → over-determined; defines a spherical triangle and gives area via spherical excess. The 2-point case is the minimum to get a working coordinate system. This is the structural reason the perpendicular bisector great circle feels so important — it's the missing axis that makes the geometry usable. --- ## Geopuesto v2 — the unifying architecture Everything in this doc is a feature/mode of a single app: **Geopuesto v2**, the expansion of the current antipode tool into a full spherical-geometry playground. This is not three separate tools (Geopuesto, polyhedra app, Earth-grid debunker). It's one app with progressive complexity. ### Current state (v1) — already built Don't underestimate what's already shipped. v1 is not just "antipode calculator." It's already a rich single-point exploration tool: - **Antipode calculation** for any user-input point. - **Great circle (orthodrome)** drawn between point and antipode. - **Distance ring with adjustable thickness** along the orthodrome: user picks band width (5, 10, 25, 50, 250 km) and city-size filter (1k+, 10k+, 100k+, 1M+); app surfaces cities within that band at that scale. - **Rich contextual data at the antipode**, pulled live from APIs: - Wikipedia article for that exact location (down to museum/landmark level) - Google Street View for overland points - Recent satellite imagery for any point - Sea traffic data for ocean points - Nearby radio stations - (Other API-driven enrichment as built) The v1 strength is the **data-enrichment pipeline**. The geometry is currently limited (antipode only), but the contextual richness around each point is the part that makes the app feel alive. ### The v2 thesis **Everything v1 does for one point, v2 does for N points.** Polyhedron vertices, perpendicular-bisector intersection points, Voronoi cell centers — these are all just "points on the sphere." Each one is a candidate for the existing enrichment pipeline. The hard work in v1 — wiring up Wikipedia, Street View, satellite, sea traffic, radio stations, deduplicating sources, handling API failures — does not need to be redone. It needs to be **routed** to a list of geometry-generated points instead of just one antipode. ### Target structure (v2) ``` Geopuesto v2 ├── Core (v1, already built — KEEP) │ ├── Pick a point │ ├── Antipode + great circle through it │ ├── Adjustable thickness ring along the orthodrome │ ├── City-size filter (1k / 10k / 100k / 1M+) │ ├── Rich data card per point (Wikipedia, Street View, satellite, sea traffic, radio) │ └── Distance/bearing │ ├── Two-Point Mode (new) │ ├── Pick a second point │ ├── A–B orthodrome (with same adjustable thickness ring as v1) │ ├── Great-circle midpoint M and antipodal midpoint −M │ ├── Perpendicular bisector great circle │ ├── n, −n (poles of A–B great circle) │ ├── Cross-track and along-track distances │ ├── Initial vs final bearing (with asymmetry visualized) │ ├── Voronoi split — "closer to A" vs "closer to B" hemispheres │ └── Rich data card for each named point (M, −M, n, −n) — reusing v1 pipeline │ ├── Polyhedra Suite (new) │ ├── Inscribed mode (vertex set generated by shape choice) │ │ ├── 5 Platonic solids │ │ ├── Selected Archimedeans (truncated icosahedron, cuboctahedron, icosidodecahedron) │ │ ├── Rhombic triacontahedron (= Becker-Hagens grid) │ │ ├── Kepler-Poinsot stars (4 of them, share vertex sets with Platonics) │ │ ├── Compounds (stella octangula, 5-tetrahedra, 5-cubes) │ │ ├── n-prism / n-antiprism (user-chosen n) │ │ ├── Geodesic subdivision (user-chosen frequency) │ │ ├── Fibonacci sphere (user-chosen N) │ │ └── Flat star polygon {n/k} on a great circle │ ├── Circumscribed mode (toggle: face/edge/vertex tangency) │ ├── Anchor controls (1-point anchor + spin slider, or 2-point anchor) │ ├── Each polyhedron vertex routed through v1 enrichment pipeline (lazy-loaded) │ ├── Thickness ring works for each polyhedron edge (great circle between adjacent vertices) │ └── Export vertices as GeoJSON │ ├── Analysis Suite (new) │ ├── Spherical Voronoi cells around any point set │ ├── Dataset overlays (shipwrecks, earthquakes, volcanoes, magnetic anomalies, megalithic sites, custom CSV) │ ├── Monte Carlo "is this pattern real?" tester │ ├── Spherical harmonics inspector (icosahedrally-allowed modes flagged) │ ├── Vertex-comparison views (filter/sort across all vertices by any v1 data field) │ └── Curvature mode — visualize Theorema Egregium with a draggable patch │ ├── Real-Earth Mode (new, low priority) │ ├── Toggle: sphere ↔ WGS84 ellipsoid │ ├── Geoid undulation overlay (EGM2008) │ └── Datum transformation tester │ ├── Content/Export (new) │ ├── Frozen-state share links │ ├── Great-circle paths and polyhedron wireframes as GeoJSON / KML │ ├── Voronoi cells as GeoJSON │ └── Image/SVG snapshot for social │ └── Pirate Mode (new, Phase 7) └── Whydah-era navigation simulator: latitude only, dead reckoning, no clock ``` ### Why this consolidation matters - **One codebase, one mental model**: everything is "a point on a sphere with something attached." Antipode is the simplest case; polyhedra are points-with-symmetry; Voronoi is points-with-influence-regions. v1's pipeline doesn't care which kind of point it's enriching. - **No rebuilding**: the data-enrichment work is preserved and extended, not thrown away. - **Progressive feature exposure**: users start with what v1 already does, discover more by toggling modes. No retraining. - **Earth-grid debunking is one feature branch**, not a separate portfolio piece. Analysis Suite + Polyhedra Suite + preset datasets. - **Mapzimus content is a byproduct**: any specific configuration is a frozen-state share link. ### What this means for v1 features **Don't strip anything from v1.** Every existing feature stays. Specifically: - The Wikipedia / Street View / satellite / sea traffic / radio data pipeline becomes the **shared enrichment layer** that all new modes feed into. - The thickness ring + city-size filter generalizes: works on the antipode's great circle (existing), works on the A–B orthodrome (Two-Point Mode), works on every edge of a polyhedron wireframe (Polyhedra Suite). - The rich data card stays the canonical right-panel pattern. New modes generate point lists; each point becomes a card. ### Phased build order (revised) **Phase 1 — Two-point upgrade**: extend v1 from 1 point to 2 points. Add midpoint, perpendicular bisector great circle, A–B distance/bearing. Critically: reuse the existing thickness-ring and enrichment-card components without modification — they just need to accept two points instead of one. Weekend-sized. **Phase 2 — Polyhedra Suite v1**: 5 Platonics + truncated icosahedron + rhombic triacontahedron + stella octangula. Single anchor + spin slider. Inscribed only. Vertices get pins immediately; full enrichment cards fetched on tap (lazy-load to keep API costs manageable). Weekend to a week. **Phase 3 — Circumscription toggle and shape-catalog expansion**: midsphere/circumsphere modes, plus catalog additions (Kepler-Poinsot stars, compounds, prisms/antiprisms, cones, pyramids, Fibonacci, flat star polygons). Per the parametric shape-engine principle, these are content additions to the catalog, not new code paths. Days. **Phase 4 — Analysis Suite**: Voronoi cells, dataset overlays, Monte Carlo, vertex-comparison filters. Portfolio-piece phase. Week or two. **Phase 5 — Spherical harmonics**: HEALPix integration, mode decomposition, icosahedral-mode test. Publishable-result phase. Several weeks. **Phase 6 — Real-Earth Mode**: optional ellipsoid/geoid toggle. Ship when convenient. **Phase 7 — Pirate Mode and content/export polish**: Whydah-era navigation simulator, share links, GeoJSON exports. ### API cost / rate-limiting concern This is the only real new technical constraint: v1 hits Wikipedia/Street View/etc. for one point per session. v2 might want to hit them for 12, 20, 30, or 60 vertices simultaneously. Strategies: - **Lazy load** — only fetch the deep enrichment for a vertex when the user taps it. Show pin + city name + distance immediately (cheap), defer the rich card. - **Caching** — cache vertex lookups by lat/lon (rounded to, say, 3 decimal places) since polyhedron vertices in a given orientation are deterministic. - **Tier the data sources** — Wikipedia and city-name lookups are cheap and can run for all vertices. Street View, satellite, sea traffic are expensive and gate behind a tap. - **Per-mode default behavior** — in "casual user" modes, only enrich the anchor vertex. In "explorer" modes, enrich all vertices. ### Naming and brand alignment - **Geopuesto** as the master app name still works — "geo-opposite" generalizes from antipodes to "what's geometrically related to this point." - Lives under Mapparatus Org alongside TappyMaps and Mapzimus. - Mapzimus markets specific frozen-state share links as viral content. - The Earth-grid debunking work gets framed as a Mapparatus serious-GIS case study, separate landing page, links into Geopuesto for the interactive part. --- ## UI/UX philosophy The whole point of Geopuesto v2 is that the user never sees the math. They see a marble they can play with, and the rich contextual data that v1 already pulls about any point — Wikipedia, Street View, satellite, sea traffic, radio stations — now appears for every geometry-generated point, not just the antipode. ### The core rule Never expose terminology. Translate every concept into a one-line prompt anyone can read: | Concept | What we say to the user | |---|---| | Antipode + great circle | "Where's the opposite side?" | | Inscribed icosahedron | "Spin a star inside it" | | Circumscribed cube (midsphere) | "What if a cube was wrapped around the Earth touching here?" | | Kepler-Poinsot polyhedron | "Spin a spiky star" | | Spherical Voronoi cell | "Show me all the places closer to Salem than anywhere else" | | Small circle at distance d | "Ring of cities at 1000 km" | | Monte Carlo grid test | "Does this cluster on the grid? — Probably coincidence: 62%" | | Latitude-only celestial navigation | "Sail like it's 1717" | The math happens silently in the backend. The user picks a point, picks a shape, watches it spin, sees the places that light up, and taps any of them to dive into the same rich data card v1 already builds for the antipode. ### Carrying v1's strengths forward v1's rich-data pipeline (Wikipedia, Street View, satellite, sea traffic, radio stations, etc.) is the unsung strength of the existing app. It's what makes the antipode feel alive instead of being just a dot. v2 must preserve and extend this: - **Same data card UX** for every geometry-generated point. A vertex of an icosahedron should feel the same to tap as the antipode does today. - **Same thickness ring + city-size filter** generalizes from "along the antipode's great circle" to "along any great circle in the scene" (A–B orthodrome, polyhedron edge, perpendicular bisector, etc.). - **Lazy load** the rich card. Show pin + city name + distance immediately for all vertices; defer the deep enrichment to user interaction. ### The core interaction loop 1. **Tap a point on the 3D globe** (or type a city/coordinates). 2. **Globe rotates to center that point.** Tapped point glows. 3. **Mode dropdown** appears with simple plain-language options (5 max at v1): - "Where's the opposite side?" (current v1 behavior) - "Pick a second point" (two-point mode) - "Spin a cube around it" (circumscribed cube) - "Spin a star inside it" (icosahedron inscribed) - "Test a grid" (analysis mode with dataset overlay) 4. **Visualization renders.** Polyhedron appears (inside or outside the globe), vertices light up as glowing dots, edges drawn as great-circle arcs on the surface. 5. **Right panel auto-populates** with a list of vertex points showing name + distance + small thumbnail. Each entry is tappable. 6. **Tap any vertex** → expand to the full v1-style rich card: Wikipedia, Street View if overland, satellite if ocean, sea traffic, radio stations, all the rest. 7. **Chained interaction**: tap any place in a card → globe centers on it → user can now run a new mode from that point. ### Visualization specifics - **The globe**: Three.js with Mapbox tiles (or Cesium). Terrain off by default; clean continental boundaries. Atmospheric glow optional. - **Points**: glowing dots, color-coded by mode (blue for antipode pair, green for cube tangent points, red for icosahedron vertices, etc.). - **Lines**: great-circle arcs and polyhedron edges drawn as curves on the globe surface. Semi-transparent, soft. - **Polyhedron rendering**: 3D wireframe outside (circumscribed) or inside (inscribed) the globe, with tangent/vertex points where they hit the surface. - **Spin controls**: mouse drag rotates the polyhedron around the anchor point. Optional spin slider for fine control. Optional auto-spin button for content capture. - **The right panel**: list of vertex points → tap to expand into v1's existing rich data card. ### What the user never sees - Words like *orthodrome*, *Voronoi*, *circumscribed*, *midsphere*, *Kepler-Poinsot*, *Rodrigues rotation*, *spherical harmonics*, *Theorema Egregium*. - Coordinate values unless they specifically click "show coordinates." - Formulas of any kind. - Explanations of *why* something works. Just *what* happens. Optional "ℹ︎ what's this?" button per mode opens a short popover with the proper name and a plain-English one-paragraph explanation, linkable to deeper Mapparatus blog posts. Default state: no explanation. ### User journeys **The casual user**: opens Geopuesto, types "Salem," picks "Where's the opposite side?", gets the antipode card — same as v1 today. Wikipedia, Street View, satellite. Shares the link. Done. **The curious user**: picks "Spin a cube around it." 12 dots appear. Drags to rotate the cube, sees them shift. Notices Tunisia, Vietnam, the Antarctic all light up. Taps Vietnam → gets the full rich card for that point (Wikipedia, Street View, etc.) just like the antipode card. Chain-interacts. Spends 20 minutes. **The conspiracy-curious user**: picks "Test a grid." Uploads a CSV of shipwrecks (or picks the preloaded NOAA dataset). App overlays dots, runs Monte Carlo silently, returns: "62% chance this is random." User pokes individual vertex cards to see what's actually there. **The educator**: uses Pirate Mode. Drops a class into 1717 navigation. Students try to sail from Boston to a Caribbean island, get lost. Discussion follows. The app *is* the lesson. **The Mapzimus content producer**: configures a striking visualization, hits "Share" or "Record." Frozen-state link. Posts it. ### Visual mood The app should feel like a marble you're holding and turning, not like ArcGIS. Globe-floating-in-dark-space aesthetic, smooth transitions, touch-friendly on mobile, optional ambient soundtrack for content capture. ### Progressive disclosure of features - **First open**: only the antipode mode visible. Identical to current Geopuesto. No new UI complexity. - **After first use**: small "try another mode" prompt unlocks the next mode (cube). One at a time. - **After 3+ modes explored**: full mode dropdown unlocked. - **Settings toggle**: "Show all modes immediately" for users who already know what they want. ### Backend / frontend split - **Frontend** (Three.js + Mapbox/Cesium + UI framework): globe rendering, drag-to-rotate, point-tapping, mode dropdown, right-panel rendering. Stays dumb — renders what the backend says. - **Backend** (existing v1 backend, extended): receives "anchor at lat/lon, mode=cube, spin angle=θ" and returns vertex positions + city-name resolution + (on tap) the full v1 enrichment for any specific vertex. The polyhedron math, Monte Carlo, and spherical harmonics live server-side. - **The v1 enrichment service is the centerpiece**, not a new build. Polyhedron vertex lookups call into it the same way the antipode call does today. Just with a list of points instead of one. ### API cost management Hitting Wikipedia / Street View / satellite / sea traffic APIs for 12-60 vertices instead of 1 needs care: - **Lazy load the deep enrichment** — only fetch on tap. Show pin + nearest city name + distance immediately (cheap calls). - **Cache by rounded lat/lon** — polyhedron vertices in a given orientation are deterministic, so cache hits are common when users replay configurations. - **Tier the data sources** — Wikipedia and city name are cheap, run for all vertices. Street View, satellite, sea traffic are expensive, gate behind a tap. - **Per-mode defaults** — antipode mode loads everything (1 point); polyhedron modes only fully enrich on tap. --- ## From one point P Things you can build from a single point P on the sphere: - **Antipode** (−P) — the diametrically opposite point. Already the basis of Geopuesto. - **Horizon circle** — the great circle 90° from P in every direction. P is its pole. If P were the north pole, the horizon circle would be the equator. - **Small circles at radius d** — concentric loci at fixed angular distance from P. Gives you a polar azimuthal projection if you draw a bunch of them. - **Tangent plane / gnomonic projection center** — straight lines on a gnomonic map centered at P *are* great circles through P. Useful for navigation. - **Azimuth/bearing field** — the angle from P to every other point on the sphere. Combined with distance, gives polar coordinates centered on P. Critically, you do **not** get a unique "perpendicular" or "meridian" from one point alone. The geometry has rotational symmetry around the P-axis, and any great circle through P is equally valid as a reference meridian. You have latitude (distance from P), but no longitude. --- ## From two points A and B The second point breaks the rotational symmetry and unlocks new structure: - **A–B orthodrome** — the unique great circle through both points. The shortest path on the sphere between them. - **Great-circle midpoint M** — halfway along the A–B orthodrome. - **Perpendicular bisector great circle** — the unique great circle that is the locus of points equidistant from A and B. *The central construct.* - **Loxodrome (rhumb line)** — constant-bearing path. Spirals into the pole, never a geodesic except on meridians/equator. Mercator's whole reason to exist. - **Cross-track distance** — shortest distance from a third point to the A–B great circle. "How far off-route am I." - **Along-track distance** — projection onto the A–B great circle. "How far along the route am I." - **Initial vs final bearing** — asymmetric. Bearing at A pointing toward B is generally *not* the reverse of the bearing at B pointing toward A. Great circles curve in bearing-space. - **Antipodal pair n, −n** — the two poles of the A–B great circle. Both are 90° from every point on the A–B orthodrome. --- ## The perpendicular bisector great circle ### Definition The locus of all points on the sphere that are equidistant from A and B. ### Math in 3D unit vectors Convert A and B to unit vectors **a**, **b** on the unit sphere (lat/lon → xyz). - **Pole of A–B orthodrome**: `n = a × b` (normalize) - **Midpoint of A and B**: `m = (a + b)` (normalize) - **Pole of perpendicular bisector**: `(a − b)` (normalize) These three are mutually orthogonal. The set `{m, (a−b)/|a−b|, n}` is an orthonormal frame built directly from A and B. ### Derivation of equidistance A point P (unit vector p) is equidistant from A and B iff `p·a = p·b`, i.e., `p·(a − b) = 0`. So the perpendicular bisector great circle lies in the plane perpendicular to `(a − b)`, which is exactly what "pole = (a − b)" means. ### What it passes through - M and −M (the midpoint and its antipode — both equidistant from A and B) - n and −n (the poles of the A–B great circle — trivially equidistant since both are 90° from every point on A–B) ### What it does NOT pass through - A or B (unless A = B). Check: `a·(a − b) = 1 − a·b`, which is 0 only when A = B. ### Parameterization for plotting ```python p = (a - b) / norm(a - b) # pole of bisector u = m # midpoint, lies on circle v = cross(p, u) # second basis vector, also on circle circle = lambda t: cos(t)*u + sin(t)*v # t in [0, 2π) ``` Convert each `circle(t)` back to lat/lon for plotting. --- ## Two perpendiculars worth distinguishing The word "perpendicular" hides two different constructions: - **Perpendicular bisector great circle** — equidistant from A and B. Goes through M, −M, n, −n. Does not pass through A or B. - **Perpendicular at A** — the great circle that crosses the A–B orthodrome at right angles at the point A. Goes through A, −A, n, −n. ### General fact All great circles perpendicular to the A–B orthodrome form a **pencil** through n and −n. There are infinitely many — one through every point of the A–B great circle. They all hit A–B at 90°. Like meridians through the north pole, all perpendicular to the equator. The perpendicular bisector is the specific member of this pencil that also passes through M. --- ## 2D vs 3D intuition What breaks when you move from a plane to a sphere: - **90° still exists.** Two great circles can meet at right angles. The angle concept is fine. - **Unique perpendicular line through a point breaks.** On a sphere, "perpendicular" needs a reference great circle, not a reference point. Through any point off a great circle G, there's still a unique great circle perpendicular to G — but through points on G there's only one, and the family of perpendiculars to G as a whole is infinite (the pencil through G's poles). - **Two perpendicular lines meet at one point → two antipodal points.** Two great circles always intersect at exactly 2 antipodal points. - **Four quadrants → four lunes.** The AB orthodrome + perpendicular bisector partition the sphere into four orange-slice wedges (lunes), not four flat quadrants. - **The "four corners" of the system** are M, −M, n, −n. Not lone meeting points, but the cardinal points of the new coordinate system. --- ## The A–B coordinate frame The AB orthodrome + perpendicular bisector = **custom equator + prime meridian**. - **M** is the origin. - **n** is the "north pole" of the frame. - **−M** is the antipodal origin. - **−n** is the "south pole." - Any point on the sphere can be addressed in (lat, lon) relative to this frame instead of Earth's geographic frame. ### What this unlocks - **Voronoi split**: the perpendicular bisector divides the sphere into two hemispheres — "closer to A" and "closer to B." Two-point spherical Voronoi. - **Buffer zones**: regions within distance d of a point or great circle, defined as small circles. - **Orthogonal coordinates**: combined with small circles, you get a usable grid for distance-based geometry. --- ## Next concept — small circles and distance loci The natural next step beyond the frame: parametrize position by distance from the frame's axes. ### Small circle from a point The locus of all points at angular distance d from a fixed point P is a small circle centered at P. Its 3D Euclidean radius is `sin(d)`. At d = 0 it's a point; at d = 90° it's the great circle (P's horizon); at d = 180° it's the antipode. ### Small circle from a great circle The locus of all points at perpendicular distance d from a great circle G is a pair of small circles, one on each side. These are the analog of lines of latitude relative to the equator. At d = 0 you have G itself; at d = 90° you have G's two poles (degenerate, just points). ### Combined: orthogonal coordinates Once you have the A–B frame, you can describe any point by: 1. Distance along the A–B orthodrome from M (the "longitude" coordinate) 2. Perpendicular distance from the A–B orthodrome (the "latitude" coordinate) This is the spherical analog of Cartesian coordinates, with the grid curving along the sphere's surface. --- ## Spherical triangles and spherical excess Add a third non-collinear point C and you get a spherical triangle. Properties that differ from flat triangles: - **Three great-circle sides.** Each side is an arc of a great circle. - **Three angles measured between great circles** (dihedral angles, technically). - **Angle sum exceeds 180°.** The excess (sum − 180°) directly gives the triangle's area: `area = R² × excess` where R is the sphere's radius and excess is in radians. - **There are no similar triangles on a sphere.** Two triangles with the same angles have the same area, which means the same side lengths. Spherical geometry doesn't have scale-invariance. ### Why this is useful Historically: this is how surveyors actually used spherical geometry. Measure angles between landmarks, solve for distances and positions. Modernly: any time you need to compute the area of a polygon on Earth (e.g., a country, a watershed, a school district), you triangulate and sum spherical excesses. This is core GIS math. --- ## Bearings, azimuths, and the asymmetry The bearing from P to Q is the angle measured clockwise from north (at P) to the great circle from P to Q. ### Key quirks - **Asymmetry**: the bearing at P toward Q is not, in general, the reverse of the bearing at Q toward P. Walk from Boston toward London on a great circle and you start out heading roughly northeast; arrive in London and the line behind you points southwest, but not from London's perspective — London-back-to-Boston starts out heading west and curves north. The bearing field is not symmetric. - **Curvature in bearing-space**: even on a single geodesic, your compass heading changes continuously as you walk. Only along a meridian or the equator does it stay constant. - **Loxodromes are the constant-bearing path**, which is why they're not geodesics — they trade shortest-distance for navigational simplicity. --- ## Inscribed shapes on the sphere — full taxonomy The Platonic solids are the famous five, but they're a small slice of what you can inscribe in a sphere. The broader space matters because it (a) opens up far more visual options for the interactive tool, (b) lets you directly reproduce specific conspiracy-grid claims (which use non-Platonic shapes), and (c) gives you arbitrary n-fold symmetry when you want it. ### Platonic solids — the 5 regular convex polyhedra Already covered. All faces same regular polygon, all vertices equivalent. Vertex counts: 4, 8, 6, 20, 12 (tetrahedron, cube, octahedron, dodecahedron, icosahedron). ### Archimedean solids — 13 semi-regular convex polyhedra All vertices equivalent (vertex-transitive), faces are regular polygons but more than one type. All can be inscribed in a sphere with vertices on the surface. The full list with vertex counts: - **Truncated tetrahedron** — 12 vertices (4 hexagons + 4 triangles) - **Cuboctahedron** — 12 vertices at permutations of (±1, ±1, 0). Buckminster Fuller's "vector equilibrium"; cited heavily in Earth-grid material. - **Truncated cube** — 24 vertices - **Truncated octahedron** — 24 vertices; only Archimedean that tessellates 3D space - **Rhombicuboctahedron** — 24 vertices - **Truncated cuboctahedron** — 48 vertices - **Snub cube** — 24 vertices, chiral (two enantiomers) - **Icosidodecahedron** — 30 vertices at the edge-midpoints of an icosahedron - **Truncated dodecahedron** — 60 vertices - **Truncated icosahedron** — 60 vertices. The soccer ball, buckminsterfullerene C60. 12 pentagons + 20 hexagons. - **Rhombicosidodecahedron** — 60 vertices - **Truncated icosidodecahedron** — 120 vertices - **Snub dodecahedron** — 60 vertices, chiral Vertex counts span 12 → 120, giving fine control over grid density. ### Catalan solids — 13 face-transitive duals of the Archimedeans Each face is the same irregular polygon; vertices are not all equivalent. The key one for the conspiracy angle: - **Rhombic triacontahedron** — 32 vertices, dual of the icosidodecahedron. **This is the shape used in the Becker-Hagens grid.** Crucially, its 32 vertices are exactly the 12 vertices of an icosahedron plus the 20 vertices of a dodecahedron, both inscribed in the same sphere with the same circumradius. So you can build it for free by unioning the two Platonic vertex lists. - **Rhombic dodecahedron** — 14 vertices, dual of the cuboctahedron. Tiles 3D space. - **Pentakis dodecahedron** — 32 vertices - **Triakis icosahedron** — 32 vertices - **Disdyakis triacontahedron** — 62 vertices. Combined with other shapes in some conspiracy maps; the full 62-point Becker-Hagens grid corresponds to this. ### Kepler-Poinsot polyhedra — the 4 regular non-convex (star) polyhedra Exactly four of these exist. They're the "regular star polyhedra" — non-convex but still regular in the strict sense (all faces congruent regular polygons, all vertices equivalent). Faces are either star polygons (pentagrams) or convex polygons that pass through one another. - **Small stellated dodecahedron** — 12 vertices coinciding with the icosahedron. 12 pentagram faces. Looks like a 12-pointed spiky star. - **Great dodecahedron** — 12 vertices, also coinciding with the icosahedron. 12 pentagon faces that pass through each other. - **Great stellated dodecahedron** — 20 vertices coinciding with the dodecahedron. Extremely spiky. - **Great icosahedron** — 12 vertices coinciding with the icosahedron. 20 triangular faces that pass through each other. **Key insight for the tool**: vertex placements are identical to the Platonics they share with. You don't need new vertex coordinates for any Kepler-Poinsot star — just different edge lists. Means the tool can offer "star mode" for free once the Platonics are working. ### Compound polyhedra Multiple polyhedra interpenetrating around a shared center. Many compounds have vertex sets that coincide with other regular polyhedra, so again the math is free: - **Stella octangula** — two tetrahedra forming a 3D Star of David. 8 vertices total = the 8 vertices of a cube. Visually striking. - **Compound of five tetrahedra** — 20 vertices, coincide with a dodecahedron. Chiral (left and right versions exist). - **Compound of five cubes** — 20 vertices, coincide with a dodecahedron. The five cubes share their 8 vertices each among the dodecahedron's 20. - **Compound of five octahedra** — 30 vertices, coincide with an icosidodecahedron. - **Compound of ten tetrahedra** — both enantiomers of the five-tetrahedron compound combined; achiral; 20 vertices. Compounds are a cheat code: dense, beautiful point patterns without new vertex math. Particularly viral-content-friendly. ### Stellations A stellation extends the faces of a polyhedron outward until they meet again. The dodecahedron has 3 distinct stellations; the **icosahedron has 59 catalogued stellations** (Coxeter, Du Val, Flather, Petrie, *The Fifty-Nine Icosahedra*, 1938). Most aren't regular but they're geometrically rich. Vertex coordinates depend on the specific stellation — they extend outward along rays from the original Platonic's face centers or vertices. ### Prisms and antiprisms — arbitrary n-fold symmetry For any n ≥ 3 you can inscribe a regular n-prism or n-antiprism in the sphere: - **n-prism**: 2n vertices on two parallel small circles. Aligned (one vertex above another). - **n-antiprism**: 2n vertices on two parallel small circles, rotated 180°/n relative to each other. For a unit sphere with prism axis along z: ``` vertices_top = [(r · cos(2πk/n), r · sin(2πk/n), h) for k in 0..n-1] vertices_bottom = [(r · cos(2πk/n), r · sin(2πk/n), -h) for k in 0..n-1] constraint: h² + r² = 1 ``` For the antiprism, offset the bottom angles by π/n. This is how you get exactly 5-fold or 7-fold or 13-fold symmetry at any latitude you want. A pentagonal antiprism gives you 10 nicely arranged points; a 5-prism gives you 5 points in two stacked pentagons. ### Geodesic spheres / icosahedral subdivision Start with an icosahedron. Subdivide each triangular face into k² smaller triangles. Project new vertices outward to the sphere. Repeat. Vertex counts follow `10k² + 2`: - Frequency 1: 12 (the icosahedron itself) - Frequency 2: 42 - Frequency 3: 92 - Frequency 4: 162 - Frequency 5: 252 - Frequency 10: 1002 This family powers: - Buckminster Fuller's geodesic domes - **H3** (Uber's hexagonal spatial index) - **S2** (Google's spherical indexing system) - **DGGS** (discrete global grid systems used in serious GIS work) The Earth-grid conspiracists use the same family of shapes, just at low frequency. Higher-frequency subdivisions are how modern GIS actually subdivides the planet. ### Quasi-uniform N-point distributions (Fibonacci sphere) When you need arbitrary N points without being locked to a polyhedron's vertex count, use the **Fibonacci sphere lattice** with the golden angle: ```python golden_angle = pi * (3 - sqrt(5)) for i in range(N): z = 1 - 2*(i + 0.5)/N theta = golden_angle * i r = sqrt(1 - z*z) point = (r * cos(theta), r * sin(theta), z) ``` Points aren't exactly equidistant but they're very close. Trivial to compute, scales to any N. The classical alternative is the **Thomson problem** (minimize potential energy of N electrons on a sphere), which has no closed-form solution for most N — numerically optimized configurations exist but Fibonacci is good enough for visualization. ### Flat star polygons on a great circle The simplest "stars" on a sphere: pick a great circle, place n points evenly around it (every 360°/n), connect them in a star pattern by jumping k vertices at a time. Notation: **{n/k}** is the regular star polygon with n vertices, connecting every k-th one. - **{5/2} pentagram** — 5 points at 72° intervals, classic 5-point star - **{6/2} hexagram** — Star of David; technically two overlapping triangles since gcd(6,2)=2 - **{7/2}** and **{7/3}** — two distinct heptagrams for n=7 - **{8/3} octagram** - **{12/5}** — beautiful 12-point star Requires `gcd(n, k) = 1` for a single connected star; otherwise you get multiple overlapping smaller polygons. These lie in the plane of the great circle you chose. On the sphere they trace out 2D star shapes wrapping around the planet. Visually very clean — and minimal vertex count if you want clarity. ### Quick summary table | Family | Count | Vertex range | Notes | |---|---|---|---| | Platonic | 5 | 4–20 | Regular convex | | Archimedean | 13 | 12–120 | Vertex-transitive, mixed faces | | Catalan | 13 | 14–62 | Face-transitive, includes rhombic triacontahedron (Becker-Hagens) | | Kepler-Poinsot | 4 | 12–20 | Regular star polyhedra; share vertices with Platonics | | Compounds | many | 8–60+ | Often share vertex sets with Platonics | | Stellations | 59 (icosa) | varies | Star forms via face extension | | Prisms/antiprisms | infinite | 2n | Arbitrary n-fold symmetry | | Geodesic | infinite | 10k²+2 | Subdivided icosahedron; H3/S2 family | | Fibonacci | infinite | any N | Quasi-uniform, not symmetric | | Star polygons {n/k} | infinite | n | Flat, lies on great circle | --- ## The parametric shape-engine principle A key architectural insight: **the polyhedra suite is not "a feature per shape." It's one engine plus a shape catalog.** Every 3D shape with named anchor points (corners, vertices, apex, spike tips) can be inscribed, circumscribed, or projected onto the globe using the same Rodrigues rotation machinery. What differs between a cube, a cone, a pyramid, and a 3D star is *only the vertex coordinates*. The math doesn't care. ### The general framework For any shape with N anchor points: 1. Define the canonical vertex coordinates (constants). 2. Anchor one (or two) vertex to a user-chosen lat/lon. 3. Apply rotations to position the rest. 4. Convert all vertices back to lat/lon, project to globe. This is identical to the polyhedra math already spelled out — only the input table changes. ### What this unlocks Beyond the standard polyhedra catalog, the same engine handles: - **Cone Earth**: 1 apex + a circular base (parameterized as N points on a small circle). Anchor the apex at Salem → the base traces a small circle on the opposite hemisphere. Anchor a base point at Salem → the apex lands at a specific location, base ring spreads from there. - **Pyramid Earth**: 4 base corners + 1 apex (square pyramid), or 3 base + 1 apex (tetrahedron — already a Platonic, but reframed). Anchor any vertex; the rest lands accordingly. - **3D Star Earth**: the Kepler-Poinsot stars already in the taxonomy. 12 or 20 spike tips. Same engine, framed as "stars" for the user. - **Bipyramids, dipyramids, trapezohedra**: dual to prisms/antiprisms. Two apexes plus a polygonal "belt." User-chosen n. - **Tori (non-convex)**: if you parameterize a torus as N anchor points on its outer or inner ring, the engine handles it. - **Arbitrary user-defined shapes**: a CSV of vertex coordinates uploaded by the user. The engine doesn't care if the shape is "valid" geometrically — it just rotates the points and shows where they land. ### Architectural implication The Polyhedra Suite section of the architecture should treat the **shape catalog as content** (a JSON or database table of `{shape_name: [vertex_coords...]}` entries) and the **engine as infrastructure** (rotation logic + anchor controls + visualization + enrichment-pipeline routing). This means: - **Adding a new shape requires zero code changes.** Drop new vertex coordinates into the catalog. Done. - **The shape library can grow indefinitely.** Cone, pyramid, prism, star, custom user-uploaded shape — all the same operation. - **The user experience stays consistent.** Every shape works the same way: pick anchor, spin, see vertices light up, tap any vertex for the full v1 enrichment card. - **Mapzimus content multiplies for free.** Every new shape in the catalog is a new viral hook ("Earth as a pyramid," "Earth as a cone," "Earth as a 12-pointed star") without new engineering. ### Practical scope decisions The catalog should grow in phases, but the engine should be built shape-agnostic from day one of Phase 2: - **Phase 2 catalog**: 5 Platonics, truncated icosahedron, rhombic triacontahedron, stella octangula, user-chosen n-prism, Fibonacci-N, flat star polygons (already specified). - **Phase 3 expansion**: Kepler-Poinsot stars, compounds, geodesic, plus **cones, pyramids, bipyramids** as new families that drop into the same engine. - **Phase 4+**: arbitrary user-uploaded shape catalog. CSV upload → vertices appear on globe. Becomes a creator tool. ### Prior art for non-polyhedral shapes The cone/pyramid framing as anchored-corner projection of Earth doesn't appear to exist as a consumer-facing tool, but the math is standard: - **Cube projection (Esri, COBE Quad Sphere)**: established cartographic projection but always with fixed pole-aligned orientation. - **Oblique projections**: well-established concept (oblique Mercator, oblique Lambert) — same rotation math as anchoring a cube corner at Salem. - **mrgris's "Mercator Extreme" demo** (mrgris.com/projects/merc-extreme): the closest existing analog — lets users drag any point to become the new North Pole and watch the cylindrical projection warp. Strong proof-of-concept for the interactive appeal. What doesn't exist publicly: the cube, cone, pyramid, or star versions of this with user-controlled anchoring and enrichment cards per vertex. Open territory. --- ## Circumscribed shapes — the dual operation Inscription puts a shape inside the globe with its vertices on the surface. The dual operation is **circumscription**: put the globe inside the shape, with the shape tangent to the globe along faces, edges, or vertices. This generates a different family of point patterns (sort of — see the duality note below) and opens up "outside the globe" framings that are visually more striking. ### The three tangency configurations For any polyhedron arranged concentrically with the sphere, there are three natural tangency modes corresponding to three concentric spheres associated with the polyhedron: - **Insphere** (touches every face center): smallest. Tangent points are the face centroids of the polyhedron. - **Midsphere** (touches every edge): intermediate. Tangent points are along edges — at edge midpoints for regular polyhedra. - **Circumsphere** (touches every vertex): largest. Tangent points are the polyhedron's vertices. The technical term for the edge-tangent sphere is the **midsphere** (or intersphere). It's a standard concept in polyhedron geometry. All Platonic solids, all Archimedean solids, and all Catalan solids have midspheres. ### Tangent-point patterns by configuration For each Platonic solid circumscribing the globe, the tangent points form a recognizable shape: | Circumscribed shape | Face-tangent (insphere) | Edge-tangent (midsphere) | Vertex-tangent (circumsphere) | |---|---|---|---| | Tetrahedron | 4 pts (dual tetrahedron) | 6 pts (octahedron) | 4 pts (tetrahedron itself) | | Cube | 6 pts (octahedron) | **12 pts (cuboctahedron)** | 8 pts (cube itself) | | Octahedron | 8 pts (cube) | 12 pts (cuboctahedron) | 6 pts (octahedron itself) | | Dodecahedron | 12 pts (icosahedron) | 30 pts (icosidodecahedron) | 20 pts (dodecahedron itself) | | Icosahedron | 20 pts (dodecahedron) | 30 pts (icosidodecahedron) | 12 pts (icosahedron itself) | The **face-tangent** column produces the dual of the circumscribed shape. The **edge-tangent** column produces the rectified shape — an Archimedean for the cube/octahedron and dodeca/icosa pairs. ### The Salem cube example Concrete worked case: enclose the globe in a cube of edge length r√2 (where r = Earth's radius), arranged so the globe is tangent to all 12 cube edges. Anchor one tangent point at Salem (42.52°N, 70.90°W). Pick a canonical secondary orientation (the cube edge through Salem aligned toward local north). The 12 tangent points land at: | # | lat | lon | rough location | |---|---|---|---| | 0 | +42.52 | −70.90 | **Salem** (anchor) | | 4 | +77.48 | +109.10 | Arctic, near Siberian coast | | 5 | +7.19 | −126.28 | Eastern Pacific, SW of Mexico | | 8 | +33.41 | +7.11 | Northern Algeria / Tunisia | | 9 | −17.48 | −70.90 | Off coast of Peru, same meridian as Salem | | 1 | +25.18 | +173.56 | Central Pacific | | 2 | −25.18 | −6.44 | Atlantic off West Africa | | 10 | +17.48 | +109.10 | Vietnam / South China Sea | | 6 | −7.19 | +53.72 | Western Indian Ocean | | 7 | −77.48 | −70.90 | Antarctica, directly south of Salem | | 11 | −33.41 | −172.89 | South Pacific | | 3 | −42.52 | +109.10 | Salem's antipode, southern Indian Ocean | Distance distribution from Salem: 4 vertices at 60° (~6,670 km), 2 at 90° (~10,000 km), 4 at 120° (~13,340 km), 1 antipode at 180°. That's the cuboctahedron's natural neighborhood signature. Notable: three of the twelve tangent points sit on Salem's meridian (Salem itself, the Peru point, the Antarctica point, and the antipode at +109.10°). Tunisia, Vietnam, and SW Mexico fall out as the other "named" locations. ### Duality note: same points, different framing Circumscribing a cube around the globe with edge tangency produces the same 12 tangent points as inscribing a cuboctahedron in the globe with vertices on the surface. Mathematically identical operation; just two ways of describing it. Inscribed dual relationships: - Cube edge-tangent ↔ inscribed cuboctahedron (12 pts) - Octahedron edge-tangent ↔ inscribed cuboctahedron (same 12 pts via a differently-oriented octahedron) - Dodecahedron edge-tangent ↔ inscribed icosidodecahedron (30 pts) - Icosahedron edge-tangent ↔ inscribed icosidodecahedron (same 30 pts) So circumscription isn't a *new* family of point patterns mathematically. What it adds is **a different mental model and a more striking visualization**: a giant cube wrapped around the Earth is more visceral than a cuboctahedron embedded inside it, even though the highlighted points are identical. ### Anchoring constraint Same constraint structure as the inscribed case: anchoring one tangent point at Salem locks one rotational degree of freedom; the shape can still spin around the Salem-to-Earth-center axis. Same Rodrigues math handles both modes — no new architecture needed beyond what's already in the Polyhedra Suite. ### Prior work on this framing The pure mathematics is classical and well-named (midsphere, intersphere). It appears in Coxeter, Wolfram MathWorld, and standard polyhedron references. There's also cartographic prior art: at least one US patent (4,773,861) uses a circumscribed polyhedron tangent to the sphere ("Rome de l'Isle polyhedron") for map projection, and polyhedral map projections occasionally use circumscribed configurations (though inscribed is the more common cartographic choice). For Earth-grid / conspiracy work specifically: the related shapes show up (Becker-Hagens use the rhombic triacontahedron, the dual of the icosidodecahedron — the edge-tangent shape for the dodeca/icosa pair). But the **"circumscribe a cube around the Earth touching at 12 edges"** framing as a content or analysis device appears to be unexplored — a viral-content-shaped framing that produces actual mathematical content rather than New Age vagueness. --- ## Tangent: the longitude problem (separate from the above) Came up via Whydah research. Worth distinguishing because it sounds geometrically related but isn't. - **Latitude** = North Star angle above the horizon. Easy from antiquity, no clock required. - **Longitude** requires accurate timekeeping. One hour difference between local solar time and reference time = 15° of longitude. - **Pre-Harrison (1759)** ship chronometers drifted or broke. So sailors used dead reckoning (logging speed and heading), recognized landmarks, followed established trade routes, or just got lost. - **Why pirates thrived** in this era: merchant ships were often wandering blind, off their intended courses by hundreds of miles. Easier to pick off. This is a **technology** gap, not a **geometry** gap. The math of longitude was understood; the instruments couldn't deliver. --- ## Modern debunking work on the Earth-grid claims ### The history being debunked The "Earth grid" pseudoscience has three main historical strands worth knowing: - **Ivan Sanderson, 1972** — proposed 12 "Vile Vortices," roughly icosahedral, claimed as anomaly zones. Includes the Bermuda Triangle and the Devil's Sea (which are roughly antipodal, a fact he leaned on hard). - **Goncharov, Morozov, Makarov (Soviet researchers, 1970s)** — proposed a combined icosahedron-dodecahedron "Earth grid" of 62 vertices. Claimed to align with megalithic sites, civilization centers, ocean current anomalies, fault lines, atmospheric phenomena, etc. - **Becker-Hagens grid (1980s)** — popularization in the West, often packaged with ley line and earth-energy mysticism. Uses the rhombic triacontahedron explicitly, plus a Buckminster Fuller derivation for the 62-point version. The underlying trick: once you've placed 12, 20, 32, or 62 points on a sphere, *something* will be near each of them. Confirmation bias does the rest. The grid is no more predictive than a random scatter of points at the same density — but it *feels* non-arbitrary because the points come from symmetry rather than from someone choosing locations. ### What's been done The Bermuda Triangle specifically has been demolished from multiple angles since the 1970s: - **Larry Kusche, *The Bermuda Triangle Mystery—Solved* (1975)** — went through each incident case by case using primary sources (Coast Guard, Air Force, Lloyd's, newspaper microfilm). Concluded virtually all incidents were caused by storms or accidents, occurred outside the Triangle, or couldn't be verified to have happened at all. Coined it a "manufactured mystery." - **Lloyd's of London** — has maintained since 1975 (reaffirmed in 1997 and again recently) that losses in the Triangle are no higher than elsewhere. No elevated insurance premiums. This is the cleanest market signal: the people who make money by being right about maritime risk price the Triangle as ordinary ocean. - **NOAA and U.S. Coast Guard** — official position is that there is no evidence of a higher rate of disappearances than in other well-traveled ocean regions. The Triangle is not recognized as a distinct or hazardous zone on official charts. - **Karl Kruszelnicki (2017–present)** — comparative risk analysis: when disappearance rates are calculated as a percentage of total voyages, the Triangle aligns with global averages. Volume of traffic plus weather plus human error explains the absolute count. - **Simon Boxall (oceanographer, Southampton)** — attributes specific incidents to rogue waves rather than supernatural causes. For the broader icosahedral grid claim: - **Sharon Hill (geologist, skeptic, 2022)** — detailed debunking of the whole vortex concept. Key points: locations on the "mathematically tidy" map didn't actually line up with the perceived anomalies, locations meandered and became less exact over time, Sanderson himself admitted the Bermuda effect was "weak," and when physical energy measurements failed to show anything anomalous, proponents pivoted to unfalsifiable "spiritual energy" claims. ### The gap There is no peer-reviewed spatial statistics study that formally tests the icosahedral pattern claim. The clean modern test would be: 1. Place the 12 icosahedral vertices on the globe in some canonical orientation. 2. Generate (say) 10,000 random alternative 12-vertex sets on the sphere with the same minimum-spacing constraint. 3. Compare whether real anomalies — earthquakes, magnetic anomalies, shipwrecks, atmospheric phenomena, megalithic sites — cluster more tightly around the icosahedral grid than around the random sets. 4. Report a p-value. Nobody has published this. Likely reasons: - The claim isn't taken seriously enough in mainstream geosciences to be worth refuting in academic literature. - Proponents moved the goalposts to unfalsifiable "spiritual energy" claims, so there's nothing left to test. - Skeptics who care (Hill, Kusche, Kruszelnicki) work case-by-case, not by spatial statistics. ### The opportunity A clean modern test using actual GIS tools — Monte Carlo against random rotations of the icosahedron, real anomaly datasets, properly published — doesn't exist. See *Spherical harmonics* section below for a rigorous version that doesn't even require Monte Carlo. --- ## Topology of the sphere — structural truths Several deep facts about what makes a sphere a sphere. These aren't curiosities — they're the underlying reasons many of the patterns above exist. ### Hairy ball theorem You cannot comb a hairy sphere flat without leaving a cowlick. Formally: there exists no continuous nonzero tangent vector field on a sphere. Any attempt to define a smooth field of vectors tangent to the sphere's surface must vanish (equal zero) at at least one point. **Practical consequence**: at any given moment on Earth, somewhere the horizontal wind is exactly zero. There is always a windless point. Sometimes there are multiple (paired around storm systems), but never zero windless points. This is provable without measurement — it follows purely from the sphere's topology. Other applications: - Vector fields in fluid dynamics on planetary surfaces must have singularities (storm eyes, dead zones). - Hair on a sphere always has a part or cowlick (which is why this theorem has the name it does). - Provides constraints on the design of antennas, sensor coverage, and any vector-field-like phenomenon mapped to a sphere. ### Euler characteristic For any polyhedron topologically equivalent to a sphere: ``` V − E + F = 2 ``` where V = vertices, E = edges, F = faces. This is **the deep reason there are exactly 5 Platonic solids**. Combined with the regularity constraint (each face must have the same number of edges p, each vertex must have the same valence q), you can solve V − E + F = 2 explicitly, and only five (p, q) pairs work: (3,3), (4,3), (3,4), (5,3), (3,5) — corresponding to tetrahedron, cube, octahedron, dodecahedron, icosahedron. **The soccer ball corollary**: a polyhedron with only pentagonal and hexagonal faces, with three faces meeting at each vertex, must have *exactly 12 pentagons* no matter how many hexagons you add. The standard soccer ball has 12 pentagons and 20 hexagons. A buckminsterfullerene C₆₀ molecule has 12 pentagons and 20 hexagons. This is the same theorem. This also constrains virus capsid structure: many viruses have icosahedral capsids, and the 12-pentamer structure (for "T=1" capsids) is forced by topology. ### Four-color theorem on the sphere Every map drawn on a sphere can be colored with at most four colors so that no two adjacent regions share a color. Proven in 1976 (Appel-Haken), the first major theorem proved by computer-assisted exhaustive case analysis. Topology matters here: on a torus you need *seven* colors. The number is determined by the genus of the surface. Earth (genus 0) gets the minimum. ### Why this matters for the broader story The Platonic-solid count, the soccer ball's 12 pentagons, the windless point, and the four-color rule are all expressions of the same underlying topology. The sphere is a particular topological object (genus 0, simply connected, Euler characteristic 2), and every "nice property" of it is downstream of that. --- ## Spherical harmonics — the Fourier of the sphere Spherical harmonics are to functions on a sphere what Fourier series are to functions on a circle: an orthogonal basis that decomposes any reasonable function into modes of increasing angular frequency. ### The basics Spherical harmonics are denoted **Y_l^m(θ, φ)** where: - **l** (degree, ≥ 0): the angular frequency. Larger l = finer angular structure. - **m** (order, |m| ≤ l): which of the 2l+1 orientations within degree l. The first few modes: - **l = 0**: a constant (monopole). The function's average over the sphere. - **l = 1**: dipole. Three modes (m = −1, 0, +1) capturing left-right, north-south, and front-back asymmetries. - **l = 2**: quadrupole. Five modes. Captures things like equator-to-pole differences. - **l = 3**: octupole. Seven modes. - **l = n**: 2n+1 modes. Any reasonable function f on the sphere can be written as: ``` f(θ, φ) = Σ_l Σ_m c_l^m Y_l^m(θ, φ) ``` The coefficients c_l^m tell you "how much" of each mode the function contains. This is the angular power spectrum. ### Real-world applications Spherical harmonics power most of modern Earth science: - **EGM2008** (Earth Gravitational Model 2008): the official gravity field of Earth, expressed as ~2 million spherical harmonic coefficients up to degree l = 2159. This is what GPS uses to compute orthometric heights ("real" elevations above sea level versus heights above the ellipsoid). - **IGRF** (International Geomagnetic Reference Field): Earth's magnetic field, expressed in spherical harmonics. Updated every 5 years. - **Climate models**: temperature, pressure, and circulation fields decomposed into spherical harmonics for global atmospheric general circulation models (GCMs). - **Cosmic Microwave Background analysis**: the Planck satellite published the entire CMB as spherical harmonic coefficients. Cosmological parameters are extracted from the angular power spectrum. The famous "axis of evil" controversy is about an anomalous alignment of the l=2 and l=3 CMB modes. - **Radioastronomy, oceanography, and satellite remote sensing** all use SH decomposition routinely. ### Direct relevance to the Earth-grid project If a real icosahedral pattern existed in Earth's anomalies, it would show up as anomalous power in specific spherical harmonic modes. The icosahedral symmetry group constrains which (l, m) modes can carry icosahedral structure — specifically degrees l = 6, 10, 12, 15, 16, 18, 20, 21, 22... (these are the degrees for which icosahedrally-symmetric harmonics exist). This gives you a **rigorous test with no Monte Carlo required**: compute the SH decomposition of an anomaly dataset (earthquakes, magnetic field, gravity, whatever) and check whether the icosahedrally-allowed modes carry significantly more power than would be expected by chance. If they do, that's evidence of icosahedral structure. If they don't, the grid claim is statistically dead. This has not been done in the published literature for any anomaly dataset. It's potentially a publishable result either way — either you confirm "no, the icosahedral grid is statistical noise" (which kills the conspiracy with finality), or you confirm "the icosahedral modes are anomalously strong" (in which case there's a real geophysical explanation to find, separate from any mystical claim). ### Tooling - **Python**: `scipy.special.sph_harm`, `healpy` (the HEALPix library, originally for CMB analysis, gives you a sphere pixelization plus SH transforms). - **HEALPix** (Hierarchical Equal Area isoLatitude Pixelization) is the standard tool — used by NASA, ESA, and most of cosmology. It pixelizes the sphere into equal-area pixels and supports fast SH transforms. --- ## Real Earth — geodesy and why "sphere" is an approximation Everything in this doc so far has treated Earth as a perfect sphere. Real GIS work doesn't. Earth's actual shape has three layers of refinement, and which one you use matters. ### Layer 1: the sphere The idealization we've been using. Constant radius (typically 6371 km). Fine for: - Visualization and intuition - Continental-scale spatial analysis - Geopuesto-style antipode calculations (the error from sphericity is well under 1° for antipodal points) - Classroom geometry Not fine for: anything requiring sub-100-meter accuracy, vertical positioning, or large-area precise measurements. ### Layer 2: the ellipsoid (WGS84) Earth is an oblate spheroid — flattened at the poles. The flattening is small (about 1/298.257) but significant: - Equatorial radius: 6,378.137 km - Polar radius: 6,356.752 km - Difference: ~21 km WGS84 (World Geodetic System 1984) is the reference ellipsoid GPS uses. Most modern GIS data is in WGS84 (EPSG:4326). The subtle thing: **there are three different definitions of "latitude"** on the ellipsoid, and they don't agree: - **Geocentric latitude**: angle from equatorial plane to the line from Earth's center to your point. - **Geodetic latitude**: angle from equatorial plane to the normal of the ellipsoid surface at your point. This is what GPS reports and what shows up in coordinates. - **Astronomical latitude**: angle from equatorial plane to the local vertical defined by gravity (the plumb line). These disagree by up to about 11 arc-minutes — roughly 20 km at the surface. For most purposes geodetic latitude is correct. But the distinction matters in geodesy and surveying. ### Layer 3: the geoid The actual equipotential surface of Earth's gravity field. Lumpy. The geoid bulges over mass concentrations (mountains, dense crust, ocean trenches paradoxically *also* cause bulges because of the surrounding crust) and dips over mass deficits. The geoid deviates from the WGS84 ellipsoid by up to ±100 meters. "Sea level" technically means the geoid — that's where water would settle in equilibrium under gravity. The ellipsoid is a mathematical convenience; the geoid is what water actually does. Practical implication: **GPS measures heights relative to the ellipsoid**, but your topographic map's elevations are relative to the geoid. To convert, you need a geoid model (EGM2008 again — it's both the gravity field model and effectively the geoid model). The conversion can differ by tens of meters depending on where you are. ### Layer 4: the topography The actual surface, ±9 km from sea level. This is what DEMs (digital elevation models) describe. ### Datums and reference frames A "datum" is a specific realization of a reference ellipsoid plus an origin and orientation. Different datums fit the geoid better in different regions: - **WGS84**: global, used by GPS. - **NAD83**: North American Datum 1983. Fits North America's local geoid better than WGS84 by up to a meter or two. - **NAD27**: older NA datum, off from WGS84 by up to ~200 meters in places. - **ETRS89**: European Terrestrial Reference System. - Hundreds of regional datums exist. When GIS data from different datums gets mixed without proper transformation, you get the classic "everything is in the right shape but shifted by 50 meters" bug. This is one of the most common sources of error in professional GIS work. ### Why this matters for your projects - **For Geopuesto / TappyMaps**: spherical approximation is fine. Ellipsoidal corrections are at most a few km for antipodes — well within "good enough for visualization." - **For the Earth-grid project**: when running formal tests, use real anomaly data in its native datum. Don't compute distances on a sphere if data is in WGS84 — the discrepancy creates artifacts that could mask or mimic real patterns. - **For the GIS job search**: geocentric vs geodetic vs astronomical latitude, geoid undulation, datum transformations — professional-level GIS vocabulary. Signals "I understand what's actually going on under the hood" in interviews. ### The longitude problem revisited Earlier in this doc the longitude problem was framed as a pure technology gap (no accurate clocks). With geodesy in mind, there's actually a layer underneath: even *with* a perfect clock, longitude on a non-spherical Earth requires knowing the ellipsoid model. Pre-Harrison sailors weren't just lacking clocks; they were lacking the geodetic framework that would have made their measurements precisely meaningful even if they had clocks. Both gaps were filled in the 18th and 19th centuries — the chronometer for time, then geodetic surveys (Cassini, Maupertuis, et al.) for shape. --- ## Math reference — polyhedron-on-globe construction This section is the math for the Polyhedra Suite in Architecture above. Concept and UI are covered earlier; this is the implementation reference. ### The math #### Step 1: Canonical vertex coordinates (constants) Each Platonic solid has a known set of vertex coordinates on the unit sphere. Let φ = (1 + √5)/2 ≈ 1.618 (golden ratio). Normalize each set so all vertices lie at distance 1 from origin. **Tetrahedron (4 vertices)**: ``` (1, 1, 1), (1, −1, −1), (−1, 1, −1), (−1, −1, 1) ``` divide each by √3. **Cube (8 vertices)**: ``` (±1, ±1, ±1) ``` divide each by √3. **Octahedron (6 vertices)**: ``` (±1, 0, 0), (0, ±1, 0), (0, 0, ±1) ``` already unit length. **Icosahedron (12 vertices)**: ``` (0, ±1, ±φ), (±1, ±φ, 0), (±φ, 0, ±1) ``` divide each by √(1 + φ²). **Dodecahedron (20 vertices)**: ``` (±1, ±1, ±1), (0, ±1/φ, ±φ), (±1/φ, ±φ, 0), (±φ, 0, ±1/φ) ``` divide each by √3. Store these as 3D arrays in your code. They're constants — same every time. #### Step 1b: Beyond the Platonics — vertex coordinates for the rest **Kepler-Poinsot star polyhedra (4 of them, all share vertices with Platonics)**: - Small stellated dodecahedron → use icosahedron vertices, different edge list - Great dodecahedron → use icosahedron vertices, different edge list - Great stellated dodecahedron → use dodecahedron vertices, different edge list - Great icosahedron → use icosahedron vertices, different edge list No new vertex coordinates needed. **Edge lists differ** — that's what makes them stars when rendered as wireframes. **Compound polyhedra (vertex sets coincide with other polyhedra)**: - Stella octangula (two tetrahedra) → 8 vertices = cube vertices (alternating sets of 4) - Compound of 5 tetrahedra → 20 vertices = dodecahedron vertices - Compound of 5 cubes → 20 vertices = dodecahedron vertices - Compound of 5 octahedra → 30 vertices = icosidodecahedron vertices Again, no new vertex math — just edge lists that connect them differently. **Rhombic triacontahedron (Catalan, 32 vertices, Becker-Hagens grid)**: ``` vertices = icosahedron_vertices + dodecahedron_vertices ``` Both inscribed in the same unit sphere. Concatenate the two arrays. Done. This is the literal Becker-Hagens grid. **Cuboctahedron (Archimedean, 12 vertices)**: ``` (±1, ±1, 0), (±1, 0, ±1), (0, ±1, ±1) ``` divide each by √2. **Icosidodecahedron (Archimedean, 30 vertices)**: ``` (±φ, 0, 0), (0, ±φ, 0), (0, 0, ±φ), (±1/2, ±φ/2, ±φ²/2) and all even permutations ``` divide each by φ. **Truncated icosahedron (the soccer ball, 60 vertices)**: ``` (0, ±1, ±3φ), (±1, ±(2+φ), ±2φ), (±φ, ±2, ±(1+2φ)) ``` and all even permutations of each row. Divide each by √(9φ + 10). **n-prism (any n ≥ 3, 2n vertices)**: ```python # Inscribed in unit sphere with axis along z; choose height h # Constraint: h² + r² = 1 h = chosen_height # for "regular" n-prism with square sides, specific h applies r = sqrt(1 - h*h) top = [(r*cos(2*pi*k/n), r*sin(2*pi*k/n), h) for k in range(n)] bottom = [(r*cos(2*pi*k/n), r*sin(2*pi*k/n), -h) for k in range(n)] ``` **n-antiprism (any n ≥ 3, 2n vertices)**: ```python # Same as prism, but bottom rotated by pi/n top = [(r*cos(2*pi*k/n), r*sin(2*pi*k/n), h) for k in range(n)] bottom = [(r*cos(2*pi*k/n + pi/n), r*sin(2*pi*k/n + pi/n), -h) for k in range(n)] ``` **Geodesic sphere (icosahedral subdivision, frequency k → 10k² + 2 vertices)**: Start with icosahedron vertices and face list. For each triangular face with vertices A, B, C, generate the grid of subdivision points: ```python for i in range(k+1): for j in range(k+1-i): l = k - i - j # Barycentric coordinates point = (i*A + j*B + l*C) / k point /= norm(point) # project to unit sphere ``` Deduplicate shared edge/vertex points across faces. **Fibonacci sphere (any N points, quasi-uniform)**: ```python golden_angle = pi * (3 - sqrt(5)) points = [] for i in range(N): z = 1 - 2*(i + 0.5)/N theta = golden_angle * i r = sqrt(1 - z*z) points.append((r*cos(theta), r*sin(theta), z)) ``` **Flat star polygon {n/k} on a great circle (n vertices)**: Place n points evenly on a great circle, then specify a connection pattern. The vertices themselves are just: ```python # In the xy-plane (great circle = equator) vertices = [(cos(2*pi*i/n), sin(2*pi*i/n), 0) for i in range(n)] # Edges connect vertex i to vertex (i + k) mod n edges = [(i, (i + k) % n) for i in range(n)] ``` Pentagram {5/2}: n=5, k=2. Hexagram {6/2}: n=6, k=2 (degenerates into two overlapping triangles). If the user wants the great circle to be something other than the equator, apply a rotation to the vertices first (same Rodrigues math from Step 2). #### Step 2: Rotate so vertex v₀ lands at P Pick one of the canonical vertices as v₀ (any one — the choice just changes the rotation, not the final shape). Convert P (lat, lon) to a 3D unit vector **p**: ``` p_x = cos(lat) · cos(lon) p_y = cos(lat) · sin(lon) p_z = sin(lat) ``` Compute the rotation that takes v₀ to p using **Rodrigues' rotation formula**: ``` axis a = (v₀ × p) / |v₀ × p| angle θ = arccos(v₀ · p) ``` The rotation matrix is: ``` R = I + sin(θ)·[a]× + (1 − cos(θ))·[a]ײ ``` where `[a]×` is the skew-symmetric "cross-product matrix" of a: ``` [a]× = | 0 −a_z a_y | | a_z 0 −a_x | | −a_y a_x 0 | ``` Apply R to every vertex of the polyhedron. Now v₀ is at P, and all other vertices have moved accordingly while keeping the polyhedron rigid. **Edge case**: if v₀ is already very close to p, |v₀ × p| → 0 and the axis is undefined. Special-case this: just apply the identity rotation (or skip the rotation entirely). If v₀ is at the antipode of p, any axis perpendicular to v₀ works — pick one arbitrarily. #### Step 3: Free rotation about the P-axis After Step 2, the polyhedron is anchored at P but can still rotate around the axis through P and the origin. This is the "spin" degree of freedom the user controls. Apply a second Rodrigues rotation: ``` axis a = p (the user's chosen point, used as the rotation axis) angle φ = user-controlled (slider or drag) R_spin = I + sin(φ)·[p]× + (1 − cos(φ))·[p]ײ ``` Apply R_spin to every vertex except v₀ (which is on the axis and doesn't move). #### Step 4: Project vertices back to lat/lon for display For each rotated vertex **v** = (v_x, v_y, v_z): ``` lat = arcsin(v_z) lon = arctan2(v_y, v_x) ``` Drop a pin on the map at each (lat, lon). Done. #### Step 5 (optional): Draw edges as great-circle arcs Each polyhedron has a fixed edge list (pairs of vertex indices). For each edge connecting vertices A and B, draw a great-circle arc on the globe: ``` For t in [0, 1]: interp(t) = sin((1−t)·Ω)/sin(Ω) · A + sin(t·Ω)/sin(Ω) · B where Ω = arccos(A · B) ``` This is **spherical linear interpolation (SLERP)**. Sample 30–50 points along each edge, convert to lat/lon, draw as a polyline. ### Implementation notes (Stack and backend/frontend split are covered in the UI/UX section above. These notes are math-side gotchas.) - **Edge lists differ between shapes that share vertices**: Kepler-Poinsot stars, compounds, and Platonics often share vertex sets but render as totally different shapes because the edges connect different pairs. Maintain a separate edge list per shape, not per vertex set. This is what makes "star mode" essentially free once Platonics work. - **Vertex deduplication**: when computing geodesic subdivisions, neighboring triangular faces share edge vertices. Build a dedup pass (round coordinates to 6 decimal places and key into a hash map) to avoid drawing the same point multiple times. - **Chirality flag**: snub cube, snub dodecahedron, and the compound of 5 tetrahedra each have two enantiomers. The tool should expose both, or pick one and stick with it. - **Single source of truth**: keep vertices as 3D unit vectors throughout. Only convert to lat/lon at the display step. Avoids accumulating projection errors during rotation. - **Quaternion vs matrix rotations**: Three.js has native quaternion support, which is slicker than matrix Rodrigues for chained rotations. Functionally equivalent. - **Overlay datasets** for the analysis mode: shipwrecks (NOAA AWOIS), earthquakes (USGS), magnetic anomalies (NOAA EMAG2), megalithic sites (Megalithic Portal), UFO sightings (NUFORC), volcanoes (Smithsonian GVP). Each overlay toggleable. - **Monte Carlo mode**: button to randomize the polyhedron's orientation N times (10,000 default) and plot the distribution of "near-anomaly" hits. The icosahedron-versus-random-12-points test is the formal Earth-grid debunking experiment. ### Effort estimate Standard 3D math throughout — nothing here is research. The only "lookup" piece is canonical vertex coordinates, which are tabulated everywhere. A weekend for v1 (single polyhedron, no overlays, no Monte Carlo); roughly a month total for the full feature set per the phased build order in Architecture. --- ## Open threads and next decisions Now that the architecture is one consolidated app, the open questions are scoped to phasing, not "what's this for": ### Immediate (Phase 1 scoping) - **Two-point upgrade**: is this the right first phase to ship, or do you want to go straight to Polyhedra Suite? Two-point is smaller, ships faster, and is a genuine usability upgrade to existing Geopuesto users. - **Stack decision**: current Geopuesto stack vs. anything new. If current stack works, stay; don't restart what's working. - **2D map projection vs 3D globe**: current Geopuesto presumably uses one. The polyhedra visualizations work in either — orthographic D3 looks great, Three.js looks more "real." Pick one for consistency with existing app. - **Enrichment pipeline reuse plan**: how exactly does the current v1 backend get refactored to accept a list of points instead of just one? This is the central architecture question for v2. Probably small refactor (loop over points calling the existing single-point endpoint), but worth confirming early. - **API cost / rate-limit strategy**: decide on lazy-loading approach before Phase 2 ships. Cheap calls (Wikipedia, city name) for all vertices on render; expensive calls (Street View, satellite, sea traffic) only on user tap. ### Soon (Phase 2-3 decisions) - **Polyhedra Suite v1 shape list**: suggested cut is 5 Platonics + truncated icosahedron + rhombic triacontahedron + stella octangula + user-chosen n-prism + Fibonacci-N + {n/k} flat star. Drop or add? - **Anchor controls**: 1-point anchor with spin slider, or 2-point anchor that fully constrains orientation? The 2-point option is more powerful but more UI; the 1-point option is simpler and matches the "Geopuesto = point-based tool" feel. - **Circumscription toggle in Phase 2 or Phase 3**: same math but different rendering. Could ship in v1 if visual budget allows. - **Parametric shape engine commitment**: build the Phase 2 engine shape-agnostic from day one (vertex catalog as data, engine as code) so cones, pyramids, custom user shapes, and future additions slot in without refactoring. This is a one-time architectural decision worth getting right in Phase 2. ### Later (Phase 4-6 strategic decisions) - **Earth-grid debunking module**: when does it ship — as part of Geopuesto, as a separate Mapparatus landing page that links in, or both? - **Spherical harmonics**: realistic for a solo build? HEALPix has a Python wrapper but no clean JS equivalent. Might need a Python backend service for this feature. - **Real-Earth Mode (ellipsoid/geoid)**: needed for professional credibility, but doesn't affect any user-facing feature meaningfully unless you're chasing meter-level accuracy. Probably ship-when-convenient, not blocking. ### Cross-project - **Mapzimus content pipeline**: which frozen-state share links go up first? Best candidates: (a) cube around the Earth anchored at Salem, (b) always-windless point, (c) 5-tetrahedra compound spinning, (d) the icosahedral grid failing the spherical harmonics test side-by-side with the conspiracy claim. - **GIS job-search portfolio framing**: does the Earth-grid debunking go on the portfolio site as its own project, or as a Mapparatus subprojects writeup? Affects how you describe it in cover letters. - **High school GIS course**: this doc is essentially a curriculum outline for a unit on spherical geometry. Worth flagging as such for the 99x elective planning. - **Whydah connection**: the longitude problem already fits the existing teaching arc. Pirate Mode in Geopuesto (Phase 7) could be a fun standalone module that drops a user into 1717 navigation — celestial latitude only, dead reckoning, no clock, see how lost you get. Synergy with existing Whydah research. ### Out of scope - **howe2math**: don't pull sphere geometry into the Algebra/Geometry pipeline. The Geometry warm-up about Platonic solids derivation (V−E+F=2) is the only legitimate crossover; everything else lives in the future GIS elective. - **NSN**: no connection. Stay walled off.