File Conversion Overview

Browser-native GSI, CSV, and DXF conversion — survey workflows, USDM v1, client-side privacy, and quality checks.

Foundation

High-Precision Spatial Data Exchange: A Technical Overview of Survey File Conversion

In geomatics and land surveying, migrating coordinate and observation datasets across field instruments, office spreadsheet applications, and computer-aided design (CAD) environments is critical to maintaining data integrity. For decades, surveyors and technicians have wrestled with discrepancies between proprietary instrument files, raw text documents, and complex vector drawings.

The Surveying Core platform provides browser-native utilities designed to resolve these data translation friction points:

  • The GSI → CSV converter bridges the gap between raw field observations and tabular office formats.
  • The CSV → GSI converter translates adjusted coordinate tables back into instrument-ready files for layout operations.
  • The CSV → DXF converter builds structured 2D CAD point layers optimized for drafting and layout reference.

Converter pages are public for discovery, but file conversion requires sign-in. Calculators remain free; conversion requires an account — see Pricing. All parsing and export run in the browser — coordinate files are not uploaded to external servers for conversion. For field reference tables, see the Library.

Formats in the Survey Workflow

The lifecycle of survey data is cyclical, beginning with field acquisition, moving to office analysis and drafting, and returning to the field for stakeout and construction layout. Each stage relies on distinct file structures optimized for hardware constraints, software flexibility, or drawing manipulation.

During field acquisition, electronic total stations capture spatial information using optical encoders and electronic distance meters (EDMs), recording raw measurements such as horizontal circle readings, vertical angles, and slope distances. Proprietary file formats, such as Leica’s Geo Serial Interface (GSI), write these observations along with computed Cartesian coordinates directly to on-board storage.

Once field operations conclude, office technicians must process and adjust these measurements. For least-squares network adjustments, coordinate comparisons, or manual attribute editing, raw database structures are highly impractical. Technicians require flat, human-readable formats like Comma-Separated Values (CSV) that open in Microsoft Excel or database management systems. Historically, this step relied on legacy MS-DOS utilities or custom Excel VBA macros — solutions that are increasingly difficult to maintain on modern operating systems and lack cross-platform compatibility.

After data cleaning, adjusted coordinates are brought into CAD programs like AutoCAD or Civil 3D to draft boundary lines, design alignments, and model physical structures. For this drafting stage, coordinate lists are converted into vector formats, with the Drawing Exchange Format (DXF) acting as the primary open standard for coordinate point imports.

Finally, design coordinates created in CAD must return to the field. Laying out proposed foundation piles, utility lines, or roadway corridors requires exporting design coordinates from CAD, converting them back into GSI format, and uploading them to a field total station. Modern geomatics students must master these format transitions to understand how coordinate geometry behaves across different operating systems, instrument firmwares, and design software.

The Conversion Pipeline and the Universal Survey Data Model (USDM v1)

Converting files between multiple formats can lead to complex development challenges as the number of formats grows. If every file format required a custom converter for every other format, supporting NN files would require N×(N1)N \times (N-1) distinct conversion paths. To prevent this complexity, Surveying Core uses a centralized translation architecture based on the Universal Survey Data Model version 1 (USDM v1).

Incoming File ──► [Parser] ──► USDM v1 (in-memory) ──► [Exporter] ──► Target File

The conversion pipeline consists of three distinct phases:

  1. Parsing: The parser reads the source format (such as GSI or CSV), validates the file structure, and extracts core spatial parameters into local browser memory.
  2. Normalization: Parsed data is structured into a unified in-memory representation. USDM v1 uses a clean point schema that strips instrument-specific headers while preserving coordinate precision.
  3. Exporting: The exporter reads the USDM v1 structure and writes coordinate points into the target file format (such as GSI, CSV, or DXF).

The USDM v1 point schema is detailed in the table below:

PropertyTypeConstraintsPurpose
idstringRequired, trimmedPoint identifier or label
eastingnumberRequiredEast–west Cartesian position
northingnumberRequiredNorth–south Cartesian position
elevationnumber | nullOptionalVertical height
codestringOptional, max 32 charsFeature or attribute code

