WCSAxes seem to be dependent on the unit handling of the WCS object
See original GitHub issueHi 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.
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (10 by maintainers)
Top Results From Across the Web
Develop new APE 14-compliant WCS class for FITS ... - GitHub
Develop new APE 14-compliant WCS class for FITS WCS with units ... WCSAxes seem to be dependent on the unit handling of the...
Read more >WCS — Astropy v5.2
An iterable of strings given the units of the world coordinates for each axis. world_n_dim. The number of axes in the world coordinate...
Read more >WCS — Astropy v1.0.4
WCS objects perform standard WCS transformations, and correct for SIP and distortion paper table-lookup transformations, based on the WCS keywords and ...
Read more >Simulation of the Handling of Real Objects with a Complete ...
(1996) and Levoy and Hanrahan (1996) are other works which do not rely on ... Object rotation about WCS's axes: When the object...
Read more >astropy.wcs.wcs — Astropy v0.3.dev3797 - stsdas
Wcsprm ` object) """ from __future__ import division # confidence high ... alternative='astropy.units')( UnitConverter) else: WCSBase = object Wcsprm ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Any suggestions @pllim, @Cadair ? Would this work?
“WCSAxes seem to be dependent on the unit handling of the WCS object”
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’