Tweak text

posts/zarr-visualization-update.md

@@ -36,7 +36,7 @@ First, we explored whether the next version of the Zarr specification (V3) and t
 
 Second, we implemented support for on-the-fly projection in the [`@carbonplan/maps`](https://github.com/carbonplan/maps) Javascript library, making it possible to load “unprojected” data stored with latitude/longitude coordinates and dynamically project it into Web Mercator (and, in the future, other coordinate systems). In our testing, we found slower performance (~30%) with this approach relative to rendering data already stored in Web Mercator, particularly at higher zoom levels. This feature is still a major step towards dynamically rendering analysis-ready datasets because many Earth science data products are stored in this coordinate system, so we expect many users will be willing to tolerate the performance difference. But the results are a reminder that removing some pre-processing steps may come at the cost of visualization performance.
 
-You can check out the [Zarr visualization report](https://nasa-impact.github.io/zarr-visualization-report/) for more details on our approach, benchmarking results, and recommendations. Our collaborators at Development Seed, an engineering and product company that specializes in Earth data, have built a tile server approach to Zarr visualization, in which a server dynamically generates visualization-ready Zarr data from a different data source. That differs in several ways to the “serverless” approach described above, and has both advantages and disadvantages. The Zarr Visualization Report provides more information on the tile server approach.
+You can check out the [Zarr visualization report](https://nasa-impact.github.io/zarr-visualization-report/) for more details on our approach, benchmarking results, and recommendations. Our collaborators at Development Seed, an engineering and product company that specializes in Earth data, have built a tile server approach to Zarr visualization, in which a server dynamically generates visualization-ready Zarr data from a different data source. That differs in several ways to our approach described above, and has both advantages and disadvantages. The Zarr Visualization Report provides more information on the tile server approach.
 
 Alongside this progress, we’re excited about several directions for further improvement. On the front-end side, we hope to further loosen the pre-processing requirements to support non-global pyramids or eliminate the need for pyramids altogether. While this flexibility will be useful, our work also showed that reducing pre-processing requirements can make it slower to render maps. Our collaborators at Development Seed showed that providing pyramids is particularly important for high-performance web map rendering. Therefore, on the data pre-processing side, we are working to make the pyramid-generation requirement less onerous by generalizing and optimizing the [`ndpyramid`](https://github.com/carbonplan/ndpyramid) library and integrating `ndpyramid` with [Pangeo-Forge recipes](https://github.com/pangeo-forge/pangeo-forge-recipes). Finally, we’ve been engaging with the Zarr Implementation Council and Zarr refactor working group to support the finalization and implementation of the Zarr V3 spec in Python.