Ask a service that knows which leg it is, and fetch a map worth the screen
A callsign is a flight number rather than a leg, and the free registers hold one route per number, so an aircraft over Arizona kept being handed a hop between two airports in Texas. Nothing on the air settles it: ADS-B carries no origin or destination. A commercial schedule service does know, because it holds the day's actual movements. Four are wired up and all four are optional: FlightAware AeroAPI, Flightradar24, OAG and Cirium. Each is asked before the free databases and each answers for the moment the aircraft was overhead rather than for the flight number in general, so the leg chosen is the one that was in the air. With no keys set nothing changes at all: a source with no key is skipped rather than asked and refused, and the free databases answer as before. Keys come from the environment and are never written to the settings file, because a settings file is meant to be copied between machines and pasted into a message asking for help, and an API key is not. There is a test that holds that line. None of the four has been run against its live service, since each wants a paid account. They were written from the published response shapes and are tested against those shapes, so each reader finds what it recognises and returns nothing otherwise: a service that has changed since costs a route rather than a scan. Cirium's plain departureTime is local and carries no offset, so the UTC field is preferred where it is there -- reading the local one as UTC is up to half a day out, which is exactly far enough to pick the wrong leg of the same number. Reading now happens inside the same guard as asking, as an answer shaped differently from the documented one is the failure most likely to actually happen. And the map. The zoom is now chosen from how wide the picture is rather than from the area alone, with half again over the width fetched and averaged down, since a downscaled tile is sharp and an upscaled one is not. The window fetches a little more world than it shows so panning does not leave the ground blank, and now fetches that bigger piece at the bigger piece's own size: rendering it into the window's own pixels and stretching it back was a fifth of an upscale over the whole map, which is what a sharp map looks like when it looks blurred. The comment in the fetcher said the opposite of what the code did, which is how it stayed hidden. At 1920 by 1080 over a hundred miles the tiles now hold about 1.6 times the pixels the window wants. At 3840 by 2160 the tile budget is reached, the zoom stops climbing and the map is enlarged after all; a smaller radius buys the detail back, and somebody else's tile server is not a thing to fetch a thousand tiles from for one picture. The README says so rather than implying otherwise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg
This commit is contained in:
parent
87b0954f0c
commit
8eb3bdbb86
20 changed files with 1758 additions and 66 deletions
36
INSTALL.md
36
INSTALL.md
|
|
@ -150,6 +150,42 @@ ask public registers about a callsign or a 24-bit address and cache the
|
|||
answers for a month; `--no-lookup` turns them off, and what the address and
|
||||
the callsign say on their own is worked out offline either way.
|
||||
|
||||
### Optional: a paid schedule service
|
||||
|
||||
Nothing here needs installing either — these are accounts, not packages, and
|
||||
all four are optional. They answer the one question the free registers cannot:
|
||||
an airline runs the same flight number over several legs in a day, and a free
|
||||
register holds one route per number, so it will often name somebody else's
|
||||
leg. A schedule service holds the day's actual movements.
|
||||
|
||||
| Service | Sign up at | Set |
|
||||
|---|---|---|
|
||||
| FlightAware AeroAPI | <https://www.flightaware.com/commercial/aeroapi/> | `BANDSAUNTER_AEROAPI_KEY` |
|
||||
| Flightradar24 | <https://fr24api.flightradar24.com/> | `BANDSAUNTER_FR24_TOKEN` |
|
||||
| OAG Flight Info | <https://developer.oag.com/> | `BANDSAUNTER_OAG_KEY` |
|
||||
| Cirium (FlightStats) | <https://developer.cirium.com/> | `BANDSAUNTER_CIRIUM_APP_ID` and `BANDSAUNTER_CIRIUM_APP_KEY` |
|
||||
|
||||
Put the ones you have in your shell profile:
|
||||
|
||||
```sh
|
||||
echo 'export BANDSAUNTER_AEROAPI_KEY=your-key-here' >> ~/.bashrc
|
||||
. ~/.bashrc
|
||||
```
|
||||
|
||||
**Keys are read from the environment and never written to the settings file**,
|
||||
on purpose: a settings file gets copied between machines and pasted into
|
||||
messages asking for help, and an API key should not travel that way.
|
||||
|
||||
Any service whose key is set is asked; one whose key is not set is skipped
|
||||
silently, and the free registers answer exactly as they did before.
|
||||
`--schedules flightaware,oag` picks which to ask and in what order. Only the
|
||||
callsign and the time are ever sent.
|
||||
|
||||
These readers were written from each service's published response format and
|
||||
tested against it, but none has been run against a live service, because each
|
||||
one needs a paid account. Each is written to return nothing rather than guess,
|
||||
so a service that has changed its format costs you a route, not a scan.
|
||||
|
||||
---
|
||||
|
||||
## Speech transcription, step by step
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue