Geodesy, GNSS and Survey Data Processing

Gains:

• Ability to edit and quality control GNSS raw observations, RINEX files and point coordinates with AI-powered workflows
• Ability to convert free text measurement notes, reference and triangulation records into standard tables and reports
• Ability to verify AI-generated position and accuracy interpretations with static/RTK measurement principles and occlusion errors

Geodesy is the science of determining the shape and size of the earth's surface and the location of points on it with high accuracy. The main tool of this science today is GNSS. GNSS (Global Navigation Satellite System / Global Satellite Positioning System) is the common name of satellite constellations such as GPS, GLONASS, Galileo, BeiDou; Receivers calculate position by measuring the arrival time of signals from these satellites. In this unit, we discuss where artificial intelligence works safely and where the line is drawn on the path from the scattered state of GNSS and classical surveying (total station, leveling) data to regular, verified coordinates. The principle is immutable: AI organizes the data and flags inconsistency; The engineer gives the final acceptance of the coordinate through measurement principles.

Let's clarify a few basic terms first. RINEX (Receiver Independent Exchange Format) is a text file standard that stores raw GNSS observations of different brands of receivers in a common format. Static measurement is the method in which the receiver remains fixed on a point for a long time (minutes-hours) and produces high accuracy. RTK (Real Time Kinematic) is a method that instantly gives centimeter accuracy with correction from a reference station. Closure error is the difference that accumulates when returning to the starting point of a closed measurement route (polygon or level) and is theoretically expected to be zero; It is the most concrete indicator of the quality of the measurement.

Where Does AI Safely Come Into Action?

The most reliable contribution of AI to GNSS and survey data processing is not the position calculation itself, but the regulation and control work around that calculation:

1. Raw data and note editing. The free text notes in the field notebook, point names, instrument heights, and observation conditions are often scattered. AI breaks these down into standard tables.
2. Quality control screening. It lists inconsistencies such as points whose receiver altitude was never entered, points measured twice with the same name, unreasonable fix times, out-of-order coordinates, etc.
3. Report production. It converts the summary of the measurement campaign, the method used, and metrics such as number of satellites/PDOP into a readable text. (PDOP: Position Dilution of Precision; is a number that is desired to be small and shows the effect of the geometry of the satellites in the sky on the position accuracy.)

However, it is not and should not be AI's job to: declare a coordinate "exactly correct" without considering the occlusion error, ignore the measurement principles and confirm the application value, replace balancing (the process of distributing the measurement excess to the statistically best position). Balancing and final acceptance remain under the control of the relevant software and engineer.

Hint: Ask the AI ​​"is this coordinate correct?" It is the wrong question to ask. The right question is "what inconsistencies and out-of-order values ​​are in this data set?" with "is this closure error reasonable for the given accuracy class?" are the questions.

Step by Step: Turning the Field Measurement Book into Processable Data

1. You define the schema first. Columns: point_no, type (triangulation/polygon/detail), right_y, up_x, elevation_h, tool_load, method (static/RTK), satellite_number, pdop, date, note. Impose the schema on the model so that the output is consistent.
2. Fix the unit and datum. Write down in which CRS the coordinates are (for example, TUREF/TM) and in which vertical datum the elevation is (for example, Türkiye National Vertical Control Network).
3. Process small batch. Give in batches of 20-30 points; You catch the mistake early.
4. Get a QC scan. The model should collect problems such as missing instrument height, duplicate point name, high PDOP observation etc. in a separate "warning" list.
5. Return to the source. Compare random rows of the resulting table with the raw annotation; especially the coordinate order and point names.

Three Mini Cases: By the Numbers

Case 1 — Repetitive point capture. A detail retrieval campaign measured 1,240 points. AI-assisted QC scanning flagged that 3 point names were used twice (with different coordinates) and tool height was not entered at 7 points. If these 10 issues were reviewed manually, it would take hours; Because it was caught early, erroneous data did not leak into map production.

Case 2 — PDOP warning. In one RTK campaign, 15 points were measured in conditions with a PDOP value above 6 (bad satellite geometry). The model marked these points as "high uncertainty"; The engineer had them remeasured and was found to be off by a few centimeters at two points. The AI ​​didn't make decisions, it just drew attention to risky observations.

Case 3 — Closing error comment. On a range route, the AI ​​described the closure error as "acceptable" when preparing its campaign report. The engineer checked the allowable limit according to the route length and accuracy class by hand calculation; The error was just below the limit, but very close to the limit. To be on the safe side, the engineer had one leg remeasured. Lesson: AI saying "acceptable" is no substitute for a hand-calculated check of the standard.

