Skip to content
LOS Analyzer

LOS Analyzer Methodology

Last updated: 2026-05-09

Purpose & Scope

The LOS Analyzer provides preliminary line-of-sight screening only — a fast, visual way for developers and property owners to assess whether a proposed structure near an airport might interfere with control tower sightlines. It is not a substitute for licensed engineering review or FAA regulatory submission.

This tool is designed as an early-stage feasibility check to help decide whether filing an FAA Form 7460-1 (Notice of Proposed Construction or Alteration) is necessary and worth the time investment. All results must be validated by a licensed professional engineer before use in formal submissions, building permits, final design decisions, or any life-safety evaluation.


Data Sources

The analysis combines automated data sources and user-supplied inputs:

Automated sources:

  • Google Static Maps — high-resolution satellite imagery of the airport, used to render the map overlay and measure distances.
  • Google Geocoding API — airport name-to-coordinates lookup for search functionality.
  • Seeded tower database — approximate tower position and cab height for the top 100 US airports, sourced from FAA Airport Diagrams. Important: These positions are approximate and must be verified against current FAA official airport plans (see server/src/data/towers.ts in the repository — each entry includes an accuracy note flagging which entries are best-effort).

User-supplied inputs (the critical path):

  • Control tower position and height — can be auto-populated from the seed database (which covers major US airports) or manually placed on the map and overridden. Height is in feet above ground level (AGL); Phase 1 defaults to 50 ft if not known.
  • Building corners — extracted from uploaded PDF/PNG/JPEG documents via 4-tier regex pattern matching plus Tesseract OCR fallback (see below). Users can manually edit extracted coordinates.
  • Building height above ground — user enters in feet. The tool treats the building as a rectangular prism from grade level to this height.
  • Runway endpoints — clicked on the map or entered as lat/lng coordinates. Defines the sightline that must be protected.

Coordinate extraction pipeline: When a user uploads a PDF or image, the server applies four regex patterns in order of specificity:

  1. Signed decimal degrees — e.g., 37.6213, -122.3790
  2. DMS with leading hemisphere — e.g., N37°37'17.0" W122°22'44.4"
  3. DMS with trailing hemisphere — e.g., 37°37'17.0"N 122°22'44.4"W
  4. Bare DMS — e.g., 40°11'58.308, 76°46'17.6844" (assumes N lat, detects western hemisphere by sign or magnitude)

If regex fails, Tesseract OCR is run on the image. Important: All extracted coordinates are best-effort and must be manually verified by the user.


Geometry — Flat-Earth Projection

The side-profile elevation chart uses a flat-earth assumption accurate for airport-scale distances (under ~5–10 miles).

When rendering the side profile for a tower looking toward a runway end, the tool:

  1. Calculates the bearing from tower to runway using Turf.js bearing().
  2. Projects building corners onto this bearing axis via a simple 2D dot-product calculation:
    • Converts lat/lng deltas to meters (using 111,320 m/° at the tower’s latitude).
    • Takes the bearing’s unit vector and projects each corner along it.
    • Returns the minimum and maximum projections — the “near” and “far” edges of the building’s footprint as seen along the sightline.
  3. Renders the profile with the building as a rectangular silhouette at these distances and the user-supplied height.

This projection is implemented in buildingExtentAlongBearing() in client/src/components/SideProfileView.tsx. For great-circle distances under ~5 miles, the error is <1%; beyond 10 miles, earth curvature and great-circle deviation become significant (Phase 2 improvement).


Ray Sampling

The map overlay casts N rays per tower at stepDeg angular spacing (default 1°, configurable), covering 360° around the tower. Each ray is 10 km long.

Blockage detection:

  • Each ray is a line from tower center to a far point 10 km away at the specified bearing.
  • Using Turf.js lineIntersect(), the ray is tested against the building polygon.
  • If the ray intersects the polygon:
    • First intersection point = ray enters the building (near face).
    • Last intersection point = ray exits the building (far face).
    • The ray is marked blocked.

Shadow extension:

  • For blocked rays, a “shadow” segment is drawn from the ray’s exit point (far face) to the ray’s full 10 km endpoint. This visualizes the region behind the building that is hidden from the tower’s view.
  • The side profile uses the blocked status to determine final LOS determination.

Note: This is a 2D plan-view analysis — rays are cast at ground level and ignore terrain elevation and atmospheric refraction. Phase 2 will add 3D terrain awareness.


Side-Profile Calculation

