4 Basic Points to Avoid Confusion in RTK Coordinate Systems
By LRTK Team (Lefixea Inc.)
One of the things that trips up sites that have just introduced RTK more than you might expect is understanding coordinate systems. The receiver may be working normally and a fix obtained, so there appears to be no problem, yet results don't match the drawings, don't coincide with known control points, don't overlap with data measured on another day, or are offset from the results of other personnel. Such troubles are often caused not only by equipment failure or degraded satellite reception, but also by operating with an ambiguous approach to handling coordinate systems.
RTK is widely used as a high-precision positioning technology, but simply measuring positions does not make them immediately usable. What is needed on site is to sort out the prerequisites: which coordinate system the acquired position information will be handled in, how it will be reconciled with existing drawings and design coordinates, and how to understand the geodetic datum and the handling of heights. If these points remain ambiguous, even though centimeter-level positioning can be achieved, the results will be difficult to use.
In practice, geographic coordinates expressed as latitude and longitude, public coordinates handled in the plane rectangular coordinate system, site-specific local coordinates, and even height information such as ellipsoidal heights and elevations tend to be mixed together, making this an area that can confuse not only beginners but also experienced practitioners. Moreover, mistakes in coordinate systems are hard to detect on the spot and often become problems later on, so establishing operational rules is extremely important.
This article narrows the basics you should grasp first down to four points so you won’t get confused about RTK coordinate systems. Instead of merely listing difficult terms, it organizes—from a practical, on-site perspective—what to check, what to align, and how to think in order to prevent offsets, tying these to the confusions and judgment errors that are likely to actually occur in the field.
Table of Contents
• First, clarify what a coordinate system is
• Ensure the zone number of the plane rectangular coordinate system is correctly matched.
• Do not confuse the geodetic datum with the height reference.
• Determine the transformation to local coordinates down to the operational rules.
• Summary
First, clarify what a coordinate system is
The starting point for avoiding confusion about coordinate systems in RTK is to properly understand what a coordinate system actually is. In the field, the term "coordinate" is used routinely, but it is not uncommon for operations to be carried out without a deep awareness of what it actually means. However, in RTK, if this premise is left vague, discrepancies and confusion will inevitably surface at some stage.
A coordinate system is a set of rules for expressing positions on Earth as numbers. Even for the same location, the numerical values shown change depending on which set of rules is used. For example, expressed in latitude and longitude it takes the form of degrees north and degrees east, while in a plane rectangular coordinate system it is given as X and Y values. Furthermore, if a site's own local coordinate system is used, it becomes different numbers representing distances from an origin. In other words, even though the position itself is the same, there are multiple ways to represent it.
The important point here is that when you look at the values shown by an RTK receiver, you cannot correctly interpret the meaning of the position unless you understand what rules those values are based on. For example, if you cannot tell whether the screen is displaying latitude and longitude, plane rectangular coordinates, or values that have already been converted to a local system, you cannot compare them with design drawings or known points. There is a difference between numbers being displayed and those numbers being usable.
A common situation in the field is that person A is viewing data in a plane rectangular coordinate system while person B is checking it with latitude/longitude displayed, and although both believe they are "looking at the same point," their conversation doesn't align. Furthermore, they may not notice that the software is performing automatic conversion and end up confusing the coordinate system of the source data with the display coordinate system. Such discrepancies are hard to detect without an understanding of the concept of coordinate systems, and on-site they tend to be dismissed as mere operational errors.
In RTK, based on information obtained from satellites, a position referenced to the entire Earth is first determined. From there, it is common to convert that into a form that is practical for use in the field. In other words, the coordinate values you see on site are both the final result of the positioning and the result of multiple conversions. If you do not understand this flow, you will not be able to isolate at which stage a discrepancy occurred when a problem arises.
When trying to understand coordinate systems, what beginners should first be aware of is that "coordinate values alone are not enough." What is necessary is which coordinate system is being used, which geodetic datum, what the vertical datum is, and whether the values are original data or have been converted. Even if you receive a string of numbers, if the rules associated with them are unknown, the results cannot be considered correct.
In the field, it is common for the positioning team, drawing team, construction team, and management team to use different software and equipment. As a result, even if each person uses the same word "coordinate," the coordinate system they have in mind may not match. This can cause problems such as measured points being unusable, not loading into machine guidance for heavy equipment, or discrepancies when comparing as-built results to design values. Understanding coordinate systems is essential not only for individual knowledge but also for creating a shared understanding across the entire team.
Furthermore, especially in the early stages of RTK adoption, people tend to think "it's high-precision, so we can fine-tune details later," but the opposite applies to the coordinate system. If the coordinate system is not correct, no matter how accurately you measure, the results will not agree. If offsets of tens of centimeters, meters, or in some cases more caused by a coordinate system mistake are mixed into a world where errors are contained within a few centimeters, the whole discussion about accuracy no longer makes sense.
Therefore, before using RTK, the first things you should check are not just reception status or communication status. You need to clarify what coordinate system the data you are about to handle uses, what coordinate system existing drawings and known points use, and what coordinate system the destination software assumes. Doing this at the outset will prevent many problems.
Understanding coordinate systems is not about memorizing all the difficult theories. What is needed in the field is to strongly keep in mind three things: "the coordinate values for the same location can change depending on the coordinate system," "you need the reference information as well as the numbers," and "if everyone does not handle them according to the same rules, the results will not match." If you have this basic understanding, it will be easier to organize the following discussion of the plane rectangular coordinate system and geodetic systems.
Ensure the Zone Number of the Plane Rectangular Coordinate System Is Correctly Matched
In practical RTK work in Japan, the most basic yet often the biggest cause of trouble is the zone number setting of the plane rectangular coordinate system. When drawings and coordinates on site don’t match, this is one of the first items to suspect. Even if the Fix is stable and the receiver is in good condition, if the zone number is different the results will not align.
The plane rectangular coordinate system divides all of Japan into multiple zones and handles coordinates using a projection method appropriate to each zone. In Japan it is divided into 19 zones, and the zone that should be used varies by region. This system exists to make the Earth's curved surface easier to handle by projecting it onto a plane, but from a user's perspective it is easier to understand as a practical rule: "you need to choose the correct zone corresponding to the site."
What you need to be careful about here is that even a difference of a single coordinate-system number can result in more than a slight offset. If you select the wrong system, the values may look plausible numerically, but the actual positional relationships will be greatly distorted. On some sites the discrepancy can be hundreds of meters or even larger. Therefore, you must not take the mere presence of coordinate values as reassurance. What matters is whether those values were calculated in the correct coordinate system.
A common situation in the field is bringing equipment from another site with the previous settings still in place. For example, you may have used a particular system/zone at a site in a different prefecture last time, and this time—although it’s a different area—you might carry out positioning without reviewing the settings. It’s also not uncommon for the coordinate-system setting to differ in just one place among the receiver unit, the controller, the design data, and the CAD software. Be especially careful when passing data through multiple pieces of software, because the coordinate system information may not be explicitly indicated along the way and only the numeric values may be transferred.
To avoid confusion with the plane rectangular coordinate system, you should first clearly confirm "which coordinate system this site uses." Design documents, existing survey results, control point result tables, contract drawings, and construction-coordinate setup materials typically include information about the coordinate system in use. If the documentation is ambiguous, confirm with the site supervisor, the surveying staff, the prime contractor, and the design team, and align everyone’s understanding. As a rule, base your decisions on the original source documents rather than on the equipment’s settings screen.
Next, it is important to verify with known points that the coordinate system you set is actually correct. Even if you think you have configured it correctly at the desk, another transformation may have been applied during operation. By observing known points and checking the difference from the expected values, you can at least detect major coordinate system number errors at an early stage. If you skip this check, an entire day's worth of surveying or layout results could become invalid.
Also, when dealing with plane rectangular coordinate systems, it is important not only to know which system is being used but also to manage whether everyone is working in the same system. For example, if the surveyor records points in System No. 9 and the drafter imports them into CAD under System No. 8, each may think they are working correctly but the results will not match. These kinds of problems occur more from the lack of verification rules within the team than from individual knowledge deficiencies.
Therefore, on-site it is effective to share in advance—via documents or checklists—"which coordinate system (which system number) will be used," "what coordinate system the input data uses," and "which format to use for output." Relying solely on verbal communication makes omissions more likely the busier the site is. Especially when multiple teams are working simultaneously, whether or not there are unified rules for coordinate systems can greatly affect the workload of subsequent data integration.
When using the plane rectangular coordinate system, extra caution is needed if the site is located near the boundary of a coordinate zone. Usually following the original source material is sufficient, but when overlaying data from neighboring municipalities or other project sections, the other party’s coordinate system may differ. Even if there are no issues when looking only at your own site, discrepancies can surface when connecting with other sections or with data from previous years. If data linkage is expected, it is important not to limit your coordinate-system checks to the extent of your own site.
Additionally, depending on the equipment manufacturer or software, the way the plane rectangular coordinate system is represented can differ subtly. Some clearly display the zone number, others allow selection based on region name, and others treat it as part of the projection settings. These differences can lead to situations where you think you chose a similarly named option but the settings are actually misaligned. Don’t be complacent just because a screen looks familiar; make it a practice to check each setting item one by one.
The important point is that an error in the plane rectangular coordinate system looks different from poor positioning accuracy. Poor accuracy appears as scatter and poor repeatability, whereas a wrong coordinate system zone number often shows up as a constant offset while the observations themselves appear stable. Therefore, when you have a fix but the position doesn't match, or repeated measurements at the same spot remain offset, you should suspect the coordinate system zone number before blaming communications or the number of satellites.
To achieve consistent results in coordinate management using RTK, it is important not to treat the plane rectangular coordinate system as merely a configuration setting. It is the very foundation of the deliverables and a common language that links drawings, design, construction, and inspection. For that reason, you should make four practices routine: checking before entering the site, verifying at known points, ensuring consistency within the team, and explicitly documenting it when transferring data. Doing just this will greatly reduce RTK coordinate troubles.
Do not confuse the geodetic datum and the vertical datum
When trying to understand RTK coordinate systems, attention tends to focus only on planar positions, but in practice it is also crucial not to confuse the geodetic datum with the height reference. Among consultations about mismatched coordinates, there are quite a few cases where the cause is not only a mistaken planar coordinate system code but differences in the geodetic datum or inconsistencies in the height reference. Because these issues are not readily apparent, pinpointing the cause often takes longer.
First, a geodetic datum is the framework that defines which reference is used to specify positions on the Earth. Coordinate data handled in Japan include some based on the currently mainstream datum and some created under past datums. From a practical standpoint, it's good to understand that "old drawings and results may differ from the datum you're using now." If you ignore this and simply overlay past data and RTK results, you can get offsets of tens of centimeters or more (several inches to over a foot). Even if RTK advertises centimeter-level accuracy (half-inch accuracy), if the datum itself is different, they naturally will not align.
Particular attention is required when reusing existing control points, old ledgers, or construction data from previous years. On site there are many cases where people decide to refer to previous results as-is, but it is dangerous to use that data without confirming which geodetic datum or coordinate system it was defined in. If you judge it to be correct just because the numbers look similar, you may later find that the whole dataset is slightly offset, and correcting it will take a great deal of effort.
Another aspect that often causes confusion in practice is how height is handled. RTK can provide height information, but if you don't understand what that height actually represents, it's easy to draw incorrect conclusions when comparing it with ground elevations or design elevations. The height the receiver obtains directly is often referenced to the ellipsoid, a mathematical representation of the Earth, and may not match the elevations normally used on site. For site personnel, a practical rule of thumb is to remember that "RTK height and the heights on drawings are not necessarily directly comparable."
If you use them without understanding this difference, you can experience cases where the horizontal position is exact but the height alone is off by tens of centimeters (several in), or where the elevation is consistently offset by a fixed amount during checks. In such situations you may suspect only receiver accuracy problems or antenna height input errors, but in reality the cause can sometimes be differences in the height reference. Height issues require you to be more conscious than with horizontal position of "what reference the values are based on."
To handle heights consistently on site, you should first check the vertical datum used in the design documents and control point data and confirm that the RTK output settings correspond to it. Furthermore, it is important to verify not only the horizontal position but also the elevation at known points and understand how much they differ from the expected values. If you only check the horizontal position and assume everything is fine, you may miss vertical discrepancies. This check should not be omitted, especially for tasks where vertical accuracy is critical, such as as-built management, excavation depth management, and pavement thickness management.
Also, problems with the geodetic datum and vertical reference occur when transferring data between software. When point clouds or coordinate lists output from receivers are imported into CAD or construction management software, the coordinate system information may be carried over while the handling of vertical conversion is not consistent. As a result, you can have the horizontal positions match but only the heights be wrong. This tends to cause considerable confusion on site, and different personnel often have different assessments of "what is wrong."
To prevent such confusion, it is important when transferring data to specify not only the planar coordinate system but also the vertical datum. Rather than handing over a coordinate file containing only numbers, you need to indicate which geodetic system is used, which height datum is being used, and whether any necessary transformations have been performed. The common on-site exchange of "I've entered these coordinates" alone will make it impossible to trace the root cause later.
One further point to note is that, even on the same site, the required strictness of elevation varies by process. For example, while a certain amount of error may be acceptable when checking an approximate position, small differences in finished elevations or in controlling the top of foundations directly affect quality. In other words, understanding elevation standards is not merely theoretical but also the basis for judging how strictly each process needs to be handled.
The geodetic datum and height reference are items that are difficult to keep consistently in mind at a job site. That is precisely why it is effective to establish fixed checkpoints as part of operations. If you decide in advance the documents to check before starting on-site work, the items to compare against known control points, and the notes to include when delivering data, you can reduce oversights even when busy. Relying solely on individual memory and experience will lead to the same mistakes being repeated when the person in charge changes.
When working with RTK coordinate systems, simply matching the planar zone number is not enough. You can only say that "the coordinates agree" after confirming that the geodetic datum matches and that the vertical reference is consistent with the design and control points. Common field issues such as "the horizontal position is correct but only the elevation differs" or "it differs slightly from last year's data" become easier to sort out simply by adopting this perspective.
Determine the conversion to local coordinates as part of the operational rules.
When it comes time to actually use RTK coordinate systems on site, they are often converted and operated as local or site coordinates rather than kept as public coordinates or the plane rectangular coordinate system. Especially at construction sites, it is often easier to work if you establish a convenient origin and orientation aligned with building or structure centerlines, temporary benchmarks, or construction baselines. Local coordinates are extremely useful, but if the rules are ambiguous here as well, the high accuracy of RTK can be easily compromised.
The advantage of local coordinates is that they can be represented as numbers that are easy to understand on-site. For example, values that would be in the hundreds of thousands or millions in a public coordinate system can be treated as small numbers representing distances from the site origin. Also, if the axes are aligned with the design drawings, setting out, as-built verification, and guidance of construction positions become intuitive. This is a major practical benefit and helps operate the site efficiently.
However, it is dangerous to convert to a local coordinate system lightly just because it is convenient. This is because, to transform coordinates obtained by RTK into a local coordinate system, the correspondence with the original public coordinates must be correctly defined. If that correspondence is inaccurate, the transformed coordinates may look consistent but their actual positions will be displaced. Moreover, if everything is confined within the local coordinate system, you may not notice that displacement for some time.
A common situation on site is creating a local transformation by matching only a few points at first, then continuing to operate without anyone verifying it. If the known points used for the transformation have low accuracy, if coordinate values were entered incorrectly, or if one of the points has moved, the entire local coordinate system will be displaced. Because the numbers still appear consistent within the site, the problem only becomes apparent when the data is later connected to public coordinates or to data from other work sections.
For this reason, when using local coordinates you need not only to create the transformation settings but also to establish their operational rules. First and foremost, it is important to clearly preserve the original coordinate system. If local coordinates are allowed to stand on their own, you may not be able to revert to a public coordinate system later or explain it to third parties. You should always record which public coordinate system was used as the reference, which points were used, and by which method the localization was performed.
Next, the selection of known points used for the transformation is also important. If there are too few points, the points are unevenly distributed, or accuracy checks have not been performed, the transformation results can become distorted. The accuracy of the local coordinates is not determined solely by the original RTK accuracy. The quality and spatial distribution of the control points used for the transformation have a major impact. In other words, even if the RTK is high-precision, if the localization procedure is sloppy the results will be unstable.
Furthermore, when local coordinates are used by multiple people, clarifying the rules becomes increasingly important. For example, if one crew sets out using local coordinates, another crew verifies as-built conditions using public coordinates, and the office manages design data with different software, then unless the coordinate transformation relationships are shared somewhere, the same point will be handled with different values. Not only does this increase the hassle of having to ask on site, "Which coordinate system is that point in?", but it also raises the risk of reusing incorrect coordinates.
What is effective when operating with local coordinates is to document a minimum set of rules before work starts on site. For example, if you decide on the definition of the origin, the X-axis direction, the original public coordinate system, the reference points used for the transformation, known check points for verification, and how to name output files, it will be easier to hand over operations even if personnel change. This is not only true for large sites. Even on small sites, if work continues for multiple days, whether records exist or not can greatly affect the amount of confusion later.
Local coordinates are convenient, but you need to be careful when integrating external data. When dealing with drone survey results, point cloud data, machine guidance data, client‑supplied design coordinates, or survey deliverables from other contractors, each may be based on a public coordinate system. In that case, if your site alone is self‑contained in local coordinates, you will need to perform conversions every time you overlay external data. Moreover, if the conversion procedure is not clearly defined, reinterpretation will occur each time and create a breeding ground for mistakes.
Therefore, even when using local coordinates, it is important to maintain the ability to restore the correspondence with the public coordinate system at any time. Work efficiently on-site using local coordinates, while ensuring you can revert to the public coordinate system for handovers with external parties. Thinking in this two-layer structure makes operations more stable. Using local coordinates itself is not wrong; the danger is losing the relationship to the original coordinate system.
Furthermore, in practice it is important to clarify the purpose of introducing a local coordinate system. Whether it is for ease of construction, alignment with drawings, or improving on-site management efficiency, the required accuracy and operational methods will differ. If you localize without a clear purpose, the management burden can become greater than the convenience. Deciding in advance on the purpose of implementation and the management items required for that purpose will help avoid unnecessary complexity.
Transforming to local coordinates may look like the final touch in RTK coordinate system operations, but in fact it is the aspect most influenced by site-specific practices and most prone to operational variation. Precisely for that reason, you must not rely solely on the operator’s intuition or on-the-spot decisions; it is essential to thoroughly record the original coordinates, save the transformation conditions, recheck at known points, and clearly state these details when handing over data. If these practices become routine, you can create sites where using local coordinates is unlikely to cause confusion about the coordinate system.
Summary
To avoid getting confused by RTK coordinate systems, it is more important to organize and clarify the foundational concepts that underlie coordinates than to rely on a high-performance receiver. Problems with coordinate systems are not like satellite reception or communications, which visibly become unstable; their danger is that even if settings are wrong, they can still appear to be working plausibly.
For that reason, they can suddenly become serious problems later in the form of not matching drawings, deviating from known points, having only the elevation different, or not integrating with other results.
First and foremost, you should understand that the position itself and the way that position is expressed are distinct. Even for the same point, the numbers will vary depending on whether you express it in latitude and longitude, a plane rectangular coordinate system, or local coordinates. That is why you must not look only at the reported numbers, but always confirm which coordinate system those numbers belong to. This is the first basic principle.
Next, in practical RTK work in Japan, matching the zone number of the Plane Rectangular Coordinate System is extremely important. If you do not confirm that the same zone is being used in all site documents, drawings, known points, receivers, controllers, and CAD software, the results will not match no matter how stable the Fix is. A mismatch in the zone number appears as a large positional shift, so make it a habit to check this first rather than confuse it with poor accuracy.
Furthermore, it is important not to confuse the geodetic datum and the vertical reference. In work that involves comparison with older results or height control, having only the horizontal position agree is insufficient. If you do not confirm which geodetic datum is assumed, what vertical reference is used, and whether the transformations are appropriate, you can end up with situations where the horizontal positions match but the heights differ, or where there are slight discrepancies with past-year results. This is caused less by RTK accuracy issues and more by a failure to reconcile differences in reference systems.
And when you introduce local coordinates because they are more convenient on site, don’t stop at the transformation settings—you need to define operational rules as well. Record the relationship with the original public coordinates, manage the control points used for the transformation, and maintain a state in which anyone who looks at them will have the same understanding. Local coordinates are convenient, but if the correspondence with the original coordinates becomes ambiguous, you will inevitably encounter difficulties connecting with external data and in downstream processes.
To create field sites where RTK coordinate systems don't cause confusion, you don't need to memorize all the especially difficult theory. What really matters on site is confirming which coordinate system you're using, verifying it with known points, sharing the same standards among all stakeholders, and not omitting coordinate system information when transferring data. Simply making these four practices a habit will prevent many coordinate-related problems.
RTK shows its true value not just as a measurement technology but when used as a technique for managing coordinates. Rather than focusing solely on receiver performance and fix rate, carefully handling the coordinate system—the foundation—leads to stable results, construction with fewer reworks, and reliable as-built control. Instead of treating coordinate systems as a difficult topic to be avoided, understand them as basic rules that protect the site and incorporate them into every operation; that is the shortest route to using RTK with confidence.
Next Steps:
Explore LRTK Products & Workflows
LRTK helps professionals capture absolute coordinates, create georeferenced point clouds, and streamline surveying and construction workflows. Explore the products below, or contact us for a demo, pricing, or implementation support.
LRTK supercharges field accuracy and efficiency
The LRTK series delivers high-precision GNSS positioning for construction, civil engineering, and surveying, enabling significant reductions in work time and major gains in productivity. It makes it easy to handle everything from design surveys and point-cloud scanning to AR, 3D construction, as-built management, and infrastructure inspection.


