Repository navigation
Add extra Galactic coordinate frames in Astropy? #3344
Description
As discussed in various other issues already (e.g. astropy/coordinates-benchmark#37, #3107), Galactic coordinates are not well-defined and different codes / catalogs use different definitions.
E.g. @adonath and I are currently producing a source catalog for HESS using the current Astropy Galactic frame and noticed that it differs by ~ 2 arcsec from the Galactic frame used in the Fermi catalogs ... see the check here.
- What definition for Galactic coordinates is most commonly used for source catalogs?
- Which definition do NED / Simbad / Vizier use when they use Galactic coordinates?
And here's my feature request for Astropy:
- Can we please add the one or two alternative Galactic frames that are in use in the astronomy community to
astropy.coordinates?
I'm not sure if it would be best to do this with classes / functions that are part of the public API or if we want to keep this as internal classes / functions. But I think it would be useful to have at least to check / reproduce Galactic coordinate results from others.
@astrofrog @eteq @dsberry, all: what do you think?
Activity
astrofrog commentedon Jan 23, 2015
@cdeil - is the 2" offset with the latest master or 0.4?
astrofrog commentedon Jan 23, 2015
Currently, all the different Python codes currently agree to within << 1", and even astrolib agrees within 0.2" with other codes. I think we also agree with ds9 (which uses ast?). I've never seen a 2" offset so I actually think something may be wrong in the way the Galactic coordinates were computed in the Fermi catalogs? Is there a way to ask them what they used?
cdeil commentedon Jan 23, 2015
The 2 arcsec offset is with the latest Astropy master.
I've written an email to the Fermi catalog contact ... at the moment I don't know what they use.
I still don't understand the details of the various Galactic systems, but if I'm not mistaken Astropy and most other codes do something slightly different from Reid & Brunthaler 2004 or what is proposed in Liu et al. 2011.
IMO the main criterion whether it makes sense to add other Galactic frames to Astropy is whether they are used in practice, not if they are different by 2 arcsec or 0.2 arcsec.
Has anyone checked other source catalogs that publish both RaDec and Galactic positions or know what NED / SIMBAD / Vizier use (I presume they have code to compute Galactic coordinates for catalogs that don't include Galactic position columns themselves)?
astrofrog commentedon Jan 23, 2015
If there are two clear competing definitions then I agree we can consider whether to add additional frames, but I'm going to guess that for every catalog you find you will find a slightly different convention used. However, I'm willing to be proved wrong! But if Fermi aare the only ones to use their convention I don't think it justifies the introduction of a new frame. +1 to checking what Vizier do.
astrofrog commentedon Jan 23, 2015
This thread is relevant:
http://mail.scipy.org/pipermail/astropy/2014-November/003510.html
Also:
http://mail.scipy.org/pipermail/astropy/2014-November/003523.html
cdeil commentedon Jan 23, 2015
So at the very least we have to document what is used in Astropy ... I think I mentioned this already somewhere but now there's an open issue so we don't forget. :-)
eteq commentedon Jan 23, 2015
Yeah, it sounds like the one we're using (galactic is defined by poles in FK4 with no E-terms) is the more "official", but it's a bit of a mess in the field so definitely @cdeil is right we should at least document it so that others know without having to dig into the mailing list.
Please let us know what (if anything) you hear from Fermi, ideally within a week so we can add this to the docs in time for 1.0.
cdeil commentedon May 11, 2015
I did hear back from Fermi, but forgot to comment here.
They were using a self-written software to do this coordinate conversion at low precision ... Fermi has a systematic error of ~ 10 arcsec, i.e. for them it didn't matter.
Still, just for consistency, now they plan to switch to use Astropy.
So all that's left to be done here is to add a sentence or two to the Astropy docs mentioning what exactly is implemented. I still don't understand the details and am not really sure what exactly to write so that it's well-defined and clear at least to the coordinate experts.
astrofrog commentedon May 12, 2015
By the way, I think we really should look into the ERFA ICRS <-> Galactic conversion now since in the long term this is going to be the definitive 'exact' conversion to use. If anyone has time to look into it, it would be great to figure out how different that is from our current comparison.
dsberry commentedon May 12, 2015
Presumably the new ERFA Galactic system will need to be seen as an
additional system rather than as a replacement for the existing Galactic
system, since people will have existing data sets calibrated in the old
system. The old system will need to be supported basically for ever in
order to allow legacy data sets to be interpreted correctly.
David
On 12 May 2015 at 02:45, Thomas Robitaille [email protected] wrote:
astrofrog commentedon May 12, 2015
@dsberry - I am going to assume that the new system was fit to minimize deviations from the old system in most cases (at least that's how I would have defined it). I'd be fine with keeping the old system, but I think I'd like the ERFA version to be e.g.
Galacticand the legacy one could be e.g.Galactic1958. We should encourage use of the new system.In fact, the old system was poorly defined enough that no one can trust it to better than around 1" anyway, and there are many different implementations. So it's not like the current version we have in astropy is some kind of high accuracy legacy version in any case...
astrofrog commentedon May 12, 2015
Another possibility is to consider the convention as a parameter to the Galactic frame, so
Galactic()would give the new erfa frame, whileGalactic(convention='1958')would give the original one (well, one interpretation of the original one, which is what we have currently in astropy)astrofrog commentedon May 12, 2015
If the differences between the old and new system is of the order of milliarseconds, this is moot anyway since the old system was never that accurate in absolute terms due to the different interpretations.
dsberry commentedon May 12, 2015
I'm thinking of a case where someone has an image calibrated accurately in ICRS (for example), which is then transform into Galactic coordinates using the old convention. They will need the old convention to be retained separately to the new convention so the image can if necessary be converted back from (inacccurate) old galactic coords to (accurate) ICRS at some point in the future. If they used the new convention, the final ICRS map would not be quite the same as the original.
astrojuanlu commentedon Aug 2, 2019
This conversation is very similar to what we faced when adding new ecliptic frames:
#8394
We ended up adding one different class per type of frame, which was a bit controversial because increased the overall number of frames quite a bit, and possibly introduced a bit of confusion. I like the
Galactic(convention='1958')idea that @astrofrog proposed above, but would be a bit complicated to implement with the current architecture. I have some ideas about this but it will take me some time.adrn commentedon Oct 23, 2019
::insert zombie resurrection gif here::
I'm open to using the ERFA convention, or adding the option to use the ERFA convention, but I don't want to use the ERFA transformation machinery itself to do this transformation. Right now, the transformation is implemented as a set of rotations, which make velocity (proper motion) transformations fast and analytic. If we switch to using the ERFA transformation directly, we would have to turn it into a
FunctionTransformand the velocity transform would then have to be done via numerical derivatives through the function. But, since ERFA provides the ICRS-->Galactic matrix, we could adopt that whenconvention='erfa'. For reference, here's a comparison of positions in astropy's current Galactic frame transformed to ICRS compared to a frame that uses the ERFA definition: https://gist.github.com/0954aec46b2f7f581831b286e550cff9However, because of the nature of the frame transform graph, I don't think it would be easy to add a
convention='...'frame attribute to control this, because one convention maps fk5<-->galactic and the other icrs<-->galactic. I don't think we can easily make a frame attribute "disable" a transformation pathway, so this would probably have to be implemented as a separate frame, but @eteq can correct me if I'm wrong.