example: ProjectedCoords #43 with new proposed coords system

[icweaver]

Example application for #43 (comment)

Depends on #101

Plan to merge into #43 / update the PR description with the below if things look alright to y'all (modulo self-references to #43)

---

Adds ProjectedCoords: a flat-sky, small-field-of-view representation of a coordinate as an offset from an origin coordinate on top of the #105/#101 conversion design.

• ProjectedCoords{TC, T} stores an origin::TC coordinate and a 2-vector offset (longitude difference scaled by cos(lat(origin)), latitude difference, both in radians).
• project(origin, c) constructs one, converting c into origin's frame first.

Design: no convert methods at all

A projected coordinate is a representation around an origin value, not a coordinate frame of its own, its frame is the origin's. #43 integrated it with two custom Base.convert methods, which are cross-ambiguous with the CartesianCoords target methods (more specific in the source, less specific in the target). After #105/#101, the right place to plug in is the primitives, and the whole integration is:

• One frame_transform delegation to the origin's frame (plus a one-line FK4 disambiguator, the same pairwise cost the EclipticCoords/FK4NoETerms rotmat pair pays). Every conversion out of a ProjectedCoords then works generically: spherical targets, CartesianCoords targets in every parameter spelling, KDTree matching, non-rotational origin frames (projecting around an FK4Coords origin works, E-terms included), and even nested projections, which chain through their origins.
• A _checkframe override makes every conversion into a projected type (which would need an origin value that no type can carry) throw one clear ArgumentError pointing at project(origin, c), instead of feat: add simple projected coordinates #43's recursion. Identity conversion (convert(typeof(cp), cp) === cp) still works.
• cartesian(proj) tags with the origin's frame. constructorof must keep returning ProjectedCoords for setproperties reconstruction, so this is the first type where reconstruction identity and frame identity diverge, possibly an argument for eventually giving the frame tag its own function rather than reusing constructorof.
• Explicit ==/hash on (origin, offset). The generic frame-tag equality from refactor!: Consistent conversion rules and a frame-tag design for CartesianCoords #105 sees only the bare ProjectedCoords tag (the origin's frame is erased) so raw lon/lat numbers around origins in different frames would have compared equal. Comparing the origin (frame included) and the offset fixes that, with a matching hash.

Periodic-longitude isapprox (first commit, extracted from #43)

Constructors normalize longitude with mod2pi, so two points straddling the lon = 0 wrap are stored ~2π apart, and the elementwise (lon, lat) comparison called them not-≈: ICRSCoords(-eps(), 1) ≈ ICRSCoords(0, 1) was false. This is not just a constructed case, conversion round-trips genuinely land on the far side of the wrap (e.g. ICRSCoords(0.0, -1.372) comes back from a Galactic round-trip with
lon = 6.283185307179586), so convert(ICRSCoords, convert(GalCoords, c)) ≈ c failed spuriously for sources at ra ≈ 0.

The longitude difference is now taken in (-π, π] via rem2pi before comparing. Where #43 applied this to 3 of the 5 frames (leaving SuperGalCoords and EclipticCoords with the old behavior), it now goes through one _isapprox_lonlat helper used uniformly by all seven frames. Away from the wrap the comparison is unchanged.

Breaking changes

• Same-frame isapprox near the lon = 0 wrap now returns true where it previously returned false (that was the bug). Results away from the wrap are identical.
• Everything else is purely additive on top of refactor!: Consistent conversion rules and a frame-tag design for CartesianCoords #105/feat: Add FK4Coords and FK4NoETerms #101.

[codecov]

Codecov Report

❌ Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.42%. Comparing base (232c4dc) to head (353aa8c).

Files with missing lines	Patch %	Lines
src/types.jl	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              fk4     #106      +/-   ##
==========================================
+ Coverage   95.16%   95.42%   +0.26%     
==========================================
  Files           8        9       +1     
  Lines         310      328      +18     
==========================================
+ Hits          295      313      +18     
  Misses         15       15              

☔ View full report in Codecov by Harness.
📢 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.