Problem
fly#54 found the catalogue's FLYING_HEIGHT 10.764 times too large on 1,589 film frames and
repairs it. The same sweep found 1,963 film frames whose FLYING_HEIGHT is under half what
their SCALE x FOCAL_LENGTH implies (1,962 of them terrain-sampled; the figures below are over
those), and about 7,400 under 0.9. Those are deliberately
not repaired: fly_footprint(dem = ) marks them height_source = "implausible" and sizes
them from nominal scale.
They are not repaired because three different remedies each explain a comparable share and
the terrain cannot choose between them. Over MRDEM-30, of the 1,962:
| remedy |
frames it brings inside [1/1.6, 1.6] |
reading |
| x 10.764 |
726 |
the fly#54 slip, run the other way |
| x 10 |
729 |
a dropped digit in a height in feet — 609 m is 2,000 ft |
| x 2 |
799 (a different set of rolls) |
a 153 mm lens catalogued as 305 — 519 of the 799 are catalogued at 305, but 280 are at 153, which this reading cannot explain |
Nor does 10.764 sort this tail the way it sorts the upper one: it scatters the 1,962 from
-0.70 to 5.38, leaving 130 still below the band and 1,106 above it, where the forward repair
puts all 1,589 at 0.80-1.32 with nothing between 6.69 and 10.01. Examples: bc79122 640 m at 1:20000 / 305 mm,
bc7584, bc7675, bc81013, bc77032; and at 0.500 bc80001, bcc162, bc79209.
bc7280 reads 60 m and bc5598 2 m, which nothing explains.
The mirror of the x2 case is on the high side too: a mass centred on r = 2, where 209 of the
223 frames sampled beyond r 1.8 are catalogued at 153 mm — a 305 recorded as 153.
Why it is worth an issue
For these frames nominal scale is the right fallback for the lens-mislabel cases (it never
reads focal_length) and an unknown quantity for the rest. Nothing is lost today — most were
already falling back, since 588 of the 1,962 have terrain above the recorded height — but
they cannot get the ~14% terrain correction until the height can be trusted.
What would settle it
Something independent of FLYING_HEIGHT, SCALE and FOCAL_LENGTH:
- the flight log (
flight_log_url) where one exists, which states the planned altitude;
- adjacent-frame spacing along a leg against the footprint width each remedy implies —
forward overlap is designed to about 60%, so a remedy that implies 5% or 95% is wrong.
fly_bearing() already identifies contiguous legs;
- for the lens mislabel specifically, the calibration report or camera named on the roll.
Evidence
inst/extdata/flying_height_sweep.csv (set == "lower_tail" and "near_upper"),
data-raw/height_calibrate-flying_height_slip.R, and the "held against the scale" section
of inst/notes/terrain-correction.md.
Problem
fly#54 found the catalogue's
FLYING_HEIGHT10.764 times too large on 1,589 film frames andrepairs it. The same sweep found 1,963 film frames whose
FLYING_HEIGHTis under half whattheir
SCALE x FOCAL_LENGTHimplies (1,962 of them terrain-sampled; the figures below are overthose), and about 7,400 under 0.9. Those are deliberately
not repaired:
fly_footprint(dem = )marks themheight_source = "implausible"and sizesthem from nominal scale.
They are not repaired because three different remedies each explain a comparable share and
the terrain cannot choose between them. Over MRDEM-30, of the 1,962:
Nor does 10.764 sort this tail the way it sorts the upper one: it scatters the 1,962 from
-0.70 to 5.38, leaving 130 still below the band and 1,106 above it, where the forward repair
puts all 1,589 at 0.80-1.32 with nothing between 6.69 and 10.01. Examples:
bc79122640 m at 1:20000 / 305 mm,bc7584,bc7675,bc81013,bc77032; and at 0.500bc80001,bcc162,bc79209.bc7280reads 60 m andbc55982 m, which nothing explains.The mirror of the x2 case is on the high side too: a mass centred on r = 2, where 209 of the
223 frames sampled beyond r 1.8 are catalogued at 153 mm — a 305 recorded as 153.
Why it is worth an issue
For these frames nominal scale is the right fallback for the lens-mislabel cases (it never
reads
focal_length) and an unknown quantity for the rest. Nothing is lost today — most werealready falling back, since 588 of the 1,962 have terrain above the recorded height — but
they cannot get the ~14% terrain correction until the height can be trusted.
What would settle it
Something independent of
FLYING_HEIGHT,SCALEandFOCAL_LENGTH:flight_log_url) where one exists, which states the planned altitude;forward overlap is designed to about 60%, so a remedy that implies 5% or 95% is wrong.
fly_bearing()already identifies contiguous legs;Evidence
inst/extdata/flying_height_sweep.csv(set == "lower_tail"and"near_upper"),data-raw/height_calibrate-flying_height_slip.R, and the "held against the scale" sectionof
inst/notes/terrain-correction.md.