On May 2, 2025, at theCNG 2025, we held a birds of a feather session onZarr Visualization approaches.

As an opening prompt, attendees were asked to share what their interests and experience is with Zarr visualization approaches. Attendees were familiar with or using @carbonplan/maps, have built in-house Zarr visualization platforms with pyramiding and caching, and were interested in using the GPU for visualization and 3 and 4-D mapping. In general, attendees agreed that visualizing Zarr should be "as-easy" as visualizing COGs, with interoperability for platforms such as QGIS, so Zarr datasets can be accessible to all levels of user.

Summary of discussion

• Adopting COG-Style Overviews for Zarr: Broad agreement that Zarr should support overview levels (like COGs) to enhance visualization; ideally, chunks should align with CRS-based resolutions.
• Zarr and Visualization Tools: A GDAL Zarr driver could improve integration with tools like QGIS, but virtualization systems like Icechunk may not be supported even if GDAL reads Zarr.
• 3D Visualization: Tools like Neuroglancer and Nepari demonstrate potential for 3D visualization using Zarr, suggesting broader use cases beyond 2D rasters.
• Standards Evolution: Need to define a Web-Optimized Zarr (WOZ) spec, potentially building on ndpyramid and GeoZarr. Discussion centers on CRS encoding approaches (CF vs COG-like) and multi-dimensional aggregation.
• Client-Side Rendering Benefits: Rendering directly in-browser (e.g., via GPU) allows flexible, fast interaction without server overhead—highlighted by Kyle’s GPU-based demo using deck.gl raster layers.

Roadmap for Zarr Visualization

I wrote up a roadmap that I felt represented the discussion about order of operations. I am open to feedback or modifications!

1. Web-Optimized Zarr Spec drafted, tested and accepted by community

• Revisitndpyramid, reconcile ndpyramid andWOZ and CRS with GeoZarr.

The spec should include:

• How CRS should be specified
• How TMS multiscales will be stored and the associated metadata specification
• Definition of support for varied tile matrix sets

2. Build server-side tools on top of that spec

There is no need for a server vs client-side debate as both are necessary for different use cases: Server-side can plug-in to existing tools via WMS and WMTS. Client-side enables power, serverless direct data interactions.

• Build a purpose built Zarr IO library for reading chunks and generating tiles. We don't need to overhead of xarray.
• Improve server-side APIs using the purpose-built Zarr IO library

3. Build client-side tools on top of that spec

4. Zarr in-browser readers

   1. Do we need to pick one, zarrita.js or zarr-js? See open questions.

5. Icechunk in-browser readers

   • Develop a typescript reader for icechunk, which could be extracted from neuroclancer
   • build WASM binding for Icechunk. It will take a lot of work (well some say a week, some say a year) but is possible. Will require re-writing some of Icechunk.

• GL layers for Zarr (can be more than one)
  1. numeric-data-layer is in progress at Development Seed (Hanbyul, Kyle). Currently using deck.gl but may usezarr-gl (Mapbox GL and Maplibre).

Open questions

• Do we need more than one gl implementation?
• What is the strategy for addressing transforms? Are they supported or only Zarr that follows the WOZ spec?
• zarr-gl uses zarr.js, whereas preference for zarrita was expressed, which should be adopted by the community?