7 checkpoints when civil engineering design software cannot import LandXML

In practical work where the target software listed in the title handles the specified format, the phenomenon described as “cannot import” does not always point to a single cause. Multiple symptoms tend to be described the same way: reaching the import dialog but seeing nothing, surfaces importing but alignments not appearing, large coordinate shifts after import, processing never finishing, or importing but not getting the form needed for work. The official help also explains this import as a two-step flow of setting options and then selecting files and components, so multiple factors — the source file contents, import settings, the destination, and conflict handling — influence the result.

Furthermore, in domestic civil engineering practice this exchange format is often used not just as a shape-saving format but as part of a standard for handing over points, coordinate systems, alignments, cross-sections, terrain surfaces, etc. Therefore, judging success or failure solely by whether visible geometry appeared increases the chance of rework. Domestic extension specification explanations also organize exchange targets such as units, coordinate systems, coordinate points, centerline alignments, cross-section shapes, and terrain models, so whether the required elements are present in the source file itself becomes an important checkpoint.

Table of contents

• What to separate first when you can’t import

• Checkpoint 1: Is the file content as expected?

• Checkpoint 2: Are the selected elements to import correct?

• Checkpoint 3: Do the drawing units and coordinate conditions match?

• Checkpoint 4: Are translation and rotation settings applying unnecessarily?

• Checkpoint 5: Are objects being rejected due to same-name collisions?

• Checkpoint 6: Is the destination site or collection as expected?

• Checkpoint 7: Is data volume or update status the cause?

• Practical workflow to reduce import troubles

• Summary

What to separate first when you can’t import

The first thing to do is to separate the phrase “cannot read” into specific phenomena. Concretely, check in order whether you can open the import dialog, whether you can select the target file, whether element names appear in the data tree, whether the event display shows success counts after completion, and whether the target objects can be found on the drawing or in the management tree. The official help states that in the dialog you can select elements from the data tree and confirm import status in the event display. In other words, the first thing to look at is not the on-screen appearance but how far the process has progressed.

If you work without this separation, you can mistakenly conclude a file is corrupted when coordinates are simply shifted, or misattribute a missing alignment to operator error when it is absent from the source file. The official exchange format site and domestic specification materials show that this format can contain multiple types of information — points, surfaces, alignments, parcels, etc. — so files with the same extension can contain entirely different contents by project. Therefore, even dividing symptoms into the four categories “not displayed,” “missing,” “shifted,” and “stalled” can greatly narrow down the cause.

Checkpoint 1: Is the file content as expected?

The first checkpoint is whether the received file actually contains the elements you need. Domestic explanatory materials organize exchange targets as units, coordinate systems, coordinate points, centerline alignments, cross-section shapes, and terrain surfaces, and not every file contains the same amount of information. Some files contain only surfaces, while others include centerline alignments. So when alignments do not appear, the first suspicion should not be a failed import operation but rather that the source file’s described scope is narrower than expected.

In practice, rather than placing a received file straight into the production drawing, simply getting a sense of its contents beforehand can change the outcome. Because it is XML, if you open it as text you can quickly check for project name, coordinate system, element names, and the presence of surface or alignment-like descriptions. You do not need to perform a detailed analysis there, but if you can at least grasp whether the file is surface-focused, includes centerline alignments, or seems written with domestic specifications in mind, it becomes easier to calmly judge what was missing after import. This is a practical check derived from the element composition listed in the official specification.

Also be careful not to misinterpret the inability to edit after import as “not read.” The official settings explanation notes that if surface data is composed only of breaklines, the surface itself may be generated but those breaklines might not appear in the management tree as editable objects. In other words, it may not be that the file “was not read” but rather that it did not import with the expected editability. Whether you can distinguish this changes how you respond.

Checkpoint 2: Are the selected elements to import correct?

The second checkpoint is whether you properly selected the required elements in the import dialog. The official dialog description says importable components are shown as a data tree, and you can narrow the import targets using the checkboxes to the left of each element. By default, all components are selected. This convenience can actually cause oversights in practice: you may think you selected everything but some child elements are unchecked, or you may import unnecessary elements and make cause isolation difficult.

When starting import trouble investigation, it is safer to test with only the elements directly related to your purpose rather than trying to import everything at once. If you want to check existing terrain, focus on surfaces; if you want to check centerline alignments, focus around alignments. Narrowing the target this way makes clear which elements exist and which do not. The official help states that object names in the source file are used when converting to the drawing, so cross-checking the names in the delivered materials helps determine whether the problem is a selection omission or a deficiency in the source file.

