QA_1305M226Q0125_0001.pdf

Q&A 1305M226Q0125

1. What is the Esri end user customer or account number?

a. There is no mention of ESRI in the PWS.

2. The PWS identifies an "Option Task - Updating the LASER engine to the latest Eigen libraries."

Should offerors price this option task separately from CLIN 0001, or should it be included in the single firm-fixed-price quote for CLIN 0001?

a. Pricing should be within the format provided. Thus, it should be included in the 1 FFP

CLIN.

3. The PWS includes Task 1, Task 2, Task 3, and the option task. Does NOAA intend to award all listed tasks under this RFQ within the one-year period of performance, or may NOAA award/exercise tasks in phases based on available funding and priority?

a. This is a FFP order with 1 CLIN. The full requirement should be captured in the 1 CLIN for the POP stated.

4. For Task 3, the PWS notes that contractor testing of the antenna calibration data collection system will be limited without access to NGS equipment. What level of contractor-side testing is expected before NGS conducts in-environment validation?

a. There is no expectation from NGS to be able to test the “Automated data collection” (deliverable 3.4, page 17) because NGS cannot provide access to its hardware.

NGS does expect the ability to test the “Pre-process data”, where NGS will provide example input and output for deliverable 3.5 (Page 17)

The expectation is developing a Graphical User Interface (GUI) calling a code that runs the GNSS antenna calibration testing.

5. For technical acceptability, is prior geodetic/GNSS software past performance required, or may an offeror demonstrate technical acceptability through relevant numerical/scientific software capability, C++/Python experience, and a detailed domain onboarding and validation plan?

a. Yes, it is important to have a basic understanding of geodetic/GNSS software. There is a learning curve under the geodetic algorithms and the way they are computed.

Based on past experience with companies, NGS cannot support contractors that have a gap in knowledge about basic geodetic processes. Any company applying to this contract needs to understand the tasks.

6. Is subcontracting or teaming with a geodesy/GNSS/numerical-methods specialist acceptable for portions of the requirement, provided the prime manages delivery and performs the required prime share of work?

a. Yes, it is acceptable to subcontract or team up with a geodesy/GNSS/numerical-methods specialist

7. Given that the new program must parse GDX and STARNET data files, which, if any, of the nine files listed in section 4.3.1 need to be supported in the new program? This question pertains specifically to file types HDS, DES, INST.PAR, TRA, DAT, LVL, HGZ, Inst.dat, Rods.dat.

a. None of the formats outlined in section 4.3.1 needs to be supported in the new program.

When validating results, NGS will be using their code formats

8. Does NGS want the C++ GDX and STARNET parsing routines already developed as part of the previous LASER work to be rewritten in Python, or would it be sufficient for the new Python code to simply call those C++ routines (we acknowledge that the C++ STARNET parser will need to be extended somewhat, depending on answers to questions 4-6 below)?

a. Yes, it is acceptable to use Python code to call C++ routines that already exist in LASER.

9. Will the GDX format be finalized by NGS before the start of this contract? If not, when will it be finalized?

a. A final draft of GDX is expected in September, 2026.

10. As NGS is aware, LASER already includes programs for baseline calibration adjustments and leveling network adjustments. Neither of these programs use any of the following observation types: GNSS vectors, horizontal angles, horizontal directions, slant distances, zenith angles, elevation angles, "traverse observations." Can NGS specify which of these observation types must be included in each of the two respective programs?

a. None of these observation types are required for baseline calibration adjustments.

Instead, these observation types are needed to be read from an input file for reduction, correction, and preparation for a 3-D geometric adjustment that exists in the LASER engine. See response to question 12 for how to add vertical angles and slant distances to leveling adjustments.

In Task 2, the observations mentioned above shall be ingested using the GDX file format into the software.

11. As a follow up to the previous question, if anything other than slant distances and vertical angles reduced to the horizontal plane using equations from plane surveying need to be added to the calibration baseline adjustment, can NGS explain how they would be used in that adjustment?

a. See response to the previous question. No additional observation types are needed to be added to the calibration baseline adjustment.

12. As a follow up to question 4, if anything other than vertical angles and slant distances (e.g., as trigonometric leveling observations) need to be added to the leveling network adjustment can NGS explain how they would be used in that adjustment? If zenith angles and slant distances must be added, should they be transformed to orthometric height differences using rigorous geodetic computations (which would require knowledge of latitude, longitude, and geoid undulation for the points involved)?

a. Only vertical angles and slant distances are needed.

Task 2 is focused on using CBL and differential leveling observations. The task shall be able to handle River Crossing situations that incorporate trigonometric leveling, which requires transformation to orthometric height differences using geodetic computations NGS will provide these computations

With that said, there is an expectation that the code will include the calibration base line (in CALIBRATE) to estimate unknown systematic errors between an EDM instrument and a specific type of reflector. The systematic errors are of two types: an offset (or bias) and a distance-dependent scale factor. These terms are estimated from distance measurements made between a number of points arrayed along a line at known distances. This is mentioned in the PWS under Task 2 (Section 4.1).

13. Regarding task 3: "Updating Antcal source codes absolute and relative source codes to Python":

The example interface program in Appendix B shows GPS, Galileo, and GLONASS constellations. Is BeiDou also supported?

a. The contractor is not expected to include BeiDou support.

Does new Python code need to be written that communicates directly with GNSS receivers from various manufacturers? If so, does it need to issue commands to the receivers that set items such as their tracking loops, types of observations to log, constellations to track, logging rates, mask angle, etc.?

a. The code shall communicate only with Septentrio receivers using Septentrio Receiver Command Language (Section 5.2.1). NGS will provide SBF language documentation in addition to the simple commands already used in the Perl software.