How to prevent DWG position shifts? 4 coordinate-setting items to review

When you receive and open a DWG, you have likely experienced the drawing being far from its expected position or not matching the base drawing it should be overlaid on. In practice, especially, data created at different stages—design drawings, survey results, construction drawings, and drawings for as-built verification—are frequently overlaid. If the DWG coordinates shift each time, not only does the amount of checking work increase, but the risk of making decisions based on incorrect positions also rises.

DWG positional shifts may look like simple import errors, but in most cases they are actually caused by inconsistent assumptions about coordinate settings. It’s not that the drawing itself is corrupted; rather, a mismatch in units, origin, rotation, or transformation conditions causes it not to appear in the correct location. In other words, rather than trying to fix it by ad hoc use of the move command, clarifying which coordinate assumptions were used to create the drawing and under what conditions it was transferred is the quickest way to prevent recurrence.

In this article, aimed at practitioners searching for "dwg 座標 ずれる", we clearly explain from a practical perspective four coordinate-setting items to review to prevent DWG position shifts. Rather than scrambling to make adjustments after loading, we organize what you should check before and after handover and where misalignments in understanding are likely to occur.

Table of Contents

• Reasons why position shifts occur in DWG

• Review item 1 Unit settings

• Review item 2 Reference coordinates and origin

• Review item 3 Rotation angle and direction

• Review item 4 Conversion conditions during transfer

• Operational practices to prevent position shifts

• Summary

Reasons why position shifts occur in DWG

When people talk about DWG position shifts, they often mean phenomena that occur the moment a drawing is opened—objects 'jumping' somewhere else, failing to overlap, or being scattered in distant locations. However, even if they look the same, there can be multiple causes. First, it's important to understand that positional shifts are easily confused between geometry problems and coordinate problems. Even when the geometry of lines and points is correct, a different coordinate reference will cause them to appear in another location. Conversely, even if objects appear close on screen, slight deviations in distance or angle may indicate that the coordinate system or units do not match.

In practice, a particularly common case is when one person works in local coordinates while another assumes public coordinates or site reference points. Even if the drafter believes they have drawn elements in the correct position, if the other party reads them using a different datum the whole thing can appear to be significantly displaced. Also, even when a drawing looks "approximately correct," differences of a few centimeters to several tens of centimeters can remain. This is often not uncommon to occur because multiple small discrepancies accumulate — unit conversions, handling of rotation angles, rounding during transformations, mistakes in specifying reference points, and so on.

To prevent DWG position shifts, you first need to organize "why they shift" as explicit conditions rather than as a feeling. When handling coordinates, more important than the drawing's appearance is what is used as the origin, what is defined as one unit, how the north direction is interpreted, and which settings were used to convert the file at handover. In other words, most positional shifts occur when the assumptions about the coordinates remain outside the file during transfer. Even if you only send the DWG, the recipient cannot reproduce the same result unless the creator's assumptions are shared.

Another thing to watch for is when automatic corrections are applied on the importing side. Depending on the drawing environment, the software may infer units at insertion, reposition the origin, or optimize the internal display for readability. While these features are convenient, they can lead to interpretations that differ from the original drawing intent. Therefore, don't let a DWG positional shift end with "it didn't match when I imported it"—it's important to trace at which point the assumptions changed.

The four items addressed in this article are unit settings, reference coordinates and origin, rotation angles and directions, and the transformation conditions when handing off files. These four are interrelated, but by checking them separately you can identify the cause much more quickly. Conversely, if you leave these ambiguous and simply align drawings by moving or rotating them, discrepancies will reappear when you overlay another file. Even if they appear to be aligned once, they can fail in a different process. That is why, to prevent positional misalignment in DWG files, you need to carefully review the initial coordinate settings.

Review Item 1 Unit Settings

