The cost of disorganised survey data

Survey data management is not a glamorous topic, but poor practices here undermine even the best fieldwork. A misnamed file delays a deadline. An overwritten observation set means returning to the field. A backup that was never made turns a hard-drive failure into a project crisis. Establishing a clear data workflow before the first day of fieldwork saves far more time than it costs to set up.

The challenge grows with project scale. A single-day topographic survey might produce a handful of files, but a multi-phase infrastructure project running over months generates thousands. Without consistent naming, folder structure, and version tracking, the team spends progressively more time searching for data and less time using it.

File naming conventions that scale

A robust naming convention encodes enough information that anyone on the team can identify a file without opening it. A proven pattern is: project number, date in YYYYMMDD format, data type code, and version number, all separated by underscores. For example, PRJ025_20241015_TOPO_V01 tells you the project, the survey date, the data type, and which revision you are looking at.

Common data type codes

  • RAW: unprocessed instrument observations
  • ADJ: adjusted or corrected data
  • DWG: CAD drawing files
  • RPT: written reports
  • IMG: site photographs
  • CSV: exported coordinate lists
  • RINEX: GNSS raw observation files

Avoid spaces, accented characters, and special symbols in filenames. These cause problems when transferring between Windows, macOS, and Linux systems, and they break some FTP and cloud sync tools.

Folder structure for survey projects

A standardised folder template applied to every project eliminates guesswork about where to save or find a file. A practical structure places a root folder named after the project number, containing five subfolders: 01_RAW for untouched instrument downloads, 02_PROCESSED for corrected and transformed data, 03_DRAWINGS for CAD and GIS outputs, 04_REPORTS for technical reports and correspondence, and 05_PHOTOS for dated site photographs.

The critical rule is that raw data is never modified in place. All processing works on copies stored in the processed folder, preserving the original observations as an audit trail. If a processing step goes wrong, you can always start again from the raw data without returning to the field.

Backup strategies that actually protect you

The minimum standard is the three-copy rule: one working copy on the office workstation, one on a separate physical drive kept in a different location, and one in cloud storage. Each copy must be verified periodically; a backup you have never tested restoring from is not a backup.

Cloud storage in practice

Services such as Google Drive, OneDrive, and Dropbox can synchronise the project folder automatically so that every saved file is mirrored to the cloud within minutes. This provides both off-site backup and remote access, which is particularly useful when field staff need to send data to the office before returning from site.

Be aware of storage limits. Point cloud files from terrestrial laser scanners can reach several gigabytes per scan, so choose a plan with adequate capacity or archive completed scans to cold storage after delivery.

Transferring data from instruments to the office

Total station data

Modern total stations store observations on internal memory or SD cards. At the end of each field session, download all job files to the 01_RAW folder immediately. Do not rely on instrument memory as long-term storage: memory fills up, instruments are shared between crews, and hardware faults happen. Once the download is confirmed, the instrument memory can be cleared for the next session.

For information on the instruments we supply and support, visit our surveying equipment page.

GNSS data

GNSS receivers typically export data in multiple formats: RINEX files for post-processing, manufacturer-proprietary formats, and CSV coordinate lists. Download all available formats to the raw folder. The RINEX files may not be needed today, but if a coordinate is later questioned, they allow independent re-processing against a different base station or correction service.

Version control without complexity

For most survey offices, a simple version numbering scheme in the filename is sufficient. Each revision increments the version number: V01, V02, V03. When a drawing or report is formally approved, the suffix changes to FINAL. Previous versions are moved to an Archive subfolder rather than deleted, because they may be needed to resolve disputes or trace the history of a design change.

Teams working on larger projects may benefit from a shared document management platform that tracks changes automatically, but the filename convention remains the foundation even when such tools are used.

Software compatibility and data exchange

Survey data passes through many software environments during its lifecycle: instrument firmware, field processing apps, office CAD and adjustment packages, GIS platforms, and the client's own systems. Exporting data in open, widely supported formats such as CSV and DXF alongside the native format ensures that every recipient can use it regardless of their software choice.

When delivering data to a client, include a brief readme file listing the coordinate reference system, the units, the date of survey, and the software versions used. This metadata prevents misinterpretation and makes the dataset self-documenting.

To learn more about our end-to-end survey services, including data processing and deliverable preparation, get in touch with us.

For answers to common questions about working with a survey office, see our frequently asked questions guide.