Six requirements to clarify before consulting about RTK implementation

Table of Contents

• Why Preparing Before Consultation Is Important for RTK Implementation

• Requirement 1 Decide the accuracy requirements first

• Requirement 2 Clarify which tasks it will be used for

• Requirement 3: Align coordinate systems and deliverable conditions

• Requirement 4: Organize correction information and the communication environment

• Requirement 5: Solidify the operational structure and on-site workflow

• Requirement 6: Have an approach to budget and scalability

• How to Communicate to Make RTK Implementation Consultations Go Smoothly

• Summary

Why Preparing Before Consultation Is Important for RTK Implementation

When considering the introduction of RTK, many sites tend to start by comparing equipment and checking prices. However, what actually determines success or failure is the preliminary clarification of requirements rather than the equipment itself. No matter how high-performance an RTK device may appear, if you implement it while the required accuracy is vague, the communications environment has not been adequately checked, and the conditions for deliverables have not been decided, usability problems will dominate on site. As a result, you may find the system used far less than expected, operable only by specific personnel, or that you revert to the traditional paper workflow.

RTK is not merely a tool for measuring positions. It is a system that touches the entry points of various tasks—surveying, as-built verification, stakeout/layout, inspection, assessment of current conditions, construction records, photo management, and alignment with point clouds. That is why it is important to clarify what you want to achieve before consultation. If your objectives are clear, it becomes easier to select equipment, determine the necessary peripheral functions, and design operational methods. Conversely, if you start consultations with vague requirements, discussions tend to skew toward device specifications and actual operational challenges are likely to be left behind.

One common mismatch in implementation consultations is that the client thinks, "I just want to use RTK to improve efficiency," while the proposer wants to confirm "which accuracy band, which method, and which tasks it will be applied to." Bridging this gap requires requirements clarification. If you can verbalize the site conditions before the consultation, the other party can make more appropriate proposals and post-implementation mismatches can be reduced.

In particular, RTK is less a standalone product than an operational system that only functions once multiple elements—receivers, terminals, correction information, communications, apps, coordinate settings, and results management—are combined. For that reason, you need to organize not only what to buy but also how you will use it. Aligning requirements before consulting is useful not only to improve the accuracy of proposals but also to advance internal consensus. When explaining to superiors or other departments, decisions are reached more quickly if it is clear why the system is being introduced, which operations will start first, and what level of benefit is expected.

Moreover, when introducing RTK, the points emphasized differ between field personnel and managers. Field personnel prioritize portability, connection stability, and ease of operation, while managers emphasize cost-effectiveness and the prospects for continued use. In addition, surveyors and designers who receive the deliverables are concerned with the consistency of coordinate systems and data formats. If these differing perspectives are not sorted out before consultations, no proposal is likely to be decisive. Requirements clarification is not merely preparation; it is also the task of aligning stakeholders’ viewpoints on a single foundation.

In this article, we explain the six key requirements you should at least have organized before consulting about RTK implementation. None of them need to be treated as difficult technical jargon. What matters is that you can put your company's or your site’s assumptions into words well enough to explain them during the consultation. Simply being able to do that will make it much easier to advance discussions about implementation.

Requirement 1: Decide the accuracy requirements first

When introducing RTK, the first thing you should clarify is what level of accuracy is required. If you start considering RTK based only on the term, you tend to stop at the vague understanding that it can provide high-precision positioning, but in practice the most important question is what you will use that accuracy for. Some tasks truly require centimeter-level accuracy, while others are perfectly adequate without being that strict. If you consult while leaving required accuracy ambiguous, you may end up with an over-specified configuration that drives up costs, or conversely fail to meet the necessary standard and have to reconsider.

For example, when confirming current positions or recording the approximate locations of equipment, an accuracy sufficient to grasp the overall site may be adequate. On the other hand, in situations that require as-built control, layout marking, verification of reference positions, or consistency with point clouds and design data, positional deviations can directly lead to rework and quality problems, so a stricter approach to accuracy is necessary. Even when using the same RTK, the degree of careful operation and the verification methods required will vary depending on the level of work demanded.

