Description

This PR provides an optional way to overcome a bug in SlicedLowLevelWCS, whereby slices that would reduce a data array associated with the WCS to length-0 axes is not caught. WCS cannot describe scalars or length-0 array axes. However, the current sanitization of inputs to SlicedLowLevelWCS currently allows such scenarios. This PR introduces a new optional kwarg to SlicedLowLevelWCS (presliced_shape) and another to sanitize_slices (shape), which give the shape of the data array described by the WCS. If either are set, an additional set of sanitization checks is performed to catch the cases below.

(This bug was identified by @hayesla when using ndcube.)

Case 1: Slices with stop >= start

Slice items like slice(3, 2), slice(-2, -4), and slice(1, 1) can be applied to a data array and will return array([]). However, this is an array that cannot be validly described by a WCS. This PR solves this problem by erroring if stop - start <= 0.

Case 2: Slices with mixed positive and negative indices

If the slice item mixes and matches positive and negative indices, e.g. slice(3, -2) or slice(-4, 5), the above check cannot be done without knowing the length of the relevant axis. In this case, the shape info is combined with the info in the slice object to perform the same check as in Case 1.

Case 3: Indices or slices whose range are entirely outside the data array

If we have an array of length 3, and we apply an index or slice whose range is beyond this, e.g. 6, -6, slice(5, 8) or slice(-20, -15), this will again lead to an array of array([]) being returned which cannot be described by a WCS. A separate check is performed to catch these cases. But, like Case 2, this requires the data shape information provided by the new kwargs.

Discussion on Making These Checks Optional

The reason for making the checks of Cases 2 and 3 optional is that a WCS can be a standalone object without associated with a data array. If such a WCS would like to be sliced for some reason, shape information may not be available.

The check in Case 1 can actually be performed without the shape information and so could be performed every time. I think this is a valid choice, but the reasons I didn't go that way here are:

1. Doing them every time would technically be a breaking change. Only performing it when shape is set, is not.
2. The slice items in Case 1 are valid slice items for arrays, even if they return non-WCS-describable arrays. Some users may not want this level of restriction.
3. Always checking Case 1 but not Case 2 would probably feel like a bug to any users who encounter it, since if you want this check performed, you probably want it regardless of the combination of positive and negative slice indices.
4. Doing all the checks only if shape is set, simplifies the code somewhat. (A less crucial consideration)

Fixes #

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.