Add AltAzCoord

[kiranshila]

To follow https://docs.astropy.org/en/stable/api/astropy.coordinates.AltAz.html

I'm currently tackling this, so PR inbound soon. I wanted to open an issue to start having discussions on this.

There are a ton of steps between local coordinates and the others. Astropy has only a few conversions fixed and uses a graph to find the shortest path between different coordinate systems. Should we do this as well? That would require a rewrite of the conversion methods. Additionally, as I'm getting into the weeds now reading how the conversions work, astropy uses calls to erfa for all the fast stuff. Is there a reason we shouldn't use the ERFA.jl wrapper? Or should we try a "pure julia" approach?

[kiranshila]

For reference, for AltAz to Galactic, using the graph from https://docs.astropy.org/en/stable/coordinates/index.html#built-in-frame-classes,

we would have to implement AltAz -> CIRS -> ICRS -> FK5 -> Galactic

[mileslucas]

The graph idea is really novel, I really like the idea of "looking up" the chain of functions that convert between coordinates. The implementation details are a bit more complicated than that, I assume.

Perhaps a good way to segment this work would be to initiate a PR for AltAz that enables conversion to/from ICRS and in a separate PR we can discuss the global conversion strategy in more detail. In particular, I'm also curious about the design decision for astropy to use a reference frame as a parameter for the coords rather than using unique coords classes. This kind of design decision is closely coupled with the conversion implementation.

[giordano]

Regarding the "why not using erfa", if we can do everything in Julia we can have advantages both in terms of speed and generality.

For the conversion graph, some eons ago, @helgee did Convertible.jl which I believe is somewhat related to this

[kiranshila]

For the conversion graph, some eons ago, @helgee did Convertible.jl which I believe is somewhat related to this

This is a pretty cool package! It seems very similar, with much less complexity than what astropy is doing (it took me a few hours to work it all out).

With respects to the work breakdown, I agree. I can get a MWE of AltAz -> ICRS (I think we need CIRS for this, I can't find any examples of AltAz directly to ICRS).

Also, unlike astropy, I think we shouldn't allow construction of an AltAzCoord without an observation time and location. This never made sense to me, as its like underdefined from the perspective of a "Sky Coordinate"

[helgee]

Convertible.jl was quite the hack and I came up with a less dangerous solution in the meantime.

I have implemented a graph of time scales using ItemGraphs.jl for AstroTime.jl. Please have a look here.

Unfortunately, I will not be able to assist much in the coming weeks due to personal reasons.

[helgee]

Also have a look at the still unpublished AstroBase.jl. Some of the conversions have already been ported to Julia and you can lift them from there for the time being.

[kiranshila]

Also have a look at the still unpublished AstroBase.jl. Some of the conversions have already been ported to Julia and you can lift them from there for the time being.

Oh interesting. You seem to have done a lot of the legwork there for the graph of frame conversion. Was the intention to use this library as the base package for Coords?

[giordano]

@kiranshila would you be interested to work on this in the Google Summer of Code? I think you said you're a PhD student, if so you'd be eligible to participate

[kiranshila]

@giordano That sounds interesting for sure! I'd have to clear things with an advisor if I start signing on for "formal deliverables", but I'll be working on this one way or another haha (because I desperately need it)