Causes of Point Cloud Shifts in the Plane Rectangular Coordinate System and 6 Foolproof Correction Methods

For personnel using point clouds in the field, dealing with the plane rectangular coordinate system is an unavoidable topic. It is not uncommon to experience cases where the measurements themselves went well, but the moment you overlay them on drawings or design data the positions do not match; when you overlay point clouds acquired on different days they shift slightly; or they cannot be trusted when used for cross-sections or earthwork volume calculations. These problems are not caused merely by software operation mistakes, but arise from a combination of factors including assumptions about the coordinate system, handling of the geodetic datum, the vertical datum, the order of point cloud integration, and even computational quirks when handling large coordinate values. The Geospatial Information Authority of Japan defines Japan’s plane rectangular coordinate system in 19 zones, with the X axis positive to the north and the Y axis positive to the east. In addition, materials from the Ministry of Land, Infrastructure, Transport and Tourism outline the importance, in point cloud integration, of how to choose a base point cloud, ensuring common overlap, and appropriately shifting the origin before processing. In other words, it is important to understand that misalignments are not accidental but are typical practical problems that can be prevented in advance.

Table of Contents

• First, grasp the relationship between plane rectangular coordinates and point clouds

• Cause 1: The system number has been mixed up

• Cause 2 Geodetic datums and vertical reference systems are mixed

• Cause 3: The interpretations and units of X and Y are not consistent.

• Cause 4: Confusing local coordinates with public coordinates

• Cause 5: The order in which point clouds are integrated and the way reference data are selected are poor

• Cause 6: Processing with large coordinate values

• How to Proceed with Corrections Without Failure

• Summary

First, grasp the relationship between planar rectangular coordinates and point clouds

The plane rectangular coordinate system is a projected coordinate system designed to make positions in Japan easier to handle in practical work. According to the Geospatial Information Authority of Japan, the plane rectangular coordinates used in Japan are represented by the Gauss-Krüger conformal projection, and the country is divided into 19 coordinate systems. Furthermore, the scale factor on the meridian passing through the coordinate origin is 0.9999, and it is designed on the premise that the application range is approximately within 130 km (426509.2 ft) east and west of the origin. What is important for field personnel is not to memorize this mechanism as a theory, but that even if XY coordinates appear to be in the same meter notation, they indicate completely different locations if they were calculated in different systems. In other words, handling point clouds in plane rectangular coordinates is not simply assigning XY numbers; it is nothing other than ensuring that the reference framework on which those values are based is consistent.

Point clouds can appear plausible even if they are slightly misaligned. However, what is required in practice is not merely viewing them but making them usable for downstream processes such as overlaying with drawings, checking for interference with existing structures, comparing before-and-after earthworks, verifying as-built conditions, creating cross sections, and calculating earthwork volumes. To achieve this, point clouds must be managed using coordinates that correctly represent the same locations. The Ministry of Land, Infrastructure, Transport and Tourism’s materials also note that point clouds acquired by different methods have errors stemming from differences in acquisition methods and equipment, and that algorithm-induced errors can occur when integrating with other data; therefore, methods that are less likely to produce integration errors should be chosen. Aligning to the plane rectangular coordinate system is not a cosmetic process for improving appearance but a fundamental step to ensure the reliability of downstream processes.

Cause 1: The system number was mixed up

The most typical — and also one of the most damaging — mistakes is confusing the zone number. The Japanese plane rectangular coordinate system is divided into 19 zones nationwide, and even within the same prefecture, if the method of reference is mistaken depending on location or work conditions, the numeric values may look plausible while the actual position is significantly off. A common on-site error is failing to check the zone number recorded in the control point results table or on existing drawings and instead reusing the settings from the person in charge’s past projects. If you apply the zone used at a previous site directly to a new project, or convert only the point cloud without confirming the creation conditions of the received design data, the foundation is misaligned from the very beginning. Once that happens, even if you later adjust the appearance by translating it, you have essentially aligned things on an incorrect coordinate system, so the setup will fail when reconnecting with other data.

Errors in coordinate system identifiers often arise less from the point clouds themselves than from inadequate checking of surrounding documents. In practice, control points, existing drawings, design data, coordinates used for quality control, contract documents, and deliverables from previous years are mixed together. Even if each has the same site name, they do not necessarily share the same assumptions about the coordinate system. It is particularly risky to trust received data as-is: if you process it without confirming which system was adopted, whether it was converted from latitude/longitude, or whether it is already fixed as plane rectangular coordinates, you will leave unexplained shifts for downstream processes. The first step in correction is not to move numbers, but to organize the system identifiers from all related documents into a single table and first eliminate any uncertainty about whether all the data truly use the same system.

Cause 2: Mixed geodetic datums and vertical reference standards