By converting all files to USDM v1 first, the platform decouples input logic from output logic. A parser only needs to translate its specific format into USDM v1; the system can then export that data to any supported target format without custom file-to-file translation code.

CSV Conventions and Spatial Office Pitfalls

The Comma-Separated Values (CSV) format is widely used for tabular data exchange, but it lacks a single formal specification. In surveying offices, this flexibility can lead to coordinate mapping and translation errors.

Delimiters and encodings

CSV files use delimiters to separate data columns — typically commas, semicolons, or tabs. In regions where a comma is used as a decimal separator (such as 15204,32115204{,}321), semicolons are often the column delimiter. In Anglo-American regions, commas separate columns and periods separate decimals. Text encodings can also cause issues; legacy total stations require standard ASCII or UTF-8 without a Byte Order Mark (BOM) to prevent corruption on upload.

Coordinate order layouts

Geomatics professionals use several coordinate ordering layouts. If a system interprets coordinates using the wrong layout, the entire dataset can be rotated or flipped, leading to severe construction errors. Common layouts include:

  • PNEZD: Point ID, Northing, Easting, Elevation, Description — common in regional grid workflows.
  • PENZD: Point ID, Easting, Northing, Elevation, Description — the default column order for Surveying Core CSV export (PointNumber,Easting,Northing,Elevation,Description).
  • ENZ: Easting, Northing, Elevation — typical for surface modeling imports.
  • NEZ: Northing, Easting, Elevation.

Header row pitfalls

Field instrument firmware cannot parse string headers. If a coordinate file contains a header row like Point_ID,Northing,Easting,Elevation,Description, the instrument may reject the upload. Office software and web parsers, however, need headers to map columns automatically.

Surveying Core uses an intelligent CSV import path. On upload, the parser reads the initial lines. If it detects standard geomatics header strings, it maps columns automatically. If headers are missing or ambiguous, a column mapping wizard lets you verify Easting, Northing, Elevation, ID, and Code assignments before conversion.

GSI Overview

The Geo Serial Interface (GSI) is a fixed-width, block-structured format used by Leica Geosystems total stations and digital levels. For bit-level structures and word-index detail, see the GSI format guide.

GSI-8 versus GSI-16 structure

Two primary variants exist, distinguished by word length:

  • GSI-8: Each data block uses 8-character data payloads. Common on legacy total stations (TPS300, TPS400, TPS700 series).
  • GSI-16: Uses 16-character payloads for higher precision and longer point IDs. GSI-16 blocks are identified by an asterisk at the start of the line.
GSI-8 coordinate block example:
110001+00000101 81..00+01234567 82..00+02345678 83..00+00100000
└─ Pt ID       └─ Easting      └─ Northing     └─ Elevation

GSI-16 block example:
*110001+000000000PNC0055 81.002+0000000012345678 82.002+0000000056789012
└─ Pt ID                 └─ Easting              └─ Northing

Word indexing (WI) and block architecture

GSI records are written in lines called blocks, with words separated by spaces. Each word contains:

  1. Word Index (WI): Positions 1–2 define the parameter (11 = Point ID, 81 = Easting, etc.).
  2. Information fields (AI): Positions 3–6 describe sequence, units, or input mode.
  3. Data payload (DA): Remaining characters hold the value, prefixed with + or - and zero-padded to fixed width.

Critical word indices for coordinate exchange:

WIParameterTypical representationUSDM v1 mapping
11Point IDText (padded)id
81Target eastingMeters or feet (per AI)easting
82Target northingMeters or feet (per AI)northing
83Target elevationMeters or feet (per AI)elevation
71Point / feature codeAlphanumericcode
84–86Station E/N/HInstrument setupMetadata (not stakeout points)

When parsing GSI, the importer scans each line for these word indices. When WIs 81, 82, and 83 are present, payloads are extracted, decimal scaling is applied from the unit flag, and coordinates are written to USDM v1 in memory.

