5 Steps to Writing a Specification for Organizing 3D Measurement and GNSS Before Ordering

When outsourcing 3D surveying or point cloud acquisition, the issue that field personnel most often struggle with is what to specify and to what level of detail in the specification document. Differences in the performance of measurement instruments and in work methods are not easy to see, and if the client makes a vague request, problems are likely to arise such as delivered data being difficult to use, not meeting the required accuracy, necessitating additional work, or being hard to reuse internally.

In projects that combine 3D surveying with GNSS in particular, it is essential to clarify not only the acquisition of the point cloud but also which coordinate system will be used, what degree of positional accuracy is required, whether GNSS will be stable under the site conditions, and how the data will be used in downstream processes; otherwise, large discrepancies can appear between the order and the deliverables.

Specifications are not documents for the client to constrain the contractor. Rather, they form the foundation for aligning a shared understanding of the site’s objectives, the required level of accuracy, how the deliverables will be used, and the methods of verification. If these points are vague, the contractor will have no choice but to proceed on safe assumptions, and the client is likely to feel that the result differs from what they expected. Conversely, when a specification clearly organizes the objectives and conditions, it becomes easier to compare estimates and enables efficient use of point clouds and positional information across pre-construction review, as-built verification, maintenance, drafting, ledger preparation, and internal sharing.

Practitioners searching for information with the keywords "specification point cloud 3D surveying GNSS" are likely more interested in what they need to organize before placing an order to avoid failure than in the detailed theory of the equipment. This article explains, from that practical perspective, how to write a specification to organize 3D surveying and GNSS before ordering, in five steps. Whether you're drafting a specification for the first time or reviewing an existing purchase order, the guidance is presented in the order of thinking so you can use it directly for internal organization.

Table of Contents

• Why specification documents for 3D measurement and GNSS become important

• Basic approach to drafting specifications to confirm before placing an order

• Step 1 Clarify the purpose of measurement and use cases

• Step 2 Define the target scope and site conditions

• Step 3 Specify accuracy requirements and coordinate conditions

• Step 4 Document deliverables and data specifications

• Step 5 Finalize the work structure, verification methods, and delivery conditions

• Common mistakes in specifications for 3D measurement and GNSS

• Summary

Why Specifications for 3D Measurement and GNSS Become Important

Many of the problems that arise when ordering 3D surveys do not stem from failures of the measurement itself but begin with insufficient wording at the order stage. For example, a request that simply says "Please capture the existing conditions as a point cloud" gives no indication of how much area to capture, which parts to prioritize, how much noise removal to perform, or how much loss of features to tolerate. Furthermore, even if the use of GNSS is assumed, unless it is specified whether absolute coordinates are required, whether relative alignment is sufficient, or whether a connection to site control points is needed, the value of the deliverables can change significantly.

Even if the client believes that simply acquiring a point cloud is sufficient, in practice multiple uses follow: producing drawings, checking cross sections, determining quantities, comparing deformations, planning construction, and linking with maintenance management ledgers. Therefore, what is truly important is not the act of measurement but delivering data in a usable form. Specifications exist to define that usable state.

Also, in projects that include GNSS, a lack of understanding about handling location information tends to lead to omissions in the specifications. If you assume that anything outdoors can be measured with high accuracy, you will overlook that visibility to the sky, surrounding structures, trees, reflective environments, and occlusion along travel routes can change the positioning conditions. As a result, the expected coordinate accuracy may not be achieved, causing extra work for point cloud alignment and post-processing. Specifications need to describe not only whether GNSS can be used, but under which conditions, with what accuracy targets, and how it will be verified during operation.

Furthermore, when the specifications are well organized, the quality of estimate comparisons also improves. If you receive proposals from multiple companies while the conditions remain ambiguous, each company will construct the scope of work based on different assumptions, so even if there are differences in price or the number of working days, you cannot accurately compare the reasons. On the other hand, if the scope, accuracy, deliverables, and verification methods are aligned, it becomes easier to see where the differences lie, allowing you to judge based on content as well as price. This is a significant benefit for the client.

