Civil 3D Point Import Errors: A File Check Workflow

Identify whether the problem is reading, placement or display

Write down the exact error message and the operation used. Importing points into a drawing, adding point-file data to a surface and importing into a survey database are different workflows with their own settings. A file that cannot be read needs a different investigation from points that imported successfully but appear in the wrong location. Points that are present but not visible may instead involve a point group, style, layer or view setting in the receiving application.

Keep the original export unchanged while investigating. Record the Civil 3D version, selected file format, target drawing or database context and a few affected identifiers. This browser toolbox can help inspect and prepare supported point tables, but it cannot read your drawing's internal configuration or verify an installed Civil 3D session. Use the official documentation for the actual operation and version when checking application-specific behavior or resolving an error that persists with a verified small file.

Compare the selected format with the physical columns

A named point-file format describes the input layout. Check the column meanings in the actual definition, including ignored or user-defined fields, rather than relying solely on a familiar name. Compare that definition with several physical source records. PNEZD expects Northing before Easting; PENZD expects the opposite. Extra leading codes, omitted heights or descriptions placed in a different column require a suitable explicit format instead of pretending the source is a standard five-field table.

Load a copy in the checker and map the columns deliberately. Use a known point with unequal Easting and Northing so an axis swap is visible. A successful browser check confirms that this interpretation can read the supported table; it does not automatically validate the separate Civil 3D format definition. The two interpretations should describe the same fields. If one treats an identifier as Easting, the resulting numbers can look plausible while belonging to the wrong quantity.

Check separators, headers and text encoding

Inspect the raw file in a text viewer rather than only in a spreadsheet. A comma, semicolon, tab and run of spaces are different separator schemes. Descriptions containing the separator require correct quoting under the chosen text format. Unexpected extra columns can come from a comma inside an unquoted description, while a whole row appearing in one field often means the wrong delimiter was selected. Record boundaries matter as well as the number of visible columns.

Confirm whether the first record is a header, a comment or actual point data. Do not lose the first point by skipping a line without checking it. This site's shared point importer reads UTF-8 comma, semicolon or tab data and explicitly selected XLSX worksheets; a vendor's whitespace format may need a controlled export to that supported layout. Renaming a file does not change its encoding. In a workbook, resolve formulas, date cells and error cells before creating ordinary coordinate values.

Distinguish numeric errors from absent optional data

A coordinate field should contain a valid number in the intended notation. Unit text embedded in the number, an accidental decimal comma, a missing required coordinate or a spreadsheet error can make a record unusable. Check the exact source line and field reported by the checker. Do not replace every invalid value with zero: zero may be a valid coordinate or elevation and would conceal the difference between a measurement and an unknown value.

Height requirements depend on the receiving task. A planar review can work without elevations, but a three-dimensional surface or point deliverable may require them. Obtain the missing height from an authoritative source or choose an explicitly acceptable two-dimensional workflow. Keep excluded or uncomputed records in a separate report if the application cannot import them. A smaller output is not a complete successful conversion unless the omitted records and the reason for each omission are accounted for.

Inspect point-number conflicts in the destination

A clean source table can still collide with identifiers already present in a drawing or survey database. Review the receiving application's configured conflict behavior before importing. Options that overwrite, merge or renumber can have different consequences for coordinates and attributes. A spreadsheet preview of unique names does not establish whether the destination considers 001 and 1 equivalent. Consult the actual destination rules and test with a nonproduction copy.

If a separate number range is appropriate, prepare it with the renumbering tool and keep the complete mapping. Protect controls that must retain their identifiers. Do not change names simply to suppress an unexplained conflict; the existing point may represent a revised or unrelated observation that deserves review. A point-file edit does not update external drawing labels, survey setups or project references automatically, so coordinate the naming change with the rest of the handoff.

Check position and height context after a successful import

When coordinates parse but points land far from the expected location, investigate axis order, units, projection zone, local calibration and design revision. A visually similar pattern is not enough to prove the reference is correct. Compare at least one documented control numerically in both source and destination. A uniform scale difference may suggest units or grid/ground context, but identifying a pattern is only a clue; confirm the actual definition before applying any correction.

A systematic height difference similarly needs a known vertical reference. Do not solve an unexplained discrepancy by applying an arbitrary height shift to make the display align. This site's format converter changes serialization and explicitly selected units; it does not establish a horizontal or vertical datum operation. The supported projection and local-fitting tools have their own scope and required evidence. Use them only when their assumptions match the real relationship between the sources.

Reproduce the problem with a small known file

Create a minimal copy containing one known control and a few representative records, while retaining the untouched full export. Include a leading-zero name and a description with punctuation if those features matter. Test a supported destination format in a copy of the drawing or the appropriate safe test context. If the small verified file imports correctly, add the problematic records until you can identify the particular row or condition that changes the outcome.

Save the exact import error, the format definition, the source rows, expected values and actual values. The examples page supplies synthetic files for practicing the check-and-convert sequence without disclosing a project. A reproducible case can distinguish a source-data issue from a destination setting or software behavior. When reporting a problem, state what was actually tested; do not describe an older forum workaround as proof of a current defect in the version you are using.

Questions and answers