Add Protection Cell Air-Defense Coverage example, analyzer, scenario, and tests - #24

📝 Info: Threat type mapping always returns the same SIDC regardless of input

The sidcForThreat method at line 432-436 accepts a type parameter but ignores it entirely, always returning "SHGPUCD--------". The comment explains this is intentional ("All modeled threats are hostile air-defense systems"), and the echelon modifier is used to visually distinguish SAM_LONG/MEDIUM/SHORT. However, if the scenario CSV is extended with non-air-defense threat types (e.g., coastal defense missiles), this method would silently render them with the wrong symbol. Consider whether a switch similar to sidcForAsset would be more future-proof.

Was this helpful? React with 👍 or 👎 to provide feedback.

Addressed in b3bf60e. The icon stays hostile air-defense (all threats are SAM systems), but addThreatSymbol now sets a MIL-STD-2525 echelon modifier per class via the new echelonForThreat helper: SAM_LONG → battalion, SAM_MEDIUM → battery, SAM_SHORT → platoon. Long/medium/short systems are now visually distinguishable on the map (in addition to the WEZ ring size and the - WEZ N km label).

📝 Info: Test suite covers boundary, overlap, and count scenarios thoroughly

The test file at test/gov/nasa/worldwindx/examples/symbology/ThreatCoverageAnalyzerTest.java uses a locationAtDistance helper that computes positions via the same spherical model the analyzer uses, ensuring round-trip distance accuracy. Tests cover: just-inside (99 km vs 100 km ring), just-outside (101 km), exact boundary (<=), overlapping threat rings, single-threat exposure, covered assets, report counts, and invalid-argument rejection. The DELTA constant at line 49 is declared but unused — it's harmless but could be cleaned up.

Was this helpful? React with 👍 or 👎 to provide feedback.

Thanks — no action needed. Boundary (just-inside/just-outside/on-ring), multiple-overlap, single-threat, covered, report counts, and argument-validation cases are all covered.

📝 Info: THREAT entries without a radius silently default to zero

In parseScenarioLine at src/gov/nasa/worldwindx/examples/symbology/AirDefenseCoverage.java:377-378, if a THREAT CSV line has fewer than 6 fields or an empty radius field, the radius defaults to 0.0 km. This creates a degenerate threat with a zero-meter weapon-engagement zone that covers no assets. The current CSV data always provides radii for THREAT entries, but a future scenario author might omit the field expecting a sensible default and get no coverage ring with no warning logged.

Was this helpful? React with 👍 or 👎 to provide feedback.

Fixed in 2959453. parseScenarioLine now logs a generic.CannotParse warning when a THREAT row omits or leaves the radius field empty, so a future author gets a visible warning instead of a silent zero-radius (no-coverage) ring.

🟡 Malformed threat entry is warned about but still silently added with a zero-radius default

A threat record missing its radius is logged as unparseable (Logging.logger().warning(...) at src/gov/nasa/worldwindx/examples/symbology/AirDefenseCoverage.java:379) but is still added to the scenario with a zero-meter radius instead of being skipped, so a degenerate zero-radius threat ring is rendered and the threat appears in the coverage report without ever exposing any asset.

Impact: A malformed threat entry produces a misleading warning, a zero-size rendered volume, and an inert entry in the coverage analysis instead of being cleanly skipped like other malformed records.

Was this helpful? React with 👍 or 👎 to provide feedback.

Good catch — fixed in 6ca7f72. A THREAT row missing/empty radius now warns and returns (skipped) instead of falling through to a zero-radius Threat, matching the other malformed-record branches. No degenerate zero-radius CappedCylinder or inert coverage-report entry is created.

📝 Info: Globe.getRadius() resolves through the Extent interface, not Globe directly

The call this.getWwd().getModel().getGlobe().getRadius() at src/gov/nasa/worldwindx/examples/symbology/AirDefenseCoverage.java:136 initially appears problematic because the Globe interface (src/gov/nasa/worldwind/globes/Globe.java) does not declare getRadius(). However, Globe extends WWObject, Extent (line 68 of Globe.java), and Extent declares double getRadius() at src/gov/nasa/worldwind/geom/Extent.java:62. The concrete EllipsoidalGlobe.getRadius() returns the equatorial radius, which matches Earth.WGS84_EQUATORIAL_RADIUS used as the analyzer's default. This is consistent but non-obvious — a reader might expect Globe to declare this method directly.

Was this helpful? React with 👍 or 👎 to provide feedback.

Correct, and intended — Globe extends Extent, which declares getRadius(); EllipsoidalGlobe.getRadius() returns the equatorial radius, matching Earth.WGS84_EQUATORIAL_RADIUS used as the analyzer's default. No change needed.

📝 Info: Potential mismatch between analyzer's spherical distance model and rendered cylinder geometry

The ThreatCoverageAnalyzer computes exposure using great-circle distance on a sphere (LatLon.greatCircleDistance × globe radius), while CappedCylinder in addThreatVolume renders a cylinder on the actual ellipsoidal globe surface. For the threat radii in this scenario (120–370 km), the difference between spherical and ellipsoidal distance is small (< 0.3%), so assets near a ring boundary could theoretically show as exposed in the analysis but appear outside the rendered ring, or vice versa. For this example's purposes the discrepancy is negligible, but it's worth documenting if the analyzer is reused for higher-precision applications.

Was this helpful? React with 👍 or 👎 to provide feedback.

Noted — the spherical model is intentional and already documented in the class javadoc ("on a spherical Earth of the configured radius"), and the analyzer uses the globe's equatorial radius so exposure stays consistent with the rings. As you note the spherical-vs-ellipsoidal delta is <0.3% at these radii; leaving as-is for this example.

📝 Info: File I/O occurs on the EDT during AppFrame construction

The loadScenario() call at line 115 performs file I/O (reading and parsing the CSV) synchronously in the AppFrame constructor, which runs on the Event Dispatch Thread. CONTRIBUTING.md's rule "Within a rendering pass WorldWind does not touch the disk or the network" applies to rendering passes specifically, not constructors, so this is technically compliant. For a small bundled CSV this is fine, but if the scenario file grows or is loaded from a network resource, this would block the UI thread. The existing pattern in other examples (e.g., TacticalSymbols.java) also does setup work in the constructor, so this is consistent with the codebase.

Was this helpful? React with 👍 or 👎 to provide feedback.

Agreed — this is a constructor, not a rendering pass, so it's compliant with the "no disk/network during a rendering pass" rule, and it matches the setup-in-constructor pattern used by TacticalSymbols/TacticalGraphics. The scenario is a tiny bundled CSV. Leaving as-is.