Conversation
Deploying gridlook with
|
| Latest commit: |
460d9fc
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://af1a44f0.gridlook.pages.dev |
| Branch Preview URL: | https://loco.gridlook.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
feat: follow live datasets that stream one timestep at a time
Summary
Adds support for live datasets — a Zarr store whose time axis is fully declared up front, but where only the currently-available timestep can be fetched at any moment. This lets Gridlook follow a running simulation or a rolling forecast, jumping to and re-rendering each new timestep as the model produces it.
Enable it by appending
::live=trueto the dataset URL:How it works
When live mode is active, Gridlook:
current-timestependpoint, so the very first render requests a chunk that actually exists (bounded by a 10s timeout; best-effort — the follow loop recovers on its own if it fails).next-timestependpoint and, whenever a newer timestep is reported, writes it into the time slider — which the existing grid loader already watches — triggering a refetch and re-render.5xx, showing a subtle "Reconnecting…" indicator until the connection recovers.Live mode is HTTP-only (Zarr
FetchStore); Icechunk stores are not supported. The live time index is deliberately kept out of the shareable URL, since it's re-seeded from the server on load.Server contract
The data server must expose two endpoints as siblings of the store root, each returning
{ "timestep": <index> }:current-timestepnext-timestepFull details in
docs/live-datasets.md.Changes
src/lib/data/liveTimestep.ts— endpoint helpers plusLiveTimestepController, which drives the fetch-current-then-long-poll loop with backoff and abort handling.src/store/useLiveTimestep.ts— Vue composable wiring the controller into the store, starting/stopping it as live/pause state and the datasource change.live/livePaused/liveConnected/liveTimestepstate and actions;liveURL param plumbed throughparamStoreandurlParams.DimensionControl.vueshows the LIVE badge + pause/resume and disables manual time scrubbing;useTimeAnimation.tsdisables playback for live datasets;GlobeView.vueseeds the initial timestep on load.tests/unit/lib/data/liveTimestep.test.tscovers URL joining, payload parsing/validation, HTTP-only detection, and the controller's emit-current-then-follow / stop-before-start behaviour.docs/live-datasets.md; README pointer.Incidental: more robust HEALPix
nsidedetectionHealpix.vue'sgetNside()was refactored into a clear fallback chain —healpix_nsideon the CRS variable →dggs.refinement_levelon the group → inferring from a global grid's cell count (ncells = 12 · nside²) — with a descriptive error when none apply. This makes grid rendering more resilient for stores that don't carry an explicithealpix_nside.Notes
package-lock.jsonchurn is metadata only (devOptional→devreclassification of platform-specific optional deps).