DXF Stakeout Export Mechanics

The Drawing Exchange Format (DXF) is a tagged vector format developed by Autodesk. Unlike proprietary DWG files, ASCII DXF is plain text and widely compatible across CAD and GIS software.

For stakeout, surveyors typically need a clean set of point nodes — not complex linework, hatching, or block libraries. The Surveying Core converter exports minimal POINT entities suitable for layout reference.

The MVP exporter writes ASCII DXF with a lightweight header and one POINT entity per USDM point. Each point includes:

  • Group code 0: Entity type (POINT)
  • Group code 8: Layer name (default layer 0 in the current MVP)
  • Group code 10: X-coordinate (easting)
  • Group code 20: Y-coordinate (northing)
  • Group code 30: Z-coordinate (elevation; 0 when elevation is missing)

CAD programs may display bare POINT entities as small markers. If points are hard to see, adjust point display style in your CAD software (for example AutoCAD PDMODE / PDSIZE) after import.

Tool Guide: GSI → CSV

The GSI → CSV tool supports field-to-office workflows — converting Leica memory-card coordinates into spreadsheets for Excel, Google Sheets, or QGIS.

  • Primary use case: Transforming total-station GSI jobs into tabular CSV for office processing.
  • Input: A valid Leica .gsi file (GSI-8 or GSI-16).
  • Output: Comma-delimited .csv with header row (PointNumber,Easting,Northing,Elevation,Description).
  • Converter: GSI → CSV

Step-by-step field-to-office pipeline

Leica instrument ──► SD card ──► GSI file ──► CSV ──► spreadsheets / QGIS
  1. On the Leica total station, export the desired job in standard GSI format.
  2. Transfer the .gsi file to your computer or mobile device.
  3. Open the GSI → CSV converter and sign in.
  4. Select the .gsi file. The browser parses it locally through USDM v1.
  5. Click Convert to CSV and download the result.

Tool Guide: CSV → GSI

The CSV → GSI tool reverses the office workflow, preparing coordinate lists for field upload.

  • Primary use case: Preparing stakeout point lists from design spreadsheets for Leica total stations.
  • Input: Delimited .csv with numeric coordinates and point identifiers.
  • Output: Formatted Leica .gsi text (GSI-8 in the current MVP UI).
  • Converter: CSV → GSI

Step-by-step prep-to-instrument pipeline

Design coordinates (CSV) ──► GSI file ──► SD card / USB ──► total station layout
  1. Export layout points from design software as CSV.
  2. Open the CSV → GSI converter and sign in.
  3. Upload the CSV. If columns are not auto-detected, map them to ID, Easting, Northing, Elevation, and Code in the mapping wizard.
  4. Click Convert to GSI and download the .gsi file.
  5. Copy the file to your Leica SD card or USB drive and load it into the instrument job.

Tool Guide: CSV → DXF

The CSV → DXF tool generates lightweight point drawings from coordinate lists.

  • Primary use case: Creating CAD point layers with elevation for reference in AutoCAD, Civil 3D, or BricsCAD.
  • Input: Delimited .csv file.
  • Output: ASCII .dxf with one POINT entity per coordinate.
  • Converter: CSV → DXF

Step-by-step CAD import pipeline

Survey points (CSV) ──► DXF file ──► CAD drawing area
  1. Prepare your coordinate list as CSV.
  2. Open the CSV → DXF converter and sign in.
  3. Upload the file and confirm column mapping (Easting → X, Northing → Y, Elevation → Z).
  4. Click Convert to DXF and download the drawing.
  5. Open the .dxf in your CAD program or attach it as an external reference (XREF).

Client-Side Processing and Privacy

A core design feature is that file conversion executes entirely in the user’s browser. No coordinate data, raw measurement files, or project point lists are uploaded to external servers for parsing or export.

The privacy advantage

Land survey coordinate databases represent sensitive intellectual property, proprietary infrastructure layouts, and boundary control. Uploading these files to third-party servers creates security and compliance risk.

