Skip requests for layers with no data in the time window - #421
Open
sandesh-sp wants to merge 5 commits into
Open
Skip requests for layers with no data in the time window#421sandesh-sp wants to merge 5 commits into
sandesh-sp wants to merge 5 commits into
Conversation
A time-enabled layer requests tiles for every instant the timeline visits, including instants its data does not cover, and every one of those requests comes back empty. The layer configs already declare their coverage through time.dataStartTime, time.dataEndTime and time.dataDates, but nothing reads them at request time. The design gates requests on that coverage: a pure coverage module, three gate points that take an out-of-coverage layer off the map, a state record on the layer registry, and a warning icon in the Layers tool whose popover names the instant asked for and the coverage the layer does have.
The design had the Layers tool reading the coverage registry off L_ and importing the core's coverage module for its popover wording, and it accepted two derivations of coverage — the core's and the Timeline's — policed by an agreement test. All three cross the plugin boundary the wrong way. The core now derives coverage, holds it and serves it as a complete record over layers:getDataCoverage and layers:dataCoverageChanged, following the layers:getCogCapabilities precedent. Consumers read that record and word themselves; the core ships no prose. A second phase migrates the Timeline off its own parsing so the core is the single authority rather than one of two opinions.
…rity and precision
Each time-enabled layer can declare when it has data, as a list of dates or a start/end extent. On every time change, a layer whose declared coverage does not overlap the requested window is hidden and makes no tile or URL-replacement requests; it is shown again once the window moves back into its coverage. Coverage state is published on the event bus as layers:dataCoverageChanged. TimeControl now initializes before Map_ in the modern layout, so layers are built with their time window already set.
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
1 participant
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.
What
Layers can now say when they have data: either a list of dates or a start/end range (the new Data Time Extent fields in the layer config).
Each time the time window changes, we check every time-enabled layer against its coverage:
Layers that don't declare any coverage behave exactly as before.
Why
Without this, moving the time slider sends tile requests for every time-enabled layer, even ones that have nothing for that date. Those requests are wasted and can show empty or error tiles.
Other changes
layers:dataCoverageChanged), so plugins can show it (e.g. "no data for this date").Spec
docs/superpowers/specs/2026-09-09-layer-data-coverage-request-gating-design.mdTesting
npx vitest run: all passing).