Re locating traffic cop to correct location in the file

CLAUDE.md

@@ -149,13 +149,18 @@ struct target_data_to_shader_structure {
   float altitude;     // Target altitude profile (meters)
   time_t timestamp;   // Data aging tracking identifier
   float reflectivity; // derivied from TargetType (see table below)
-  float heightestivate;  // derived from TargetType (see table below)
-  fload noiseglint;   // derived from TargetType (see table below)
+  float height_estimate;  // derived from TargetType (see table below)
+  float noiseglint;   // derived from TargetType (see table below)
   binary police_boat  // this indicates that the target is for the roaming police boat.
 };
 
-Plese note that height, reflectivity, and noiseglint have to be derived from the target type
-in this table: (note that this is suggested code just to show you what should be happeneing)
+Please note that height and material are not included in the data received from the simulator
+nor the raspberry pis. This has to be derived. That will be discussed when I talk about the
+traffic cop later in this document.
+
+
+Suggested code for deriving target height, reflectivity
+    (derived from material) and noiseGlint (derived from material)
      
 struct RadarMaterialProfile {
     float reflectivity; // 0.0 (stealth/fiberglass) to 1.0 (massive steel)
@@ -237,7 +242,6 @@ Data synchronization between threads must be managed explicitly using std::mutex
    double-buffered array driving the SSBO, copy the structural contents, and 
    clear the mutex immediately.
 
-Note that the construction of the simulator will be discussed later in this document.
 
 =============================================================================
 
@@ -1084,7 +1088,10 @@ Here is the data items for the table in the Postgres database:
                              database editing program will use this.
 7. int vessel_type (AIS type code or aircraft type)
 8. uint32_t mmsi   (unique identification for boat or ICAL for aircraft
-9. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
+9. float reflectivity (derived from target type)
+10. float height_estimate (derived from target type)
+11. float noiseglint (derived from target type_
+12. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
 
 Please note that this database is only for the physical characteristics. Dynamic
 information which is created by the simulator (or raspberry pis) as that data changes.
@@ -1141,13 +1148,124 @@ Thread 5 = Raspberry pi data recever = this receives the data from the raspberry
         not be developed for the current version of the project. The Raspberry PI receiver will
         need to set a mutex in order to transfer target data to the traffic cop.
 
+================================================================================
+
+The traffic cop - handling radar data and deriving reflectivity stuff
+
+The segment handling asynchronous target ingestion is called traffic_cop.
+The traffic_cop runs on a dedicated background execution thread separate from the rendering loop. 
+Data synchronization between threads must be managed explicitly using std::mutex blocks.
+
+Among its duties are to manage the database.
+
+New targets (which have not ever been introduced to this system will be added to the
+database. The purpose of the database is to remember physical characteristics of targets;
+ie; the stuff that is not dynamic to the movement of the target. 
+
+This is to save processing time for stuff such as reflectivity.
+
+As target data is read from the database, it will also be copied to an in-memory copy
+of the database so that processing can be more efficent. The maximum size of the in-memory
+copy shall be limited to 200 targets. If the number of targets gets larger than 200 targets, the
+targets that have not been updated for the longest time shall be overwritten by new targets.
+Judging from the current traffic of bellingham bay, 200 targets for the caching memory copy of
+the database should be enough.
+
+As you may notice, height and material have not been including in the table of data we get from
+the simulator nor the raspberry pis taking in the ais and ads-b data from the sdr's. Those values
+have to be derived by the traffic cop and then entered into the database.
+
+Here is sample code for doing this; this is suggestion only.
+
+Suggested code for deriving target height, reflectivity
+    (derived from material) and noiseGlint (derived from material)
+     
+struct RadarMaterialProfile {
+    float reflectivity; // 0.0 (stealth/fiberglass) to 1.0 (massive steel)
+    float heightEstimate; // in meters, to calculate radar horizon cutout
+    float noiseGlint; // simulated signal scintillation
+};
+
+RadarMaterialProfile getMaterialProfile(int aisTypeCode) {
+    RadarMaterialProfile profile;
+    
+    switch(type) { // type is in the target_data_structure
+        case 30: // Fishing (often wooden/fiberglass hulls, low sitting)
+            profile.reflectivity = 0.35; profile.heightEstimate = 4.0; profile.noiseGlint = 0.2;
+            break;
+        case 36: // Sailing Vessel (tall aluminum mast, but low fiberglass hull)
+            profile.reflectivity = 0.25; profile.heightEstimate = 15.0; profile.noiseGlint = 0.4; // High mast glint!
+            break;
+        case 37: // Pleasure Craft (fiberglass speedboats, yachts)
+            profile.reflectivity = 0.20; profile.heightEstimate = 3.0; profile.noiseGlint = 0.1;
+            break;
+        case 52: // Tugboats (dense, heavy low-sitting steel blocks)
+            profile.reflectivity = 0.85; profile.heightEstimate = 6.0; profile.noiseGlint = 0.15;
+            profile.reflectivity = 0.95; profile.heightEstimate = 35.0; profile.noiseGlint = 0.05; // Perfect metal reflector!
+            break;
+        default: // Catch-all / Code 0 - some owners neglect setting this in their transponders
+            profile.reflectivity = 0.50; profile.heightEstimate = 8.0; profile.noiseGlint = 0.2;
+            break;
+    }
+    return profile;
+}
+
+
+Using this data, the traffic cop can derive the time varying fluctuations of the target
+(note that this is suggested code; may not be the actual code you generate; and
+note that this data is not included in the database as it is active data)
+
+
+// Inside your C++ target loop (running every frame or every radar sweep)
+float baseReflectivity = target.materialProfile.reflectivity;
+float glintFactor = target.materialProfile.noiseGlint;
+
+// Generate a random float between -1.0 and 1.0
+float randomNoise = ((float)rand() / RAND_MAX) * 2.0f - 1.0f;
+
+// Calculate the dynamic, fluctuating reflectivity for THIS frame
+float dynamicReflectivity = baseReflectivity + (randomNoise * glintFactor);
+
+// Clamp it so it doesn't drop below 0 or overshoot 1.0
+dynamicReflectivity = std::max(0.0f, std::min(1.0f, dynamicReflectivity));
+
+// Pass 'dynamicReflectivity' to your GLSL shader uniform array
+glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynamicReflectivity);
+
+
+The segment handling asynchronous target ingestion is called traffic_cop.
+The traffic_cop runs on a dedicated background execution thread separate from the rendering loop. 
+Data synchronization between threads must be managed explicitly using std::mutex blocks.
+
+[TRAFFIC COP OPERATIONAL TIMING PROTOCOL]
+1. Processing Loop: Aggregated targets are packaged into a uniform array and dispatched 
+   as they arrive to the traffic cop from the simulator or the receiver handling the raspberry pis.
+2. Range Filtering: Discard any targets residing outside the active radar's 
+   designated maximum operational range.
+3. Altitude Restriction: Enforce a strict <= 40-meter restriction for marine nodes (Marine Chain Home 
+   and all PPI Marine radars). Discard any aircraft violating this ceiling.
+4. Precision Alignment: Latitude and longitude coordinate conversions into local meters relative to 
+   the radar origin must be handled on the CPU thread within traffic_cop 
+   to protect against FP32 structural precision rounding errors inside the GPU.
+5. The determination of the reflectivity, height estimate, and the noiseglint must 
+   be processed by the traffic cop
+6. The traffic cop needs to know the longitude and latitude of the chain home ascope, the marine ascope,
+   and the marine traffic control radars. It will already have the longitude and latitude of the
+   police boat radar as it will be processing the location of the police boat radar from the
+   simulator.
+7. Critical Section: Assert a std::mutex to gain safe writing access to the 
+   double-buffered array driving the SSBO, copy the structural contents, and 
+   clear the mutex immediately. May I suggest that this activity be performed 
+   about once every screen update. However, the processing speed may not be
+   able to achieve this. Also bear in mind that data from the raspberry pis
+   and the simulator may not updata every screen update. If that's the case, the
+   traffic cop will not do anything.
+
+
 ===============================================================
 
 Sections still to be worked on:
 
-Details of the Traffic Cop and the PostGres database. These
-two subjects are interrelated and will be discussed later
-
 Details on the simulator will be discussed later.
 
 Details on the relationship between the simulator and the movement of the