タイトルなし

\# Seven checkpoints to avoid failures in JGD2011 coordinate transformations

JGD2011 coordinate transformations may look like simple tasks in surveying or construction management. It’s easy to think you only need to convert the coordinates you have into another format, but in practice small oversights—mixing up coordinate systems, misidentifying the zone number of the Japan plane rectangular coordinate system, confusing vertical datum types, or inconsistencies with known points—can lead to major rework. Especially when comparing with public surveys or design drawings, managing as-built results, referencing control points, or overlaying point clouds and CAD, discrepancies of a few centimeters to several tens of centimeters (a few in to several dozen in) cannot be ignored in practice. That is why matching the conditions before and after transformation correctly is more important than the transformation operation itself. JGD2011 is a framework for survey results revised and organized in response to the large crustal movements caused by the 2011 Tohoku–Pacific Ocean earthquake, and in current practice it is essential to verify consistency while understanding that background.

Moreover, in practice, seeing the term JGD2011 and feeling reassured can lead to another pitfall. The Geospatial Information Authority of Japan has unified result names as JGD2024 in line with the elevation revision in fiscal year Reiwa 7, but latitude/longitude and plane rectangular coordinate values for horizontal positions are inherited from JGD2011. Therefore, recent result tables and explanatory materials may show JGD2011 and JGD2024 mixed together, and working without understanding this can lead you to assume heights are under the same conditions, or conversely to mistakenly think horizontal positions have changed. To avoid failures in coordinate transformations, the starting point is calmly clarifying whether the target of the conversion is horizontal position or height, and what the epoch or name of the result actually means.

This article explains, in order, seven checkpoints that practitioners should always confirm before performing JGD2011 coordinate transformations to prevent common failures. It covers not only the concepts of transformation but also why each check is necessary, where it is easy to overlook, and what kinds of discrepancies or confusion can occur if the check is omitted. It is organized so that those about to perform coordinate transformations, those reusing past data, and those aligning with design data or verifying consistency with public coordinates can all find immediately practical guidance.

Table of contents

• Basic premises to grasp first in JGD2011 coordinate transformations

• Checkpoint 1: Make clear what coordinates are being handled before and after transformation

• Checkpoint 2: Do not mix up the zone number of the plane rectangular coordinate system

• Checkpoint 3: Do not assume the directions of X and Y coordinates

• Checkpoint 4: Do not confuse types of height

• Checkpoint 5: Align the epoch and reference of known points

• Checkpoint 6: Do not ignore crustal deformation corrections and regional conditions

• Checkpoint 7: Do not omit post-transformation verification

• Summary

Basic premises to grasp first in JGD2011 coordinate transformations

To perform JGD2011 coordinate transformations correctly, you must first understand that coordinate transformation is not merely rearranging numbers. Coordinates handled in the field include geographic coordinates expressed as latitude and longitude, public coordinates expressed in the Japan plane rectangular coordinate system, and vertical information such as orthometric height and ellipsoidal height, each with different meanings and uses. Many practical failures arise less from not knowing the transformation equations and more from starting processing without clarifying what is being transformed into what. Assuming that numbers on a drawing must be plane rectangular coordinates or that GNSS-acquired values will directly match public coordinates can produce results that later cannot be reconciled.

Also, in the context of JGD2011, terms such as the old Japanese geodetic system, Japanese Geodetic Datum 2000, JGD2011, and the more recent JGD2024 appear together, and judging by name alone can cause confusion. In particular, when reusing old documents, older drawings or ledgers may have been created under legacy conditions, and mixing them with current results may produce superficially close but not strictly identical values. In practice, determining first what geodetic datum, result name, and coordinate type the source data were created under is the top priority. Proceeding without this confirmation makes it difficult to trace where errors were introduced later.

The key is that transformation is not a stand-alone process but is always connected to known points, design drawings, field observations, result tables, and delivery specifications. Therefore, whether a transformation result is correct should be judged not by whether the equation executed but by whether it is consistent with surrounding data. The seven checkpoints that follow are practical checks precisely intended to preserve that consistency.

Checkpoint 1: Make clear what coordinates are being handled before and after transformation

The first thing to confirm is exactly what coordinates are being handled before and after transformation. Saying “JGD2011 coordinate transformation” can mean different tasks: converting latitude/longitude to plane rectangular coordinates, converting plane rectangular coordinates back to latitude/longitude, or translating older results into newer ones. In the field, this distinction is often left vague and only “coordinate transformation is needed” is shared. If each operator begins processing under different assumptions, the values will not match when compared later and it becomes impossible to judge which is correct.

For example, if you want GNSS-acquired latitude/longitude to match public coordinates on a design drawing, you need conversion to plane rectangular coordinates. Conversely, if you want to check existing plane rectangular coordinate data on a map or in a location information system, you may need to convert to latitude/longitude. Without clarifying input and output formats, you can be using the same term JGD2011 while actually doing different work. Before starting transformation, it is important to check three items as a set: the format of the source data, the desired result format, and the final intended use.

