add simple projected coordinates

[aplavin]

almost a copy of the implementation in SkyImages.jl

would be useful to upstream to SkyCoords, if this is in scope of the package

[codecov]

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.61%. Comparing base (6c8849b) to head (56fbeae).
⚠️ Report is 53 commits behind head on master.

Files with missing lines	Patch %	Lines
src/projected.jl	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #43      +/-   ##
==========================================
+ Coverage   91.52%   94.61%   +3.08%     
==========================================
  Files           3        4       +1     
  Lines         118      130      +12     
==========================================
+ Hits          108      123      +15     
+ Misses         10        7       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mileslucas]

Thanks for working on this @aplavin! I get a little wary of code like this that starts doing lots of Type gymnastics- it's really easy to miss a corner case when constructors and converts get written this way. I would prefer to see an exhaustive test suite that uses a for loop to check all types work with projected coords (for both projected types).

I'm curious about your thoughts of defining Base.parent and using that in addition to or instead of SkyCoords.origin? Also, should SkyCoords.separation and SkyCoords.position_angle be defined for the projected offsets (i.e., we can measure the direct distance of the offset from the origin, but do we want that?)?

[aplavin]

I'm curious about your thoughts of defining Base.parent and using that in addition to or instead of SkyCoords.origin?

I'm neutral on that. Typically, Base.parent is used for arrays, but can be added here as well.
I definitely prefer to keep origin either way, because it's the more intuitive name in coordinates context.

Maybe, parent_coords_type should be renamed to origin_type, if kept at all? Then, I think, overloading parent would make less sense.

Also, should SkyCoords.separation and SkyCoords.position_angle be defined for the projected offsets

Now, offsets are just a SVector{2}s. Don't think we should overload these funcs for them...

[mileslucas]

I definitely prefer to keep origin either way, because it's the more intuitive name in coordinates context.

Sounds good

Also, should SkyCoords.separation and SkyCoords.position_angle be defined for the projected offsets

Now, offsets are just a SVector{2}s. Don't think we should overload these funcs for them...

I mean like so:

using LinearAlgebra
separation(proj::ProjectedCoords) = norm(proj.offset)

[aplavin]

Bump...
Anything else remains to be addressed in the code?

[giordano]

Is this method needed? Isn't it already covered by https://github.com/JuliaLang/julia/blob/162ee48e1c34b2a2cd797395353f19a7aca21aa2/base/Base.jl#L64?

[aplavin]

The Base method is less specific and won't be called when converting skycoords. Same motivation as

SkyCoords.jl/src/types.jl

Line 76 in 6c8849b

Base.convert(::Type{T}, c::T) where {T<:AbstractSkyCoords} = c

.