The first thing to suspect when a DWG is displaced is the unit settings. If units don’t match, both the overall size of the drawing and the coordinate values can be thrown off at once. In practice, some drawings are drawn with 1 representing 1 mm (0.04 in), while others treat 1 as 1 m (3.3 ft). The same line segment may be recorded as 1000 in one file and as 1 in another, so if the recipient interprets the units differently, not only the position but the sense of scale itself changes. If this is overlooked, the drawing can appear to have shifted far away, or be extremely small or large compared to the base map.

The tricky thing about unit settings is that they’re hard to judge by appearance alone. For example, when you’re only looking at a plan view, the lines appear closed and the shape looks plausible, so it feels as if it was imported correctly. However, when you measure a known distance between two points, it can turn out to be 1,000 times larger or 1/1,000 of what you expected. In such cases, the essence of the positional shift is not a coordinate translation but a mismatch in the assumed units. In other words, what looks like a positional problem is actually an inconsistency in the dimensional system.

When reviewing unit settings, first clarify what the DWG was drawn to. Architectural drawings tend to use millimeter units (mm / in), while civil engineering or surveying drawings may assume meter units (m / ft). However, this is only a tendency, and practices vary by site and organization. Therefore, rather than deciding solely based on industry conventions, it is important to measure a known dimension. For example, choose one reliably known value—such as road width, the length of a structure, centerline spacing between streets, or the distance between control points—and after importing, compare it with the measured value. If the discrepancy is large, you should first suspect the unit settings.

Also, unit issues occur on both the export and import sides. If unit information is not specified during export, or if a default value is inserted during import, unintended scale conversions can occur on the receiving side. In particular, when consolidating multiple drawings into a single file, the unit assumptions for each source file may differ, and multiple scales can even coexist within the same DWG. This makes overlays and dimension checks unstable and makes it difficult to pinpoint the cause of any misalignment.

As a practical measure, before handing over a DWG it is important to check the representative dimensions in the drawing and be aware of how those values will look in the recipient’s assumed units. If unit recognition is consistent, the initial steps of investigating positional shifts can be greatly shortened. Conversely, if units remain ambiguous and you pass it along thinking “it will probably match,” you will face major rework in later stages. Even if coordinate values exist as numbers, if what those numbers represent has not been decided, positions cannot be determined. The first step to prevent DWG positional shifts is to align the drawing’s size and the coordinate units by numeric values rather than by appearance.

Furthermore, reviewing units is also important when reusing past data. When reusing previously created drawings, you may not accurately grasp the original data’s operating rules. If the person in charge has changed or the drawing was received from an external party and is being reused, the geometry on the drawing may be usable while the unit assumptions tend to be unclear. Bringing such data into a new project as-is will make discrepancies surface the moment you overlay it on another reference drawing. For that reason, unit settings are not something you set once and forget; they are a basic item that should be confirmed every time, for each project and each handover.

Review Item 2: Reference Coordinates and Origin

After units, the next most important thing is which coordinate system you use as the reference for placing the drawing and where the origin is set. When it comes to DWG positional misalignments, this factor often becomes the most fundamental cause. Even with the same geometry, a drawing created in local coordinates and one referenced to public coordinates will have completely different coordinate values. For that reason, even if the shape is correct, they can appear far apart the moment you overlay them. Simply moving one to match will destroy the original reference relationships, causing it to become inconsistent with other drawings and survey data.

Situations where the handling of the origin becomes ambiguous are common. For example, to prioritize ease of drafting, a corner of the site is sometimes used as a temporary origin. This is convenient while creating drawings, but if shared as-is the recipient may read it assuming public coordinates, causing positional discrepancies. Also, because it is difficult to work with coordinates that cover a wide area, drawings are sometimes shifted internally closer to the origin for drafting and then shifted back before delivery. If this "shift back" step is omitted, the DWG will look fine visually but will be offset from the reference coordinates.