Surveying Core uses the HTML5 FileReader API to read the source file from local storage. The conversion engine (lib/formats/*) runs in JavaScript, normalizes data to USDM v1 in RAM, and generates a download via a local blob URL. Spatial records never leave your machine during conversion.

┌─────────────────────────────────────┐
│         Your local browser          │
│                                     │
│  User file ──► FileReader           │
│            ──► Parse → USDM v1      │──► Download
│            ──► Export target format │
└─────────────────────────────────────┘

Credits are checked and consumed via API calls (metadata only — format, file size, point count), but the coordinate file itself stays client-side.

Re-export without extra credits

If you convert the same USDM dataset to a different export format within five minutes, a re-export session applies and no additional credit is charged. This supports exploring CSV, GSI, and DXF outputs from one import without penalizing format trials.

Mathematical and Spatial Validation Protocols

Conversion must not be treated as simple text translation. Spatial data integrity demands structured quality-assurance steps after every job.

1. Point count verification

Verify that the record count in your source file matches the output. If your CSV has 1,250 data rows, your GSI export should contain 1,250 coordinate blocks and your DXF should contain 1,250 POINT entities. A discrepancy usually indicates blank rows, malformed headers, or parsing errors.

2. Spatial extents sanity check

After import to CAD or GIS, zoom to extents and confirm coordinates fall in the expected range for your project. If eastings should be near 400,000 m and northings near 5,000,000 m but the drawing shows swapped axes, re-run the conversion with corrected column mapping.

You can also verify bearings and distances between control points with the Bearing & distance calculator.

3. Spot-checking control points

Identify at least one known monument or control point in the source file and compare coordinates character-for-character in the output — horizontal and vertical.

Verify horizontal distance between two points:

ΔE=E2E1ΔN=N2N1\Delta E = E_2 - E_1 \qquad \Delta N = N_2 - N_1

D=(ΔE)2+(ΔN)2D = \sqrt{(\Delta E)^2 + (\Delta N)^2}

Grid bearing from north (clockwise):

θ=atan2(ΔE,ΔN)\theta = \text{atan2}(\Delta E, \Delta N)

(normalize to 0°θ<360°0° \le \theta < 360°)

4. Re-export round-trip testing

The gold standard of coordinate validation is the round-trip test:

  1. Convert raw GSI to CSV.
  2. Convert that CSV back to GSI.
  3. Compare initial and final GSI files. Trailing-zero formatting may differ, but coordinate values must match.

MVP Limits and Future Capabilities

The current MVP focuses on direct, point-based spatial conversions. Be aware of these limits:

  • No bulk/batch processing: One file per conversion job.
  • No direct DWG export: Output is ASCII DXF with POINT entities only.
  • No LandXML / alignment geometry: Discrete USDM v1 points only — not road alignments, cross-sections, or surfaces.
  • No direct .xlsx parsing: Save spreadsheets as .csv before conversion.
  • No cloud project storage: Processed coordinates live in browser memory; refreshing clears unsaved work (by design for privacy).
  • GSI-8 default on CSV → GSI UI: The engine supports GSI-16 round-trips in tests; the live converter page currently exports GSI-8.

Troubleshooting Common Conversion Failures

SymptomProbable causeCorrective action
Parser rejects GSI inputMissing sign flags or inconsistent formattingUse instrument-native export; GSI-16 lines must start with *
Points rotated 90° in CADEasting and Northing columns swappedRe-upload CSV and swap Easting/Northing in the mapping wizard
Points at elevation 0.0Elevation column unmapped or missingMap the elevation column; missing values export as 0 in DXF
Total station rejects GSI uploadGSI-8 vs GSI-16 mismatchMatch instrument settings to exported variant
Special characters corrupted in point IDsUTF-16 or UTF-8 BOM encodingRe-save as UTF-8 (no BOM) or ANSI in a plain-text editor
Conversion blockedNot signed in or insufficient creditsSign in; check remaining credits on your account

Next Steps

Maximize field efficiency and protect data privacy with Surveying Core’s browser-native tools: