E. FAA Airport Surveys

The National Geodetic Survey, in accordance with a series of interagency agreements with the Federal Aviation Administration (FAA), provides airport geodetic control, as well as runway, navigational aid, obstruction, and other aeronautical data that is critical to the operation of the National Airspace System. Most of these data are source information obtained using field survey and photogrammetric methods. These data are used to develop runway approach procedures and obstruction charts.

NGS contracts survey work for Area Navigation Approach (ANA) charts to the private sector on a funds available basis. Survey specifications are provided in AC No: 150/5300-16B(2019) and the older “FAA No. 405, Standards for Aeronautical Surveys and Related Products,” 4th edition, September, 1996; and “General Specifications for Aeronautical Surveys, Vol. I. Establishment of Geodetic Control on Airports.” Funding for these surveys is provided to NGS by the FAA. This latest version of OPUS Projects (OP) fully supports the bluebooking process for FAA surveys by producing a b-file and g-file, and automatically invokes ADJUST in the required series of network adjustments. All files required for a successful submission of an airport survey to NGS are fully supported by OP.

E.1. New PACS/SACS

When PACS/SACS are established as “New” there should be very little deviation from the recommended style of processing in OP. Observations for new PACS/SACS must meet all required observation criteria as defined in the AC 150/5300-16B to include, but not limited to:

  1. Two 4-hour or more simultaneous observation sessions are required on the PACS, HARN, and NAVD 88 bench marks involved in the survey, with a 30-60 minute break between. Observations must be simultaneous with the PACS.

  2. Two 2-hour or more observations on the SACS with a 30-60 minute break between sessions is required. Observations must be simultaneous with the PACS.

  3. The operator must reset the tripod (take down - set up) between the sessions and document the same.

  4. Start times on subsequent days must be at least 2.5 hours different from the previous start times to incorporate a different satellite geometry.

  5. If the OPUS solution report is “bad” (low % obs or low % ambiguities fixed or high overall RMS or any uncertainties > 4 cm), the mark must be reoccupied (no exceptions). OP can, on occasion, “recover” data that OPUS could not initially process as successfully as we might like, but if OPUS struggles in its initial solution, chances are significantly higher that OP will struggle as well. The initial OPUS solution is your first quality control stage: use it.

  6. Remember that OPUS will not allow less than 2 hrs of usable data.

  7. NGS recommends collecting and processing GNSS data at a 10° elevation mask.

E.2. Existing PACS/SACS

The following example provides guidance for those FAA surveys where the existing PACS is found to be in good condition at an airport, but either one or more SACS are destroyed. The existing PACS may serve as passive control to position new SACS so long as the existing PACS meets the AC 150/5300-16B Section 7.7.3 Accuracy Standards. The PACS and SACS (including both new and existing SACS) must be observed. Observation criteria is similar to a new PACS/SACS survey, except additional HARN and NAVD88 bench mark ties are not a requirement.

  1. Two 4-hour or more observation sessions on the PACS with a 30-60 minute break between sessions is required.

  2. Two 2-hour or more observations on the SACS with a 30-60 minute break between sessions is required. Observations must be simultaneous with the PACS.

  3. The operator must reset the tripod (take down - set up) between the sessions and document the same.

  4. Start times on subsequent days must be at least 2.5 hours different from the previous start times to incorporate a different satellite geometry.

  5. If the OPUS solution report is “bad” (low % obs or low % ambiguities fixed or high overall RMS or any uncertainties > 4 cm) the mark must be reoccupied (no exceptions). OP can, on occasion, “recover” data that OPUS could not initially process as successfully as we might like, but if OPUS struggles in its initial solution, chances are significantly higher that OP will struggle as well. The initial OPUS solution is your first quality control stage: use it.

  6. Remember that OPUS will not allow less than 2 hrs of usable data.

  7. NGS recommends collecting and processing GNSS data at a 10° elevation mask.

E.3. Example of Recovering an Existing PACS

PACS station PIH FAA (AA3682) was recovered and observed in 2 sessions spanning 4 hours or more. The observations were uploaded into OP.

  1. The two PACS initial OPUS solutions are compared to ensure consistency among the redundant observations (see section 7.1.4.6 of this document). The two horizontal coordinates are verified to be within 3 cm of each other. The ellipsoid heights are verified to be within 5 cm of each other. Failure to meet this requirement would mean re-observing the mark. An example is shown in Fig. E.1.

Example using INVERS3D to compare two OPUS solutions from redundant observations

