# Overview

## Design goals

- Provide a way for tools to recognize that multiple versions of an array at different resolutions are available for rendering or analysis
- Support adding new resolution to the set of multiscales
- Minimize duplication of metadata
- Provide a fingerprint of the methods used to produce a version of the native dataset
- Support both explicit coordinates, which are defined by arrays, and implicit coordinates, which are defined by metadata
- Support multiple coordinate systems (e.g., affine, EPSG:4326, EPSG:3857, etc.)
- Support multiscales that vary across any number of resolutions

## Non-goals

- Solve consistency issues between Zarr arrays, groups, and metadata so that this can be solved by other conventions or libraries

## Configuration

## FAQ

- Why not have `factors` and `scale`:
- To minimize surface area for mistakes, since the two fields would contain duplicative information

## References

- [OME-Zarr](https://ngff.openmicroscopy.org/0.5/index.html#multiscale-md)
- [CarbonPlan/ndpyramid](https://docs.carbonplan.org/maps/data)
- [EOPF-Data-Model](https://github.com/EOPF-Explorer/data-model)
- [Zarr Specifications Discussion on Multiscales](https://github.com/zarr-developers/zarr-specs/issues/50)
- EOPF-ZARR (Sentinel 2, UTM r10, r20, r60)
- GRID4EARTH (DGGS)

## Notes from discusssion

Multiscales
- Convention
- Composable
- Discipline agnostics
- Enable visualization
- Enable times (hourly monthly, daily)
- Optional to fingerprint method of creation
- Assume naive average
- Minimize number of gets
- Must be possible to add multiscales (not based on ordering 
- Must be possible to make something a multiscales isn’t a multiscipes
- Must work for summary statistics, machine learning 

Where should multiscals live?

- Above Zarr  
- Software for creating
- solve pain by needing to write all levels at once
- Zarr drop-in for COG