Especially in projects that include multiple surfaces or alignments, everything may be present yet indistinguishable, leading you to assume “the needed ones aren’t there.” To prevent this misrecognition, it is effective to have an expected name list on the receiving side before import and then check whether those names match in the event display or management tree after import. Import success cannot be judged solely by whether lines or a triangulated mesh appear on screen. Being able to trace by name is very important in practice.

Checkpoint 3: Do the drawing units and coordinate conditions match?

The third checkpoint is the units and coordinate conditions of the destination drawing. Vendor support notes advise that if spatial shifts occur when importing objects in this format, you should set the drawing units to match the source data and confirm coordinate system and geodetic datum or projection settings. In other words, even if the file itself is correct, if the destination drawing’s settings are not aligned, the on-screen result will appear as if objects “flew off” or “don’t match.”

Domestic exchange specifications also explicitly list units and coordinate systems as basic elements. Therefore, before importing you should confirm what coordinate assumptions the received file was written under and how your drawing is configured relative to that. Whether the file uses a local origin or a common coordinate system, and whether vertical references align as well as horizontal ones — if you import without checking these, the geometry may appear to be present but will not overlap existing drawings and will be unusable in later processes. Coordinate shifts are often due to mismatched preconditions rather than the import procedure itself.

A recommended practical measure is to prepare known points or reference lines in advance. If known points or the start and end points of a centerline exist on the drawing, you can immediately judge how far the import shifted. Conversely, importing without any reference and manually nudging geometry to a roughly correct visual position creates a drawing that lacks reproducibility and will fail when overlaid with other data later. First align units and coordinate conditions, then verify against known elements. Simply following this sequence will resolve many import troubles. This recommendation follows both support article guidance and the fact that the exchange specification includes units and coordinate systems.

Checkpoint 4: Are translation and rotation settings applying unnecessarily?

The fourth checkpoint is translation and rotation settings. The official help says the import settings tab allows you to define data transformations, rotations, and various conversion conditions. These are useful features, but if used without understanding the preconditions they can apply unnecessary corrections even when the source file is correct, leading to misunderstandings like “cannot read,” “jumped,” or “wrong orientation.” This is especially likely when settings from a previous project are left and reused for another project, causing recurring similar symptoms.

What matters here is not to apply multiple corrections at once on the first attempt. If you change both translation and rotation simultaneously, it becomes unclear which setting caused the shift. When the reference position is unknown, it is safer to import with unnecessary corrections turned off, check the result against known points or reference lines, and then add only the necessary corrections one at a time. The official help also suggests turning transformations and rotations on or off individually and configuring base point and angle, so a staged isolation approach matches the intended operation.

A common pitfall for practitioners is thinking “it’s only slightly off so I’ll fix it manually.” But design exchange data is reused in later processes, so ad-hoc manual adjustments break reproducibility when receiving different files later. Positioning reproducibly via import settings and simply moving geometry by hand to make things appear correct are different in quality even if they look the same. Review import settings first and make manual geometry edits only as a last resort; that approach is the way to avoid failures.

Checkpoint 5: Are objects being rejected due to same-name collisions?

The fifth checkpoint is how same-name objects are handled. The official help includes a conflict resolution setting in import options, offering choices such as do not import, update, or add with a different name when an object of the same name exists. If you leave the default without considering it, the import may actually run but some items will not be included due to conflict rules, or existing objects may be unintentionally updated.

This problem is troublesome because it is hard to judge by appearance alone. If an existing drawing already contains objects with the same names and the conflict setting favors “do not import,” users may perceive the result as “cannot import.” In reality the system is simply following the conflict rules. Conversely, settings leaning toward “update” can replace existing objects and affect labels and dependent elements. The official explanation also notes that update behavior is not a simple delete-and-recreate but is designed to preserve dependent elements where possible. Thus this checkpoint affects not only import success but also the preservation of existing drawings.

Countermeasures include receiving the file into a test drawing first, checking not only the received file name but also internal object names, and using add-with-different-name on conflicts to compare differences if necessary. Even when the source file name differs, internal object names can still collide with existing drawings. Because imported object names use the names from the source file, being mindful of naming on the receiving side helps detect collisions quickly.

Checkpoint 6: Is the destination site or collection as expected?

The sixth checkpoint is the destination where imported objects are placed. The official dialog allows you to specify which site to place alignments, parcels, and planned lines into. By default, alignments and planned lines may be placed into a higher-level collection, and parcels may go into a default site. So when you feel you “can’t find” objects after import, they may have been placed into a different destination than you expected.

