Police Boat (Taylor Street Dock) — This one I want to flag: 48.735519° N, -122.331931° W. The -122.331931° W
  longitude seems significantly too far east for a Bellingham waterfront dock. The Bellingham waterfront is
  roughly -122.48° to -122.50° W. At -122.33° W you're several miles inland, near the eastern suburbs/I-5 corridor
   — not a dock. Worth double-checking this coordinate. The Taylor Dock / Boulevard Park dock area is around
  -122.497° W.

  ---
  Ground Terrain and LIDAR Data Processing (lines 784-837)
  
  Coverage gap for Chain Home: The terrain data (LiDAR zips, ENC chart, USGS GeoTIFF) all cover the Bellingham Bay
   / Pacific Northwest area. The Chain Home scope is at RAF Ventnor, Isle of Wight, England — there is no terrain
  data for that location. Since Chain Home is an A-scope (not PPI), land clutter isn't visually displayed the same
   way, but if you want to simulate land return/clutter in the Chain Home A-scope signal, you'll need to either
  skip terrain effects for that scope or procedurally generate some clutter. This should be explicitly called out
  in the document.

  Raycasting architecture — online vs. offline: The document says "processed into a fragment shader via ray
  casting." This is a critical architectural decision that needs clarification:

  - Offline preprocessing (recommended): Run the raycasting once at startup (or as a build step) using GDAL + CPU
  code to produce a pre-baked radar shadow/land-mask texture. Load that texture once into VRAM. The fragment
  shader then just samples it. This is fast and suitable for the integrated Radeon 780M.
  - Real-time raycasting in the fragment shader: Computing terrain shadows per-pixel per-frame is very expensive,
  even on discrete GPUs. On an integrated Radeon 780M sharing system RAM as VRAM, this would likely be a serious
  performance problem.

  You should specify which approach you intend. I'd strongly suggest offline preprocessing into a pre-baked
  GL_R32F texture.

  Moving texture for police boat: The document notes "the texture will need to be moved around for the police boat
   PPI radar." This is more nuanced than translating it — as the boat moves, the UV coordinate mapping from
  radar-local meters to texture space changes. At 6 nm max range the boat could traverse a significant fraction of
   the texture. The shader needs to recompute the texture origin offset each frame based on the boat's current
  lat/lon. That needs to be spec'd out when you get to that scope.

  Data layering order is correct: LiDAR overrides coarse USGS DEM where they overlap. The suggestion to reproject
  everything to UTM Zone 10N before merging is the right approach for the Bellingham area.

  One missing element: The ENC chart (US5WA45M.000, S-57 vector format) gives you shoreline and bathymetry. The
  document doesn't yet describe how the ENC shoreline data feeds into the radar simulation specifically — whether
  it's used to generate a land-mask (anything above 0m elevation = land = returns radar signal) or just for visual
   reference. The LiDAR/DEM heights already handle this implicitly (height > 0 = land), but it's worth a sentence
  clarifying the ENC chart's role vs. the elevation data's role.

  ---
  Summary of action items from the review:
  1. Verify the police boat Taylor Street Dock longitude — -122.331931° W looks wrong.
  2. Clarify how Chain Home handles terrain (or explicitly state it doesn't).
  3. Decide offline-preprocess vs. real-time raycasting and document that decision.
  4. Add a note on how the ENC chart's role differs from the DEM/LiDAR data.

✻ Churned for 58s

──────────────────────────────────