In practice, what matters is clearly stating which origin rule the drawings are based on. If the drawings are confined to a single site, they can be operated with a local coordinate system. However, if there is a possibility of overlaying them with survey results, point clouds, construction management data, or drawings from other trades, they ultimately need to be aligned to a common reference coordinate system. The important point here is not that local coordinates are bad, but that it is dangerous when the fact that they are local coordinates is not communicated. If the reference is shared, recipients can treat the data assuming a conversion. If it is not shared, the data may be used as-is by mistake and the misalignment will be discovered.

When verifying the origin, it is effective to use known points within the drawing. For example, refer on the drawing to points whose coordinate values can be confirmed in separate documents—such as control points, boundary stakes, corners of structures, or center points—and check whether those values match. If only one point matches while others do not, there may still be a rotation or scale issue. Conversely, if all points are shifted by a consistent amount, misidentification of the origin or a translation (parallel shift) problem is suspected. In this way, checking reference coordinates and the origin also helps determine the nature of positional displacement.

Also, where you place the origin has a direct impact on the usability of the drawing. If shapes are located extremely far from the origin, display, selection, and export behavior can become unstable. For that reason you may be tempted to adopt a convenient temporary placement during work, but even then you must always retain the correspondence with the official delivery coordinates. For example, recording the translation from the temporary origin to the official origin, the actual coordinates of reference points, and rotation conditions will reduce errors when handing the files over. Without such records, no one will be able to reproduce the correct positions later.

From the perspective of preventing DWG positional misalignment, the origin should be regarded not simply as the starting point of drafting but as the starting point for data integration. Even if a drawing is valid on its own, the moment it is overlaid with other data any ambiguity in the origin becomes problematic. That is why, before handing it over, it is essential to confirm "what coordinate reference this drawing uses", "what convention was used to set the origin", and "whether you can explain it when overlaid with other deliverables". A DWG whose coordinate settings can be explained is less likely to cause positional misalignment, and if one does occur its cause is easy to trace. A DWG that cannot be explained will inevitably produce rework somewhere.

Review Item 3 Rotation Angle and Direction

When it comes to DWG position offsets, people tend to imagine only translations, but in fact rotation is the cause in very many cases. If a particular point lines up yet the discrepancy grows the farther you move away, you should suspect a mismatch in rotation angle rather than an origin problem. Even if one drawing treats the upward direction as north, another drawing may use the site baseline as up. In such cases, although both drawings may look aligned, their angle references differ, so when overlaid they shift in a fan-shaped pattern.

Rotation issues are likely to occur when overlaying design drawings on top of survey results as a background, or when reorienting drawings into a direction that is convenient for use on site. It is not uncommon to align a road centerline or the long side of a building horizontally on the screen for efficiency. However, if that drawing is handed to another party while still assuming the original reference coordinates, the recipient will interpret it as north-referenced, causing a positional misalignment. In other words, rotation is an adjustment made for readability, but it can easily create discrepancies in coordinate interpretation when drawings are shared.

When dealing with direction, you need to be aware not only of the rotation angle but also of the orientation of the axes. For example, if the definitions of the X and Y directions are swapped, or if one axis is treated as reversed, you can get a displacement that cannot be explained by a simple rotation. On working drawings, people may intuitively treat right as east and up as north, yet proceed without a clear correspondence to the actual numeric coordinates. When such data is matched with another dataset, it may at first glance look only slightly tilted, while in reality the discrepancy comes from different interpretations of the axes.

Using the known direction between two points is an effective way to check for rotation. Select two points on the drawing that can be reliably identified, and check whether the direction of the segment between them matches that in the other deliverable. If the distances agree but only the direction differs, a mismatch in rotation angle is likely. Also, if, when aligning to a reference point, a distant point shifts outward tracing an arc, rotation is suspected. Being aware of these phenomena lets you avoid treating positional offsets as mere translation errors and prompts you to review the angular conditions as well.

