Compute radar gate geolocation instead of delegating to PROJ

[rcjackson]

Fixes the test_adaptive_scanning.py failures that have run every night since 2026-09-06.

(This branch began as a one-line diagnostic pin. It now carries the actual fix and the pin is gone.)

Root cause

The model input is a rasterised radar image, so its geometry is part of the model contract. It was being produced by handing Cartopy AEQD metres and letting PROJ transform them — which means a PROJ release can silently change what the network sees. PROJ 9.8.0 did exactly that:

PROJ 9.8.0: "Add support for Equidistant Cylindrical ellipsoidal method (EPSG:1028)"

Cartopy's PlateCarree is defined as +proj=eqc +ellps=WGS84 +a=6378137.0 and assumes plate-carrée semantics (y = R·lat, linear in latitude). Under 9.8 that projection became genuinely ellipsoidal, so y is meridional arc length — ~24 km different at 41°N. It did not cancel, because the data went through aeqd→eqc while the axes extent went through geodetic→eqc.

Measured in CI, same runner and same torch, changing only pyproj:

              mask px   centroid                dist
PROJ 9.5.1     1605     41.68141, -88.01086       0.0 m   -> triggers   (pass)
PROJ 9.8.1     1386     41.52329, -88.08939   18732.4 m   -> no trigger (FAIL)

model input:  87.3% of pixels moved, ~10 px offset plus a scale warp

Ruled out along the way: PyTorch (2.14.0 identical either side), model weights (unchanged on HF since 2025-07-14), our code (no commits in the window), and a near-threshold flip (the case moves from 0 m to 18.7 km — nowhere near the 5000 m boundary).

The fix

adam.util.aeqd_to_lonlat solves the direct geodesic problem on WGS84 with Vincenty's formulae in numpy, agreeing with PROJ to 1.86 µm over 2160 gate points out to 300 km. The figure is drawn on a plain Matplotlib axes with longitude and latitude as the axes coordinates — which is what a plate carrée map is. Nothing in the model input path consults a projection library.

The two duplicated Cartopy render blocks in preprocess_radar_image and _preprocess collapse into one _render_model_input. Figure size, colormap, limits, PNG round-trip and normalisation are unchanged. visualize_lake_breeze keeps Cartopy — display only, never feeds the model.

Reaching into adam.util from adam.io was circular (instrument_steering imported RadarImage at module scope for annotations only). It is now a TYPE_CHECKING import, so adam.util is independently importable.

Evidence

Equivalent to the old renderer (same PROJ, so only the code path differs):

                        mean|diff|   pixels >1.0   translation
this change                0.193        0.22%         none
the PROJ 9.8 breakage    153.947       87.30%      ~10 px + warp

Version-independent — the point of the change, dumped on one machine at two projection versions:

pyproj 3.7.2 / PROJ 9.5.1  \
                            >  max |diff| = 0.000, 0.00% of pixels
pyproj 3.8.0 / PROJ 9.8.1  /

both give: mask 1608 px, centroid 41.68141,-88.01647, azimuth 224.612 deg, dist 0.0 m

Tests: 17 passed locally; unit tests, docs and diagnostics all green in CI at pyproj 3.8.0 with no pin — the exact configuration that has been failing.

Fixtures, and one thing reviewers should know

The two triggered-scan fixtures are regenerated, and their azimuth is now compared with a tolerance instead of byte-for-byte.

In the 2025-04-24 case the front sits ~3 pixels from the lidar (dist is 0.0 m — the mask covers the instrument), so azimuth_point takes atan2 of a very short vector. A one-pixel centroid shift swings the commanded azimuth by 8°, which is exactly what happened here (216.5° → 224.6°, centroid moving one grid cell in longitude). Pinning that number exactly would break again on the next Matplotlib or Py-ART release. Structure, motor parameters, elevations and the sector width are still checked exactly; only the absolute azimuth is given a tolerance, set to half the 30° scan width so a passing scan still covers at least half the reference sector.

Worth flagging honestly: best_model's mask IoU across the renderer change is 0.938, below the 0.98 bar I set for myself. The input differs by only 0.22% of pixels, so this is the model amplifying a tiny perturbation rather than renderer error — but that sensitivity is real and unchanged by this PR.

Not included

predict_lake_breeze.py never calls model.eval(), so Dropout(0.1) is live during inference and output varies with the seed. Real, but separate, and not a trivial fix: full eval() makes lakebreeze_best_model_fcn_resnet50 return an empty mask, because its checkpoint's BatchNorm running statistics are unusable (running_mean to 2574, running_var to 8.3e5). Disabling only the Dropout modules does work and makes output fully deterministic. Separate PR.

🤖 Generated with Claude Code