The time printed on a GNSS plot usually identifies the observation, but it is not necessarily when data reached the system, processing finished or the user saw the result. Mixing these timestamps can make a result that is still being produced look like an outage. Conversely, an old value left on screen can be mistaken for proof that new observations are still arriving.
RST’s permanent GNSS monitoring primarily uses solutions formed over defined observation periods. Each result needs complete observations and a quality review. “Near real time” therefore means a result is produced through a predictable process after its observation period is complete; it does not mean every instant is a separate dynamic position.
This guide explains when data forms, what interruptions mean and how interpretation resumes after monitoring recovers. For the interpretation sequence applied to a displacement itself, see Can This GNSS Displacement Be Trusted?.
The short answer: every result has at least four timestamps
Separate four metrics that are often mixed together
| Metric | Question it answers | Common mistake |
|---|---|---|
| Latency | How long after an observation period ends is its result visible? | Treating receiver sampling interval as result latency |
| Freshness | At query time, how old is the newest observed result? | Treating a recent row-update time as a new observation |
| Availability | What share of expected results has the quality and state required by the project? | Counting every database value as usable |
| Continuity | Did results remain uninterrupted during a critical period? | Letting a long-term average hide one important long outage |
The metrics affect one another but are not interchangeable. A system can usually be low-latency yet fail during one critical event. Later processing activity does not improve what was available at the time of the event.
1. Why a near-real-time static result needs time to form
A static solution estimates position jointly from observations over a period. Processing includes collecting monitoring and reference data, confirming time overlap and file completeness, forming a position, reviewing quality, storing the result and publishing it.
A user’s wait may therefore mean:
- the observation period is still open;
- monitoring or reference data is not complete;
- communications are working, but processing is queued or still underway;
- a solution exists, but quality is insufficient for a usable result;
- the result is published, but a front-end cache or synchronization has not updated.
An external “near-real-time” description should define the observation period represented, normal publication cadence, how latency is calculated and which state appears during an exception. The word “real time” alone does not tell a customer whether the system is behaving as expected.
2. An interruption has more than one possible cause
| Visible condition | Possible layer | Defensible conclusion now |
|---|---|---|
| No new source observation | Power, receiver, local storage or site environment | There is no new measurement evidence; a remote view alone cannot name the cause |
| Communications are interrupted | Communications, network or transfer path | Verify separately whether on-site observation continues and whether users receive new results |
| Monitoring data arrived, reference is incomplete | Reference source or time overlap | A relative result cannot yet be formed |
| Data is complete but no result appears | Queue, format, solution or quality decision | Inspect processing and quality states; this does not mean zero displacement |
| The screen still shows an old value | The latest result is stale, or freshness is not shown | The value describes its original observation period, not the present |
IGS station and data-center guidance likewise treats continuous observation, communications design and transmission as separate responsibilities [1][2]. “The station is still observing” and “the user has a new result” are different questions.
3. A displayed value may not be fresh: observation time and stale values
Freshness follows the latest actual observation time. A recent processing, synchronization or database-update time is not a new observation and must not make an old value appear current.
A customer-facing delivery interface should distinguish:
- the observation time of the latest observed result;
- whether the period is observed, limited or missing;
- whether the project’s agreed freshness condition is currently exceeded;
- the latest processing time.
An old value may remain as the last known state, but it must show its last observation time and must not be presented as current.
4. How to resume interpretation after an outage
Recovery starts with the newest actual observation after service resumes. Confirm its observation time, verify monitoring and reference status, and preserve the outage interval as missing evidence.
Before interpretation resumes:
- confirm the latest actual observation time and the end of the outage;
- verify monitoring and reference status;
- preserve the missing interval in plots, reports and availability records;
- run the project-defined quality checks on observations after service resumes;
- resume displacement interpretation only after those checks pass;
- record the outage cause when known and retain the applicable processing and rule versions.
The outage interval remains a period without measurement evidence. Recovery confirms when new evidence becomes available; it does not establish displacement within the missing period.
5. What a customer interface should show
| Suggested state | Plain-language meaning | Interpretation this state rules out |
|---|---|---|
| Collecting | The observation period is not complete | Outage |
| Waiting for data | Monitoring or reference data is incomplete | Zero displacement |
| Processing | Data is complete; the result is forming or under quality review | System failure |
| Usable | The project-required quality checks are complete | Never subject to revision |
| Limited | A result exists, but some evidence is insufficient | Equivalent to a usable result |
| Interrupted / missing | There is not enough observation to form a result | No site movement |
Names may vary by project, but they must answer two questions: what stage the newest actual observation has reached, and how the resulting value may currently be used.
Questions to agree before a project starts
- Does result time represent observation start, end, midpoint or another explicit definition?
- From which timestamp is latency measured, and how are normal and exceptional conditions reported?
- When the latest result becomes stale, how does the display stop presenting it as “current”?
- How is continuity monitored, and which record preserves outage timing and the known cause?
- Which monitoring, reference and quality checks must pass before interpretation resumes?
- How is availability calculated, including the treatment of limited periods and planned maintenance?
- Which decisions pause during an outage, and which safety procedures still begin?
These questions define the customer’s actual service expectations more clearly than “how many minutes per result?” They also keep the technical team and user from assigning different meanings to the same green status.
From shared definitions to project settings
The project sets its observation periods, processing schedule, retry rules, freshness thresholds, capacity, retention periods, communications architecture and state conditions according to site communications, risk, data volume and service requirements. The service specification records these operational values and how they were validated.
Shared, reviewable definitions keep observation, transfer, processing and publication time distinct; separate observed, limited and missing states; and retain outage and processing-version records. Project settings apply those definitions consistently to delivery, review and acceptance.
GNSS monitoring series
This final article explains timing and outages after the preceding guide has established how to interpret a displacement result.
Previous: GNSS displacement data trust | Series 7 of 7
References
- International GNSS Service. Guidelines for Continuously Operating Reference Stations in the IGS, Version 1.1. https://files.igs.org/pub/resource/guidelines/Guidelines_for_Continuously_Operating_Reference_Stations_in_the_IGS.pdf
- International GNSS Service. Data Access: Data Center Responsibilities. https://www.igs.org/data-access/
- National Geodetic Survey. Guidelines for Establishing and Operating CORS. https://www.ngs.noaa.gov/web/data_imagery/CORS/Establish_Operate_CORS.shtml
Frequently asked questions
Q: The screen still shows the last position. Does that mean monitoring is healthy?
Not necessarily. Check the latest actual observation time and state, not whether the screen has a number. A stale value may remain, but its age should be explicit.
Q: How can a communications outage be distinguished from an observation outage?
Check receiver and monitoring status, source-observation timestamps, transfer status and reference availability. A communications outage affects delivery; an observation outage means no new measurement evidence was recorded.
Q: How should displacement be interpreted during an outage?
Treat the outage interval as missing evidence. The last observed value describes its original observation period and cannot establish whether displacement occurred during the outage.
Q: What checks are needed after monitoring resumes?
Confirm the newest actual observation time, monitoring and reference status, and the project-defined quality indicators. Resume interpretation only after those checks pass, while preserving the outage interval and its records.
Define result time, data states and outage handling for permanent GNSS monitoring with a service specification built for your site and use case. Contact RST to structure and validate the operational settings and acceptance records.