A time-enabled vectortile layer is built with its time placeholders still
literal in its address. Raster tile layers resolve theirs while they are being
built. Because of that gap, a vectortile layer only ever receives a real time
value as a side effect of a reload happening later, so whether it is correct
depends on what else has run rather than on its own configuration.
What happens today
- A time-enabled vectortile layer draws with unresolved placeholders in its
requests until something triggers a time reload for that specific layer.
- Reloads skip layers that are switched off. A layer the mission configures off
therefore keeps its placeholders until it is switched on, or until the
timeline moves while it is on.
- One of the time tokens the raster tile path understands is never substituted
on the vectortile path at all — only the start, end and custom-time tokens
are.
- Time reaches the layer only by temporarily rewriting the layer's stored
address, rebuilding so the builder reads the rewritten value back, and then
putting the template back. A failure partway through that detour can leave the
stored address without its placeholder, and the layer then cannot be filled in
again for the rest of the session.
What we want instead
A vectortile layer resolves its time when it is built, exactly as a raster tile
layer does — the same tokens, including the one currently unsupported. Nothing
else has to run first for the layer to be asking for the right data.
This removes the rewrite-rebuild-restore detour for this layer type and makes
the two tile-shaped layer types behave the same way, which is also what makes
them reviewable against each other.
Acceptance
- A time-enabled vectortile layer configured on requests data for the selected
time on its first draw, with no placeholder left in the request.
- The same layer configured off, then switched on, requests the currently
selected time.
- Moving the timeline updates it, as it does now.
- The time token that currently only works for raster tile layers resolves for
vectortile layers too.
- After any of the above, the layer's stored address still holds its template,
so a later time change can fill it again.
- Behaviour is the same on both rendering engines.
Out of scope
- How the time control decides which layers to reload.
- The catch-up that runs when a layer is switched on — it stays useful for layer
types that resolve time elsewhere.
Implementation sketch — written as of cc22597a on 2026-09-03; a rough guide, re-verify against latest
Where it lands: the vectortile builder in the map module, alongside the
raster tile builder it should end up mirroring.
Current shape. The vectortile builder is synchronous. It takes the
configured address through the generic URL resolver (plus a rewrite for the
geodataset case) and hands the result straight to the deck.gl layer on one
branch and to the Leaflet vector grid on the other. It never calls the
time-replacement helper or the tile-URL compiler that the raster tile builder
uses, which is the whole of the difference.
Rough plan. Mirror the raster tile builder: run the resolved source address
through the time-replacement helper and then through the tile-URL compiler with
the standard tile options, before constructing the layer — on both engine
branches.
⚠️ Gotcha worth stating outright: doing this makes the vectortile builder
async, and the layer-construction dispatcher currently calls it bare. If it is
not awaited, the layer will not exist yet when the post-construction hand-off to
the rendering engine runs; the hand-off finds nothing, returns, and the layer is
never registered with the engine at all — it silently never draws and never
requests anything. This exact failure already happened once with the raster tile
builder, which is async for the same reason and had been called bare for about
two years before it mattered. Check every call site of the builder, not just the
obvious one.
Second thing to check. Once creation resolves the time, work out whether the
reload path's rewrite-rebuild-restore detour is still needed for this layer type,
and make sure the two cannot both substitute and produce a doubly-substituted
address.
Third. Order matters and should match the raster path: resolve the source
address first, then the replacements, then compile the tile options. Doing the
replacements first appends cache-busting parameters to the raw configured
address, which for a layer whose address embeds another URL puts them inside the
wrong one.
Testing. The existing unit specs around the time control and the layer toggle
are the closest models. A real check needs a mission with a time-enabled
vectortile layer, one configured on and one configured off, verified by looking
at the actual request URLs rather than at whether something rendered.
A time-enabled vectortile layer is built with its time placeholders still
literal in its address. Raster tile layers resolve theirs while they are being
built. Because of that gap, a vectortile layer only ever receives a real time
value as a side effect of a reload happening later, so whether it is correct
depends on what else has run rather than on its own configuration.
What happens today
requests until something triggers a time reload for that specific layer.
therefore keeps its placeholders until it is switched on, or until the
timeline moves while it is on.
on the vectortile path at all — only the start, end and custom-time tokens
are.
address, rebuilding so the builder reads the rewritten value back, and then
putting the template back. A failure partway through that detour can leave the
stored address without its placeholder, and the layer then cannot be filled in
again for the rest of the session.
What we want instead
A vectortile layer resolves its time when it is built, exactly as a raster tile
layer does — the same tokens, including the one currently unsupported. Nothing
else has to run first for the layer to be asking for the right data.
This removes the rewrite-rebuild-restore detour for this layer type and makes
the two tile-shaped layer types behave the same way, which is also what makes
them reviewable against each other.
Acceptance
time on its first draw, with no placeholder left in the request.
selected time.
vectortile layers too.
so a later time change can fill it again.
Out of scope
types that resolve time elsewhere.
Implementation sketch — written as of
cc22597aon 2026-09-03; a rough guide, re-verify against latestWhere it lands: the vectortile builder in the map module, alongside the
raster tile builder it should end up mirroring.
Current shape. The vectortile builder is synchronous. It takes the
configured address through the generic URL resolver (plus a rewrite for the
geodataset case) and hands the result straight to the deck.gl layer on one
branch and to the Leaflet vector grid on the other. It never calls the
time-replacement helper or the tile-URL compiler that the raster tile builder
uses, which is the whole of the difference.
Rough plan. Mirror the raster tile builder: run the resolved source address
through the time-replacement helper and then through the tile-URL compiler with
the standard tile options, before constructing the layer — on both engine
branches.
async, and the layer-construction dispatcher currently calls it bare. If it is
not awaited, the layer will not exist yet when the post-construction hand-off to
the rendering engine runs; the hand-off finds nothing, returns, and the layer is
never registered with the engine at all — it silently never draws and never
requests anything. This exact failure already happened once with the raster tile
builder, which is async for the same reason and had been called bare for about
two years before it mattered. Check every call site of the builder, not just the
obvious one.
Second thing to check. Once creation resolves the time, work out whether the
reload path's rewrite-rebuild-restore detour is still needed for this layer type,
and make sure the two cannot both substitute and produce a doubly-substituted
address.
Third. Order matters and should match the raster path: resolve the source
address first, then the replacements, then compile the tile options. Doing the
replacements first appends cache-busting parameters to the raw configured
address, which for a layer whose address embeds another URL puts them inside the
wrong one.
Testing. The existing unit specs around the time control and the layer toggle
are the closest models. A real check needs a mission with a time-enabled
vectortile layer, one configured on and one configured off, verified by looking
at the actual request URLs rather than at whether something rendered.