Jinemi/thermograph
4
0
Fork 0
Code Issues 2 Pull requests 3 Projects Releases Packages Wiki Activity Actions
thermograph/static/compare.html

110 lines
5 KiB
HTML
Raw Normal View History

Add comfort-temperature compare view; simplify Feels calendar filter (#9) Compare page (frontend/compare.{html,js} + /thermograph/compare route): line up several places over a date range and rank which best matches a comfort temperature. Per location it pulls the same daily record the Calendar uses and, per day, takes a chosen temperature (daytime high / daily mean / overnight low / feels-like) against the comfort target. A day "hits comfort" when it lands within an adjustable band; otherwise it counts as colder or warmer and the average miss is tracked. Results are ranked by comfort-day share (tie-broken by the smaller typical miss), with a diverging below/comfort/above bar and per-bucket stats. Comfort, band and judged temperature re-rank instantly client-side; only the location set or date range trigger a data load (shared calendar cache). Feels calendar filter: drop the comfort-temperature slider and the client-side felt-high/felt-low re-pick. The Feels metric now colors by the server's combined feels-like value like the other metrics, so its tab matches the rest of the metric selector.
2026-07-11 02:58:56 +00:00
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Thermograph — compare comfort</title>
Link previews: Open Graph tags + logo for shared URLs (#35) Sharing a Thermograph URL (Discord, Slack, iMessage…) now unfurls into a card with the site name, page title, description, accent color, and logo. - All five pages get description/theme-color/og:*/twitter:card meta and a favicon. og:url/og:image need absolute URLs and crawlers don't run JS, so pages carry an __ORIGIN__ placeholder the server fills in per request from X-Forwarded-Proto (Caddy) / scheme + the Host header + base path — correct on both the LAN dev server and the prod domain without hardcoding either. - New logo assets: the header's ▚ mark as an app icon (accent quadrants on the dark surface) — logo.png (512x512, the og:image) and logo.svg (favicon). - Page routes render the substitution with a weak ETag + 304 revalidation (replacing plain FileResponse) and now answer HEAD, which preview crawlers probe with (previously 404).
2026-07-11 15:59:14 +00:00
<meta name="description" content="Pick any point on Earth and see how its recent weather stacks up against ~45 years of local climate history — graded days, calendars, forecasts, and side-by-side comparisons." />
<meta name="theme-color" content="#f0803c" />
<!-- Link previews (Discord, Slack, iMessage…). The server fills the og:url /
og:image origins in from this request's scheme://host + base path —
crawlers need absolute URLs and don't run JS. -->
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Thermograph" />
<meta property="og:title" content="Thermograph — compare comfort" />
<meta property="og:description" content="Pick any point on Earth and see how its recent weather stacks up against ~45 years of local climate history — graded days, calendars, forecasts, and side-by-side comparisons." />
<meta property="og:url" content="__ORIGIN__/compare" />
<meta property="og:image" content="__ORIGIN__/logo.png" />
<meta property="og:image:width" content="512" />
<meta property="og:image:height" content="512" />
<meta property="og:image:alt" content="Thermograph logo" />
<meta name="twitter:card" content="summary" />
<link rel="icon" href="logo.svg" type="image/svg+xml" />
<link rel="apple-touch-icon" href="logo.png" />
Add comfort-temperature compare view; simplify Feels calendar filter (#9) Compare page (frontend/compare.{html,js} + /thermograph/compare route): line up several places over a date range and rank which best matches a comfort temperature. Per location it pulls the same daily record the Calendar uses and, per day, takes a chosen temperature (daytime high / daily mean / overnight low / feels-like) against the comfort target. A day "hits comfort" when it lands within an adjustable band; otherwise it counts as colder or warmer and the average miss is tracked. Results are ranked by comfort-day share (tie-broken by the smaller typical miss), with a diverging below/comfort/above bar and per-bucket stats. Comfort, band and judged temperature re-rank instantly client-side; only the location set or date range trigger a data load (shared calendar cache). Feels calendar filter: drop the comfort-temperature slider and the client-side felt-high/felt-low re-pick. The Feels metric now colors by the server's combined feels-like value like the other metrics, so its tab matches the rest of the metric selector.
2026-07-11 02:58:56 +00:00
<link rel="stylesheet" href="https://unpkg.com/leaflet@1.9.4/dist/leaflet.css" />
<link rel="stylesheet" href="style.css" />
</head>
<body>
<header>
<div class="brand">
<span class="logo">▚</span>
<div>
<h1>Thermograph · Compare</h1>
<p class="tag">Which place best hits your comfort temperature over a date range</p>
</div>
<nav class="view-nav" aria-label="Views">
<a href="./" data-view="map">Weekly</a>
<a href="calendar" data-view="calendar">Calendar</a>
<a href="day" data-view="day">Day</a>
<a href="compare" data-view="compare" class="active">Compare</a>
</nav>
</div>
</header>
<main>
<!-- Locations to line up against each other. -->
<section class="controls">
<div class="cmp-locs">
<span class="cal-filter-label">Locations</span>
<ul id="cmp-loc-list" class="cmp-loc-list"></ul>
Compare: put full state in the URL and gate reloads behind Refresh (#12) The whole comparison — locations, comfort target, band, judged temperature and date range — is now encoded in the URL hash (c/t/b/s/e/loc) and read back on load, so a link reproduces exactly what's on screen. Comfort, band and judged-temperature edits still re-rank instantly and update the hash without a fetch. Editing the date range or the location set no longer refetches on its own: it marks the comparison dirty and reveals a single "Refresh comparison" button next to Add location; the load runs only when it's tapped. Pending locations show a dashed chip until then. The initial view (from a shared link, the saved set, or the last-viewed spot) still loads on arrival.
2026-07-11 03:17:17 +00:00
<div class="cmp-loc-actions">
<button type="button" id="cmp-add" class="find-btn"></button>
<button type="button" id="cmp-refresh" class="cmp-refresh-btn" hidden>Refresh comparison ↻</button>
</div>
Add comfort-temperature compare view; simplify Feels calendar filter (#9) Compare page (frontend/compare.{html,js} + /thermograph/compare route): line up several places over a date range and rank which best matches a comfort temperature. Per location it pulls the same daily record the Calendar uses and, per day, takes a chosen temperature (daytime high / daily mean / overnight low / feels-like) against the comfort target. A day "hits comfort" when it lands within an adjustable band; otherwise it counts as colder or warmer and the average miss is tracked. Results are ranked by comfort-day share (tie-broken by the smaller typical miss), with a diverging below/comfort/above bar and per-bucket stats. Comfort, band and judged temperature re-rank instantly client-side; only the location set or date range trigger a data load (shared calendar cache). Feels calendar filter: drop the comfort-temperature slider and the client-side felt-high/felt-low re-pick. The Feels metric now colors by the server's combined feels-like value like the other metrics, so its tab matches the rest of the metric selector.
2026-07-11 02:58:56 +00:00
</div>
</section>
<!-- The comfort target, what temperature to judge by, the tolerance band, and
the date range. Comfort/band/basis recompute instantly (no refetch); only
the date range or the location set trigger a data load. -->
<div id="cmp-params" class="cmp-params" hidden>
<div class="cmp-param cmp-comfort">
<label for="cmp-comfort">Comfort temperature <b id="cmp-comfort-val"></b></label>
<input id="cmp-comfort" type="range" min="30" max="100" step="1" />
</div>
<div class="cmp-param cmp-band">
<label for="cmp-tol">Comfort band <b id="cmp-tol-val"></b></label>
<input id="cmp-tol" type="range" min="0" max="15" step="1" />
<span class="hint">A day "hits comfort" when it lands within this many degrees.</span>
</div>
<div class="cmp-param cmp-basis-block">
<span class="cal-filter-label">Judge each day by its</span>
<div class="metric-toggle" id="cmp-basis" role="group" aria-label="Temperature to compare">
<button type="button" data-basis="tmax" class="active">High</button>
<button type="button" data-basis="mean">Mean</button>
<button type="button" data-basis="tmin">Low</button>
<button type="button" data-basis="feels">Feels</button>
</div>
</div>
<div class="cmp-param cmp-range cal-range" id="cmp-range">
<div class="cal-range-head">
<span class="cal-filter-label">Date range</span>
<span class="hint">any span; longer loads take a moment</span>
</div>
<label>From <input id="cmp-start" type="month" /></label>
<label>To <input id="cmp-end" type="month" /></label>
Compare: put full state in the URL and gate reloads behind Refresh (#12) The whole comparison — locations, comfort target, band, judged temperature and date range — is now encoded in the URL hash (c/t/b/s/e/loc) and read back on load, so a link reproduces exactly what's on screen. Comfort, band and judged-temperature edits still re-rank instantly and update the hash without a fetch. Editing the date range or the location set no longer refetches on its own: it marks the comparison dirty and reveals a single "Refresh comparison" button next to Add location; the load runs only when it's tapped. Pending locations show a dashed chip until then. The initial view (from a shared link, the saved set, or the last-viewed spot) still loads on arrival.
2026-07-11 03:17:17 +00:00
<span class="hint">Editing the range arms Refresh — tap it to reload.</span>
Add comfort-temperature compare view; simplify Feels calendar filter (#9) Compare page (frontend/compare.{html,js} + /thermograph/compare route): line up several places over a date range and rank which best matches a comfort temperature. Per location it pulls the same daily record the Calendar uses and, per day, takes a chosen temperature (daytime high / daily mean / overnight low / feels-like) against the comfort target. A day "hits comfort" when it lands within an adjustable band; otherwise it counts as colder or warmer and the average miss is tracked. Results are ranked by comfort-day share (tie-broken by the smaller typical miss), with a diverging below/comfort/above bar and per-bucket stats. Comfort, band and judged temperature re-rank instantly client-side; only the location set or date range trigger a data load (shared calendar cache). Feels calendar filter: drop the comfort-temperature slider and the client-side felt-high/felt-low re-pick. The Feels metric now colors by the server's combined feels-like value like the other metrics, so its tab matches the rest of the metric selector.
2026-07-11 02:58:56 +00:00
</div>
</div>
<div id="cmp-head" class="cal-head" hidden></div>
<div class="placeholder" id="cmp-placeholder">
<p>Add two or more places to see which one best matches your comfort temperature
across a date range — the share of days that land in your comfort band, how
often it runs colder or warmer, and by how much.</p>
</div>
<div id="cmp-results" class="cmp-results"></div>
</main>
<script src="https://unpkg.com/leaflet@1.9.4/dist/leaflet.js"></script>
<script src="nav.js"></script>
<script src="mappicker.js"></script>
<script src="compare.js"></script>
</body>
</html>
Reference in a new issue Copy permalink