Support axis metadata convention

[calgray]

A limitation of using a datavars per coordinate component with SkyCoord dataset is its not easy to recombine direction/position into a single tensor. For example, SkyCoord.to_cartesian exposes the x, y, z parts as the fastest changing axis.

The reason for separating the components is primarily due to each direction component potentially needing different metadata per axis, such as units, which is not supported by any xarray unit plugins.

A novel proposal to support such a dataset where direction components are stored together could be:

overload meaning of arrays in metadata

direction = xr.DataArray(
    data,
    dims=("source", "direction"),
    attrs={
        "frame": {
            "name": "icrs",
            "representation_type": "unitspherical",
            "data": {
                "representation_type": "unitspherical"
            }
        },
        "units": ["deg", "arcmin"],
    }
)

In this case the usage of an array in metadata it attaches to the fastest changing dimension (in this case: direction) of the dataarray. While compact, its potentially ambiguous as to which dimension/s is being assigned to.

add special dictionary keyword in metadata for assigning metadata to a dimension, i.e. "dims"

direction = xr.DataArray(
    data,
    dims=("source", "direction"),
    attrs={
        "frame": {
            "name": "icrs",
            "representation_type": "unitspherical",
            "data": {
                "representation_type": "unitspherical"
            }
        },
        "units": {
            "dims": {"direction": ["deg", "arcmin"]},
        }
    }
)

Here a special {"dims": ...} value means attach metadata along specified dimension. This is less ambiguous, but is unable to support assigning metadata along multiple dimensions, i.e a matrix of metadata to a datacube, due to most formats requiring strings keys for dicts. The utility in supporting such as scheme maybe too complex for most comprehensive data storage. Worst case, a string based tuple encoding could be proposed with backwards compatibility with this proposed metadata expression.