One thing to be aware of is that the term "accuracy" is not a single concept. In the field, accuracy is evaluated from multiple perspectives, such as momentary variation in positioning, repeatability when measurements are taken repeatedly, offsets relative to known points, and stability in obstructed environments. Before consulting on deployment, you need to at least clarify what you consider to be sufficient. Simply assuming that higher accuracy alone is enough will not lead to successful real-world operation.

Additionally, the required level of accuracy is closely tied to how the deliverables will be used. Whether you want to attach precise position information to record photos, record survey points with coordinates, or use the data for comparison with design data will change the level required. If this is left vague, even if site personnel find it convenient, the data may become unusable in later processes. The value of RTK is realized only when the acquired positional information can be utilized in subsequent tasks.

What you should clarify before consultation is, first, how much error can be tolerated. Next, consider whether that level of accuracy must be required at all times or only for specific processes. It is not necessary to demand the same accuracy across all processes. For example, you can design the system so that routine records are kept in a simplified way and strict procedures are applied only during important verifications. If these operational divisions are determined, it becomes easier to narrow down the necessary configuration during an implementation consultation.

Furthermore, accuracy requirements should also include verification methods. If you do not decide how to confirm that accuracy, you will not be able to determine whether it will be usable after deployment. Whether you verify using known points, assess stability through multiple observations, or compare with other surveying methods, having a clear idea in advance will make it easier to receive concrete operational proposals from the party you consult.

A common mistake in RTK consultations is expressing the required accuracy as "as high as possible." That phrasing may sound reasonable at first glance, but it does not lead to a decision about implementation. What matters is not whether the accuracy is high or low, but whether it is sufficient for your company's operations. If you can clarify the accuracy requirements, the direction of RTK implementation becomes much clearer. Sorting this out first makes it easier to determine subsequent requirements naturally.

Requirement 2: Make clear which tasks it will be used for

The second thing to clarify is the use case: which tasks RTK will be used for. Because RTK has a wide range of applications, if you set the purpose of deployment too broadly, operations can become ambiguous. While it may seem like it can be used for anything, in practice the preparations required and the compatibility vary by task. Therefore, before consulting about deployment, it is important to first narrow down the specific operations you want to apply it to.

For example, the required features will differ depending on whether you intend to use it for pre-construction site condition checks, for positioning and verification during construction, or for record-keeping and management after construction. If site condition checks are the primary focus, the ability to record large areas efficiently becomes important. If positioning and verification are the focus, immediacy on site and clarity of the display are important. If the main use is for construction records or maintenance management, it is important that captured location data can be easily linked to photos and attribute information.

Thus, even with the same RTK mechanism, the evaluation criteria change depending on which process it is integrated into. If you clarify your operations before an implementation consultation, you can judge not only equipment comparisons but also how easily it can be incorporated into on-site workflows. Conversely, if you consult without deciding the use case, proposals will be broad and shallow, and it will become unclear which site you should actually start with.

Clearly defining the tasks to be used is also indispensable for measuring the effects of implementation. For example, effects such as a reduction in the number of trips, less transcription of handwritten records, fewer repeat visits, and faster decision-making in verification tasks cannot be measured unless the target operations are specified. To make it easier to get approval for implementation within the company, an explanation that it will simply be “convenient” is weak; you need to show what will change, in which process, and how. For that reason as well, clarifying the target operations is important.

Additionally, you need to assess compatibility with site conditions. RTK is easy to use in open-sky environments, but there are situations—adjacent to buildings, under trees, near slopes or embankments, in mountainous areas, and in narrow urban spaces—where positioning tends to become unstable. Therefore, by clarifying what kinds of environments the tasks you want to introduce will be carried out in, you can confirm realistic operating conditions during consultations. Even if it seems usable on paper, if it is not stable at the actual primary work locations, the benefits of implementation will be limited.

What you should keep in mind here is not to assume deployment to all operations from the outset. When introducing RTK, it tends to take hold more easily if you start with a subset of tasks that are a good fit. Starting small and expanding the scope once you can see the effects makes it easier to gain internal buy-in and to advance on-site training. Before consulting, it’s a good idea to distinguish between the tasks for initial implementation and those you want to expand to in the future.

