The field guide
Understand the file before you change it.
A survey point file checker helps you answer a specific question: is this point list structurally ready for the next step in my workflow? It is useful when a collector export arrives from the field, when an office technician prepares a CAD import, or when a small team receives a point list without a clear explanation of its format. CogoKit reviews the text and the fields you select, then identifies the source records that need attention. It does not decide whether the measurements represent the site correctly.
The check is deliberately separate from editing. Every point remains in the result, including repeated identifiers and records with errors. Missing values stay missing, and descriptions are kept as business data rather than rewritten as display labels. That makes it possible to compare the report with the supplied file and explain why a record was flagged. Use the findings to guide a correction in the source, then check the revised data again.
Prepare a small, readable point file
Use UTF-8 CSV or TXT, with commas, semicolons, or tabs separating the fields. Files may include a header row and a leading UTF-8 byte-order mark. Blank lines are counted and skipped, but a nonblank record is not discarded because it contains an error. Descriptions containing a separator should be enclosed in double quotes. A literal double quote inside a quoted field is represented by two consecutive double quotes. Properly quoted multiline descriptions are supported, with both the start and end source lines retained.
This release accepts up to 10 MiB and 100,000 point records. It rejects invalid UTF-8, UTF-16 input, and binary text containing null characters instead of guessing an encoding. If your collector exports a different character set, create a UTF-8 export in the source software. A failed read does not produce a partial success report. For large projects, split the input into files that retain meaningful source names and keep those names with the exported checks.
Confirm field order, axes, and units
Map the point identifier, northing, and easting before checking. Elevation and description can be omitted when they are not part of the source. The usual PNEZD order is point identifier, northing, easting, elevation, and description. PENZD places easting before northing. These are file layouts, not coordinate reference systems. Autodesk’s point-file documentation describes named import formats and how their fields are interpreted.
The automatic preview suggests recognized headings and a delimiter. A file without recognized headings is initially shown in a conventional order that you must confirm. X and Y are intentionally not assigned to northing and easting automatically. The meaning of those labels depends on the exporting application and its conventions. If they are your only headings, use the source documentation or a known control point to decide the mapping. Looking at the magnitude of two columns cannot reliably identify their axes.
Horizontal and elevation units are separate selections. Choose metres, international feet, or legacy US survey feet to describe the input. Selecting a unit does not multiply, divide, or relabel the stored coordinate strings. The two foot definitions are different; an old file must retain its documented unit. NIST’s US survey foot guidance explains the retirement of that unit for new work while acknowledging historical and legacy use. This checker performs no unit conversion or datum transformation.
Choose checks that fit the handoff
Missing point identifiers, missing horizontal coordinates, invalid numeric values, malformed quoting, and inconsistent column counts are errors. They prevent the affected record from being counted as processable under the selected rules. Coordinates may be negative or zero. Finite decimal numbers, leading signs, and scientific notation are accepted; thousands separators and decimal commas are not numeric syntax in this release. Use a decimal point, with the file delimiter separating fields. This avoids treating ambiguous punctuation as a plausible coordinate.
Require elevation when the next task needs it. With that option off, a missing elevation is a note and the record can still be processable in two dimensions. With it on, the same record becomes an error. An elevation that contains nonnumeric text is an error in either mode. Optional numeric-ID checking requires digits only; it is a narrow rule that you choose for your destination, not a guarantee of compatibility with every version of a surveying or CAD application.
Duplicate identifiers are warnings on every occurrence. The records are never overwritten, merged, or renumbered. Identifier comparison uses the exact stored text: 0012 differs from 12, and surrounding whitespace is preserved and separately flagged. Optional coordinate and elevation ranges also produce warnings. Their endpoints are inclusive, so a value exactly equal to the minimum or maximum is within the selected range. Range comparisons use the parsed value without display rounding. A range warning asks for review; it does not prove a field measurement is wrong.
A complete example you can reproduce
Choose Try example to load eight synthetic points, with a header in PNEZD order. Leave the elevation requirement and numeric-ID rule off, keep the comma delimiter, leave all ranges blank, and confirm the mapping and units. Point 0012 appears twice, on source lines 4 and 5. Point 0014 on line 6 has an empty northing. Point 0015 on line 7 has no elevation. The description for point 0011 contains a comma inside quotes and is a single valid field.
The expected summary is 8 total records, 7 processable records, and 1 blocked record. The issue list contains one missing-northing error, two duplicate-ID warnings, and one missing-elevation note. The two duplicate records remain in the processable count because warnings do not make a record structurally unreadable. They still need your review before a target import. Turn on required elevation and rerun: the missing-elevation note becomes an error, giving two blocked records and six processable records. Nothing is filled with zero.
The position preview draws seven points because the record with no northing cannot be placed. Select a drawn point to locate its record in the table, or select a table row to inspect its exact source text. The diagram uses east to the right and north upward, with equal horizontal and vertical scale. It has no basemap and makes no claim about geographic location. For larger files it draws the first 1,000 records with valid horizontal coordinates; validation and report export still cover the entire accepted file.
Read the result without losing context
Errors, warnings, and informational notes are separate issue levels. One record can have several issues, so issue counts will not always equal record counts. A record’s displayed status is its highest issue level. “Processable” means that none of the implemented error rules blocked that record; it does not mean approved, correct, or ready for an arbitrary destination. A file with no findings can still have reversed axes, an incorrect unit assumption, or an unsuitable coordinate reference.
Select a result to see its original line and fields. The table shows 25 entries per page, and status filters apply across the complete result. Additional columns are retained in each record even when the table shows only the mapped survey fields. If you change input text, mapping, units, or check options, the previous report is invalidated. That prevents an old green result from being mistaken for a check of newly edited data. A worker handles validation, and Cancel stops the current check while retaining your input.
Export a review record, not a hidden correction
The full JSON report contains the tool version, check time, source name, original text, header, field mapping, unit labels, all records, and findings. It preserves extra columns and the raw field strings without numerical rounding. The separate CSV contains the issue list with source lines and explanatory messages. Both are review formats. Neither silently removes blocked points, modifies descriptions, or produces a reformatted instrument file.
The issue CSV uses comma separators, quoted fields, and a UTF-8 byte-order mark. Text that could be interpreted as a spreadsheet formula receives a leading apostrophe, including certain values beginning with a sign. This protection is for reviewing findings in spreadsheets; it is why the issue list must not be fed into an instrument as original point data. Exact original values remain in the JSON report and source-text download. The printable report lists the summary, selected settings, and every issue; the JSON is the more complete archival record.
Keep the limits of a file check in view
All processing happens locally in browser memory, without uploading the file or saving project data in local storage. You can download reports explicitly, restore the initial input text, or clear the entire session. Refreshing the page also discards the current working data. The site does not promise installed offline operation, because no offline application cache is configured. Downloaded copies are ordinary files under your control and are not removed when you clear the browser session.
This tool does not recognize a coordinate reference from numerical values, compare against control, calculate legal boundaries, certify observations, or replace destination-software import testing. Its planar preview should not be used as a geographic map. When a handoff depends on a local origin, height datum, grid-to-ground relationship, or an agreed target format, confirm that information outside this check and keep it with your project. The most useful result is a clear statement of what was checked and what still requires professional judgment.