Draw the map's missing squares as gaps, and its rings in your own units

Two faults reported from in front of the window, both of them the map saying
something confidently and wrongly.

Tiles that did not arrive.  Resizing the window does not refetch the map: the
window deliberately fetches more world than it shows, so a resize still fits
inside what is in hand and gets stretched to the new size.  It refetches when
the view leaves that box, which is what a new station does -- and that fetch
asks a volunteer-funded server for a hundred tiles that have never been on
this disk, all at once, at the sharper zoom the bigger window chose.  Some of
them are refused.

What the window did with a refusal was draw it.  A tile that never arrived
leaves its square of the canvas black, and black is not a neutral colour
here: the brightness is inverted on the way in, because a printed map is ink
on paper and this picture is the other way round.  So the darkest possible
square came out as the brightest thing on the picture, a glowing rectangle
where the map should be.  Measured on a reproduction, one missing tile in
eighteen put thirteen thousand pixels at full brightness -- and dragged the
floor of the map's own contrast down to black with it, so thirteen thousand
four hundred and ninety pixels changed in all: the whole map was redrawn
dimmer to make room for a square that was not there.  Then it was kept, cached
under the view it was fetched for, until the view moved again.

So the missing squares are asked for again at once, and only those, the rest
being on the disk by then; what is still missing is drawn as bare ground and
left out of the reckoning when the darkest and brightest of the map are worked
out, which puts the same reproduction at two pixels changed rather than
thirteen thousand four hundred and ninety, a hairline where a cell is averaged
over part of a tile and part of nothing; and the map is kept as provisional
rather than as the last word, asked for again half a minute later, four
attempts in all, each retrying its own misses once.

Found while measuring that: the politeness pause between requests was being
paid on every tile, including the ones read straight back off the disk.  Two
hundred and twenty tiles at an eighth of a second is twenty-six seconds of
sleeping to redraw a view that was entirely cached, and it would have made
asking again for three missing squares cost the wait for the two hundred that
were not.  The constant's own comment already said it should only be paid on a
tile that was not already there.  Now it is.

The APRS map's units.  Setting imperial changed nothing at all about the
window: the unit it measures in was hardcoded to kilometres, and that one
value drives the ring labels and the scale along the bottom; and --radius was
always read as kilometres, so the rings were not merely mislabelled, they were
at the wrong distance from the flag.  A ring is what a distance gets judged
against by eye, and one labelled in a unit it was not drawn in is a wrong
answer given confidently.  The aircraft side has done this properly all along
-- a radius read in whatever unit the speeds are in, and no unit suffix on the
setting because the suffix belongs to the other setting -- so this now mirrors
it exactly.  At --radius 100 in imperial the outermost ring stands seventy-
five statute miles from the flag and says so, where it used to stand seventy-
five kilometres and say kilometres whatever you had asked for.

Twenty-one new tests against sixteen deliberately broken builds.  One
survived, and removing what it broke was the right answer rather than
strengthening a test: a check that the remembered request still matched the
map in hand could not be made to fail, a request for a different view being
taken up only after the slot it guards is already full.  The tests do not
trust the drawing to mark its own homework -- the one that matters walks north
from the flag by each ring's radius and measures the great-circle distance
with a haversine written in the test, then checks that against the printed
label.  Full suite 2685 passed.  Built as 2026-09-21_03.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg
This commit is contained in:
The Dust Council 2026-09-21 02:36:43 -07:00
parent e05b66ec3d
commit e203b3e581
11 changed files with 780 additions and 73 deletions

View file

@ -1646,6 +1646,37 @@ map is enlarged after all. Somebody else's tile server is not a thing to fetch
a thousand tiles from for one picture. A smaller `--radius` buys the detail
back, since the same budget then covers less ground.
**Tiles that do not arrive.** Resizing the window is the demanding case: a
wider picture picks a sharper zoom, and a hundred tiles that have never been
on this disk are asked for at once. A busy server refuses some of them, and
what the window used to do with a refusal was draw it.
A tile that never arrived leaves its square of the canvas black, and black is
not a neutral colour here — the brightness is inverted on the way in, so the
darkest possible square comes out as **the brightest thing on the picture**: a
glowing rectangle where the map should be. It also dragged the floor of the
map's own contrast down to black, so every other pixel was drawn dimmer to
make room for a square that was not there. And it was kept: the map was
cached under the view it was fetched for, and the hole stayed until the view
changed.
So three things happen instead. The missing squares are **asked for again**,
straight away, because the usual reason for a refusal is the ninety-nine tiles
asked for just before it — and only the missing ones, since the rest are on
the disk by then. What is still missing is **drawn as bare ground** rather
than as a light, and left out of the reckoning when the darkest and brightest
of the map are worked out, so a hole costs nothing but itself. And the map is
**remembered as provisional**: the window keeps drawing it and asks for the
rest of it half a minute later — four attempts in all, each of which retries
its own misses once, so a square gets eight chances before one that will not
come is accepted as one that is not there.
The politeness pause between requests is now paid only on a tile that had to
be fetched. It had been paid on every tile including the ones read back off
the disk, which put twenty-six seconds of sleeping into redrawing a view that
was entirely cached — and would have made asking again for three missing
squares cost the wait for the two hundred that were not.
`--map-brightness PERCENT` (70 by default) is how far up its range the map is
drawn, and **the vector themes bend the middle of that range down hard** —
because a tinted photograph of a county behind the vectors is the one thing
@ -2498,6 +2529,17 @@ trails, `g` the map underneath, `[` and `]` its brightness, `+`/`-` the range,
`q` quits. `--radius` sets how far it reaches to begin with and `--theme` picks
from the same five.
**The window measures in whatever unit you are being shown.** `--units
imperial` puts statute miles round the rings, along the scale at the bottom
and on `--radius` itself, and `--units metric` puts kilometres on all three.
The rings are then *drawn* at the distance they are labelled: the outermost
one at `--radius 100 --units imperial` stands seventy-five statute miles from
the red flag, measured on the ground, not seventy-five kilometres with miles
written beside it. A ring is the thing a distance gets judged against by eye,
so a ring labelled in one unit and drawn in another is a wrong answer given
confidently — and the tables printed afterwards have always followed this
setting, so the window disagreeing with them was the window being wrong.
**Where the aerial is** puts the red flag on the map, centres the range rings
and gives every station a distance and a bearing. Set it with `--at LAT,LON`,
or in the menu under **Receiver at** — and if you have already told the