Furthermore, rotation is tied to the settings used when transferring files. If it is unclear whether the exporter saved the file prioritizing the "visual orientation" or preserving the "coordinate orientation," the recipient can be misled. Even if the drawing is easy to read, it can create a risky situation from the perspective of coordinate alignment. Therefore, if you rotated the drawing to improve its appearance, you must specify the rotation angle and the reference direction. If you fail to do so, someone may later force a rotation to make it fit, further disrupting consistency with other files.

From the perspective of preventing positional shifts in DWG files, rotation is not simply something to match but a condition that should be shared. Ideally, everyone involved with the drawings understands which direction is north, how many degrees the drawing is rotated relative to which reference line, and whether the orientation is for local operational readability or for an official coordinate orientation. If the rotation conditions are clear, even when working in a local orientation you can return the drawing to its official position. Conversely, a drawing whose orientation cannot be explained must be considered unreliable, even if it appears to align visually.

Review Item 4: Conversion Conditions at Handover

Even if you correctly understand units, the origin, and rotation, position shifts can occur if you misconfigure the conversion settings when exchanging DWG files. This point is easy to overlook but is very important in practice, because a drawing that looked correct in the creator’s working environment can be replaced by different conditions at the moment of export or insertion. In other words, DWG position shifts can occur not during drafting but at the final step of handover.

A typical example is cases where the handling of external references and embedded elements is not standardized. Even if the background drawing or reference drawings align perfectly in the creator’s environment, the recipient may not inherit the reference origin, so the standalone DWG can appear in a different location. Also, if the insertion point is handled differently, the entire drawing can be placed in an unexpected position. This too is caused not so much by a problem in the original drawing as by the fact that which reference or origin was used when exporting at handover was not communicated.

The tricky part about conversion settings is when multiple options exist. In some environments, a setting that preserves the original coordinates and a setting that saves based on the current display state can coexist. If an operator exports using the default without understanding the intent, the recipient may find that a DWG that should line up is offset. Moreover, because the problem is hard to see in the exporter’s own environment, identifying the cause tends to be delayed. That is why the conversion conditions for handover need to be standardized by the organization, not left to individual habits.

What works in practice is to perform a reload check from a third‑party perspective before handover. In other words, insert the DWG into a new file or an empty workspace separate from the authoring environment and check whether it lands in the intended position. Simply adding this step lets you detect many issues in advance, such as reference dependencies, shifts in the insertion base point, unit conversion errors, and failures to preserve rotation. That something appears correct on the operator’s own screen is a different matter from the recipient being able to reproduce the same result. Only after verifying the latter can you say that the handover quality has been ensured.

Also, it's safer to leave a record of the conversion conditions rather than communicating them verbally. If you briefly note which coordinate reference was used to save the data, what units were used, whether any rotation was applied, how reference points correspond, and, if necessary, the translation amount, the recipient will be less likely to be confused. DWG is excellent for geometry, but it doesn't automatically convey drawing intent or handover conditions completely. Operational rules and a handover memo compensate for those shortcomings.

Furthermore, when there are multiple updates within the same project, it is important to apply the same transformation settings each time. If the first release uses public coordinates, the next uses local coordinates, and another person prioritizes on‑screen readability, positional shifts will expand with each revision. It also becomes difficult to check update differences and to determine which version is correct. The transformation settings at handover are not a one‑time note but a rule to preserve consistency across the entire project. If this is inconsistent, DWG positional misalignment will recur repeatedly.

Operational practices to prevent position drift

Even if the four items explained so far are understood, unless they are incorporated into daily operations, DWG misalignments will recur. In practice, what matters more is creating workflows that make problems less likely to occur than being able to fix them when they happen. To achieve that, it is necessary to standardize not only the drawings themselves but also the verification steps performed before and after handover.

The first thing to be conscious of is not to accept "it looks correct" as a passing criterion. Just because shapes appear to overlap on the screen, it may only mean that units, the origin, or rotation happen to coincide by chance. In practice, you can only judge that positions agree after verifying the coordinates of known points, checking representative dimensions, and confirming consistency of orientation. Especially for drawings covering a wide area, aligning only a part can still lead to discrepancies farther away. That is why verification at multiple points is indispensable.

