Before you start
What happened?
Zarr layer stops rendering above zoom ~12 — reproducible with the bundled
NOAA sample dataset
Environment
- GeoLibre Desktop 2.9.0 (also reproduced on 2.7.0)
@carbonplan/zarr-layer ^0.9.0- Linux, WebKit (Tauri)
What happens
A Zarr layer renders correctly up to map zoom ~11.9. At zoom 12 and above
the layer disappears completely — no error in the UI, the layer stays
listed and visible in the Layers panel.
Why this is not a data problem
Reproduced with two datasets of completely different size:
| dataset |
extent |
behaviour |
| bundled NOAA sample ("Load sample data…") |
global (~360°) |
stops at ~zoom 12 |
| own dataset, single farm field |
0.023° (0.0065% of globe width) |
stops at ~zoom 12 |
That the cutoff lands at the same zoom for datasets differing by a factor
of ~15,000 in extent argues against an extent-dependent cause and for a
fixed threshold somewhere in the render path.
What was ruled out on our own dataset
Before testing the bundled sample we varied nearly everything:
- Zarr v2 and v3 (v3 is required by the app; v2 gives
Not found: v3 array or group)
- UTM (EPSG:32613) and WGS84 coordinates
- compressed (zstd) and uncompressed (
bytes codec only)
- no pyramid, OME-style
multiscales:[{datasets:[{path:"0"},…]}],
and {layout:[{asset,"spatial:shape","spatial:transform"}]}
- a pyramid spanning 80 m down to 2.5 m (6 levels), so a level finer
than the native resolution exists for high zoom
All combinations behave identically: fine up to ~12, gone above.
Per-level transforms were verified to be consistent (every level covers
the same bounding box).
Code reading (may be wrong — offered as a starting point)
selectLevelForZoom in region-math.ts has no upper cutoff: when no
level qualifies it falls back to the finest available level
(return levelResolutions[levelResolutions.length - 1].index). So level
selection alone should not produce a hard stop.
Two candidates we could not distinguish from the outside:
getVisibleRegions returns an empty array when no proj4
transformer is set up (region-math.ts, ~lines 60-67) — a silent blank
path. Should not apply to a stock WGS84 sample, but it is the one
place that produces exactly this symptom without an error.MAX_CACHED_REGIONS = 128 in region-cache.ts versus
updateVisibleRegions, which fetches every visible region without
checking that count against the cache size. Visible regions grow with
zoom; if the count crosses 128, regions could be evicted before upload
and never stabilise.
(2) would explain the extent-independence: what grows with zoom is the
number of visible regions, not the geographic extent.
Steps to reproduce
- Load zarr dataset
- zoom in onto a level of 12 and higher
Expected behavior
Map still shows something on all zoom levels. in Precision Farming i have 1x1m rasters and still want to see the 10x10m raster in the background
How are you running GeoLibre?
Desktop App
Operating system and browser
Ubuntu 24.04.5 LTS
Sample data
Inegrated NOAA Dataset
Screenshots or logs
No response
Before you start
What happened?
Zarr layer stops rendering above zoom ~12 — reproducible with the bundled
NOAA sample dataset
Environment
@carbonplan/zarr-layer^0.9.0What happens
A Zarr layer renders correctly up to map zoom ~11.9. At zoom 12 and above
the layer disappears completely — no error in the UI, the layer stays
listed and visible in the Layers panel.
Why this is not a data problem
Reproduced with two datasets of completely different size:
That the cutoff lands at the same zoom for datasets differing by a factor
of ~15,000 in extent argues against an extent-dependent cause and for a
fixed threshold somewhere in the render path.
What was ruled out on our own dataset
Before testing the bundled sample we varied nearly everything:
Not found: v3 array or group)bytescodec only)multiscales:[{datasets:[{path:"0"},…]}],and
{layout:[{asset,"spatial:shape","spatial:transform"}]}than the native resolution exists for high zoom
All combinations behave identically: fine up to ~12, gone above.
Per-level transforms were verified to be consistent (every level covers
the same bounding box).
Code reading (may be wrong — offered as a starting point)
selectLevelForZoominregion-math.tshas no upper cutoff: when nolevel qualifies it falls back to the finest available level
(
return levelResolutions[levelResolutions.length - 1].index). So levelselection alone should not produce a hard stop.
Two candidates we could not distinguish from the outside:
getVisibleRegionsreturns an empty array when no proj4transformer is set up (region-math.ts, ~lines 60-67) — a silent blank
path. Should not apply to a stock WGS84 sample, but it is the one
place that produces exactly this symptom without an error.
MAX_CACHED_REGIONS = 128inregion-cache.tsversusupdateVisibleRegions, which fetches every visible region withoutchecking that count against the cache size. Visible regions grow with
zoom; if the count crosses 128, regions could be evicted before upload
and never stabilise.
(2) would explain the extent-independence: what grows with zoom is the
number of visible regions, not the geographic extent.
Steps to reproduce
Expected behavior
Map still shows something on all zoom levels. in Precision Farming i have 1x1m rasters and still want to see the 10x10m raster in the background
How are you running GeoLibre?
Desktop App
Operating system and browser
Ubuntu 24.04.5 LTS
Sample data
Inegrated NOAA Dataset
Screenshots or logs
No response