A commonly overlooked cause of mismatches in planar positions is the mixing of different geodetic datums and height reference systems. The Geospatial Information Authority of Japan published the Geodetic Results 2024 on April 1, 2025, and changed the name of the Japanese geodetic datum from JGD2011 to JGD2024. At the same time, the agency has indicated that the definition of the plane rectangular coordinate system itself remains unchanged in the Geodetic Results 2000, 2011, and 2024, and that the horizontal position results for latitude/longitude and plane rectangular coordinates are carried over from JGD2011. However, it also warned that the elevation results were revised in April 2025 and cautioned against mixing height information from before and after the revision. The important point is not to be reassured merely by the phrase "plane rectangular coordinates." Even if the horizontal position definition is the same, heights and related ancillary results may have been reorganized separately, and mixing old point clouds, existing survey results, and new GNSS observations can easily create discrepancies, especially in elevation. If the horizontal plane lines up but there is an odd vertical offset, or if a cross-section appears unexpectedly raised or lowered, this pattern should be suspected.

In practice, point cloud staff tend to concentrate on aligning horizontal positions while using whatever height values are on hand. However, if the reference point elevation results, the observation method used on site, the definition of elevation in existing drawings, and the coordinate reference information provided at handover are not all available, the final deliverable can end up with discrepancies only in height. Vertical offsets are harder to detect than horizontal ones and often only become apparent during cross-section comparisons or earthwork volume calculations. Therefore, when correcting to plane rectangular coordinates, you need to confirm not only that the XY match, but also which datum the Z is referenced to. Abandon the assumption that plane rectangular coordinates alone guarantee correctness, and adopt the practice of checking horizontal and vertical separately.

Cause 3 Interpretation and units of X and Y are not aligned

A surprisingly common issue on site is a difference in the interpretation of X and Y. According to the definition by the Geospatial Information Authority of Japan, the X axis of the plane rectangular coordinate system is positive toward true north and the Y axis is positive toward true east. However, in the context of point cloud processing and 3D visualization, one often encounters a culture of treating X as east–west and Y as north–south, and when exchanging CSVs, intermediate files, or data with external systems the column order and axis interpretation can be swapped. When this happens, you get offsets that look rotated and cannot be explained by a simple translation, or the overall orientation appears wrong. In the field this is often described as “the numbers are there but the shape doesn’t match,” but in reality it’s not that the coordinate values are incorrect—the meaning assigned to the coordinates is inconsistent.

Unit mismatches are just as dangerous. Plane rectangular coordinates are assumed to be handled in meters (ft), but if drawings converted to millimeters (in), models from different systems, or scaled intermediate outputs get mixed in during processing, the whole thing can appear 1000 times larger or 1000 times smaller. Moreover, because point clouds are collections of points, they can look reasonably like terrain when displayed, so anomalies are noticed late. Before any correction work, it is important to list and check on the same sheet or in the same table the column order of X and Y, axis directions, units, origin position, and whether there is any rotation angle. If you rely only on on-site intuition and try to align things based on “probably this way,” you will end up with point clouds that cannot be reused in later processes.

Cause 4 Mixing local coordinates and global coordinates

In the initial stages of point cloud acquisition, data may be generated in the instrument’s internal local coordinates or in arbitrary coordinates. This is not an anomaly but rather a natural occurrence. The problem arises when the point cloud in that local state is operated on without clarity about when, by which reference, or using which data it was connected to the public coordinate system. Just because it appears to align visually does not mean the point cloud is correctly located in the plane rectangular coordinate system. Sudden offsets revealed when comparing with design data or existing drawings are often cases where this connection process was ambiguous. While a point cloud in local coordinates may be convenient on site, when integrating with other data it must always be connected to the public coordinate system via control points, known points, or validated base data.

In the manual for terrestrial laser surveying systems published by the Geospatial Information Authority of Japan, a method is outlined in which individually measured point cloud datasets are first merged, and then the merged overall point cloud is transformed into the plane rectangular coordinate system. This approach is preferred because, rather than forcing each scan into absolute coordinates, it is easier both in terms of workload and accuracy management to first stably assemble the whole into a single form and then connect it to public coordinates using external control points and the like. In practice, whether you place a locally integrated point cloud into the plane rectangular coordinate system at the end, or assign each acquired dataset to public coordinates before integrating them, affects the results. Whatever approach is taken, it is important not to leave ambiguous which control points are responsible for the coordinates.

Cause 5: Poor sequencing of point cloud integration and selection of reference data

Discrepancies in point clouds vary greatly not only with the correction formula but also with which dataset is used as the reference. Materials from the Ministry of Land, Infrastructure, Transport and Tourism indicate that using a base point cloud with a wide acquisition range and quality-controlled data can reduce the loss of positional accuracy when integrating other point clouds. Conversely, if you use as the reference a point cloud that only covers a narrow area, or one that is easily affected by the sensor’s acquisition attitude, and then overlay data covering a wide area, slight tilts or rotation errors will amplify with distance. In other words, in point cloud integration, choosing the wrong dataset to move afterward can mean that—even if the alignment is theoretically the same—you will not achieve accuracy that is usable in practice.