Who will use it is another element that should be clarified at this stage. The required level of ease of use changes depending on whether a dedicated surveyor will use it, a construction management staff member will use it as an additional duty, or it will be shared across multiple sites. The topics to discuss will also differ depending on whether operation can assume advanced settings or you want to run it with as simple an operation as possible. By considering the target tasks together with the users, the conditions for practical RTK implementation become clear.

What will you use RTK for? Simply being able to answer this question specifically will greatly change the quality of consultations about its introduction. The clearer the situations in which it will be used, the easier it is for the consultant to propose an appropriate configuration and operational method. First, clearly identifying the task from which you want to achieve results is the first step to a successful introduction.

Requirement 3 Align the coordinate systems and deliverable conditions

One thing that is often overlooked in consultations about introducing RTK is the coordinate system and the requirements for deliverables. If you proceed under the assumption that it is sufficient as long as positions can be obtained on site, you may later encounter problems where the data does not match existing drawings, point clouds, or design information. While RTK can handle positions with high accuracy, ambiguous handling of coordinates prevents you from fully leveraging that accuracy. For that reason, it is necessary before implementation to clarify what you want to produce as deliverables and under which coordinate conditions those outputs will be used.

For example, if you are simply recording positions on site, you might operate without requiring strict management of absolute coordinates. However, if you consider survey point management, updating drawings, point cloud alignment, comparison with design data, as-built verification, and linking to future maintenance management data, consistency of coordinate systems is extremely important. Even if you think you are dealing with the same location, they will not coincide if the reference or settings differ.

What I want to clarify here is, first, the way coordinates used in existing operations are thought of. Are you using a site-specific local coordinate system, using an official/public coordinate system as a reference, or does it vary by project? Depending on this premise, the settings and the approach to transformations required when introducing RTK will differ. If this point is not shared during consultation, you may be able to take measurements on site, but extra work will increase during the delivery or internal sharing stages.

When it comes to deliverables, it is important to clarify what you want the final output to be. Whether it is merely a record of points, location information with photos, coordinate data for drafting, or intended to be combined with point clouds or orthophotos, the required formats and attributes will vary. Before implementation consultations, it is helpful to distinguish whether the location information will be used for on-site viewing or will be reused in subsequent processes.

Also, the conditions for the deliverables must include the perspective of who will receive the data. If the task is completed solely by on-site personnel, a format that is easy to use should be prioritized; however, if the data will be passed on to others such as design engineers, surveyors, clients, or maintenance departments, compatibility and ease of explanation become important. The usefulness of RTK data is not simply that positions can be determined on the spot, but that it can be combined with other data. To realize that value, you need to be aware of the deliverables’ downstream use before implementation.

Furthermore, the handling of elevation is a point that must not be forgotten. It is easy to focus only on planar position, but in practical work there are many situations where the handling of height is important. If the height reference is ambiguous, the planar positions may be correct yet unusable for construction or comparison. When consulting, it is desirable to be prepared to indicate whether only the planar position is sufficient or whether height should also be given importance.

Getting coordinate systems and deliverable conditions in order before a consultation is not the same as having perfect, hard-to-acquire specialist knowledge. What matters is clarifying what standards you use in your current work and where you want the data collected with RTK to flow. If you can do this, the person you consult will find it easier to propose the necessary settings, checks, and post-deployment data integration.

Even if you introduce RTK, if the collected data remains confined to the site, its range of use is limited. Conversely, if the coordinate system and deliverable specifications are organized, location information becomes an internal asset. It then becomes easier to leverage it for future comparisons, rework, maintenance, and point cloud applications. Addressing this before implementation is the key to preventing RTK from ending up as a one‑off convenience tool.

Requirement 4: Organize correction information and the communication environment

The fourth requirement is how correction information is received and the communication environment. RTK cannot always be used the same way with only a receiver; operability depends greatly on how correction information is obtained. If this premise is not clarified before consultation, then even if equipment selection proceeds, problems can arise—such as being unable to use it in the field or having to spend time configuring it each time.