In short, specifications for 3D measurement and GNSS are not only documents for procurement but also blueprints for aligning on-site expectations, ensuring the usefulness of deliverables, and making comparisons easier. For that reason, rather than indiscriminately listing technical details, it is important to work backwards from the objectives and organize the necessary requirements.

Fundamental approach to preparing specifications to confirm before placing an order

When writing a specification, the first thing to be aware of is not lining up perfect technical terms, but clarifying, in order, the decisions you want to make as the client. In practical fieldwork, you cannot always specify measurement methods and processing conditions in detail from the outset. Rather, it is important to first firm up matters that only the client can decide—such as why the measurements are being taken, what scope will be targeted, what accuracy is required, and how the results will be used after delivery.

If you get the order wrong, the specification document will become nothing more than a glossary. For example, even if you decide point cloud density and output format first, if it's unclear whether that data will be used for cross-section verification, as-built comparison, or design documentation, it cannot be considered a sufficient specification. Conversely, if the intended use is clear, it's easier to determine the required density, accuracy, and level of data organization. When creating specifications, the basic principle is to start from the purpose, not from the technology.

Another important point is to distinguish between the scope to be left to the contractor and the scope the client should specify. Specific measurement procedures and safety arrangements tailored to site conditions are areas where the contractor’s know-how should be reflected. However, the intended use of the deliverables, required accuracy, scope of work, delivery format, and acceptance criteria are matters the client should decide. If this boundary is unclear, the contractor will have too much latitude and be uncertain in making decisions, and the client may later feel, “I didn’t intend to leave that much to them.”

It is also necessary to adopt the perspective that specifications should be prepared as documents that connect stakeholders’ understandings, rather than as standalone documents. On-site personnel, managers, designers, constructors, and maintenance staff each require slightly different information. Some data are easy to collect on site but difficult to use in later stages, while conditions that are ideal for later stages may impose an excessive burden on field operations. Specifications have the role of mediating between these and indicating a realistic, usable compromise.

Therefore, before drafting the specification document, it is effective to take stock once of the problems being experienced on-site, the tasks you want to carry out after delivery, and who in the company will use what. Doing this organization makes the five steps explained in later chapters less likely to deviate. In other words, a good specification document is determined not by writing ability but by the quality of the preparation before placing the order.

Step 1: Clarify the measurement objectives and use cases

The first step is to explicitly document what the 3D measurement is being carried out for. If you try to finalize the specifications while leaving this ambiguous, the required accuracy and the deliverables will not be determined, and the data will tend to become unusable in downstream processes. Clarifying the purpose is the foundation of the entire specification document.

For example, whether the objective is to grasp current conditions, to check differences before and after construction, to record the shape of a structure, or to verify earthwork volumes and as-built conditions will change both the required measurement extent and the required accuracy. If the goal is to grasp current conditions, wide-area coverage and minimal data gaps may be emphasized, whereas for as-built verification the precision of the target area and coordinate alignment are prioritized. For maintenance-management purposes, reproducible coordinate control and a consistent approach to capture conditions are also important so that future comparisons are easy.

What matters here is not to end with the abstract expression “measure with high accuracy.” The phrase “high accuracy” is convenient, but its interpretation varies among readers. In specifications, it is important to state the intended use together with the data — what operational decision the data will be used for, what level of repeatability is required, and over what range the shape must be captured. If the objective is specific, the contractor can more easily establish an appropriate work plan.

Also, you should clarify the reasons for combining GNSS at this stage. Operational requirements will differ depending on whether it is because you want to manage data in absolute coordinates, efficiently position a wide area of interest, overlay existing records and drawing information, or facilitate comparisons during re-surveys. If using GNSS becomes an end in itself, there is a risk of employing methods that do not fit site conditions. What is important is to describe why GNSS is necessary in connection with business objectives.

Furthermore, anticipating who will use the deliverables and how will raise the accuracy of the specifications. For example, whether the data will be checked only by on-site staff, shared with the design department or external stakeholders, or retained as asset information for the future affects the file structure, naming, attribute information, and the need for explanatory materials. If the specification reflects background such as "intended for use by multiple internal departments," it becomes easier to require deliverables that are practical for operations rather than mere measurement results.