A useful practice is to explicitly document in words “what to base on and what to align to” among stakeholders. For example: align to the plane rectangular coordinates on the design drawing, align to the latitude/longitude in the known-point result table, or align to the reference coordinate system of the point cloud data. Specifying the alignment target concretely reduces misunderstanding. Doing this organization before choosing formulas or tools alone can prevent many failures.

Checkpoint 2: Do not mix up the zone number of the plane rectangular coordinate system

One of the most typical failures in JGD2011 coordinate transformations is getting the zone number of the Japan plane rectangular coordinate system wrong. Japan’s plane rectangular coordinate system is divided into 19 zones nationwide, and even the same location will have different numerical coordinates if calculated under a different zone. Nevertheless, on-site files or drawing notes may not explicitly state the zone number, or data received from another person may lack explanation, and assumptions are sometimes made. This is a major cause of large positional errors.

Be especially careful when multiple zones are involved in neighboring regions. If the project area is wide, materials within the same municipality may refer to different zones. Also, older materials may show zone numbers in kanji or Roman numerals, which can be overlooked during data entry. Converting to plane rectangular coordinates will break overall positional relationships if the zone number differs by even one, so avoid assuming “this zone is probably the one for this region.”

In practice, it is safer to confirm the zone number from multiple sources such as result tables, specifications, drawing margins, and known-point information, not just from the target coordinate values. If materials disagree, stop processing and confirm before proceeding. Once coordinate transformation is completed, it becomes hard to notice mistakes by looking only at the numbers. That is why confirming the zone number before starting is crucial.

Checkpoint 3: Do not assume the directions of X and Y coordinates

When handling plane rectangular coordinates, it is surprisingly common to swap X and Y coordinates. Many people working with CAD or drawings habitually regard the horizontal direction as X and the vertical as Y, and applying that intuition to public coordinates can lead to confusion. However, in the Geospatial Information Authority of Japan’s geospatial data specifications, the X coordinate in the plane rectangular coordinate system represents the north–south direction with north positive, and the Y coordinate represents the east–west direction with east positive. In other words, reading values with the same assumptions as ordinary drawings may lead to reversed axis interpretation.

This error can occur not only during data input but also when exchanging data. For example, CSV files or reports may simply label columns X and Y without specifying axis meaning. The creator might have used X and Y in the public-coordinate sense, but the recipient, interpreting them from a common mathematical or CAD coordinate mindset, may process them swapped. The coordinates then appear plausible, so detecting the mistake can be delayed even though the actual site positions are oddly displaced.

To prevent this, do not just look at X and Y values; explicitly handle which axis represents north and which represents east. Establish the common understanding among stakeholders that “X is north, Y is east,” and annotate that meaning on exchanged materials whenever possible. Careful confirmation of axis meaning in JGD2011 coordinate transformations forms the foundation that precedes concerns about accuracy.

Checkpoint 4: Do not confuse types of height

A commonly overlooked issue in JGD2011 coordinate transformations is handling heights. In the field, people sometimes lump height together with coordinates as if they were the same, but horizontal position and vertical height should not be treated identically. The Geospatial Information Authority of Japan also distinguishes that orthometric height (height above the geoid) is a different quantity from ellipsoidal height. When reading explanations of JGD2011 or JGD2024, be aware that latitude/longitude and plane rectangular coordinates do not simply move in the same way as orthometric or ellipsoidal heights.

This point is important because, due to recent changes in result names, horizontal positions are inherited from JGD2011 while height revisions and correction concepts may be treated separately. For public surveys in response to the Reiwa 7 elevation revision, the Geospatial Information Authority of Japan indicates handling in which coordinates are provided in accordance with Geodetic Results 2024 and orthometric heights are then reverse-corrected back to the old heights using correction parameters. In other words, even if horizontal positions do not change much, you cannot treat heights the same without consideration. When thinking about JGD2011 transformations, it is crucial to separate and confirm plane-position transformations and height consistency.

In practice, confusion is fatal in contexts involving heights such as design drawings, longitudinal and cross sections, as-built control, and earthwork calculations. Situations where horizontal positions match but heights do not, or vice versa, occur frequently. When asked to perform a coordinate transformation, always confirm whether only horizontal positions are required or whether heights must be reconciled as well, and distinguish between orthometric height and ellipsoidal height.

Checkpoint 5: Align the epoch and reference of known points

No matter how correct the chosen transformation procedure, results will not be stable if the conditions of the control points used as references are inconsistent. The standards for control point survey operations require checking the current status of known points and for abnormalities, and even when using GNSS reference stations one should verify operational status before observation. In other words, known points are not adequate merely because coordinate values are written down; you must judge whether the point is currently valid and which result it is based on.

