--- profile: elgora_markdown_bounty_challenge_v1 escrow_amount: "20000000" submission_deadline: 1795003200 payout_policy: winner_take_all --- # Hurricane Seasons Of The Planet: An Interactive, Animated 3D Globe ## Summary 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. ## Challenge details 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. ## What you need to submit (Deliverables) - `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 `, 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. ## Acceptance Criteria A valid Submission satisfies all of the following. The visualization must function entirely from the files it contains, with no network access and no resource outside the Submission: this is a property of the artifact, checked where the artifact runs. **Browsers.** The visualization loads and functions fully in each of the latest Chrome and the latest Firefox on desktop. It must not require any other browser, an extension or a server. **Dataset coverage.** The best-track dataset in `app/data/` is derived from the pinned snapshot defined under Inputs (NOAA IBTrACS, WMO agencies' best tracks, version 04r01). A storm qualifies by having at least one non-spur observation inside the window 1 January 1991, 00:00 UTC through 29 October 2026, 15:00 UTC, in any basin worldwide. The dataset contains every qualifying storm and no others. A qualifying storm's submitted track retains its observations from the snapshot inside the window and omits those outside it, so every submitted track lies wholly inside the window. Acceptance is exact source membership: the set of distinct storms listed in the manifest must correspond one-to-one with the set of qualifying storms, identified by the storm's IBTrACS serial number (SID). The reference count stated under Evidence, Provenance and Verification (3,736) is a cross-check that this comparison was done against the correct snapshot; a manifest count outside the 3,363–4,110 band indicates the wrong snapshot or a broken extraction and fails acceptance, while a count inside the band does not by itself pass it — the one-to-one membership check decides. **Converter.** Running the converter against the pinned snapshot CSV produces, from those bytes alone, a dataset and manifest that satisfy the Dataset coverage and Data integrity criteria above. The converter also accepts a later IBTrACS v04r01 revision with the same column layout: run against it, it produces a valid dataset for that revision under the same rules. Evidence is the run itself: the tool executes offline as documented and its output satisfies the coverage and integrity checks. **2026 season check.** For the year 2026, the visualization renders at least these named storms at their recorded positions on their recorded dates, in each of these two basins: North Atlantic — Arthur, Bertha, Cristobal, Dolly, Edouard, Fay, Gonzalo, Hanna, Isaias, Josephine; East Pacific — Amanda, Boris, Cristina, Douglas, Elida, Fausto, Genevieve, Hernan, Iselle, Julio, Karina, Lowell, Marie, Norbert, Nolo, Odalys, Polo, Rachel, Simon, Trudy, Vance. A storm missing from this list fails this check, as does one rendered more than 5° in latitude or longitude away from the position the source records for the selected time, or more than 48 hours from the source's date for the selected storm. This is the fixed spot-check; a Submission may render additional 2026 storms beyond it. **Features.** Each of the seven features listed under Challenge details is present and operable as described. On each, evaluation observes the running visualization: the slider updates the storm set, positions and strengths; transitions animate; fades are visible at spawn and dissipation; autoplay advances and can be paused; the current date and time is visible large in a corner throughout; and with a reference year selected, the reference year's storms appear semi-transparently beneath the current ones at the same calendar date. For a selected date that does not exist in the reference year — 29 February of a leap year against a non-leap reference year — the overlay shows the reference year's storm situation for the nearest existing time, 28 February 23:59 UTC of the reference year, so the comparison is always defined. The year picker offers every season year present in the dataset (1991 through 2026) as a selectable reference year. When the selected calendar date and time has no reference-year data — for example a date after 29 October with 2026 as the reference year, or a date before the reference year's first storm — the overlay renders no reference-year storms (an empty underlay), which passes this feature as long as the overlay works for dates where reference data exists. A feature present but broken in either browser fails that feature. **Storm rendering.** Storms are visually turbulent, rotating cloud formations that reflect strength and extent, not static dots or markers. Two storms of clearly different strength at the same time must render with clearly different visual size or intensity. **Data integrity.** The manifest's per-storm first and last observation timestamps agree with the underlying best-track data, and the visualization loads every storm listed in the within-bounds manifest without errors in the browser console. A Submission missing any required feature, failing the dataset coverage window, failing the 2026 season spot-check in either browser, or requiring network access fails acceptance, regardless of other merits. ## How is the winner selected? 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: | # | Criterion (each scored 0–2) | | --- | --- | | 1 | Time slider panning and storm set/position/strength updates | | 2 | Smoothness and quality of animated transitions between observations | | 3 | Visual quality and realism of the turbulent, rotating storm rendering | | 4 | Visibility and quality of spawn/dissipation fades | | 5 | Autoplay usability, including pause/restart | | 6 | Prominence and readability of the current time display | | 7 | Comparison overlay: usability, semi-transparent underlay quality, year pick | | 8 | Globe visual quality: planet surface, land/ocean rendering | | 9 | Overall interactivity and illustrative value to a general audience | 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. ## Inputs, Materials and References | Input | Access and selected version | | --- | --- | | Tropical cyclone best tracks, all basins, 1991–2026 | NOAA IBTrACS version 04r01, CSV access file `ibtracs.since1980.list.v04r01.csv`, the snapshot last modified 29 October 2026, 09:02 UTC (145,248,966 bytes; SHA-256 `54b9e0cca66f9a019818d1b2452a84355ba4fd224149c8e440765ea2db9d5b11`). Two access paths, either acceptable provided the fetched bytes hash to that SHA-256: (a) `https://www.ncei.noaa.gov/data/international-best-track-archive-for-climate-stewardship-ibtracs/v04r01/access/csv/ibtracs.since1980.list.v04r01.csv` — that URL is refreshed daily, so bytes fetched later may differ from the snapshot; (b) a MEGA file mirror provided by the Poster: `https://mega.nz/file/WdMXnJyJ#xaChMx-JlNFwYezFvwtbv_8NyYZ-8MbSvYwIyIYDwvc` (the full link, including the fragment after `#`, is required: it holds the decryption key). Extract storms with observations in the 1991–2026 window. | | 2026 spot-check names and dates (North Atlantic and East Pacific basins) | National Hurricane Center Tropical Cyclone Reports, 2026 season tables: `https://www.nhc.noaa.gov/data/tcr/index.php` (North Atlantic and East Pacific, as of 29 October 2026) | | Background: the illustrative story | Article "The Wrong Ocean", The Good Climate, 26 October 2026: `https://thegoodclimate.substack.com/p/the-wrong-ocean`. Background reading only; its claims are not acceptance criteria. | | IBTrACS technical documentation | `https://www.ncei.noaa.gov/sites/default/files/2025-04/IBTrACS_version4r01_Technical_Details.pdf` | 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. ## Evidence, Provenance and Verification 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. ## Out Of Scope - 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.