Fix a bug when using CoordinateFrame directly

[Cadair]

I don't see any reason why CoordinateFrame should apply axes_order, I believe that's a global thing not per-frame?

[coveralls]

Coverage increased (+0.2%) to 91.259% when pulling 117b769 on Cadair:fix_coord_coordinates into effd000 on spacetelescope:master.

[chris-simpson]

There are inconsistencies in the way all this operates #269

[Cadair]

Looks like you ran into this bug in your comment in #269. I am not really qualified to answer the more fundamental questions in #269 but at least this chips away one small part of it.

[chris-simpson]

I think you and I are pulling in different directions. I think CoordinateFrame should apply axes_order, based on the docstring that defines it as A dimension in the input data that corresponds to this axis`. At present, there is a lack of consistency in the code and I don't know what the behaviour is supposed to be.

As I note in #269, I think the axes_order in a CoordinateFrame should be valid irrespective of whether that frame is part of a CompositeFrame or not (otherwise it shouldn't be an attribute of a single CoordinateFrame but only the CompositeFrame), and the rejigging of axes_order should be done in the creation of the CompositeFrame. This is a consistent, sensible (at least to me), and well-defined behaviour. I think you have a different view. I'm not sure what @nden had in mind. It would be helpful to see some sort of design so, when two things are inconsistent, we can determine which is correct and submit a PR that fixes the wrong one.

[Cadair]

This particular fix got the code to consistency with the other frames (spectral and celestial etc) in the easiest way I could see. I agree it is generally unclear though, and clearing it up is important.

[Cadair]

@chris-simpson I have looked over this again today, and I think that your points in #269 are correct and should be implemented. That being said, I consider this a bugfix to the existing behaviour, one that is breaking my code!

If @nden wants to weigh in on #269 I probably have a small amount of time to look at taking things in a different direction, but either way I would like to see this PR land.

[nden]

I'm trying to understand where this is a problem. Within gwcs there are two calls to coordinate_to_quantity and both pass *coords . Are you calling it outside gwcs?

Also the new test does not actually test this use case.

[nden]

If you can change the test I think it's good to go

[Cadair]

I have added a test exercising this. I also reproduced the scenario in which I was hitting it just to be safe 🤣

[nden]

I think this fixes a real bug regardless of the general discussion in #269.