A traceable workflow for reviewing GNSS outliers
An unusual GNSS result should trigger investigation and a recorded decision, rather than an automatic deletion from the dataset.
Define an exception before opening the final dataset
An outlier is an observation that appears inconsistent with the expected behavior of a dataset or model. In GNSS work, that can mean an unusual repeated coordinate, a large check discrepancy, a problematic baseline residual or an improbable height. These are useful warning signs, but they do not all have the same cause. Establish which indicators trigger review and which acceptance criteria apply before deciding how to treat individual observations.
Keep detection separate from disposition. A statistical flag identifies a candidate for investigation; it does not establish that the observation is wrong. The flagged value may represent a real feature, a changed monument or a problem in the supposedly trusted reference. A traceable workflow preserves the original data, gathers relevant evidence, records a decision and identifies whether the delivered coordinates changed as a result.
Continue learning Repeat observations: creating a stronger GNSS check
Preserve the original evidence
Create a review copy of the project and protect the original field files from accidental overwrite. Assign each exception a stable identifier linked to point names, timestamps, raw observations and relevant photographs. Retain the exact coordinate system and configuration used when the discrepancy was first observed. If later processing changes the values, reviewers still need to reconstruct the original comparison and understand why it triggered concern.
Record enough context to avoid investigating a rounded export in isolation. Useful evidence can include solution state, correction source, antenna height, occupation duration, receiver setup, obstruction notes and repeated measurements. Where available, preserve processing reports and covariance information. A screenshot can supplement these records, but it should not replace machine readable data or a clear description of the conditions under which the coordinate was collected.
Continue learning Designing a GNSS project quality dashboard
Classify possible causes systematically
Begin with identification and transcription issues: wrong point code, duplicate name, swapped coordinates, unit mismatch or an incorrect antenna height. Next inspect the coordinate framework, including projection, reference frame, epoch and height convention. Then consider observation quality, such as multipath, loss of lock, incomplete corrections or unstable setup. This order often resolves simple mistakes before the team spends time on complex satellite explanations.
Use patterns across nearby observations. If an entire session shares an offset, investigate common inputs rather than treating every point as an unrelated anomaly. If only one feature is affected, inspect its physical definition and local surroundings. If differences vary with distance or direction, review transformation and scale assumptions. Document the tested hypotheses, including those ruled out, so another reviewer does not have to repeat the investigation from the beginning.
Continue learning GNSS mapping for disaster assessment: rapid data with traceable quality
Compare against genuinely independent information
A repeat observation is valuable when it tests a different part of the measurement process. A second store without changing the setup may reproduce the same error. Consider a remade setup, a different observation time, independent control or another measurement technique according to the importance of the point. Record which dependencies remain common, because agreement between two methods is less persuasive if both inherit the same incorrect reference coordinates.
Check the reference itself. Confirm the monument identity, stability, coordinate source and uncertainty. A displaced mark can make sound rover observations look wrong. A coordinate supplied in a different height convention can produce a consistent vertical discrepancy. The review should evaluate the complete comparison, rather than assuming that one side is infallible merely because it appears in an older report or a trusted looking spreadsheet.
Continue learning Building a GNSS error budget before fieldwork
Make a documented disposition
An exception can be retained as observed, corrected from evidence, remeasured, excluded from a specific calculation or marked unresolved. These are different decisions with different consequences. Correct a value only when the original evidence supports the change, such as a verified height transcription error. Do not invent a replacement coordinate by moving a point toward its neighbors or toward the expected design location.
When excluding an observation, state the reason and the scope. An unusable occupation does not necessarily invalidate every observation at that mark. A point unsuitable for control may still be useful as an approximate inventory feature if clearly labeled. Keep the original identifier and link the accepted replacement or revised status. This maintains continuity between field records, processing decisions and the final deliverable without silently erasing inconvenient information.
Continue learning Repeat observations: creating a stronger GNSS check
Recalculate the affected results
After an approved correction or exclusion, rerun the calculations that depend on it. These can include an adjustment, transformation, surface model, volume calculation or feature export. Compare the revised output with the earlier version and identify the practical impact. A seemingly minor control change can affect many downstream coordinates, so the review should follow dependencies rather than stop once the flagged point appears reasonable.
Run the original acceptance checks again using the approved final configuration. Confirm that the fix did not create a new issue elsewhere. If the dataset is already shared, identify which issued files are superseded and notify the responsible project contact through the established process. The internal review record should make it possible to connect each issued version with the observations and decisions on which it was based.
Continue learning Designing a GNSS project quality dashboard
Verify that exception status survives the export
Take one training point through the full workflow with a deliberate under review status. Export it to the formats used by the office and client, then confirm that the status remains visible and linked to its reason. Some simple coordinate exports omit custom fields, so a point that was clearly provisional on the controller can appear indistinguishable from accepted observations in a spreadsheet. Resolve that gap with an appropriate schema or companion review table before relying on the status system during production.
Repeat the exercise after the point is remeasured and accepted. The record should link the original occupation, exception, replacement observation and final coordinate without reusing identifiers ambiguously. If the accepted export excludes rejected records, retain them in the technical archive with a clear relationship. This practical test makes the outlier process durable beyond one software application. It also reduces the risk that an unresolved coordinate is issued accidentally when someone prepares a simplified export that strips away the very information the reviewer used to control it.
Continue learning GNSS mapping for disaster assessment: rapid data with traceable quality
Turn the review into a quality record
Close each exception with an owner, date, evidence summary, decision and remaining limitation. Summarize recurring causes across the project. Repeated height entry mistakes may justify changing the field form; frequent coordinate confusion may require a clearer setup template. These improvements are more useful than a report that simply announces all outliers were removed without explaining what the exceptions revealed about the workflow.
A transparent outlier process protects the credibility of the entire dataset. It acknowledges that unusual observations deserve scrutiny while resisting the temptation to force every point into a neat pattern. The final result is not merely a cleaner spreadsheet. It is a defensible record showing how the team distinguished observation problems, reference issues and legitimate variation before releasing GNSS coordinates for further use.
Continue learning Building a GNSS error budget before fieldwork
Practical checklist
- Define an exception before opening the final dataset.
- Verify that exception status survives the export.
- Turn the review into a quality record.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
