Hurricane Seasons Of The Planet: An Interactive, Animated 3D Globe

This bounty buys a polished, self-contained interactive visualization of planetary hurricane seasons: a rotating 3D globe of Earth on which every tropical cyclone of the 1991–2026 seasons, all basins worldwide, can be played through time. A time slider pans through the months; storms appear, drift, strengthen, weaken and vanish; and a comparison overlay underlays a reference year's storm situation beneath the current one. The artifact must illustrate, to a general audience, the kind of El Niño-driven anomaly described in the article "The Wrong Ocean" (thegoodclimate.substack.com, linked under Inputs): record storm energy in the eastern Pacific, a near-empty Atlantic, and typhoon activity on the far side of the planet.

The artifact is a browser visualization built from the tropical-cyclone best track record defined under Inputs. One entry per storm is one best track: the storm's position and strength at each recorded observation time. The globe shows the planet's surface — land and ocean distinguishable — with storm positions rendered on it.

Required interactive features:

1. Time slider. A single slider pans the displayed time forward and backward across the covered range (see the time bounds under Acceptance Criteria). When it moves, the set of visible storms and each storm's displayed position and strength update to the selected time.
2. Animated transitions. When the selected time changes, each visible storm's rendered position and size animate between consecutive recorded observations rather than jumping instantaneously, so that dragging the slider or autoplay produces continuous motion.
3. Storm rendering. Each storm is visualized as a rotating turbulent cloud formation whose visual extent reflects the storm's strength (winds) and whose visual character clearly distinguishes stronger from weaker storms. A rendering that is merely a colored dot or marker does not satisfy this: the storm must read as a turbulent, rotating cloud-like object.
4. Spawn and dissipation. A storm that is not yet present at the selected time fades in as it spawns, and fades out as it dissipates; the fade must be visible during slider panning and autoplay.
5. Autoplay. A control starts, pauses and restarts an automatic advance of the time slider, so a hurricane season (or seasons) can be watched pass.
6. Current time display. The currently selected date and time is displayed continuously and prominently — large and positioned in a corner of the visualization's bounding box — while the slider pans and autoplay runs.
7. Comparison overlay. The user can pick a reference year. While the overlay is active, moving the slider shows the current year's storm situation with the chosen reference year's situation at the same calendar date and time semi-transparently underlaid beneath it, so two years can be compared day-for-day.

The visualization must run inside commonly used browsers. It may use WebGL, and is expected to use it or an equivalent technology capable of the 3D globe and animated storm rendering. Everything the browser needs — HTML, JS, CSS, data — must run locally from the Submission, offline, with no network access, no external CDN and no build step that requires one.

• app/ folder: the complete, working visualization and its complete source code. Both are required: the Submission contains the full human-readable source (HTML, CSS and JavaScript as maintained by the author, including any build or bundling configuration and its inputs) and the built output the browser runs. Opening app/index.html in Chrome or Firefox, offline, loads the built output. All JavaScript, styles, textures and data it loads are local files inside the Submission; no external links. Source passes this check when every JavaScript file the built output was generated from is present in the Submission as non-minified source: each file is syntax-valid standalone, no line exceeds 500 characters, and at least 30% of its non-empty lines are under 100 characters. "Syntax-valid" means the file parses without error as JavaScript in the context the Submission declares for it — classic script or ES module, matching how the built output loads it — checked with an ECMAScript 2024-compliant parser (for example node --check for classic scripts or node --input-type=module --check for modules). The source-completeness test is presence, not reproduction: a Submission passes when the Submission's files contain the authored JavaScript sources for the built output (the files the build or bundling configuration lists as its inputs, and any configuration, package or lock files needed to identify them), each meeting the non-minified source the built output; successful build reproduction is not an acceptance criterion. The acceptance test is presence of the sources and inputs above, plus the built output itself loading and working offline in the browsers named under Acceptance Criteria. A Submission whose only JavaScript is minified or compiled output fails this requirement.
• app/data/ folder: the storm best-track dataset the visualization loads, covering all basins worldwide and the seasons 1991–2026 (see Acceptance Criteria for the source and time bounds). Any efficient format is accepted; it must be submitted as bytes.
• tools/import/ folder: a runnable, self-contained converter that transforms a full IBTrACS v04r01 CSV (the format described under Inputs, any revision — including later daily-refreshed versions) into the exact format the visualization loads in app/data/, applying the same window and spur rules stated under Acceptance Criteria, and regenerating the matching manifest.json. This lets the Poster keep the visualization current with new storm data after the bounty settles. It must run offline with Node.js 24 or 26 (node tools/import/import.mjs <csv> <outdir>, or an equivalent documented entry point) and may not require any network access, package registry or other download at run time; any libraries it uses beyond the Node standard library must be included in the Submission.
• manifest.json: JSON object listing, for every distinct storm in app/data/, one entry with the storm's IBTrACS serial number (SID) as it appears in the pinned snapshot — this is the identity key for the dataset coverage check — together with the storm's name (or designation), the season year, its basin — the BASIN value of the storm's first non-spur observation inside the window (a storm that crosses a basin boundary is represented by this single starting basin; the full per-observation basin sequence lives in the track data) — the timestamp of its first observation and the timestamp of its last observation. It is the judgeable inventory of the dataset, and its SID values must map one-to-one to the storms in app/data/.
• README.md: how to open and use the visualization, the browser versions tested, and how each required feature is operated.

