Have sky-on-sky contains not require a wcs

[eteq]

Currently, if I do *SkyRegion.contains(skycoord), it fails, demanding a wcs. This seems strange to me. Why is a wcs needed to know if a point in sky coordinates is inside a shape in sky coordinates? Is this just a convenience to share implementations? And if so, perhaps there can be a "default" wcs that's created if non is given in the sky-on-sky case?

[larrybradley]

The *SkyRegion classes are essentially convenience classes for the *PixelRegion classes. All of the real work is done with *PixelRegion classes, thus behind the scenes the *SkyRegion objects need to be converted to *PixelRegion objects. That requires a wcs object. The way *SkyRegion objects are converted to *PixelRegion objects is to do "world_to_pixel" on the central position and convert the shape parameters (e.g. radius) from angular to pixel units using the pixel scale. The *SkyRegion object is (and should be) independent of any particular WCS, thus a wcs object needs to be input to do the conversion.

All of the internal machinery uses the pixel-defined shapes. Because of distortions and projection effects, the shapes of course cannot be generally preserved in both sky and pixel coordinates, e.g. a circle defined in sky coordinates is not likely to be a circle in pixel coordinates.

[astrofrog]

Note that we did used to also have true Sky regions (I think these were removed for now?) that had edges which were great circles. But yes, the current Sky regions are defined such that the edges are straight lines in the plane of an image.

[cdeil]

I'm closing this issue as a duplicate of #276 -- let's discuss there and add this functionality now.