Securing overlapping areas is indispensable for integration. In materials from the Ministry of Land, Infrastructure, Transport and Tourism, it is also stated that, because there are many occlusions and points that exist only in one dataset, it is necessary to specify the common parts between the base point cloud and the target point cloud and align their positions. In on-site terms, this means you must ensure a sufficiently large area where the basis for overlapping is visible. If you force automatic merging when there is little overlap, similarly shaped features that happen to be nearby can be incorrectly matched, resulting in subtle misalignments that are hard to detect. If you want to improve registration accuracy, before computation you should first clarify which dataset will be the reference, which objects are commonly visible, and the extent of missing data and occlusion.

Cause 6 Processing with large coordinate values

When handling point clouds in a plane rectangular coordinate system, the point most easily overlooked by practitioners is that large coordinate values themselves can destabilize processing.

Materials from the Ministry of Land, Infrastructure, Transport and Tourism indicate that if you use large coordinate values that are far from the origin, such as latitude/longitude or plane rectangular coordinates, as they are, rotational and translational adjustments during registration are processed about the origin, increasing the computational burden and in some cases preventing movement to the accurate position. As a countermeasure, they outline a method of shifting the origin to the vicinity of the point cloud’s centroid before processing. This is not a software trick but an essential caution when handling point clouds with large coordinate values.

When this problem occurs on site, it appears as symptoms such as translations matching but rotations causing displacement, large areas aligning but only the edges failing to match, or the integration process taking a long time yet producing unstable results. Staff tend to suspect control points or measurement accuracy, but in fact there are cases where the cause is the processing system rotating large numeric values directly. When applying corrections, even if the final deliverable is to be saved in plane rectangular coordinates, simply enforcing a workflow in which internal processing is temporarily shifted to a local origin before rotating and integrating, and then returned to plane rectangular coordinates at the end, can greatly improve result stability. How the coordinates used for calculations are handled is more important than visual settings.

How to Carry Out Corrections Successfully

Given the six causes discussed so far, the first thing to do in correction is not to move the displaced point cloud. First, for each dataset, list the zone number used, the name of the geodetic datum, the horizontal position reference, the vertical reference, the ordering of X and Y, the units, whether it is a local coordinate system or a public coordinate system, the acquisition date, and information about the points used as references. Based on that, decide which dataset will be considered the final correct one. Next, base the process on data that is stable in quality over a wide area and organize the integration conditions using sufficiently large overlapping portions. Furthermore, during internal processing, move the origin near the centroid of the point cloud as needed to stabilize rotation and alignment. Finally, after converting back to plane rectangular coordinates, verify consistency with known points and drawings, checking not only planimetric alignment but also heights. By following this sequence, deviations that appeared inexplicable in many field cases can be explained to a considerable degree.

What you must not do during adjustment work is consider it complete simply because the display shows a neat visual overlap. Visual agreement is important, but it alone does not guarantee reuse for point clouds from different days, design models, as-built management, or cross-section measurements. A reliable adjustment in practice is one that anyone can reproduce under the same conditions. To achieve that, you must record the coordinate reference information before and after transformation, the known points used, the rationale for any rotations or translations, the base data adopted, and the verification results. Rather than ending the adjustment as a matter of artisan skill, formalizing it into a reproducible workflow is the shortest route to reducing errors across the site.

Summary

The causes of point cloud shifts in the plane rectangular coordinate system are not a single simple operational mistake. They appear as the result of multiple assumptions breaking down bit by bit: confusing zone numbers, mixing geodetic datums and height references, misinterpreting X and Y, mixing up local and public coordinates, selecting the wrong point cloud as the reference, and processing conditions such as applying rotations or merges while leaving large coordinate values unchanged. That is why, to successfully correct them, it is necessary to align the coordinate assumptions before matching appearances. The plane rectangular coordinate system is a common language that links drawings, design, construction, and maintenance. If point clouds are handled with this left ambiguous, valuable 3D data can become information that is unusable in later processes.

If you want to handle point clouds that correspond to the plane rectangular coordinate system more easily on site, and to connect acquired position information end-to-end through subsequent drawing checks and comparison tasks, it is important to choose a method that embeds coordinate handling into field operations from the start. LRTK, as an iPhone-mounted GNSS high-precision positioning device, brings location-enabled field measurements closer at hand and makes it easier to progress from simple surveying to creating an entry point for point cloud utilization. If you want to leave point clouds on site not merely as captured data but as usable data linked to the plane rectangular coordinate system, switching early to workflows that assume coordinate alignment will ultimately lead to the greatest efficiency gains.