Skip to content

WCSAxes seem to be dependent on the unit handling of the WCS object #8819

Closed

Description

@amunozj

Hi All,

Thank you very much for all the work that you do and thank you in advance for any help. I'm suffering from a very odd issue and I was hoping someone may help. I'm using plot_coord to overplot a field of view on a solar image, but for one of my instruments it complains that I'm using the wrong units, which is not the case. Here is how I'm making the plot:

bottom_left_coord = SkyCoord(0*u.arcsec, 0*u.arcsec, frame=MWFmap.coordinate_frame)
top_right_coord = SkyCoord(300*u.arcsec, 300*u.arcsec, frame=MWFmap.coordinate_frame)
xZOOM = [bottom_left_coord.Tx, bottom_left_coord.Tx, top_right_coord.Tx, top_right_coord.Tx, bottom_left_coord.Tx]
yZOOM = [bottom_left_coord.Ty, top_right_coord.Ty, top_right_coord.Ty, bottom_left_coord.Ty, bottom_left_coord.Ty]
coord = SkyCoord(xZOOM, yZOOM, frame=MWFmap.coordinate_frame, unit = u.arcsec)`
ax1.plot_coord(coord,"w",linewidth = 0.5)

when I do the plot I get the error:

      529         if np.any(angles.value < lower) or np.any(angles.value > upper):
      530             raise ValueError("Latitude angle(s) must be within -90 deg <= angle <= 90 deg, "
--> 531                              "got {0}".format(angles.to(u.degree)))
    532
    533     def __setitem__(self, item, value):
ValueError: Latitude angle(s) must be within -90 deg <= angle <= 90 deg, got [  0. 300. 300.   0.   0.] deg

but printing coord, it is clearly not in degrees, but in arcseconds:

<SkyCoord (Helioprojective: obstime=1999-12-11T12:00:00.000, rsun=695700000.0 m, observer=<HeliographicStonyhurst Coordinate (obstime=1999-12-11T12:00:00.000): (lon, lat, radius) in (deg, deg, AU)
    (0., -0.40808519, 0.98470895)>): (Tx, Ty) in arcsec
    [(  0.,   0.), (  0., 300.), (300., 300.), (300.,   0.), (  0.,   0.)]>

Any idea what I may be doing wrong?

EDIT: Code formatting.

Activity

  1. pllim commented on Jun 11, 2019

    @pllim
    Member

    Helioprojective? That smells like SunPy. @Cadair ?

  2. amunozj commented on Jun 11, 2019

    @amunozj
    Author

    Thank you Pllim! I'm using SunPy indeed. Though the strange thing is that I'm doing exactly the same thing for 4 other instruments without issue! In every other case plot_coord understands that Arcseconds are arcseconds :(

  3. amunozj commented on Jun 11, 2019

    @amunozj
    Author

    Ok Guys. After much hairpulling I think I found the problem. The header of this instrument's fits file was missing two entries:

    header['CTYPE1'] = 'HPLN-TAN'
    header['CTYPE2'] = 'HPLT-TAN'

  4. Cadair commented on Jun 11, 2019

    @Cadair
    Member

    This still feels like it's a weird bug somewhere, even given the lack of projection (and the resulting madness that induces in WCS) it should still work.

    FTR by the time the header made it to WCSAxes in this example it had the CTYPE1 = 'HPLN-' CTYPE2 = HPLT- headers (as SunPy will have added those headers).

  5. amunozj commented on Jun 11, 2019

    @amunozj
    Author

    The fits file already came with those header cards ('HPLN-' and 'HPLT-'), but if I leave them without the TAN part, it just doesn't work. That's why I overwrote them with

    header['CTYPE1'] = 'HPLN-TAN'
    header['CTYPE2'] = 'HPLT-TAN'
    

    then it does.

  6. Cadair commented on Jun 12, 2019

    @Cadair
    Member

    @amunozj yeah, that makes sense, not having the projection affects the way WCS works. However, WCSAxes shouldn't care, which is why I think this is still a bug in WCSAxes because it should be invariant to the unit handling of the WCS object.

  7. pllim commented on Jun 12, 2019

    @pllim
    Member

    @Cadair , okay, I'll reopen this.

  8. reopened this on Jun 12, 2019
  9. pllim commented on Jun 12, 2019

    @pllim
    Member

    Please update the title with something more descriptive that explains the bug. Thanks!

  10. amunozj commented on Jun 12, 2019

    @amunozj
    Author

    Any suggestions @pllim, @Cadair ? Would this work?

    "WCSAxes seem to be dependent on the unit handling of the WCS object"

  11. changed the title [-]plot_coord not using the right units[/-] [+]WCSAxes seem to be dependent on the unit handling of the WCS object[/+] on Jun 13, 2019
  12. pllim commented on Jun 13, 2019

    @pllim
    Member

    Well, you understand the bug more than me. 😄 Thanks!

  13. Cadair commented on Jun 13, 2019

    @Cadair
    Member

    For future readers of this:

    WCS changes the units of the header when it interacts with wcslib, which happens when you have a projection, but does not when it doesn't have a projection. This bug therefore is probably that the units of the WCS are not correctly checked and are probably assumed to be deg.

  14. amunozj commented on Jun 13, 2019

    @amunozj
    Author

    Ah man! this makes so much sense! I was pulling my hair. Why on earth was the thing using degrees, when I was so clearly telling it it was arcseconds. Thank you!

  15. astrofrog commented on Jun 18, 2019

    @astrofrog
    Member

    Related issue: #8664

  16. astrofrog commented on Jun 18, 2019

    @astrofrog
    Member

    So just to check, is there a bug that needs fixing here, or just documentation and #8664?

  17. Cadair commented on Jun 18, 2019

    @Cadair
    Member

    Well #8664 would fix the bug.

  18. astrofrog commented on Mar 3, 2026

    @astrofrog
    Member

    I'm going to close this since things do work fine if the CTYPE is fixed to be valid, and in addition #8664 has been closed so if there was a desire to use a WCS with the original units this is now possible. However feel free to re-open or open a new issue if you feel there is still work to be done here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions