Closed derekocallaghan closed 5 months ago
Hi @AdamGoldstein-USRA,
Just wanted to check whether the suggested workaround that excludes the call to SkyCoord()
is okay with you? If so, I'll create a PR.
Thanks
Met with Adam. Agree this needs further research to make sure the workaround won't break any other functionality in GDT.
@derekocallaghan Please checkout PR #38 and see if it works for you.
Your proposed fix would work only for EquatorialPlot
, and the problem would still be present for GalacticPlot
and SpacecraftPlot
. The intent is to allow plotting in other frames (currently Galactic and spacecraft), and after you identified the root cause of the issue, I think the fix in PR #38 addresses that for any frame.
Thanks @AdamGoldstein-USRA, that was just a quick workaround to get the correct plot here. I've tried the modifed lib.py
and sky.py
and the plot is rendered as expected with the following, so I'll close this issue:
eqplot = EquatorialPlot()
eqplot.add_localization(gbm_healpix, gradient=True)
Fixed by #38
I've noticed this issue when visualizing localizations with
EquatorialPlot
, where the probability heatmap isn't rendered correctly when the centroid RA is close to 0 or 360 degrees. This can be illustrated using a local copy of glg_healpix_all_bn220130968_v01.fit:The following plot is generated:
According to the GBM catalog, the correct skymap should look like:
The issue appears to be caused by the transformation of specified lon/lat arrays to
SkyCoord
inSkyMap.plot_heatmap()
:https://github.com/USRA-STI/gdt-core/blob/91020a3f569427390662c9bae26b6d8e8f99f764/src/gdt/core/plot/sky.py#L456-L467
In the case of localizations, the
lon_array
specified toplot_heatmap()
will contain values in $[0, 360]$. However, the call toSkyCoord()
will convert the last 360 value to 0. E.g.:This appears to cause the issue when subsequently rendering the heatmap. Note that it's only visible when centroids straddle RA=0/360 degrees, other localisation centroids are rendered correctly. I've also noticed a similar issue with the contour lineswhere although it doesn't impact the visualisation as much as the heatmaps, the lines are broken, and I assume it's also due to the use of
SkyCoord
.I have a local workaround that overrides
plot_heatmap()
to exclude the call toSkyCoord()
, where the specifiedlon_array
andlat_array
are passed directly toSkyHeatmap
, similar to the previous GBM Data Tools implementation:This results in a correct rendering of the heatmap, similar to that contained in the catalo:
I can create a PR with this fix but I wanted to check first whether the
SkyCoord
usage was required for other reasons.