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

packaging/make-man.py

@@ -783,6 +783,54 @@ address block says which country registered the aircraft, fixed by treaty, and
 the first three letters of an airline callsign are its ICAO designator.
 .B \-\-no\-lookup
 stops at that.
+.PP
+A callsign is a flight number rather than a leg. An airline runs the same
+number over several legs in a day and a register holds one route for it, so an
+aircraft crossing Arizona is quite often handed a half-hour hop between two
+airports in Texas; the two registers routinely disagree about the same flight
+number, and both are snapshots years old. Nothing on the air settles it, as
+ADS-B carries no origin or destination: an aircraft broadcasts who and where
+it is, not where it is going.
+.PP
+So a route the aircraft cannot be flying is left off the map and out of the
+window \[em] the two ends are known, and an aircraft on a route is never much
+further along it than the route is long \[em] and written in the report with a
+note saying so, since it is what the register holds for that flight number and
+worth having. Where a source lists a whole day's stops rather than a leg, the
+aircraft's own position picks the leg out; where no leg fits, none is claimed.
+.SS Schedule services
+Knowing the leg for certain needs live schedule data, which none of the free
+sources carry. Four commercial services are wired up and all four are
+optional: FlightAware AeroAPI, Flightradar24, OAG and Cirium. Each holds the
+timetable and the day's movements, so each can say which leg of a flight
+number was in the air at the moment an aircraft was overhead. Where one
+answers, its leg is used; where none does, the free databases answer as they
+always did, and a program with no keys set behaves exactly as before.
+.PP
+Keys are read from the environment rather than 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.
+.PP
+.nf
+BANDSAUNTER_AEROAPI_KEY       FlightAware AeroAPI
+BANDSAUNTER_FR24_TOKEN        Flightradar24
+BANDSAUNTER_OAG_KEY           OAG Flight Info
+BANDSAUNTER_CIRIUM_APP_ID     Cirium (FlightStats), with
+BANDSAUNTER_CIRIUM_APP_KEY
+.fi
+.PP
+.BI \-\-schedules " NAMES"
+picks which to ask and in what order, comma separated, from
+.BR flightaware ", " flightradar24 ", " oag " and " cirium ;
+the default asks every one that has its key. A service with no key is skipped
+rather than asked and refused. The callsign and the moment are all that is
+sent.
+.PP
+Each reader was written from its service's published response shape and
+tested against that shape; none has been run against a live service, since
+each wants a paid account. So each is written to find what it recognises and
+return nothing otherwise: a service that has changed since costs a route
+rather than a scan, and the free databases pick the question back up.
 .SS The moving map
 .B bandsaunter flights
 reads a log back \[em] the newest one in the output directory unless told
@@ -869,8 +917,20 @@ Tiles are cached in
 .I ~/.cache/bandsaunter/tiles
 and never fetched twice, every request identifies this program in its
 User-Agent, and the attribution the tiles require is written onto the picture
-\[em] a GIF travels without the readme that would otherwise carry it. A drawing
-is capped at a few dozen tiles; past that the zoom drops instead.
+\[em] a GIF travels without the readme that would otherwise carry it.
+.PP
+The zoom is chosen from how wide the picture is, not from the area alone, so a
+map asked for at 1920 pixels fetches finer tiles than the same map asked for
+at 960. Half again over the width is fetched deliberately and averaged down,
+since a downscaled tile is sharp and an upscaled one is not.
+.PP
+The window fetches a little more world than it shows so that panning does not
+leave the ground blank, and fetches that bigger piece at the bigger piece's
+own size, so what is shown comes out pixel for pixel with the screen. At 1920
+by 1080 and a hundred-mile radius the tiles hold about 1.6 times the pixels
+the window wants. A drawing is capped at a couple of hundred tiles, which at
+3840 by 2160 is reached: there the zoom has stopped climbing and the map is
+enlarged after all, and a smaller radius buys the detail back.
 .PP
 .B \-\-no\-basemap
 draws the tracks on their own,