A concept of "Global Coordinates"

[Cadair]

The rework of extra coords in #271 excludes one use case for the extra_coords dict in 1.0, which is the concept of structured metadata describing the coordinates of the whole cube. i.e. "this (x,y,t) cube is at wavelength y nm".

We should consider adding some kind of functionality to NDCube 2.0 to represent these type of coordinates.

(N.B. this is something that could potentially be upstreamed into the APE 14 WCS interface at some point)

[Cadair]

A conversation at the PyHC meeting means we should consider this as a way to represent spacecraft location and maybe frame info.

[DanRyanIrish]

Would this be attached to the WCS?

[kakirastern]

Will start working on this issue shortly...

[DanRyanIrish]

Thanks @kakirastern!

[kakirastern]

Yeah, this would be a really great feature to have for Astropy conforming to the APE 14 WCS

[kakirastern]

Thanks @DanRyanIrish for the assignment. I will take it up later today HKT during the weekly community meeting.

[DanRyanIrish]

In the case of slicing out axes, the coord value at which the slice was made will be stored in this sliced_low_level_wcs property from astropy 4.2: https://github.com/astropy/astropy/pull/10195/files#diff-3976bdca12d482d3c3b404875b2db43f9cb04a37f674e17089d3520cced2a72dR157

Something similar must be implemented in the new ExtraCoords class.

So point of GlobalCoords is to expose this information as high level objects, e.g. SkyCoord

Need an API for users to add global coords explicitly.

Draft API

• Make a GlobalCoords class and attach to NDCube.
• When asked, GlobalCoords compiles the dropped wcs coords, dropped extra coords, and user added coords into single object, e.g. dictionary/set, etc
• Index GlobalCoords like a dictionary, index with a name
• A global coord is made of three pieces of info: name, physical type, value (high level object)
• When compiling list of global coords, coord name defaults to wcs.world_axis_name/CNAME (in FITS WCS). If not present, make name physical type. If physical type not unique, append physical type with unique suffix.

Methods/Properties

1. .add
2. .remove
3. .names and/or .keys()
4. .values (like dict) that gives a list of the higher level objects in the same order as .names/.keys()
5. .physical_types that gives a list of the higher level objects in the same order as .names/.keys()
6. __getitem__ (This should only take a single string, i.e. a coord name)

[Cadair]

from collections.abc import Mapping


class GlobalCoords(Mapping):
    """
    A structured representation of coordinate information applicable to a whole NDCube.
    """
    def __init__(self, ndcube):
        pass

    def add(self, name, physical_type):
        """
        Add a new coordinate to the collection.
        """

    def remove(self, name):
        """
        Remove a coordinate from the collection
        """

    @property
    def names(self):
        """
        A tuple of all the names.
        """

    @property
    def physical_types(self):
        """
        A tuple of all physical types, one per coordinate.
        """

    def keys(self):
        """
        A set-like of all names in this collection.
        """

    def values(self):
        """
        A set-like of all values in this collection
        """

    def __getitem__(self, item):
        """
        Index the collection by a name.
        """

    def __iter__(self):
        pass

Should implement the whole Mapping API. What this means is that we only need to implement the methods listed in the "Abstract Methods" column (__getitem__, __iter__, __len__) and the ones listed in "Mixin methods" use those implementations to provide things like values().

[kakirastern]

Will start working on this today HKT

[kakirastern]

How about adding an update() besides add() and remove()for GlobalCoords? Or am I complicating things?

[Cadair]

update is a dict-like API, the issue is that as well as the key (name) we also have physical type which needs to be present, hence sticking with Mapping and custom add and remove methods, rather than MutableMapping.

[kakirastern]

I see. Thanks for the clarification ❤️!