In practice, many projects do not have a single objective. In such cases, it is easier to organize by separating primary and secondary objectives. For example, if you set the primary objective as understanding the current situation and the secondary objective as preparing baseline data for future comparisons, the contractor can more easily understand what should be prioritized most. If you demand everything with equal weight, specifications can become bloated and place an excessive burden on-site. Precisely for that reason, organizing objectives is not a task of adding information, but a task of setting priorities.

If you devote sufficient time to this step, the scope, accuracy, deliverables, and verification methods you write in later stages will naturally connect. Conversely, if this part is vague, the whole specification will become ad hoc, making it difficult to compare estimates or carry out acceptance checks. Thinking of the first step in creating a specification as articulating the business objectives rather than explaining measurement techniques makes it easier to proceed.

Step 2 Organize the target scope and site conditions

The next step is to organize where and under what conditions measurements will be taken. In 3D measurement, if the definition of the target area is vague, the quality of the deliverables becomes unstable. On-site, it is not uncommon for the area the client had envisioned and the area the contractor interprets in their work plan to differ. Therefore, specifications need to concretize the target area not only in words but also by defining the approach to boundaries and whether there are any priority capture points.

For example, even when the measurement target is the area around a road, the amount of work varies greatly depending on whether only the paved surface is measured, whether slopes and gutters are included, and how extensively roadside structures are captured. For buildings, the required measurement methods change depending on whether only the exterior perimeter is needed, whether surrounding equipment is included, and whether roof and upper-level information is necessary. In the specification document, it is important to organize the types of objects, the boundaries of the target area, priority locations, and areas that do not need to be captured.

Also, understanding site conditions directly affects the success or failure of GNSS. Even if positioning is easy in locations with open sky visibility, it can be unstable under trees, near structures, in narrow passages, in mountainous areas, or close to walls. If the specifications presume using GNSS, you should not simply write “positioning will be performed by GNSS”; you should explicitly state that planning must take into account the site’s reception environment and shielding conditions. In some cases, it will also be necessary to consider alternative position management or complementary methods for locations where GNSS is unstable.

Furthermore, available working hours and on-site regulations are also important conditions. Whether there are traffic restrictions, permitted access times, safety management requirements, third-party traffic conditions, or whether the environment is susceptible to weather effects directly impacts measurement quality and the project schedule. In the specifications, it is not necessary to detail every on-site condition, but the assumptions the contractor needs to make plans should be shared. If these are missing, unexpected situations will frequently occur on site, leading to rework and schedule delays.

A point that is often overlooked here is the idea of distinguishing the measurement scope from the varying levels of required accuracy. If you demand the same accuracy, the same density, and the same finish across every area, the workload becomes excessively large. In practice, it is more rational to prioritize key structural elements and managed locations, while keeping peripheral reference information at a level that is necessary and sufficient. Even in specifications, rather than writing the target scope as a single monolithic block, being conscious of divisions according to importance makes the content more realistic and easier to implement.

Also, organizing the relationship with existing materials at this stage is useful. If there are existing drawings, plans, survey results, management registers, past point cloud data, etc., explicitly stating to what extent you want them to be reconciled will make it easier to establish criteria for alignment and verification of results. Conversely, if the accuracy of existing materials is unknown, you should share that assumption with the contractor and clarify to what extent they can be referenced.

Organizing the project scope and site conditions is not merely information gathering. It establishes the prerequisites for the contractor to develop an appropriate work plan and for the client to receive deliverables they can accept. The more thorough this step is, the more the subsequent accuracy settings and delivery conditions will match actual site conditions, leading to realistic orders.

Step 3 Specify Accuracy Requirements and Coordinate Conditions

In specifications for 3D measurement and GNSS, the most important — and the most prone to ambiguity — are the accuracy requirements and coordinate conditions. If these are ambiguous, problems arise such as point clouds existing but being unusable, positions being recorded but not matching existing records, and difficulty comparing with re-measurements. Therefore, the specification needs to concretely define “how accurate is sufficient for operational purposes,” linked to the intended use.

First, you should consider whether what you need is absolute accuracy or relative accuracy. Absolute accuracy refers to how correctly something is positioned in geographic space, and it is important when overlaying with existing drawings or other positional information. By contrast, relative accuracy refers to how accurately shapes and distance relationships within the subject are reproduced, and it is emphasized for shape capture and change detection. Some tasks require both, but if you do not clarify which to prioritize, the specification may end up being insufficient or excessive.

Next, clarify which type of coordinate handling is required. Operational methods vary greatly depending on whether only planar positions are sufficient, whether three-dimensional coordinates including elevation information are required, whether connection to existing reference frames is mandatory, or whether relative local management is acceptable. Even when using GNSS, it is not always possible to manage the entire site uniformly to the same level of accuracy. Therefore, in the specification it is effective to describe separately the purpose of the required coordinate management, the scope of coverage, and the approach to verification.

One thing to be careful of here is that simply writing numerical values does not convey the accuracy conditions. For example, even if you specify a target for positional accuracy, it will be difficult to operate in practice if you do not state under what conditions and how that value will be verified. In a specification, you need to organize not only the accuracy targets but also the verification methods, verification timing, and the approach to acceptance decisions as a set. On site, some locations may have poorer conditions, so it is also practical to consider separating key areas from general areas rather than applying a uniform standard across the entire site.

Also, when using GNSS, it is important to document considerations for environments where positioning may be unstable. For locations that could be affected by signal obstruction or reflection, organizing procedures for preliminary checks, supplementary measurements, criteria for re-measurement, and methods for quality verification will bring consistency to on-site responses. If these perspectives are included in the specifications, it becomes easier to avoid ambiguous operations left to the contractor.

Furthermore, accuracy requirements are meaningless unless they are linked to the decision criteria of subsequent processes. It is important to consider, from perspectives such as whether, if used for cross-section creation, the required level of reproducibility; if used for construction management, the range of error that is operationally acceptable; and if used for a maintenance ledger, whether it needs to be positioned so as to withstand future comparisons. In other words, higher accuracy is not necessarily better—what matters is that the accuracy is appropriate for the intended use. Excessive accuracy requirements inflate costs and expand work processes, while insufficient accuracy requirements worsen the usability of downstream processes.

In this step, what the client should aim for is not to force a string of numbers that merely look technical, but to specify the required quality level in operational terms. In addition to purpose statements such as "does not impede drafting," "can be overlaid with existing management information," and "can be used for comparison during remeasurement," organizing the approaches to coordinate management and verification needed to achieve those purposes will make the specifications easier for contractors to implement. Accuracy requirements and coordinate conditions are the core of the specifications. By refining this part most carefully, the likelihood of procurement failure is greatly reduced.

Step 4: Formalize Deliverables and Data Specifications

When commissioning 3D surveys, what is ultimately delivered is more important than what is done on site. Even if you think you ordered point cloud acquisition, it is not uncommon for the delivered data to lack organized coordinate information, have inconsistent file naming, contain many unnecessary points that make it hard to work with, make the survey extent unclear, or lack easily viewable supporting documents. To prevent these problems, the contents of the deliverables and the data specifications must be documented in a specification.

First, what you need to clarify is the types of deliverables required. In addition to the point cloud data itself, consider whether you need a georeferenced set of deliverables, a simple verification diagram, or a report that shows the target area, acquisition date, and measurement conditions. In practice, because sharing or acceptance within a company is often difficult with the raw data alone, there is significant value in requesting supplementary viewing materials and a deliverables list.

Next, the granularity of the deliverables and the units used to organize them are important. Whether you have the entire project site delivered as a single large dataset, split it by zones or work sections, or organize it by intended use will greatly affect how easy it is to handle later. If files are too large, they become difficult to open internally; conversely, if they are divided too finely, management becomes cumbersome. In the specifications, it is useful to show an appropriate approach to splitting and naming, taking into account who will actually use the data and in what environment.

