-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is axes_order supposed to allow reordering inside a frame or a Composite frame #269
Comments
The
It may become messy to allow this changes on both objects because then we have to think which one takes precedence. I think it's cleaner to have the |
I see the point, but then this fixture in #217 sets the axes ordering over two frames, where it puts the spectral frame between the two spatial axes (something which is at least possible in real data), and it seems to work fine ( |
The fixture looks fine to me. I think that's what I would expect. The ordering is "made to work" in the transform.
|
Ah! Ok, I see, so the idea is for the |
I don't think this is resolved. Below looks like an example similar to @nden's post above but note what happens when I call the
The
which is as it should be. But what if I define my
I'm not sure what the desired behaviour here is. Personally, I'd like to define both frames with And, going back to the original post,
is counterintuitive at best. But if I do this
now it pays attention to |
This does seem rather unexpected at best. How is the inverse used in that case
While agreeing with your sentiment, @chris-simpson, if I understand you correctly there are certainly real use cases for non-adjacent spatial axes, notably visualizing slices through an IFU data cube (I don't think it's the end of the World if that case doesn't work for now, but it should not be precluded by design). |
As a pretty fundamental axiom, I don't think the order of the outputs should be affected by the value of |
Yes, constraining the order in the outputs doesn't seem unreasonable (given that you can't enforce a 1-to-1 mapping of pixel to world co-ordinates in general anyway). |
I looked at this issue a bit in an attempt to define the behavior and tie loose ends. First how we got here. Gwcs started as a numerical only library but there was always a desire to represent the results as astropy objects and to use units with transforms. This resulted in the additional parameter In the case of Celestial frame a There's another twist to this, as I discovered while looking at this issue. The methods I collected use cases from issues and tests in the notebook below and the results show how I think it should work. https://github.com/nden/documentation/blob/master/Reorder_axes.ipynb |
This issue should be addressed by the changes in #457 if people want to have a look at that. |
I understand it can reorder things in
CompositeFrame
i.e. to have an array which is (lat, spectral, lon) or similar, but what about in a WCS with just aCelestialFrame
which is orderedlat, lon
. Currently this dosen't seem to work:Given the flipped output order I would expect this to return
is this a bug or expected behaviour?
The text was updated successfully, but these errors were encountered: