SpectralRegion with multiple sub-regions enhancement

[brechmos-stsci]

@drdavella and I were just talking about this as it came up yesterday.

There could be a use-case to have multiple sub-regions in a SpectralRegion. This could be for calculating an RMS over the left and right ends of a spectrum (for example) so one would need to define a SpectralRegion with one sub-region on the left and one sub-region on the right.

The main variable would be a list of 2-tuples (rather than the current single 2-tuple). Each 2-tuple would be a (lower, upper) bound which could also have units on both (as currently is implemented).

Some possible useful usage:

• SpectralRegion([(1, 2), (8, 20), (40, 50)]) (__init__ could take a list of 2-tuples, units allowed too)
• spectral_region_out = spectral_region1 + spectral_region2 (effectively a list extend)
• spectral_region1[1] (__getitem__)
• del spectral_region[1] (__delitem__)

Considerations

• What happens with overlapping sub-regions?
  • One could say that sub-regions are allowed to overlap (so no real checking needs to happen) but then the spectral_region.extract(spectrum) would have to be thought through. I think it would make the most sense to not duplicate points in the extracted spectrum (i.e., sub-regions don't duplicate on extraction). One could also have a flag in there.
  • Actually, I think more thought needs to happen with the extract spectrum of a multiple sub-region SpectralRegion. Does it make sense to extract multiple sub-regions into one Spectrum1D? The dispersion axis could be very disjoint, which might be fine, just might have to be careful with the understanding/interpretation of it.
• Currently spectral_region.lower returns a single value, with the new implementation it should probably return a list of the lower bounds (same for upper)
• It might be useful to implement __iter__ and __next__ so one can iterate over the spectral_region (to get each sub-region). Not 100% sure of the use-case on this, but it could be interesting/useful.

[This was in discussion with @drdavella]

@eteq @stscicrawford @nmearl @drdavella

[brechmos-stsci]

@robelgeda You had talked about this yesterday as being something useful. Add any comments, here, if there are more ideas that might be useful for the implementation.

(also cc @hcferguson )

[hcferguson]

Might want to think carefully about some use cases, and what that implies for the design...some quick examples:

• I've got two regions for continuum and one for line.
• I've got a bunch of disjoint regions for continuum (avoiding lines)
• I'd like to define my regions in wavelength, frequency, velocity instead of pixels
• I'd like to use some code to define my regions? E.g. sigma clipping?
  • I'd like to give the task a mask rather than a region specification

I think in the implementation of acting on regions, one would generally want to just make a mask (not count overlapping pixels twice), but there is certainly a use case of having one set of regions for continuum and another for lines. But in that case, would one just pass two SpectralRegions to the task that needs them? Each of those regions could have sub-regions.