Also, it is important not to stop at merely listing the data format. Even if the format name is correct, a lack of explanation about how coordinate information is preserved, whether attributes are included, how units are handled, and the definition of the origin or vertical reference will hinder practical reuse. Deliverables should include a set of information that makes clear according to which standards the data were organized. In the specification, it is also advisable to require documentation that describes the delivered data and the organization of metadata.

Furthermore, you should decide in advance how to handle unwanted points and what level of editing is expected. Point cloud data are not usable as-is after acquisition; they may include noise, unwanted objects, pedestrians, and temporary obstacles. If you do not make clear how far the data should be processed before delivery, the client may receive hard-to-use raw data, and the contractor may assume that only the minimum processing is sufficient. It is important to state in the specifications how much cleanup is required according to the intended use.

The usability of deliverables is not determined solely by technical specifications. Operational organization—such as folder structure, file names, coverage maps, acquisition dates, processing history, and notes or cautions—is also a major factor. This is especially true for organizations managing multiple projects in parallel, which require a delivery format that makes it easy to distinguish items when reviewed later. By including these basic rules in the specification, the data is more likely to remain an asset rather than being used only once.

And one thing you must not forget is the perspective of making deliverables easy to verify. If a client receives data without being able to inspect its contents, it becomes difficult to judge quality. Therefore, information required for acceptance checks — such as a list of deliverables, how they correspond to the scope, an explanation of coordinate conditions, and a summary of quality-check results — should also be considered part of the deliverables. Documenting deliverables in the specification is not merely about deciding the delivery format; thinking of it as defining a state in which there will be no confusion after delivery makes it easier to organize.

Step 5: Finalize the Work Structure, Verification Methods, and Delivery Conditions

The final step is to finalize the specifications, including the implementation framework, quality verification, and delivery conditions. Even if the objectives, scope, accuracy, and deliverables have been clarified up to this point, ambiguous procedures and verification methods can leave room for differing interpretations on site and cause problems at delivery. It is important to write the specification document not only from the entry point of the work but with the completion criteria in mind.

First, regarding the work structure, it is necessary to clarify the division of responsibilities between the client and the contractor. Whether on-site attendance is required, verification of the scope before work, handover of existing documents, scheduling of measurement days, communication with stakeholders, and sharing of safety-related constraints, it is important not to leave unclear who is responsible for what. If this is unclear, waiting for confirmations on the day of the site visit may occur, or unforeseen work constraints may be revealed, affecting both quality and schedule.

Next, decide on the method for quality checks. For 3D measurement and GNSS, it is difficult to judge the quality of results by appearance alone, so it is necessary to define the inspection criteria in advance. Including acceptance-check viewpoints in the specifications—such as whether the target area is fully covered, whether coordinate conditions are met, whether there are no gaps in critical locations, and whether the required documentation is complete—will make post-delivery communications easier to organize.

Also, depending on site conditions, some requirements may be difficult to meet. Therefore, in the specifications it is practical to outline procedures for reporting unexpected obstructions or access restrictions, the approach to any additional measures, and how to discuss alternative solutions. Even if it is difficult to decide everything in advance, simply defining the conditions that should be subject to discussion can greatly improve the quality of on-site responses.

For delivery conditions, it is advisable to organize not only the delivery date but also the submission method, file structure, review period, and the scope of revisions. If you set the delivery date without taking into account the client's review time, internal acceptance checks may not be completed in time and the discovery of issues will be delayed. Especially for deliverables that include point clouds or location information, review by relevant stakeholders is often required, so it is important to set delivery conditions based on the review flow.

Furthermore, whether or not to conduct interim reviews is also a valid point of discussion. Under an approach where nothing is reviewed until final delivery, misinterpretations of scope or mistakes in coordinate settings may go undetected until the late stages. When a project is large in scale or includes conditions being handled for the first time, providing opportunities for interim reviews makes it easier to limit rework. Incorporating the concept of interim sharing and prior consultation at the specification stage also allows the client to proceed with greater confidence.

The purpose of this step is not to micromanage tasks. It is to reduce differences in understanding that may occur on site and to create a state in which quality and conditions can be verified at delivery. Because projects involving 3D measurement and GNSS are prone to quality variations in unseen areas, it is especially important to finalize the work organization, verification methods, and delivery conditions as specifications through to the end. Once this has been organized, concerns before placing an order are considerably reduced.