Weak Prompt / Strong Prompt

Weak prompt:

Edit these measurement notes and tell me if it is correct.[notes]

Powerful prompt:

Your role: measurement data QC assistant. Translate the field notes below into the provided DIAGRAM and produce a SEPARATE "warning list". JUDGING about the accuracy of the coordinate; just mark inconsistency and out-of-order values.Scheme: point_no | type | sag_y | up_x | kot_h | tool_load | method |satellite_count | pdop | date | date noteContext: CRS = TUREF/TM30 (EPSG:5254). sag_y ~6 digit meter expected. Warning rules: missing tool_yuk; repeating point_no; pdop>6; out-of-order coordinate; empty required field.Notes: [field notes]

The strong prompt prohibits judgment, concretizes the rules of the QC, and gives context to the rank expectation; The output becomes auditable.

Four Copiable Templates

1) Raw grade standardization:

Translate the following field note into standard terminology, unpacking abbreviations (e.g. "al.y."->"tool height"), but DO NOT change numerical values. Mark vague expressions with "[vague]". Note: [field note]

2) GNSS QC scanning:

List the quality problems in the GNSS observation table below: low number of satellites, high PDOP, short observation time, float (non-fixed) solution, out-of-order coordinate. For each line, write the type of problem and the recommended action. Don't decide, just mark. Table: [observation table]

3) Preliminary evaluation of shutdown error:

For the following polygon/levelling closure data: (a) calculate the closure error, (b) remind the allowable limit of the given accuracy class, (c) comment on the closeness to the limit and add a note "confirmation by hand calculation required". DO NOT make final acceptance decision. Data: [route data]

4) Measurement campaign report draft:

Write a draft measurement campaign report using the following metrics: method, number of points, average number of satellites, average PDOP, occlusion errors, CRS used, and vertical datum. Using definite statements about accuracy; Add note "subject to engineer approval". Metrics: [metrics]

Comparison of Accuracy Terms

term

Meaning

Importance in geomatics

Static measurement

Long-term constant observation

Triangulation, high accuracy basis

RTK

Instant correction from reference

Fast, centimeter detail acquisition

PDOP

Satellite geometry quality

Smaller value = more reliable location

Fix/Float

Ambiguity resolved / not resolved

Float solutions are not accepted for detail purchase.

shutdown error

Difference accumulated on closed route

Concrete proof of measurement quality

Common mistakes

• Making the AI judge the accuracy of the coordinate. AI signs inconsistency; Accuracy is determined by measurement principles and balancing.
• Float solutions are thought to be fixes. Using the unresolved RTK observation as an exact coordinate.
• Ignoring PDOP and the number of satellites. Full confidence in the measured point in poor geometry.
• Mixing vertical datum with horizontal datum. Level and coordinate sit on different references; It would be a mistake to substitute one for the other.
• Relying on the AI's judgment of "acceptable" without confirming the shutdown error by hand calculation.
• Uploading raw data to the cloud model without anonymizing it. In some projects, point locations belong to sensitive facilities.

In summary

Safe space of AI in GNSS and survey data processing; organizing raw data, scanning for inconsistencies and producing draft reports. The accuracy of the position calculation and final acceptance remain with the engineer, with measurement principles such as PDOP/fix status, closing errors and balancing. Ask the AI ​​“right?” but "what inconsistencies are there?" ask; Always confirm critical assumptions, such as closing error, by hand calculation against the standard.

Application task

Write a QC prompt for your (or hypothetical) 20-line GNSS observation table: include the schema, CRS context, rank expectation, and at least five warning rules (missing instrument height, repeating point, high PDOP, float solution, out-of-order coordinate). Then verify the first three items of the warning list in the AI ​​output against the raw data.

checklist

• [ ] I defined the scheme and the CRS/vertical datum context from scratch.
• [ ] I asked the AI ​​for inconsistency screening, not judgment.
• [ ] I instantiated the warning rules (PDOP, fix/float, rank, missing field).
• [ ] I separated float solutions and high PDOP observations.
• [ ] I checked that I did not mix the horizontal and vertical datum.
• [ ] I confirmed the closing error by hand calculation against the standard.
• [ ] I have anonymized/processed sensitive point data in a certified environment.
• [ ] I kept the final coordinate acceptance the responsibility of the engineer.