A common issue in JGD2011 transformations is using recently obtained known-point results in one material and older drawing values in another, treating them as if they share the same reference. This makes it impossible to tell whether discrepancies are due to transformation errors or the differing conditions of the known points themselves. Especially in long-term projects or when reusing data, materials that retain past result epochs can slip in and be hard to distinguish by appearance alone.

In practice, confirm for the known points to be used the result table name, coordinate system, and, if necessary, the reference epoch or revision history, and operate only with points sharing the same assumptions. If known-point groups include points under different conditions, after transformation each point may deviate differently and diagnosing the cause becomes extremely difficult. Improving transformation accuracy is more often achieved by reviewing how the reference points are aligned than by changing software or formulas.

Checkpoint 6: Do not ignore crustal deformation corrections and regional conditions

The establishment of JGD2011 is rooted in crustal deformation across the Japanese archipelago. The Geospatial Information Authority of Japan provides guidance on so-called semi-dynamic correction as a correction for crustal movements due to steady plate motion, and recommends deriving current-epoch coordinates by correcting known-point epoch coordinates. This means coordinates are not immutable fixed numbers but should be handled taking into account epoch and regional conditions.

Without this viewpoint, when current observations do not match old data at the same location, people tend to attribute the discrepancy to simple observational or input error. In reality, broad earthquakes, ongoing crustal deformation, whether results have been revised, and the scope of applied correction parameters can all be factors. The GSI’s Q&A on control point result revisions following the 2011 earthquake shows issues such as areas of suspended results, handling of correction parameters, and differences in application conditions by region, demonstrating that blanket processing that ignores regional differences is dangerous.

As a practitioner, when you see mismatching values, do not immediately suspect only the transformation formulas; also check regional conditions and the revision history of results. Especially in comparisons with past data, large-area projects, or projects with long known-point histories, neglecting this check can lead to unnecessary recalculations or on-site re-measurements. Coordinate transformation is a computational task, but only by considering background crustal deformation and institutional practices can you achieve stable results.

Checkpoint 7: Do not omit post-transformation verification

Finally, and most importantly, always perform verification after transformation. In the field, the task is sometimes considered complete once numbers have been output, but that is insufficient. Whether the transformation result is correct can only be judged by comparing with known points, drawings, and on-site positional relationships. Errors such as wrong zone numbers, swapped X and Y, or confused height types allow the calculation to finish normally and thus cannot be detected without verification.

What to check in verification starts with consistency with known points. Overlay the transformed coordinates onto known points and confirm whether they fall within the expected error range. Next, check whether positional relationships with surrounding structures and design alignments are natural. When heights are involved, also check for inconsistencies in longitudinal and cross sections. In addition, keep a set of easy-to-check items—number of digits, sign, and inter-point distances—so that elementary mistakes can be caught early.

Making this verification routine increases the likelihood of catching major errors before field deployment, even if some ambiguity about pre-transformation conditions remains. Conversely, omitting verification tends to reveal problems later in downstream processes such as staking out, as-built confirmation, drawing corrections, and point-cloud overlay, costing significant time to find causes. Consider a coordinate transformation complete not at the moment of conversion but when consistency has been confirmed.

Summary

To avoid failures in JGD2011 coordinate transformations, the important thing is not memorizing particularly difficult theories but carefully aligning basic conditions one by one. Clarify what coordinates are being converted and to what, confirm the zone number of the plane rectangular coordinate system, avoid misinterpreting the meanings of X and Y, do not confuse types of height, align the conditions of known points, do not overlook regional conditions and crustal deformation corrections, and always verify the results. Following this flow will greatly reduce failures in JGD2011 coordinate transformations. Moreover, these checks form the common foundation for most tasks that handle positional information, not only public surveys but also construction management, design comparison, point-cloud processing, and drawing overlays.

In the field, spending time organizing preconditions and checking consistency yields faster, more stable overall work than spending time only on the transformation itself. Especially when multiple people use the same coordinate data, operational practices that avoid ambiguity in transformation conditions are essential. If JGD2011-related organization is in place, confirming control points, sharing site coordinates, as-built checks, and overlaying point clouds and drawings become much easier.

If you want to make coordinate handling more reliable in daily operations, creating an environment that enables quick on-site position checks and simple surveying is indispensable. LRTK is a GNSS high-precision positioning device that can be attached to an iPhone and is a practical option to streamline initial on-site coordinate tasks. If you want to operate on-site with awareness of coordinate consistency required by JGD2011 transformations, LRTK makes it easier for one person to confirm calibration points, check coordinates before staking out, and perform simple on-site positioning. Establishing a system to check on site rather than finishing with desk-top transformations is the shortcut to reducing failures in coordinate operations.