complete land stuff
This commit is contained in:
83
CLAUDE.md
83
CLAUDE.md
@@ -720,7 +720,7 @@ PPI Radar Equiation
|
|||||||
latitude \(48^\circ 43' 25" \text{ N}\) and longitude \(122^\circ 34' 35" \text{ W}\)
|
latitude \(48^\circ 43' 25" \text{ N}\) and longitude \(122^\circ 34' 35" \text{ W}\)
|
||||||
|
|
||||||
PPI Police Boat ( starts as docked at the taylor street dock; but will be moving around
|
PPI Police Boat ( starts as docked at the taylor street dock; but will be moving around
|
||||||
48.735519° N latitude and -122.331931° W longitude.
|
48.7253874° N latitude and -122.5077482° W longitude.
|
||||||
|
|
||||||
=====================================================================
|
=====================================================================
|
||||||
|
|
||||||
@@ -783,6 +783,9 @@ PPI Radar Equiation
|
|||||||
|
|
||||||
GROUND TERRAIN AND LIDAR DATA PROCESSING
|
GROUND TERRAIN AND LIDAR DATA PROCESSING
|
||||||
|
|
||||||
|
Note: Do not do this for the Chain Home Radar. Theu user will heve enough
|
||||||
|
of a challenging dealing with the targets and noise alone.
|
||||||
|
|
||||||
Note that the following files already exist in the project directory
|
Note that the following files already exist in the project directory
|
||||||
in the following:
|
in the following:
|
||||||
|
|
||||||
@@ -803,6 +806,12 @@ PPI Radar Equiation
|
|||||||
area. It contains vector data for the shoreline, docks, piers,
|
area. It contains vector data for the shoreline, docks, piers,
|
||||||
and water depths (bathymetry), as well as navigational aids.
|
and water depths (bathymetry), as well as navigational aids.
|
||||||
|
|
||||||
|
Note that the US5WA45M.000 (ENC Chart) may not be needed at all. The
|
||||||
|
n48_w123_1arc_v3.tif (DEM) and the LiDAR DEMs already define land vs. water
|
||||||
|
by elevation — any cell above 0 meters is land and will return a radar echo.
|
||||||
|
The ENC vector shoreline data would be redundant for this purpose.
|
||||||
|
|
||||||
|
|
||||||
n48_w123_1arc_v3.tif (DEM): This is a USGS 1-arc-second Digital
|
n48_w123_1arc_v3.tif (DEM): This is a USGS 1-arc-second Digital
|
||||||
Elevation Model in GeoTIFF format. It provides a continuous grid of
|
Elevation Model in GeoTIFF format. It provides a continuous grid of
|
||||||
land elevation data for the area (roughly 30-meter resolution).
|
land elevation data for the area (roughly 30-meter resolution).
|
||||||
@@ -832,9 +841,81 @@ PPI Radar Equiation
|
|||||||
coordinates $(u, v)$ represent latitude/longitude or local grid
|
coordinates $(u, v)$ represent latitude/longitude or local grid
|
||||||
coordinates, and the pixel value represents the height above sea level.
|
coordinates, and the pixel value represents the height above sea level.
|
||||||
|
|
||||||
|
Note that it may be better to do the conversion once and save the grid of 2d
|
||||||
|
elevation data into a file. So, during the first invocation of the radar program,
|
||||||
|
run the conversion once and put the final data into map/converted_data. If the file
|
||||||
|
is already there, then do not perform the conversion.
|
||||||
|
|
||||||
The texture will need to be moved around for the police boat ppi radar, but it
|
The texture will need to be moved around for the police boat ppi radar, but it
|
||||||
will be stationary for the vessel traffic control ppi radar.
|
will be stationary for the vessel traffic control ppi radar.
|
||||||
|
|
||||||
|
Please note that we should have values defined in the settings.h file for the
|
||||||
|
strengths of the DEM map information and the LiDAR information as well as the
|
||||||
|
total strength of all of the shoreline information.
|
||||||
|
|
||||||
|
SETTINGS.H VALUES FOR LAND AND TERRAIN DATA
|
||||||
|
|
||||||
|
The following entries belong in settings.h so that terrain rendering behavior
|
||||||
|
can be tuned or disabled without touching shader or pipeline code.
|
||||||
|
|
||||||
|
/* ------------------------------------------------------------------
|
||||||
|
TERRAIN / LAND DATA — settings.h entries
|
||||||
|
------------------------------------------------------------------ */
|
||||||
|
|
||||||
|
/* Master on/off switch for all terrain rendering.
|
||||||
|
Set to 0 to suppress land echoes entirely; useful when you want to
|
||||||
|
observe only live targets without any terrain clutter. */
|
||||||
|
#define ENABLE_TERRAIN_RENDERING 1
|
||||||
|
|
||||||
|
/* Individual layer enable flags.
|
||||||
|
Lets you isolate which elevation source is contributing echoes. */
|
||||||
|
#define ENABLE_DEM_LAYER 1 // USGS 1-arc-second (~30 m) GeoTIFF
|
||||||
|
#define ENABLE_LIDAR_LAYER 1 // High-res WA State LiDAR DEMs
|
||||||
|
|
||||||
|
/* Elevation threshold (meters) above which a cell is treated as land
|
||||||
|
and returns a radar echo. 0.0 = sea level. Raise slightly (e.g.
|
||||||
|
0.5) to suppress low-lying marshes that are technically above datum
|
||||||
|
but unlikely to produce a real ship-hazard echo. */
|
||||||
|
#define LAND_ELEVATION_THRESHOLD_M 0.0f
|
||||||
|
|
||||||
|
/* Echo amplitude scalars for each elevation source.
|
||||||
|
These feed the fragment shader as uniforms so the DEM and LiDAR
|
||||||
|
layers can be weighted independently.
|
||||||
|
1.0 = nominal; raise to exaggerate; lower to soften. */
|
||||||
|
#define DEM_ECHO_STRENGTH 1.0f
|
||||||
|
#define LIDAR_ECHO_STRENGTH 1.2f // slightly stronger — LiDAR is more accurate
|
||||||
|
|
||||||
|
/* Overall terrain echo scale applied after the per-layer scalars.
|
||||||
|
Acts as a master volume knob for all shoreline / land returns.
|
||||||
|
Adjust this first before touching the per-layer values. */
|
||||||
|
#define TERRAIN_ECHO_TOTAL_SCALE 1.0f
|
||||||
|
|
||||||
|
/* Raycasting step size (meters) used when marching each radar beam
|
||||||
|
sample through the height-map texture. Smaller = more accurate
|
||||||
|
shoreline but more GPU cost. 8.0 is a reasonable starting point
|
||||||
|
for the ~30 m DEM; drop to 4.0 if LiDAR detail is being missed. */
|
||||||
|
#define TERRAIN_RAY_STEP_M 8.0f
|
||||||
|
|
||||||
|
/* Maximum elevation (meters) used to normalize the GL_R32F texture
|
||||||
|
values before they reach the shader. Should be >= the tallest
|
||||||
|
terrain feature in the scene (Bellingham area peaks ~600 m). */
|
||||||
|
#define TERRAIN_MAX_ELEVATION_M 700.0f
|
||||||
|
|
||||||
|
/* Height (meters) at which LiDAR data takes priority over the coarser
|
||||||
|
USGS DEM when the two grids are composited during map/converted_data
|
||||||
|
generation. Cells with LiDAR values >= this threshold replace the
|
||||||
|
DEM value; cells below fall back to DEM. */
|
||||||
|
#define LIDAR_PRIORITY_HEIGHT_M 0.5f
|
||||||
|
|
||||||
|
/* Debug: show only terrain echoes, suppress all moving targets.
|
||||||
|
Set to 1 to isolate land-clutter rendering during development. */
|
||||||
|
#define DEBUG_TERRAIN_ONLY 0
|
||||||
|
|
||||||
|
/* Debug: colour-code which elevation source is active for each pixel
|
||||||
|
(blue = DEM only, green = LiDAR override). Set to 1 to visualise
|
||||||
|
coverage boundaries when compositing the height-map. */
|
||||||
|
#define DEBUG_SHOW_LIDAR_COVERAGE 0
|
||||||
|
|
||||||
|
|
||||||
==================================
|
==================================
|
||||||
|
|
||||||
|
|||||||
54
work_note
Normal file
54
work_note
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
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
|
||||||
|
|
||||||
|
──────────────────────────────────
|
||||||
Reference in New Issue
Block a user