Fix a whole bunch of bugs to do with -TAB in wcsapi/fitswcs

[Cadair]

This is a grab bag of fixes of issues that cropped up using @tiagopereira's SST data in #12095

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[Cadair]

I am not sure if this is really needed. Maybe @mcara knows?

[mcara]

Not sure I understand the issue (i.e., what/when units do not get converted). As to when set() needs to be called, basically never: if you already have a valid WCS object and set parameters in a "normal" way like using assignments like:

w.wcs.crval = [20, 30]

instead of

w.wcs.ctype[0] = 20
w.wcs.ctype[1] = 30
w.wcs.set()

then WCS code will automatically call set() as needed. When you do weirder things like second approach above, the yes, you need to call WCS.Wcsprm.set(). A full list of when set should be called can be found here: https://www.atnf.csiro.au/people/mcalabre/WCS/wcslib/structwcsprm.html#a35bff8de85e5a8892e1b68db69ca7a68

This is a "mixin" class and I worry about your call to set interacting with

astropy/astropy/wcs/wcs.py

Lines 548 to 549 in b6352e1

	if _do_set:
	self.wcs.set()

[Cadair]

The issue I have seen before which I am kind of blindly solving here is that until you trigger a call to set() (i.e. implicitly in pixel to world or whatever) w.wcs.cunit can be in units of not-degrees however after set() has been called they will be in degrees. Before I use the unit here I just wanted to make sure they had been changed if they were going to be changed.

I guess that by the time you get to here in this mixin you have already called pixel_to_world or whatever so I guess that this is not needed.

P.S. Does calling set() twice cause any issues?

[mcara]

calling set after it was already called will cause performance issues. It is an expensive operation. You may not feel it if it is done once during the initialization but if this is done repeatedly it will be felt. So it depends on the usage.

My main concern though was that it may call set even when _do_set is False. I do not recall right now why _do_set was introduced but there was a purpuse. Let me investigate...

[mcara]

Another reason to avoid calling set twice is that if there are warning messages, they may also appear twice (but I did not check whether this is indeed the case).

[Cadair]

I have removed it. I don't think that it's really needed, but I could be wrong

[Cadair]

I don't know if there is an easy way to test this without using a FITS file with a bunch-o-TAB in it?

[astrofrog]

This seems reasonable to me, though of course if there is some way to make a FITS file that reproduces the issue that would be great (but I'm not sure if we can generate such a file from astropy?)

[mcara]

Could you use https://github.com/astropy/astropy/blob/main/astropy/wcs/tests/data/tab-time-last-axis.fits ? Only 14KB. If you need UTC instead of TIME, you can edit the header.

[Cadair]

Could you use https://github.com/astropy/astropy/blob/main/astropy/wcs/tests/data/tab-time-last-axis.fits ? Only 14KB. If you need UTC instead of TIME, you can edit the header.

Oh, well this is definitely a start. I shall have a go with that.

To hit the bug for the celestial units I would need a tab file for spatial axes not in degrees. I could investigate making one, but that sounds like a lot of work.

[mcara]

It's not that hard if you use this: https://gwcs.readthedocs.io/en/latest/api/gwcs.wcs.WCS.html#gwcs.wcs.WCS.to_fits_tab Choose largest sampling possible - you do not need too many data points for a test. You could start with https://github.com/spacetelescope/gwcs/blob/713a0bc710a80ff44ac711ceec1f02ceb51d591c/gwcs/tests/conftest.py#L247-L282 and just replace spectral frame with a temporal frame.

[pllim]

Might need a rebase to pick up the new wcslib that Mihai just added to this repo?

[github-actions]

Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then.

In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock.

If you believe I commented on this pull request incorrectly, please report this here.

[github-actions]

I'm going to close this pull request as per my previous message. If you think what is being added/fixed here is still important, please remember to open an issue to keep track of it. Thanks!

If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here.

[mcara]

LGTM, except maybe test function name could be (not sure) improved (but this is nitpicking).

[mcara]

Is all_fits_tab an appropriate name? Is this what is being tested? Or is it that time has UTC and -TAB in ctype. What is more relevant for this test?

[Cadair]

I still need to polish this test. I ran out of time the other day.

[pllim]

@Cadair , are you going to be done polishing by feature freeze?

[Cadair]

@mcara This is now ready to go.

[pllim]

@mcara , does your previous approval still stand?

[mcara]

Minor comments - feel free to ignore.

[Cadair]

Suggestions implemented.

I pushed changes here.