Should this package continue to exist?

[Cadair]

trafficstars

Provide a general description of the issue or problem.

As time progresses, I am more and more of the opinion that subclassing ndcube classes to add functionality specific to certain world axes is harmful as it makes things harder for users in the long run.

What I'd like to see is a list of the functionality in sunraster which is unique to this package and then a discussion about what the best ways of providing that functionality without subclassing NDCube or NDCubeSequence are. Then hopefully we can learn some stuff and make things more uniform for users.

[Cadair]

@nabobalis @DanRyanIrish Thoughts?

[DanRyanIrish]

@Cadair I agree with you. I think the aim should be to discontinue this package. sunraster does provide a few useful functionalities that IRIS and SPICE users rely on. However, I think these could be transferred to irispy-lmsal, sospice and sunpy core. Therefore, we need a roadmap to do these tasks before sunraster can be discontinued.

sunraster's unique functionalities

SpectrogramCube

instrument_axes

Tracks what axes correspond to slit position, pixel along slit, raster number, etc.

Solution to remove:

• Move instrument_axes information into sliceable NDMeta.
• The instrument_axes property can then simply return self.meta.get("instrument_axes").
• The instrument_axes property can then be deprecated in favour of self.meta.get("instrument_axes"), so that workflows will work with plain NDCube objects with instrument_axes in their meta instead of SpectrogramCube.

Status: Ongoing as part of #273

axis_world_coords Convenience Properties

SpectrogramCube.spectral_axis, SpectrogramCube.time and SpectrogramCube.celestial enable users to retrieve high level coordinate objects of the coordinate grid values.

Solution to remove:

• Implement a more user-friendly coordinates interface on NDCube, e.g. NDCube.coords.
• Deprecate these properties in favour of how to get this coordinate information through this API, e.g. NDCube.coords.celestial.grid.

Status: Requires substantial ndcube development.

Alternative solution to remove:

• Deprecate these properties in favour of self.axis_world_coords().

Status: Not started, but could be done now.

Spectrogram.exposure_time

Returns a quantity for the exposure time of each exposure.

Solution to remove:

• Move exposure_times into sliceable NDMeta.
• The exposure_time property can then simply return self.meta.get("exposure_time").
• The exposure_time property can then be deprecated in favour of self.meta.get("exposure_time"), so that workflows will work with plain NDCube objects with instrument_axes in their meta instead of SpectrogramCube.

Status: Not started, but could be done now.

Spectrogram.apply_exposure_time_correction

Solution to remove:

• Deprecate in favour of direct arithmetic operation, e.g. cube_per_s = cube / exposure_time.

Status: Not started, but could be done now.

SpectrogramSequence/RasterSequence

Equivalent features as SpectrogramCube

SpectrogramSequence has its own SpectrogramSequence.spectral_axis, SpectrogramSequence.time, SpectrogramSequence.exposure_time, SpectrogramSequence.celestial, SpectrogramSequence.apply_exposure_time_correction properties/methods. These stack/concatenate the output of the SpectrogramCube property/method from each constituent cube.

Solution to remove:

• Implement a gwcs of FITSWCS's and represent spectrogram sequences as a single NDCube/SpectrogramCube.

Status: Requires above feature to be developed robustly within sunpy or astropy.

User-friendly aliases

RasterSequence provides more user-friendly aliases for:

• NDCubeSequence.dimensions -> RasterSequence.raster_dimensions
• NDCubeSequence.cube_like_dimensions -> RasterSequence.sns_dimensions
• NDCubeSequence.array_axis_physical_types -> RasterSequence.raster_array_axis_physical_types
• NDCubeSequence.cube_like_array_axis_physical_types -> RasterSequence.sns_array_axis_physical_types
• NDCubeSequence.sequence_axis_coords -> RasterSequence.raster_axis_coords
• NDCubeSequence.common_axis_coords -> RasterSequence.raster_axis_coords
• NDCubeSequence.plot -> RasterSequence.plot_as_raster
• NDCubeSequence.plot_as_cube -> RasterSequence.plot_as_sns

Solution to remove: Deprecate for original NDCubeSequence methods.

Status: Not started, but could be done now.

raster_instrument_axes_types

Same as SpectrogramCube.instrument_axes except with "raster scan" added for the sequence axis.

Solution to remove: Same solution as for instrument_axes.

Status: Not started, but could be done now.

sns_instrument_axes_types

Same as SpectrogramCube.instrument_axes except with "temporal" replacing the common axis.

Solution to remove: No obvious ready-made replacement.

MetaABCs

sunraster defines a hierarchy of three ABCs (MetaABC, RemoteSensorMetaABC, SlitSpectrographMetaABC) that define the property names via which certain types of metadata should be accessed.

Solution to remove: Upstream these to sunpy core, as they were designed to be the beginning of a larger framework for solar (and beyond?) metadata properties.

Status: Not started. Requires agreement from the sunpy core community. This might trigger a wider metadata discussion that could delay the migration.

instr/spice.py

Contains a SPICE FITS reader function and SPICEMeta that depends on ndcube.NDMeta and the MetaABC hierarchy discussed above.

Solution to remove: Migrate to the sospice package.

Status: Ongoing via sospice#56. But blocked until #273 is merged and a new sunraster version is released.

[DanRyanIrish]

Summary of Roadmap to Deprecate Package

Essential

• #273 must be completed and merged, and a new release of sunraster must be issued.
• sospice#54 must be completed.
• Migrate metadata ABCs must be to sunpy core.
• Various deprecations within sunraster to get users to use ndcube-compatible APIs.
• Move raster_instrument_axes_types info to an NDMeta attached to RasterSequence/NDCubeSequence, and deprecate for direct access via .meta.

Essential unless functionality dropped

• gwcs of FITS wcs's. (Required for SpectrogramSequence coords convenience functions).
• Consider how/whether RasterSequence.sns_instrument_axes_types can be supported.

Preferred

• New ndcube coords API.

[DanRyanIrish]

@Cadair @nabobalis Here is my inventory. Let me know your thoughts.