Writing GNSS survey specifications that can be verified
A clear GNSS specification defines the intended use, reference systems, observation evidence, acceptance checks and deliverables in measurable terms.
Specify the required outcome first
A GNSS survey specification should explain what the coordinates must support and how suitability will be assessed. Begin with the intended use, project area, feature types and consequences of error. A requirement to use a survey grade receiver is incomplete because equipment labels do not define the full measurement process. The specification should connect the deliverable to verifiable evidence rather than rely on a brand, channel count or a general accuracy claim.
Distinguish mandatory requirements from guidance and optional capabilities. Use clear language that a field crew, contractor and reviewer can interpret consistently. Avoid combining several different quality concepts in one sentence. Horizontal accuracy, vertical uncertainty, repeatability and maximum check discrepancy are not interchangeable. Define the quantities and reporting conventions needed for the project so bidders and operators are working toward the same measurable objective.
Continue learning GNSS corridor surveys: controlling a long, changing work area
Define the coordinate framework completely
Identify the horizontal reference frame, realization where relevant, epoch, projection, units and axis order. Specify the required height convention separately, including an approved geoid or vertical transformation where applicable. A broad label such as WGS84 or above sea level may leave important details unresolved for precise work. Reference authoritative definitions and identify who is responsible for resolving compatibility with supplied control.
If a local grid is required, state how it will be established, documented and independently checked. Define the role of existing control and how inconsistent marks will be handled. A specification should not force a contractor to fit every supplied coordinate regardless of quality. Provide a review path for conflicts and require a traceable transformation record rather than an unexplained controller localization file as the sole evidence.
Continue learning Writing a GNSS survey report that supports the coordinate deliverable
Describe feature and control definitions
State what physical point each coordinate represents. A utility cover center, pipe invert, monument reference and ground surface require different observation and identification procedures. Include coding and attribute requirements sufficient for downstream interpretation. A coordinate can be precise while describing the wrong surface or feature, so physical definition belongs in the specification alongside numerical quality requirements.
For control, define mark descriptions, stability expectations, recovery information and required observation evidence. Identify whether existing marks are supplied as authoritative constraints or as information requiring verification. The contractor should know which assumptions can be relied on and which must be tested. This clarity reduces disputes in which a technically consistent survey is later judged against an undocumented interpretation of the control framework.
Continue learning A clear vertical datum handover for GNSS survey projects
Allow appropriate methods while controlling evidence
Specify the required observation and verification outcomes without unnecessarily prescribing one instrument model. Where a particular method is mandatory, explain its role through the applicable project requirements. Include antenna setup controls, reference information, correction compatibility and raw data retention as appropriate. A method should be judged by whether it can produce the required evidence under the actual site conditions.
Provide a path for difficult features that cannot be measured credibly by direct GNSS occupation. Alternative techniques, offsets or supplementary control may be appropriate when documented and verified. A specification that requires GNSS everywhere can encourage weak observations at unsuitable sites. The goal is a reliable coordinate chain, with each method's contribution and limitations visible in the final record.
Continue learning Connecting PPP coordinates to local survey control
Define independent verification clearly
State which checks are required, what they test and how independence is established. Repeated stores from one unchanged setup do not test the same dependencies as remade occupations or external control comparisons. Points used to establish a transformation should not automatically be counted as independent checks of that transformation. Define the sampling and distribution needed to represent important project areas and conditions.
Set acceptance criteria with units and statistical meaning. Where confidence levels or uncertainty measures are used, define their interpretation. Avoid copying thresholds from an unrelated project without considering reference uncertainty and intended use. The criteria should be practical to measure and review. A requirement that sounds strict but cannot be evaluated consistently creates ambiguity rather than better survey quality.
Continue learning GNSS corridor surveys: controlling a long, changing work area
Specify exception and change handling
Require a documented process for failed checks, unusual observations, corrections and remeasurement. The contractor should preserve original evidence and explain exclusions rather than simply remove inconvenient points. Identify who approves changes to control, transformations or collection methods. A controlled exception process allows the project to respond to real field conditions without weakening the agreed acceptance standard silently.
Address configuration changes and outages. State what records are needed when correction sources, equipment or project templates change. If provisional collection is permitted, define how its status must survive export and what evidence is required before acceptance. These operational details prevent temporary workarounds from becoming hidden differences within a coordinate table that appears uniform to the final user.
Continue learning Writing a GNSS survey report that supports the coordinate deliverable
Define processing and reporting requirements
Require enough information to reproduce significant processing steps: software version, input identifiers, reference data, transformations and relevant model choices. Specify the quality summary, independent check tables and exception records needed for review. Avoid demanding every possible software printout without explaining its purpose. A coherent report that connects evidence to acceptance is more useful than a large unstructured bundle of diagnostics.
State whether original observations and supporting inputs must be delivered or retained, and in which formats. Include readable metadata alongside proprietary files where appropriate. The required archive should match future reuse and audit needs. A project intended for later monitoring or control reuse may require more detailed provenance than a limited inventory, but both need an unambiguous coordinate definition and authoritative issued version.
Continue learning A clear vertical datum handover for GNSS survey projects
Make deliverables testable
List file formats, schemas, attributes, units, naming conventions and version identifiers. Define how accepted, approximate and unresolved features are represented. If GIS and CAD outputs are both required, ensure their coordinate definitions and feature identities remain consistent. Provide a small example or schema where it reduces ambiguity, especially for axis order, height fields and quality status.
Include a package completeness check and a review process. The recipient should be able to open representative files, locate metadata and identify the final approved dataset. Address superseded issues so corrected coordinates do not circulate alongside earlier versions without explanation. Testability includes practical handover, not only numerical comparisons performed inside the contractor's processing software.
Continue learning Connecting PPP coordinates to local survey control
Review the specification before procurement
Have field, processing and downstream users assess whether the requirements are understandable and achievable. Identify contradictions, undefined terms and evidence that would be difficult to obtain. Where commercial service or software capabilities matter, verify current official documentation and terms during procurement. Avoid embedding an outdated capability claim as a permanent project requirement without a review mechanism.
A strong GNSS specification creates a shared basis for planning, collection, review and acceptance. It states the coordinate framework, physical definitions and verification evidence clearly, while allowing appropriate methods for real site conditions. That reduces avoidable disagreement and gives every participant a concrete way to demonstrate that the delivered data is suitable for the intended work.
Continue learning GNSS corridor surveys: controlling a long, changing work area
Practical checklist
- Specify the required outcome first.
- Make deliverables testable.
- Review the specification before procurement.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