RTK requires correction information to improve positioning accuracy, but there are several approaches to receiving that information. Some sites are better suited to a network-based method, while others are better served by relying on an on-site reference station. Which is appropriate depends on the usage area, connectivity conditions, site size, frequency of ongoing use, and operational arrangements. Before consulting about implementation, it is important to understand how stable communications are at the primary locations of use.

On site, even if communication is possible under normal conditions, it can become unstable in cut sections, beneath slope faces, in mountainous areas, around underground structures, and in parts of temporary yards. In urban areas there are also situations where stability is affected by buildings or by communication constraints on the device. When introducing RTK, not only satellite reception but also the reliability of communication is equally important. If correction information cannot be received reliably, work will stop before accuracy even becomes an issue.

Organizing the communications environment requires more than simply checking whether there is a signal. You need to consider operational aspects such as whose devices will be used, how communication contracts will be handled at each site, whether to rely on tethering, whether dedicated lines are necessary, and whether simultaneous use by multiple people is anticipated. If these points are left unclear, you may encounter no problems during pilot runs, but in live operation different staff members may use different connection methods, which can lead to an increase in problems.

When handling correction information, initial setup and daily connection procedures are also important. Operations that require complex on-site configuration every time are difficult to sustain. In particular, when construction management staff use the system as part of other duties, it is important that it can deliver consistent results even without specialized knowledge. Before consulting, clarifying whether users can spend time on daily setup or require the simplest possible startup will lead to more appropriate recommendations.

Furthermore, correction information and the communication environment are related to the expected working time. For short verification tasks, some connection setup can be tolerated, but for jobs used throughout the day, connection stability, battery consumption, and ease of reconnection become important. If communications are cut off repeatedly during work, on-site personnel will gradually stop using it. An RTK system that should be convenient ends up being perceived as a cumbersome piece of equipment.

The important thing here is not to quickly assume that RTK is impossible just because communications are weak at a site. What matters is to organize the main operating areas and their conditions, and to consider realistic methods. Because sites do not always have the same conditions, it is important to grasp site tendencies, decide how far to make standard operations, and plan how to handle exceptions.

When consulting on RTK deployment, being able to explain correction data and the communications environment concretely will significantly affect the quality of proposals. It allows the advisor to discuss communication dependence, ease of operation, and stability, making it easier to reduce problems after deployment. As much as accuracy, how correction data is received is fundamental to RTK operation. Identifying the key site conditions before consultation leads to a more practical implementation.

Requirement 5 Solidify the operational structure and on-site workflow

The fifth thing to organize is the operational structure and the on-site workflow. RTK will not become established just by introducing high-performance equipment. Who takes it out, who configures it, who checks the data, and who stores it? If this flow is not defined, the frequency of on-site use will quickly decline. Before consultations about adoption, you need to consider not only the equipment but also the operational framework for how it will actually be run.

In many cases, equipment ends up unused on site not because of insufficient performance but because of ambiguous operational procedures. For example, if settings differ between operators, the storage location for collected data has not been decided, how to report measured results is not standardized, or responsibility for charging and maintenance is unclear, RTK becomes not a convenient tool but a tool that only some people can use. Before seeking implementation advice, it is important to have at least a basic usage workflow in mind.

First, you should clarify who the primary users will be. Whether it will be handled by dedicated surveyors, used daily by construction managers, or shared among multiple people affects the required level of training and how simple the setup needs to be. If dedicated staff are assumed, operation that includes fine adjustments is possible, but if it will be used alongside other duties, the operation needs to be as straightforward as possible to avoid confusion. During consultations, being able to convey the expected users’ skill levels and the approximate number of users makes it easier to choose a configuration that is simple to implement.

Next, consider where to incorporate it into the on-site workflow. Whether you take the equipment out and use it after the morning briefing, prepare it only for specific processes, or integrate it as part of the recording tasks will affect the required preparation time and procedures. To incorporate RTK into the daily routine without strain, it is important to find points where it can naturally replace existing work without significantly disrupting current operations.

Also, data management rules are indispensable. Decide whether you will simply check positioning results on site, save them to an internal server or the cloud, link them with photos or drawings, or organize them by project—if you do not, the location data you worked hard to obtain may become impossible to find later. The value of RTK lies not only in being able to verify on site but also in being able to trace records afterwards. Therefore, it is desirable to determine where data will be stored and the approach to naming conventions before implementation.

Additionally, an educational and support perspective is necessary. New systems do not become established after a single explanation. In particular, with RTK, if people do not understand why a setting is necessary or why it needs to be checked on site, steps are likely to be skipped. Before consultations, it is advisable to consider realistic arrangements such as how much training can be provided during the initial deployment, whether you can set up an internal point of contact for questions, and whether simple manuals can be produced.

When considering the operational setup, you must not overlook how failures and incidents are handled. If it is unclear who will handle what when issues arise—such as inability to connect, unstable positioning, or settings being changed—on-site teams will quickly stop using the system. Before seeking consultation, decide whether first-line response will be handled internally or the vendor will be consulted, and clarify the communication flow; doing so will change the sense of security after deployment.

Companies and sites that successfully implement RTK have something in common. They think through the workflow first, not just the performance of the equipment. When to start it, where to check it, who to hand it to, and how to document it. When such a workflow exists, RTK becomes integrated into daily operations. Conversely, without a workflow it will end up as nothing more than initial buzz. Organizing the operational setup before consultation directly leads to creating a system that will continue to be used after implementation.

Requirement 6: Have a way of thinking about budget and scalability

The sixth requirement is budget and scalability. When introducing RTK, attention tends to focus on initial costs. However, what you should really consider is not the implementation cost itself but the design of what to invest in and how far to scale. If you consult with a vague idea of the budget, you may later find shortages from comparing only on price, or conversely make an excessive investment by including features you will not use in the future.

First, you should clarify what to prioritize with respect to the purpose of the deployment. Whether you want to test it quickly, roll it out across multiple sites, prioritize ease of use for on-site staff, or emphasize integration with existing data will change which areas you should invest in. If you judge solely by the upfront hardware price, you tend to overlook peripheral operating costs, training costs, communication fees, and the burden of handling updates and maintenance.

Also, RTK is not something you install once and be done with; its value increases as its range of use expands. Therefore, it is important to separately consider the initial scope of deployment and how far you want to extend it into future operations. If you adopt a phased approach—initially limited to only some sites, then expanded to multiple personnel, and later bringing records management and point-cloud integration into view—it becomes easier to make a realistic investment decision.

When considering scalability, it's also important to think about which devices and workflows you want to connect in the future. Whether you limit the system to on-site records or connect it to design data, photo management, construction management, and maintenance management will change the flexibility required. Before consulting about implementation, envisioning at least the scope of use you expect over the next two to three years will make it easier to avoid a mere stopgap implementation.

Furthermore, when considering the budget, it is helpful to clarify how you will evaluate cost-effectiveness. The benefits of implementing RTK appear in multiple forms—not only as direct increases in revenue but also as reductions in travel time, fewer remeasurements, improved recording accuracy, easier internal explanations, and the ability to utilize data in downstream processes. Deciding in advance whether to assess benefits including these factors or to use time savings alone as the initial evaluation axis will make the adoption decision easier.

What you should be aware of here is that a low-cost configuration does not necessarily mean low operating costs. If every setup takes a long time, connection problems occur frequently, or data organization is labor-intensive, hidden on-site costs will grow. Conversely, even if the initial expense seems somewhat higher, if the system offers high reproducibility in the field, is easy for multiple people to operate, and makes it easy to preserve results, it can be easier to recoup the investment over the long term. Budgeting should consider not only the purchase price but also the practical costs of continued use.

Before seeking consultation, it is important to have, in addition to a basic sense of your minimum budget, a guideline for judging how far it is worth investing. For example, whether a single unit is sufficient at first, whether you are aiming for multiple users, whether you want to start with a pilot implementation, or whether you intend to proceed to company-wide standardization will greatly change the direction of any proposal. If this is unclear, it will be difficult to judge whether a received proposal is overpriced or reasonable.