For each tower, a per-tower elevation profile is computed:

  1. Tower-eye height — the tower’s cab elevation (AGL).

  2. Building extent along bearing — the minimum and maximum distances (in feet) of the building footprint along the tower→runway line (computed via flat-earth projection as described above).

  3. Line-of-sight angle from tower eye to runway end (ground) — computed as:

    angleToRunway = arctan((runway_height - tower_eye_height) / horizontal_distance)

    Since the runway is at ground level (height = 0) and the tower eye is above ground, this angle is negative (downward).

  4. Building-top angle — computed as:

    angleToBuildingTop = arctan((building_height - tower_eye_height) / distance_to_far_face)
  5. Blockage determination — the building blocks the LOS if:

    building_height > (tower_eye_height + tan(angleToRunway) * distance_to_building_far_face)

    In plain English: if the building is taller than the LOS line at the building’s far face, the view is obstructed.

The side profile is rendered in SVG with grid lines, building silhouette, tower column, LOS line, and runway endpoints, implemented in client/src/components/SideProfileView.tsx.


Known Limits & Assumptions

Phase 1 is deliberately simplified. Be aware:

  • No terrain modeling — the analysis assumes flat ground everywhere. Real terrain (hills, valleys) can block or allow views the tool misses. (Phase 2 fix: USGS 3DEP elevation data integration.)
  • No earth curvature — the flat-earth projection breaks down beyond ~5–10 miles. For very large airports or distant structures, curvature becomes significant.
  • No atmospheric refraction — temperature inversions and pressure gradients bend light paths, allowing sightlines over apparent obstacles in some conditions. The tool assumes a straight line.
  • No obstacle lighting analysis — FAA also requires lighting assessment for obstacles; the tool only evaluates sightline blockage.
  • Tower-cab elevations not in seed database — most US airports’ tower-cab heights are not publicly documented. The tool defaults to 50 ft AGL unless manually overridden or the tower position is known to be from our seed DB (see accuracy notes in server/src/data/towers.ts).
  • All inputs are user-supplied — garbage in, garbage out. Incorrect tower position, building height, or runway endpoints will produce incorrect results.
  • Coordinate extraction is best-effort — regex and OCR are reliable but not foolproof. Users must verify extracted lat/lng coordinates match the original document.
  • No building complexity — the tool models only a rectangular building footprint. Real structures (setbacks, towers, antenna mounts) are ignored.

Comparison to FAA Processes

The FAA has formal procedures separate from this tool:

ProcessPurposeWhat It Does
FAA Form 7460-1Notice of Proposed ConstructionDeveloper files a notice 45+ days before construction starts.
FAA OE/AAA Aeronautical StudyFormal FAA reviewFAA evaluates the proposed structure against Part 77 surfaces, issues a formal determination (likely no hazard / conditional no hazard / hazard).
FAR Part 77 SurfacesImaginary airspace boundariesFAA has defined 5 invisible surfaces (primary, horizontal, conical, approach, transitional) around each runway. Structures penetrating these surfaces are hazardous per regulation.
ATCT Line-of-Sight AnalysisATC visibilityFor part-time tower facilities, FAA checks if the proposed structure blocks the controller’s view of critical runway portions and approach corridors.
Obstacle Lighting & MarkingNighttime / low-vis safetyIf a structure is determined a hazard, FAA mandates lighting and/or paint schemes.

Our tool is a pre-screen before the Form 7460-1 filing. It helps you decide: “Is there even a sightline issue here worth mentioning in the filing?” If your analysis shows clear LOS, you have evidence to support a shorter, simpler 7460-1. If it shows blockage, you can refine the design before filing or prepare for FAA’s likely objection.

The tool never replaces the FAA’s official determination or the judgment of a licensed professional engineer.


References & Further Reading

  • FAR Part 77 — Subpart C defines the 5 imaginary surfaces and Part 77 obligations. Available at eCFR.
  • FAA Order JO 7400.2 — Procedures for Handling Airspace Matters. The formal guide for 7460-1 processing. Available at FAA.gov.
  • FAA AC 150/5300-13B — Airport Design standards, includes Tower Construction Standards and visibility requirements.
  • FAA Form 7460-1 Instructions — Step-by-step guide to filing a Notice of Proposed Construction. Available from the FAA’s OE/AAA portal at faaportal.faa.gov.
  • FAA ATCT Master Plan PDFs — Individual airport facility documents with tower position, cab elevation, and visibility diagrams (contact local FSDO for access).

Questions? Contact our technical team or consult the app’s embedded disclaimer. All results are preliminary and subject to professional engineering review.