Add function and map method for drawing extent of another wcs

[wtbarnes]

Fixes #7615

TODOs:

• Figure tests
• Docs for map method
• Better docs for visualization function
• Changelog

[wtbarnes]

Docs build and figure test devdeps fails are unrelated.

[nabobalis]

What is this sample data file?!

[wtbarnes]

https://docs.sunpy.org/en/stable/generated/gallery/map_transformations/reprojection_aia_euvi_mosaic.html#sphx-glr-generated-gallery-map-transformations-reprojection-aia-euvi-mosaic-py

[ayshih]

• I think the map method should be locked to plotting that map's own extent on the specified axes. I would not accept a potentially unrelated WCS as an argument.
• Instead of using the resolution approach, I think it would be better to literally use the pixel corners. That way, the segmentation of the extent box will not be mismatched from pixelization. (There can be a different parameter for adding sampling points along a pixel edge, but the default would be just the corners.)

[wtbarnes]

• I think the map method should be locked to plotting that map's own extent on the specified axes. I would not accept a potentially unrelated WCS as an argument.

Agreed. This is also more consistent with the way the other draw methods work, i.e. they "draw themselves". I don't know why I did it backwards. Are you opposed to keeping the function in sunpy.visualizations.drawing which takes in any WCS and tries to its extent on an axis?

• Instead of using the resolution approach, I think it would be better to literally use the pixel corners. That way, the segmentation of the extent box will not be mismatched from pixelization. (There can be a different parameter for adding sampling points along a pixel edge, but the default would be just the corners.)

I see what you mean re: pixelization. However, aren't the four corners alone insufficient to adequately define the map extent? For example, in your original issue, the red and green boxes you show have the same corner coordinates even though the FOVs are different. Am I missing something?

[ayshih]

• I think the map method should be locked to plotting that map's own extent on the specified axes. I would not accept a potentially unrelated WCS as an argument.

Agreed. This is also more consistent with the way the other draw methods work, i.e. they "draw themselves". I don't know why I did it backwards. Are you opposed to keeping the function in sunpy.visualizations.drawing which takes in any WCS and tries to its extent on an axis?

Nope, not opposed as it is consistent with the limb stuff.

• Instead of using the resolution approach, I think it would be better to literally use the pixel corners. That way, the segmentation of the extent box will not be mismatched from pixelization. (There can be a different parameter for adding sampling points along a pixel edge, but the default would be just the corners.)

I see what you mean re: pixelization. However, aren't the four corners alone insufficient to adequately define the map extent? For example, in your original issue, the red and green boxes you show have the same corner coordinates even though the FOVs are different. Am I missing something?

To clarify, I meant the outer corners of every edge pixel, so 2N+2M(+1) points for an NxM array. For that example image, I think I may have called sunpy.map.maputils.map_edges() (although be careful about the being off by half a pixel).

[wtbarnes]

I've removed the resolution argument and constructed the edges such that the spacing along any given edge has a resolution of 1 pixel, with the left endpoint included and the right endpoint excluded as the latter is the starting point of the subsequent edge.

The reason I didn't use sunpy.map.map_edges was to avoid tying sunpy.visualizations.drawing.extent to GenericMap and instead just accept a WCS. I suppose we could refactor map_edges to use some more general function for finding the extent of the WCS and then use that in both functions.

[Cadair]

Without having looked at this in detail, this feels like something which could be useful to upstream to astropy?

[wtbarnes]

Probably. I'm kind of surprised this doesn't already exist actually. Hopefully I'm not duplicating functionality here.