Practical field guide
This page is the short user guide for the current Clear Path workflow.
Six-step process
Enter project information so the report carries the project name, evaluation date, evaluator, object description, and notes.
Enter the ICAO and update the airfield data to load airport/runway context when available.
Select the runway pair and the active runway end because directional surfaces are evaluated from the selected threshold context.
Enter obstacle elevations, distances, or coordinates. Manual engineering inputs remain authoritative when you need overrides.
Run the evaluation, review compact results by severity, and expand only the surfaces that need detailed calculation review.
Use the map and engineering views to confirm runway orientation, active overlays, and any violated surfaces before exporting the report.
What it means: The report label used by your team when the evaluation is exported or revisited later.
Why it matters: A clear project name helps leadership, engineering, safety, contracting, and sponsors keep report context straight.
Common bad input: Using a vague placeholder like Project 1 and then forwarding the report without renaming it.
What it means: The airport context used to load runway geometry and related criteria inputs.
Why it matters: A wrong airport can load the wrong runway pair, threshold elevations, and approach context.
Common bad input: Typing the wrong ICAO or relying on the wrong nearby airport.
What it means: The selected runway pair, such as 10/28 or 18/36.
Why it matters: Runway-specific geometry and criteria dependencies can differ across the same airport.
Common bad input: Leaving the default runway pair selected when the project applies to a different runway.
What it means: The threshold context used for directional calculations.
Why it matters: Directional surfaces and local longitudinal sign depend on the selected runway end.
Common bad input: Choosing the correct runway pair but the wrong threshold end.
What it means: The governing criteria family and profile for the project, such as Part 77 fixed-wing or FAA AC fixed-wing.
Why it matters: Different criteria families can produce different results for the same location.
Common bad input: Treating comparison mode as if it automatically identifies the legal governing authority.
What it means: The direct geographic location of the object when coordinate-based review is available.
Why it matters: Coordinates affect map placement, local runway-relative conversion, and export traceability.
Common bad input: Copying coordinates in degrees-minutes-seconds or with the wrong sign when the field expects decimal degrees.
What it means: The local ground elevation of the object site above mean sea level.
Why it matters: Clear Path uses this with object height AGL to derive object top elevation MSL.
Common bad input: Leaving the runway elevation in place instead of entering the actual site elevation.
What it means: The height of the structure above local ground level.
Why it matters: This is part of the top-elevation calculation used by the evaluator.
Common bad input: Entering an MSL top elevation value into the AGL field.
What it means: The resulting top elevation used for surface comparison, whether derived or manually overridden.
Why it matters: This is the elevation the surface logic actually compares against the allowable elevation.
Common bad input: Assuming the override field is required when a normal ground-plus-height workflow would be clearer.
What it means: Known Location for a fixed proposed object, or placement-limit mode when solving for an allowable distance.
Why it matters: The result structure and export content differ by mode.
Common bad input: Using placement-limit mode when the project already has a real object location to review.
Before sharing
Review the common pitfalls and workflow notes before sharing Clear Path with a buyer who has not seen a live walkthrough.