Among valid Submissions, the winner is the highest total score on this rubric. Each criterion is scored 0 (absent or fails), 1 (meets the requirement), or 2 (meets it with polish clearly beyond the requirement), except where stated:

The maximum score is 36. If two Submissions tie on the total, the higher score on criterion 3 (storm rendering) wins. If they still tie, the higher score on criterion 7 (comparison overlay) wins. Among Submissions still tied, the active Submission with the lowest submission_call_count wins. submission_call_count is ElgoraHub's bounty-wide count of accepted submissions at that call; it rises with every call, so no two Submissions share one, and resubmitting replaces the active Submission and gives it a later count.

The daily-refreshed URL cannot alone identify these bytes, so the snapshot is pinned by its size and SHA-256, and both access paths must yield bytes hashing to it: bytes hashing differently are not the selected input. The Submission pins the exact extraction in two ways: app/data/ contains the bytes the visualization loads, and manifest.json inventories them. The 2026 season spot-check (see Acceptance Criteria) is additionally anchored to the NHC Tropical Cyclone Report tables for that date, which are static.

The best track each storm contributes is defined by the snapshot's general variables, as documented in the IBTrACS technical documentation (Appendix A, "General Variables"): storm identity and membership by SID, with SEASON, BASIN, NAME and ISO_TIME; position by LAT and LON (the IBTrACS-combined mean positions); strength by WMO_WIND (maximum sustained wind, knots, assigned by the responsible WMO agency, WMO_AGENCY) and, where available, WMO_PRES. Records whose TRACK_TYPE begins with spur are excluded from tracks, positions and strengths, following the documentation's guidance that spurs are ignored when counting and analyzing storms; every other TRACK_TYPE (main, PROVISIONAL, US-PROVISIONAL) contributes. Where the documentation assigns a value per observation, that per-observation value governs; no agency-prefixed column set other than the general variables above defines the track for this bounty.

The dataset coverage check requires exact source membership against the pinned snapshot: 3,736 distinct tropical cyclones worldwide qualify by having at least one non-spur observation in the window 1 January 1991 00:00 UTC through 29 October 2026 15:00 UTC in IBTrACS v04r01, as extracted from the pinned 29 October 2026 snapshot identified under Inputs. The manifest's storm set — keyed by SID — must correspond one-to-one with that qualifying set (see Dataset coverage). A manifest count outside 3,363–4,110 fails the check outright, indicating the wrong snapshot or a broken extraction; a count inside the band still requires the one-to-one membership comparison to pass. The offline, own-files rule is an artifact property: the visualization runs without network access and loads nothing outside the Submission. Source comparison is separate: for the dataset coverage check, the spot-check storm names, and the position and date tolerances, the evidence that governs is the fixed snapshot identified under Inputs — its hash pins the exact bytes — together with the spot-check names stated under Acceptance Criteria.

• Forecasting, predicting or explaining future storm activity.
• Climate attribution or commentary beyond what the visualization shows.
• Storm damage, casualty or economic impact data.
• Mobile browsers, touch-only operation and accessibility compliance.
• Server-side components, web services or hosting; the artifact is local-only.