[Feature] Satellite range / range rate / doppler factor, with languages

[MichaelWheeley]

What does this PR do?

When satellite is above horizon calculates and displays range / range rate / doppler factor in US or metric units.
Language keys for new words created using 'en' as master, needs non-AI native speakers to update
Language en, th are complete.
Added brief explanation of doppler factor into documentation.

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

1. only works when satellite is above horizon (I modified DE location to make it quicker)
2. change units between US and metric
3. change languages, en and th are complete

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

Screenshots (if visual change)

• Satellite below horizon:

• Satellite above horizon, metric units:

• Satellite above horizon, US units:

• Satellite above horizon, metric units, th language:

[accius]

PR Review — Satellite Range / Range Rate / Doppler Factor

Nice feature, Michael — this is useful data for satellite ops. A few things to address:

Bug: Range rate sign convention appears inverted

The code computes:

rangeRate = (1 - dopplerFactor) * c;

satellite.js's dopplerFactor() returns values > 1 when the satellite is approaching (blueshift). So (1 - dopplerFactor) produces a negative value when approaching — which contradicts the PR description ("positive approaching, negative receding").

Either flip to (dopplerFactor - 1) * c, or update the description to match. Please double-check against a known pass to confirm which convention you intend.

README typos

• "dopper factor" → "doppler factor"
• "downlnk" → "downlink"

Minor items

• Neutral doppler value: dopplerFactor is initialized to 0 when below horizon. Since 1.0 means "no shift", consider defaulting to 1 (or null) so downstream consumers aren't surprised. The popup guards against this, but other code consuming the satellite data might not.
• Removed comment: The // Formula: radius = Earth_radius * arccos(...) comment on the footprint calculation was helpful for readability — consider keeping it.
• visible → isVisible rename: This looks safe (only useSatelliteLayer.js consumes it), but worth noting it's a breaking change to the satellite data shape if anything else references sat.visible.

Looks good

• Clean usage of satellite.js API (geodeticToEcf, eciToEcf, dopplerFactor)
• Unit conversion is consistent with existing patterns
• Conditional rendering gated on isVisible — no wasted computation
• Language keys added across all 16 locales

[MichaelWheeley]

@accius after quite some time debugging dopplerFactor (as you observed the value greater than or less than 1 appears faulty), it appears this was corrected in satellite.js 6.0.0 . I notice the version used is currently 5.0.0 . I locally updated my version to 6.0.0, not yet checked-in.

https://github.com/shashwatak/satellite-js/blob/develop/CHANGELOG.md

satellite receding looks much better,

satellite approaching,

[MichaelWheeley]

satellite.js
I loaded 6.0.0 without problem - runs and takes care of dopplerFactor/RangeRate issue.
I tried to load the latest version 7.0.0, however quote

Dropped AMD, CJS and minified builds. The library is now ESM only

see https://github.com/shashwatak/satellite-js/releases/tag/7.0.0

Perhaps there is a way to get it to work?