Survey Point File Tools

Start by identifying what the file represents

A coordinate file may be an instrument export, a design list, a drawing extraction or an edited office deliverable. Those sources can share the same five columns while describing very different things. Before changing anything, retain an untouched copy and note the originating application, export date, project revision, horizontal reference and height reference. A filename ending in CSV establishes a container, not the meaning of its values. A file that parses successfully can still belong to the wrong grid or an obsolete design revision.

Use the point file checker first when the layout is uncertain. Inspect several rows, state whether the first row is a header and assign the columns explicitly. PNEZD and PENZD are useful shortcuts only when the source specification agrees. Fields labelled X and Y need special care because different surveying and CAD conventions assign them differently. Compare one documented control point before trusting a visual plot.

Decide whether you are checking or changing records

The checker identifies structural problems such as missing coordinates, invalid numbers and repeated identifiers. The viewer adds a spatial check: an isolated point or an unexpected orientation can reveal an interpretation worth investigating. Neither result certifies the accuracy of the survey. A suspicious coordinate needs a source-based explanation, not a convenient replacement value. Review the source line beside the finding so you can distinguish an import problem from an observation that genuinely needs revisiting.

When the structure is correct but the receiving program needs another layout, use the format converter. Map the output order, delimiter and header deliberately. Preserve precision unless the delivery specification calls for rounding. Selecting a unit label in the importer does not convert the existing numbers. Actual unit conversion is a separate explicit choice in the converter, and it still does not perform a horizontal or vertical datum transformation.

Combine crews without losing their identities

The merge tool is appropriate when several interpreted point lists belong in one deliverable. Read and confirm each source independently before adding it to the queue. One crew may supply northing before easting, another the opposite order, and a third a different delimiter. Correct mapping resolves those layout differences. It does not resolve different coordinate systems, height datums or units; those need to be settled before the merge context is confirmed.

Conflicting point identifiers must be handled explicitly. Preserving identifiers blocks an unresolved collision. Assigning a distinct prefix and sequence to each source can retain every observation while making identifiers unique. The output mapping is essential because it connects new names to original files and rows. For an ordinary full merge, reconcile the sum of source records with the result. If records were deliberately excluded, retain the exclusion reason and account for them separately.

Renumber points and standardize descriptions separately

Renumbering changes point identifiers. Code editing changes descriptions. Keeping these operations separate makes a review easier because a point can be traced through each change. Use sequence numbering for a new convention, or an integer offset when the numerical spacing of old identifiers matters. Protect control identifiers and inspect the complete old-to-new map before applying it. Renaming a point in an exported table does not update a CAD label, a survey database reference or an instrument setup elsewhere.

The code editor works with complete description values and explicit mappings. For example, a documented EP to EDGE rule can normalize one crew's terminology while preserving coordinates. Do not assume that every space or punctuation mark is disposable: some field descriptions contain structured instructions. Review protected and unmatched descriptions, and keep the change audit. A visually tidy code list is not evidence that it still expresses the original field coding scheme.

Separate duplicate review from intentional selection

Repeated IDs, identical coordinates and nearby points are different findings. Two observations may legitimately describe different features at one location; two rows with the same name may represent incompatible measurements. Use duplicate review to identify candidates and record decisions. Avoid treating a distance threshold as an automatic permission to erase data. The receiver should be able to understand why one observation was retained and another was excluded.

Use the filter tool when the purpose is selection rather than correction. It can extract a documented point range, code group, elevation interval or coordinate window. Save both selected and unselected outputs when reconciliation matters. Their counts should account for the source without changing its fields. A display search is not necessarily the same thing as an export scope, so review the tool's explicit selection summary before downloading a handoff.

Compare revisions before replacing a deliverable

The file comparison tool answers what changed between two point-table versions. It is useful when a revised design arrives or an edited office file needs review. Retain both source versions, confirm their mapping and inspect added, removed, modified and unmatched records. Merely rearranging rows should not become a false coordinate change when point correspondence is clear. Repeated or changed names require an explicit matching decision rather than an assumption.

Use the design/as-built tool for a different question: how measured positions differ from confirmed design positions under a supplied tolerance. A revision comparison does not know which version is the intended physical target. Keep this distinction in filenames and reports. Replacing the previous file before reviewing the difference list destroys context that may be needed to explain a construction or drafting decision later.

Prepare CAD and spreadsheet deliveries deliberately

For CAD, export ordinary DXF point entities, optional labels and explicitly ordered paths. A three-dimensional point needs a known height. If you choose a two-dimensional projection, confirm that choice and keep it in the report; zero on a drawing plane is not an invented field elevation. Conversely, extracting a DXF means choosing supported entities and inspecting excluded objects. The visible drawing may contain information that is not represented by extracted point coordinates.

For spreadsheet input, choose an XLSX worksheet explicitly. Formulas, date cells and error cells are not silently treated as coordinate values. Plain UTF-8 CSV, TXT and TSV remain useful because their content is easy to inspect. A normal delivery should include the result file, the source-to-result mapping where relevant, and the settings report. Open a small output in the receiving application and compare a known control, a leading-zero identifier and a description containing punctuation before sending the complete job.

Questions and answers