Next, it is important at the start of a project to decide the assumptions for coordinates. Whether to proceed using local coordinates, to standardize on a public coordinate system, to use a temporary origin only during work, or where to return the coordinates upon delivery—if these are decided from the outset, confusion in later stages is reduced. Conversely, if each person handles things in whatever way is convenient at the time, it may be useful during the process but will cause large discrepancies at the final integration stage. DWG position shifts often result not only from individual operator errors but also from the absence of a defined initial policy.

Also, reflecting the coordinate assumptions in drawing file names and management sheets is effective. For example, if you can identify whether it is a local-coordinate version or an official-coordinate version, or whether it has been rotated or not, it becomes easier to prevent incorrect distribution or accidental overwriting. Of course, names alone won't completely prevent this, but at least they make it easy to tell at a glance "which state the DWG is in." This is especially effective on busy sites. Because people tend to skip verification steps, simply having easily identifiable information reduces the incidence of mistakes.

Also, when re-saving after making corrections, you should make it a habit to confirm that you are outputting under the same conditions as before. Even if you think you've only added a small note, saving with different settings can change positional relationships even if the shapes are the same. This is especially true when editing a DWG received from someone else: if you make changes without understanding the original coordinate assumptions, you can run into problems where things that were correct before the edit become misaligned afterward. For this reason, when the person responsible for updates changes, it is important not to omit handing over the coordinate rules.

In operations aimed at preventing positional misalignment, the procedures for final checks should also be reviewed. Before delivery or sharing, it is effective to routinize basic actions such as actually overlaying the file on a separate file, measuring the coordinates of known points, and verifying distances and directions. This may seem like a hassle at first, but it is far less burdensome than discovering problems later and having the file sent back for correction. Positional misalignment in a DWG affects a broader scope the longer it goes undetected. That is precisely why it is important to establish a process that ensures pre-checks are carried out reliably, even if only for a short time.

Finally, it’s important to recognize that coordinates are not just the drafter’s problem. If the approach to coordinates is not linked across surveying, design, construction, and management, discrepancies will occur somewhere. To reduce DWG positional shifts, having a shared understanding between stages is more important than skill in file handling. What are the units, where is the origin, what is the orientation, and what is retained at handover? If these four points are shared, drawings remain stable. If they are not shared, no matter how carefully they are drawn, they will be compromised in the next stage.

Summary

To prevent DWG position shifts, rather than forcefully aligning them after import, the most important thing is to standardize the assumptions for coordinate settings. In particular, the four items to review are unit settings, reference coordinates and origin, rotation angle and direction, and transformation conditions at handover. If these four are sorted out, not only will the overlay of drawings be more reliable, but coordination with survey results and field data will also be more stable. Conversely, if even one of these remains ambiguous, a precarious situation can arise where things appear to line up but do not actually coincide correctly.

In practice, DWG position shifts are often dismissed as operator error, but in essence they frequently result from a lack of information sharing. That is why it is important not to try to resolve everything with the file alone, and to be able to explain the assumptions behind the coordinates. Verify against known points, measure distances, check directions, and reload in a different environment. These methodical checks are, in the end, the most reliable measures to prevent recurrence.

And the more carefully coordinates are handled on the drawing side, the more important the accuracy of the position information acquired on site becomes. In situations where you want to accurately link the positional relationship between design drawings or construction drawings and the actual site, it is effective to ensure coordinate consistency from the acquisition stage. By utilizing LRTK (iPhone-mounted high-precision GNSS positioning device), it becomes easier to handle position information acquired on site, and verifying it against drawings and organizing records also becomes simpler. Efforts to reduce positional shifts in DWG are not something that can be completed by drawing edits alone. Maintaining awareness of aligning coordinates in both the field and the drawings leads to work with less rework.