RTK is an area where choosing solely based on price often leads to failure, and choosing solely based on a future vision makes it hard to achieve lasting adoption. What’s important is to separate what you need now from what you want to expand in the future. If you clarify your budget and scalability requirements, implementation consultations become not just requests for quotes but opportunities to design investments that fit actual operations. Doing so will greatly reduce regret after deployment.

How to Communicate to Make Consultations for RTK Implementation Go Smoothly

We've reviewed six requirements so far, but it's also important to put the points you've organized before the consultation into a form that the other party can understand. If you only have a vague understanding in your head, the conversation tends to become scattered during the consultation. What matters is not creating complicated materials, but being able to briefly explain the on-site assumptions.

For example: which operations do you want to use it for, how much accuracy is required, what are the main site conditions, what coordinates or deliverables are being assumed, who will operate it, and how far does the initial deployment extend? Simply having these items organized makes consultations much more concrete. It also makes it easier for the other party to discuss matters in line with actual operations rather than merely giving a product explanation.

In implementation consultations, it is often more effective to communicate on-site problems as they are rather than listing only ideals. For example, these might include frequent revisits to survey points, the time-consuming transcription of position records, variability in recording accuracy between staff, difficulty correlating photos with locations, and difficulty linking point clouds or drawings with on-site information. If you convey these problems together with the six requirements, the consultation will move a step beyond superficial equipment selection.

Also, it is important to align the consultation points within the company. Even if only frontline staff are positive, implementation will struggle to move forward if managers do not understand the cost-effectiveness, and conversely, if only managers rush implementation, it will not take hold if the frontline finds it difficult to use. Before consulting, share at least four items—purpose, target tasks, operators, and expected benefits—to reduce misalignment after implementation.

Recently, inquiries about operating RTK in a form that is easy to handle on-site by combining it with an iPhone have been increasing. Even in such cases, what matters is not just the newness or convenience of the device but clarifying which requirements you want to satisfy. For example, the appropriate configuration changes depending on whether you prioritize immediacy of position recording, portability, or planning for deployment across multiple sites. Even if there are options that make on-site operation easy—such as an iPhone-mounted high-precision GNSS positioning device like LRTK—if requirements are not organized, you cannot make a proper comparison. Deciding the requirements in advance makes it easier to calmly and clearly assess differences between equipment and methods.

The key to smoother consultations is not to wait until you fully understand before speaking. Rather, it is more important to convey the on-site conditions accurately—neither more nor less. If you address six requirements, the implementation consultation will shift from mere information gathering to a review that can lead to actual implementation.

Summary

Before consulting on RTK implementation, the requirements you should clarify are six: accuracy requirements, target operations, coordinate systems and deliverables, correction information and communication environment, operational structure, and budget and scalability. Each may look like a basic item on its own, but in practice the consultation only becomes concrete when all six are in place. Conversely, if even one of them remains ambiguous, it often causes the system to be unusable as intended after deployment.

RTK is not just equipment for obtaining high-precision positional information. It can be a system that serves as the foundation for business improvement, encompassing on-site recording, verification, sharing, and reuse. That is why, at the consultation stage, you should not look only at the equipment but consider how it connects with the overall operations. Sites where implementation succeeds always have done their preparatory work before consultation. That is because they have clarified what they want to achieve, where to start, and how to operate it.

If you are considering introducing RTK, I recommend first writing out six requirements in your company's or your site's own words. You don't need to create a complicated document. Simply writing down the issues you're facing on site, the required accuracy, the main places of use, how the data will be used, the operators, and your budget expectations is enough. Once you have that organized, the quality of implementation consultations will improve significantly, and it will also make comparing proposals easier.

RTK, when introduced without sufficient preparation, tends to end up as an expensive piece of equipment; when introduced after clarifying requirements, it becomes a powerful tool for improving on-site operations. Understanding what needs to be prepared before consulting on implementation is the quickest way to move toward practical use. To realize RTK operations suited to the site, it is important to start by articulating the requirements.