Common Mistakes in Specifications for 3D Measurement and GNSS

One common mistake when creating specifications is writing about the methods before the objectives. For example, if you specify particular measurement methods or data formats in detail without explaining why those conditions are necessary, the specification is likely to become unsuitable for the field. If it remains unclear whether the client really wants a before-and-after construction comparison, records for maintenance, or creation of drawings, the contractor will not be able to make the best proposal. A specification should be a document that derives conditions from the objectives, not a list of methods.

Another common problem is ambiguity about the scope. Phrases like "include the surrounding area" or "capture the necessary locations" may seem convenient at first glance, but they leave too much room for interpretation. It is not uncommon for the scope that the client assumed to be obvious to fail to be communicated to the contractor. In particular, areas you want to focus on or areas where omissions are unacceptable need to be made clear using stronger wording.

Also, many specifications assume the use of GNSS but do not describe the on-site reception conditions or the approach to position management. This leaves no preparations for environments where positioning is difficult, and as a result issues with coordinate consistency remain. GNSS is a convenient means, but it is not a universal solution. Specifications need to consciously state the intended use, scope of applicability, and verification methods as a set.

There are also many failures related to deliverables. If you only require the delivery of point cloud data and don't establish explanatory materials or organization rules, the deliverable tends to become something that no one can use effectively afterward. If specifications are decided without considering the environment on the client's side for viewing or the internal sharing workflow, the post-delivery value will be greatly reduced. Successful measurement and successful utilization are different things, and specifications must be drafted with the latter in mind.

Furthermore, there are cases where delivery occurs while the acceptance criteria remain ambiguous. If it hasn’t been decided what condition is acceptable, post-delivery discussions become subjective and place a burden on both parties. If you define the axes for acceptance checks in advance—such as the scope, accuracy, coordinate conditions, the composition of deliverables, and whether explanatory materials are provided—you can more easily avoid unnecessary trouble.

A common thread in these failures is treating the specification only as a submission document. In reality, a specification is meant to link the client's expectations, the contractor's work, and the post-delivery use into a single document. Simply taking a little time to organize it carefully before estimating can greatly reduce the burden on downstream processes. Although organizing specifications before placing an order may seem tedious, it is actually the most efficient form of quality control.

Summary

When outsourcing work that includes 3D measurement and GNSS, the quality of the specification directly determines how usable the deliverables will be. What matters is not adding more complicated technical terms, but organizing the purpose, scope, accuracy, coordinate conditions, deliverables, and verification methods in an order that will not be misunderstood on site. If you think along the five steps introduced in this article, it becomes much easier to see what should be explicitly stated as ordering conditions.

First, clarify the purpose of the measurements and the intended use; next, organize the target scope and site conditions, and on that basis specify the accuracy requirements and coordinate conditions. Furthermore, formalize the data specifications so the deliverables are genuinely usable after delivery, and finally finalize the work structure, validation methods, and delivery conditions. Organizing the process in this way reduces gaps in understanding between the client and the contractor, makes it easier to compare estimates, and minimizes rework after delivery.

In particular, going forward, opportunities to use point cloud data continuously—not just to check it once—but for construction, maintenance, update records, and comparative verification will increase. What becomes important then is an operation that can handle shape information and position information together. In other words, clarifying how to combine 3D measurement and GNSS before procurement directly links to future work efficiency.

If, from the specification-drafting stage, you want to make on-site positioning simpler, naturally link high-accuracy positional information to point clouds and photos, and operate with a view to comparing re-measurements and integrating with registers, structuring your workflow around an iPhone-mounted high-precision GNSS positioning device such as LRTK can also be effective. By designing specifications based on a system that is easy to use in the field, the accuracy of procurement documents improves and the range of uses for the acquired 3D data expands. Specifications are not something that is completed on paper; they are the blueprint that connects the field and data utilization. For that reason, taking the time to organize things thoroughly before placing orders is the shortest route to successful 3D measurement and GNSS utilization.