Fig. E.1 Example using INVERS3D to compare two OPUS solutions from redundant observations

  1. Once the initial OPUS solutions are checked for consistency, the results can be verified with the NGS published coordinates for this station, as shown in Fig. E.2. The observed vs. published values must meet the AC 150/5300-16B requirement of 3 cm horizontal, 5 cm ellipsoid, 5 cm orthometric. If the PACS does not meet this requirement in the initial OPUS solution stage, this station may need to be redetermined in accordance with the AC 150/5300-16B, Section 7. A revised geodetic control plan will need to be submitted for review.

Example using INVERS3D to compare an initial OPUS solution to the published coordinates

Fig. E.2 Example using INVERS3D to compare an initial OPUS solution to the published coordinates

  1. Following the OPUS solution verification of the PACS, the additional observations may be uploaded into the project, as shown in Fig. E.3.

Two, same-day sessions loaded into OPUS Projects (2020-021A and 2020-021B)

Fig. E.3 Two, same-day sessions loaded into OPUS Projects (2020-021A and 2020-021B)

  1. Review Project Preferences as described in Section 4 of this User Guide. Do not edit or modify the Data and Solution Quality Thresholds.

  2. Add the NGS-Assigned Tracking ID

  1. Following the approval of the Geodetic Control Plan (GCP), NGS will assign a Project Tracking ID. This number will be at the header of the NGS review.

  2. Use the assigned Project Tracking ID as described in Section 7.1.4.5 of this document to enter into the appropriate field. Complete all other necessary information in this window.

  1. Upload Description files (*.dsc, *.des, *.err, *.dis, *.nbr) for all marks searched for or recovered during this survey. This operation will associate published and non-published marks with the observed marks.

  2. Upload Field Logs as described in section 7.1.4.9.

  1. GNSS Observation Logs

  2. Station Location Sketch and Visibility Diagrams

  3. Recovery Logs (Optional)

  1. Add mark photos (Close-up, Eye-level, and Horizon View) as described in Section 7.3, Individual Mark Web Pages (7.3.7). Ensure proper captions and filenames are applied prior to upload.

  2. Confirm the information for the mark occupations (Data File, Span, Antenna/Receiver Hardware, Antenna/Receiver Serial Number, ARP Height, and Receiver Firmware version) as described in section 7.3. This information must match the GNSS Observation Logs.

  3. Evaluate and select CORSs to be used in the project as described in Section 8.

  4. Add a distant CORS to de-correlate the tropospheric parameters as described in section 8.2.2.

  5. Remove any unused CORS(s) to reduce clutter.

  6. Perform the first session processing as described in Section 10 and evaluate results. Carefully review the a priori shifts of all stations given in the Processing Report (*.txt, as shown in Fig. E.4). Keep in mind the a priori coordinates can vary from a mark with a published PID (eg. existing PACS) or an OPUS solution for a mark with an unpublished PID (eg. new SACS being established).

Coordinate shifts between a priori estimates and OP session processing for session 2020-021-A

Fig. E.4 Coordinate shifts between a priori estimates and OP session processing for session 2020-021-A

  1. Once results are acceptable for the first session, perform session processing on the next sequential session and evaluate results.

  2. Once two sessions have been processed, evaluate the peak-to-peak errors from the Solution Statistics selection in the pull-down menu above the “Marks and Sessions” table, as shown in Fig. E.5 (section 11.5.5). Ensure that no user marks have errors that exceed 1 cm for North or East and 3 cm for UP as required by the AC-16B (Section 7.7.4.3)

Solution Statistics for all sessions

Fig. E.5 Solution Statistics for all sessions

If P2P errors exceed these values, common causes that should be investigated can include:

  1. Incorrect ARP height calculated/entered (height error).

  2. Incorrect antenna type selected (horizontal and/or vertical error).

  3. Tripod out of calibration (horizontal and/or vertical error).

  4. Improper tripod equipment (horizontal and/or vertical error).

  5. Insufficient dataset

  6. Limited CORS availability

  1. Process additional sessions if there are any and evaluate results.

  2. Set up Adjustment

  1. Run the preliminary network adjustment as described in Section 11 with a single CORS HUB as the 3D constraint and evaluate solution quality. Using the Processing Report (*.txt, as shoen in Fig. E.6), verify a priori coordinate shift for the PACS still the accuracy requirement of 3 cm Horizontal, 5 cm Ellipsoid. For those marks with PIDs, this will be the initial Minimally Constrained Adjusted vs. Published comparison using GPSCOM.

Coordinate shifts between a priori estimates and minimally constrained preliminary network adjustment

