# SunpyMetadataWarnings when using Hinode XRT data **URL:** \ **Category:** SunPy\ **Tags:** sunpy, question\ **Created:** [July 8, 2022, 6:13pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393 "2022-07-08T18:13:26Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jdslavin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/jdslavin/32/232_2.png) [@jdslavin](https://community.openastronomy.org/u/jdslavin)\ **Post date:** [July 8, 2022, 6:13pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/1 "2022-07-08T18:13:26Z")
Hi, I’ve now upgraded to Sunpy 4.0.1. Viewing Hinode XRT data now works, but I’m getting annoying warnings regarding missing metadata: WARNING: SunpyMetadataWarning: Missing metadata for observer: assuming Earth-based observer. For frame ‘heliographic\_stonyhurst’ the following metadata is missing: hgln\_obs,hglt\_obs For frame ‘heliographic\_carrington’ the following metadata is missing: crln\_obs,crlt\_obs The plotting still works so apparently this metadata is not needed. I am the one who runs and monitors the Hinode XRT Level 1 archive generating pipeline and I can tell you that the metadata that is in those files is all there will be. So I don’t see any point in Sunpy generating such warnings. There was discussion among us some time ago about which metadata to include and in the end we decided to include: DSUN\_OBS, RSUN\_REF, RSUN\_OBS, and SOLAR\_B0 So, any chance that those warnings will go away when plotting XRT data in future versions of Sunpy? Thanks, Jon ---
**Author:** ![wafels](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/wafels/32/234_2.png) [@wafels](https://community.openastronomy.org/u/wafels)\ **Post date:** [July 8, 2022, 6:43pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/2 "2022-07-08T18:43:17Z")
Jon, Is there a document somewhere that defines the XRT Level 1 FITS header keywords? Thanks, Jack ---
**Author:** ![nabobalis](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/nabobalis/32/14_2.png) [@nabobalis](https://community.openastronomy.org/u/nabobalis)\ **Post date:** [July 8, 2022, 6:47pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/3 "2022-07-08T18:47:00Z")
Hi Jon, Without looking at a XRT Level 1 file, it is difficult for me to say. If you think this is an issue with how sunpy is getting the metadata from the level 1 FITS file, I would ask you open an issue on the sunpy repository: [Issues · sunpy/sunpy · GitHub](https://github.com/sunpy/sunpy/issues) so we can work out the problem and ideally come to a resolution. In our Map sources we try to ensure that an instrument’s file raises the least amount of warnings so it is possible, we have missed something in the XRTMap code and that would need updating. Cheers, Nabil ---
**Author:** ![jdslavin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/jdslavin/32/232_2.png) [@jdslavin](https://community.openastronomy.org/u/jdslavin)\ **Post date:** [July 8, 2022, 7:30pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/4 "2022-07-08T19:30:39Z")
Thanks Nabil. The Sunpy site gave me the impression that the preference was to use the openastronomy page to raise issues. I’m happy to raise an issue on the github page. I don’t think it’s a problem with sunpy getting the metadata. The metadata isn’t there. Jon ---
**Author:** ![jdslavin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/jdslavin/32/232_2.png) [@jdslavin](https://community.openastronomy.org/u/jdslavin)\ **Post date:** [July 8, 2022, 7:33pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/5 "2022-07-08T19:33:13Z")
Hi Jack, I don’t think that there is one for the L1 header keywords. The SolarSoft XRT Analysis Guide has a list of the keywords for the L0 files. The L1 files have additional keywords added. Regards, Jon ---
**Author:** ![ayshih](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/ayshih/32/84_2.png) [@ayshih](https://community.openastronomy.org/u/ayshih)\ **Post date:** [July 8, 2022, 7:38pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/6 "2022-07-08T19:38:54Z")
From what you have written, I gather that XRT metadata files do not include the heliographic longitude of the spacecraft (either in Stonyhurst or in Carrington), despite having the heliographic latitude (`SOLAR_B0`). The problem with not having that information is that it is needed for any coordinate-aware plotting, such as overlaying a heliographic grid, or coordinate-aware transformation of the data, such as reprojecting the map to another observer, Thus, when SunPy can’t find the heliographic longitude in a file, it assumes that observer is at Earth center (i.e., the Stonyhurst heliographic longitude is zero). > So I don’t see any point in Sunpy generating such warnings. For Hinode, the assumption that it is at Earth center is probably sufficiently accurate for nearly all use cases. However, since you choose not to include `HGLN_OBS = 0` in the metadata (or something equivalent), and we are currently making a guess that it is appropriate to make that assumption, we must emit the warning. Along the lines of what @nabobalis said, one solution would be to modify SunPy’s `XRTMap` so that it explicitly adds `HGLN_OBS = 0` to the metadata before parsing the metadata. > The plotting still works so apparently this metadata is not needed. This conclusion is flawed because, as stated in the warning, the assumption is made that the observer is at Earth center. So, plotting and everything else will of course work, but that’s because we have made up metadata to fill in the missing metadata. ---
**Author:** ![jdslavin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/jdslavin/32/232_2.png) [@jdslavin](https://community.openastronomy.org/u/jdslavin)\ **Post date:** [July 8, 2022, 7:56pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/7 "2022-07-08T19:56:23Z")
Well the plotting works because it makes a reasonable assumption in lieu of the needed metadata. Kathy Reeves, Mark Weber and I had a discussion about what metadata to include sometime back and concluded that for Hinode XRT assuming an Earth centered location is good enough. So yes, modifying XRTMap to explicitly add HGLN\_OBS = 0 to the metadata would be a good solution. Jon ---
**Author:** ![nabobalis](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/nabobalis/32/14_2.png) [@nabobalis](https://community.openastronomy.org/u/nabobalis)\ **Post date:** [July 8, 2022, 8:50pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/8 "2022-07-08T20:50:51Z")
A WIP PR is here [add a fixed lon,lat values on advice from xrt instr team by nabobalis · Pull Request #6328 · sunpy/sunpy · GitHub](https://github.com/sunpy/sunpy/pull/6328) if you would like to have a review of the changes. ---
**Author:** ![jdslavin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/jdslavin/32/232_2.png) [@jdslavin](https://community.openastronomy.org/u/jdslavin)\ **Post date:** [September 19, 2023, 8:39pm UTC](https://community.openastronomy.org/t/sunpymetadatawarnings-when-using-hinode-xrt-data/393/9 "2023-09-19T20:39:49Z")
So the metatdata warnings are now suppressed if you just make an XRT map and plot it. However, in XRTpy we sometimes create maps based on XRT data that are not XRT images. For example the routine currently named xrt\_teem (likely soon to be renamed) generates temperature maps based on the filter ratio method. When plotting those, you still get those metadata warnings. Does anyone have suggestions on how to suppress the warnings in such a case? Currently we add the metadata for rsun\_ref, rsun\_obs, dsun\_obs and solar\_b0 to the maps. Maybe adding appropriate values of hgln\_obs and hglt\_obs would work?