This symptom is especially common in drawings that use multiple sites. In practice, teams may separate sites or collections for existing, planned, and validation work, but if you do not clarify the destination before importing, objects may exist in the drawing but the person only checks their usual location and concludes “it’s not in there.” Since the official documentation explicitly states that alignments or planned lines can be placed into an upper collection, the basic step is to check the entire management tree.

The event display after import is also helpful here. If the event display shows success counts but you cannot find the objects, first suspect destination or display conditions. If the event display indicates elements failed, then suspect the source file content or selection settings. Checking the destination is not a standalone task — it works best when combined with event display, object names, and the data tree selection results. Practitioners who quickly resolve import troubles tend to check management information as well as the drawing space.

Checkpoint 7: Is data volume or update status the cause?

The seventh checkpoint is data volume and the update status of the environment. Vendor support notes include examples where importing exchange files containing numerous planned lines or massive numbers of elevation points leads to processing never completing or remaining pending, and they explain that later updates implemented performance improvements. In other words, before concluding “operator error” or “file is broken,” consider the simple possibility that the load is too high or that you’ve hit a known performance issue.

This checkpoint is important because if the cause is the environment rather than settings, repeating the same procedure will not improve the situation. Especially in projects that exchange planned lines or high-density data through this format, the file’s mass directly affects processing time. If import is extremely slow, nearly unresponsive, or the same symptoms occur on multiple environments beyond the operator’s terminal, it is realistic to first separate the issue by data volume or check whether updates have been applied. This judgment is consistent with known vendor-reported issues.

In practice, heavier projects tend to tempt you to import all elements at once, but trying surfaces, alignments, and other elements separately can reveal the bottleneck. If surfaces import but planned lines stall, then a specific element is the performance source; if everything is slow regardless of selection, suspect the overall file size or the environment. Only by viewing settings, content, and environment from three directions can you truly say “it cannot be read.” Before hastily rebooting or reinstalling, perform this separation.

Practical workflow to reduce import troubles

It’s hard to remember the seven checkpoints every time on the spot, so standardizing the flow in practice is effective. A recommended fixed sequence is: upon receipt confirm purpose, get a sense of contents, check drawing units and coordinate conditions, reset import settings, run a test import with only necessary elements, confirm success via the event display, and then reflect to production. This adds pre- and post-receipt verification steps to the two-step import structure shown in the official help. With this flow you can clearly see whether the cause is the source file or a setting.

Also, using a separate validation drawing is highly effective. Importing directly into the production drawing increases the chance of multiple simultaneous problems such as same-name collisions, inclusion of unnecessary objects, or carrying over wrong transformation settings. If you first import into a validation drawing, you can calmly check object names, destinations, counts, positions, and usability. The exchange format is a standard designed for reuse in later processes, so preserving reproducibility of import results is not mere careful operation but a matter of work quality itself.

Furthermore, when requesting the sender to rework or re-export, it is important not to say vaguely “we couldn’t read it” but to be specific: “surfaces import but alignments are missing,” “coordinate conditions are unclear so position verification is impossible,” “please separate naming to avoid same-name collisions,” etc. Understanding what the exchange specification can contain makes your requests concrete and improves the quality of handoffs next time. The more accurate the receiver’s verification, the more naturally the sender’s output quality improves.

Summary

When the target software cannot import the target format, the points to check are not just simple operator mistakes. It is important to sequentially separate causes from seven perspectives: the source file contents, the selection of elements to import, drawing units and coordinate conditions, translation and rotation, same-name object conflicts, destination confirmation, and data volume or update status. The official help also states that import is a two-step process of setting and component selection and that status can be checked in the event display. In other words, import troubles are best addressed by verifying facts at each stage rather than relying on intuition.

What is really required in practice is not merely the ability to import, but that the imported design data can be reliably connected to review, construction planning, as-built confirmation, and completion checks. Domestic specifications standardize exchange data for reuse in design, construction, and maintenance stages. Therefore, you should emphasize whether the necessary elements have been imported in a reusable form with the correct coordinate conditions, rather than merely whether something appeared.

After confirming consistency of exchange data within the office, the next efficiency difference is how quickly you can verify coordinates and design positions on site. Even if the drawing looks correct, if you cannot quickly check relationships with reference points or planned positions on site, rework will occur. In such situations, using smartphone-mounted high-precision GNSS positioning devices like LRTK to connect design data checks to on-site coordinate verification shortens the cycle between drawing verification and field verification. Having both a system that avoids import confusion and methods that prevent field confusion steadily raises overall productivity in practice.