Fig. E.6 Coordinate shifts between a priori estimates and minimally constrained preliminary network adjustment

  1. Set up Adjustment to run the Horizontal Free as described in Section 12.7.2 and shown in Fig. E.7. Hold the HUB CORS as the only 3D constraint. Ensure all other marks and CORSs are not constrained.

Setting up the Horizontal Free network adjustment

Fig. E.7 Setting up the Horizontal Free network adjustment

Evaluate solution quality, as shown in Fig. E.8. The a priori shifts of the CORSs may be a bit higher in this solution due to holding the CORS HUB as the only constraint. You may notice that the N E H shifts (North, East, and Ellipsoid Height) are closely related to the N E H Free vs. Published inverse output for the PACS in the solution above.

Coordinate shifts between horizontal free and preliminary network adjustments

Fig. E.8 Coordinate shifts between horizontal free and preliminary network adjustments

  1. Set up Adjustment to run Horizontal Constrained as described in Section 12.3. In this case, FAA PIH A, PIH N and all CORSs are selected as 3D Constraints. DO NOT modify any of these a priori coordinates. This is a good time to check coordinate constraints vs. the published datasheets. In all cases, remove the distant CORS as a constraint. Constrain all other CORSs in 3D, shown in Fig. E.9.

Setting up the horizontal constrained network adjustment

Fig. E.9 Setting up the horizontal constrained network adjustment

Evaluate the results of the Constrained Adjustment starting with the F-test as described in section 12.7.3.2 and shown in Fig. E.10. A failed F-Test will likely result in an unsuccessful project submission. Evaluate the mark estimated - horizontal-free adjustment coordinate shifts, mark estimated - published horizontal coordinate shifts, and residuals (see Fig. E.11, Fig. E.12, and Fig. E.13).

Output from the Processing Report of the Horizontal Constrained network adjustment showing the result of the F-test

Fig. E.10 Output from the Processing Report of the Horizontal Constrained network adjustment showing the result of the F-test

Shifts between Horizontal Constrained and Horizontal Free adjusted coordinates

Fig. E.11 Shifts between Horizontal Constrained and Horizontal Free adjusted coordinates

Shifts between the Horizontal Constrained adjusted and Published coordinates

Fig. E.12 Shifts between the Horizontal Constrained adjusted and Published coordinates

Output from Preplt2 showing the residuals from the Horizontal Constrained adjustment

Fig. E.13 Output from Preplt2 showing the residuals from the Horizontal Constrained adjustment

  1. Set up Adjustment to perform a Vertical Free as described in Section 12.4. Constrain the PACS only in Vertical, constrain the HUB CORS in HOR-only, as shown in Fig. E.14. Do not modify any of these a priori coordinates. This is a good time to check coordinate constraints vs. published.

Setting up the Vertical Free network adjustment

Fig. E.14 Setting up the Vertical Free network adjustment

Evaluate output. The a priori coordinate shifts, as shown in Fig. E.15, may appear higher than normal due to holding only a single passive control mark as the vertical constraint.

Shifts between the Horizontal Constrained and Vertical Free coordinates

Fig. E.15 Shifts between the Horizontal Constrained and Vertical Free coordinates

  1. Set up Adjustment to perform a Vertical Constrained as discussed in Section 12.5. Constrain the PACS vertical and in cases where the existing SACS meet all Horizontal, Ellipsoid and Vertical requirements, constrain the Vertical as well. Constrain the HUB CORS in 2D only. This is illustrated in Fig. E.16.

Setting up the Vertical Constrained network adjustment

Fig. E.16 Setting up the Vertical Constrained network adjustment

  1. Evaluate output. Take note if the adjustment passed the F-Test, as shown in Fig. E.17. Evaluate mark estimated - vertical free adjustment coordinate shifts, mark estimated - published vertical coordinate shifts, and residuals (see Fig. E.18 and Fig. E.19).

Processing Report (\*.txt) from Vertical Constrained network adjustment highlighting the result of the F-test

Fig. E.17 Processing Report (*.txt) from Vertical Constrained network adjustment highlighting the result of the F-test

Shifts between Vertical Free and Vertical Constrained adjusted coordinates

Fig. E.18 Shifts between Vertical Free and Vertical Constrained adjusted coordinates

Shifts between Vertical Constrained and published orthometric heights

Fig. E.19 Shifts between Vertical Constrained and published orthometric heights

In this case, BREW is the distant CORS and was unconstrained in the adjustment. The output for this CORS may be ignored.

  1. Follow OP guidance to Review and Submit to NGS as described in Section 12.7.6. Additional notification on the FAA Airports GIS portal as well as supplemental documents, including the OPUS Projects ID, NGS Tracking ID and date submitted will be required.