How to Transfer GNSS, Point Cloud, and Raw Survey Files to the Office

A survey crew can lose a day of work without deleting a single file. It happens when the wrong thing goes back to the office: a coordinate list instead of the raw observations, a truncated LAZ that opens but is missing its last scan, a rover job with no note about which datum or antenna height it was collected on. The bytes moved. The information the office needs to actually process the job did not. And unlike a photo, a static GNSS occupation or a scan setup cannot be recreated from a desk. Getting it again means sending someone back to the point.

Raw survey files are large and unforgiving, which makes them the hardest thing a field crew has to move. This post is about the mechanics of moving them well: pulling the true raw files off the data collector, packaging observations and point clouds into one tracked delivery, pushing multi-gigabyte scans over a thin connection, proving each file arrived whole, and labeling it so the office can process it the first time. It is the file-handling detail underneath the broader routine for getting survey work from the field to the office, and it pairs with the wider view of how a survey crew should deliver field data.

Export the raw files, not the processed report

The most common mistake is sending the wrong export. A data collector will happily hand you a coordinate file, a stakeout report, or a LandXML of computed points, and those are useful deliverables. They are not the raw record. If the office needs to re-run a baseline, adjust a network, or re-derive a coordinate after a datum correction, it needs the observations themselves: the RINEX or vendor session files from each occupation, the total station raw job with its measured angles and distances, and the scanner's native project, not a decimated preview.

Know the difference for your own gear before you leave the point. Trimble collectors produce a .job or JobXML plus the raw GNSS .T02files; Leica and Topcon have their own session formats; RINEX is the neutral fallback almost everything can export. For scan work, the LAS or LAZ point cloud is the exchange format, but the scanner's own project holds the registration and full-density data. The rule is simple: if the office could not reconstruct the answer from what you sent, you sent a summary, not the survey.

Package the observations and the cloud as one packet

A survey delivery is never a single file. It is a set: several occupation files, the base logs, a total station job, one or more LAS/LAZ clouds, a control sheet, and the field notes that tie them together. Sent piecemeal, as three emails and a file-share link, they land in different places at different times and the office has no way to know when it has all of it. Missing one observation file looks exactly like having the whole set.

Treat the whole delivery as one unit. Compose a packet: every raw file, the processed products, a short cover sheet that says what the job is, and the job number, kept together and sent to one intake queue instead of scattered across inboxes. The office receives one thing with a clear boundary. It either arrived complete or it did not, and that is a question you can answer at a glance instead of by counting files against a memory of what should be there. The general technique for bundling this way is covered in the piece on handling large datasets and zips from the field, and it applies cleanly to survey work.

Move multi-gigabyte LAZ over the signal you actually have

A single scan project runs to tens of gigabytes; even a compressed LAZ of a corridor is far past anything email will carry, and often past what a shaky field connection can push in one attempt. Two design choices decide whether that transfer finishes.

The first is that the upload should go direct from the device to storage, not up through an application server or a field laptop acting as a middle hop. On a truck running one weak connection, that middle hop is exactly where a 40 GB cloud stalls. Streaming straight to the storage bucket lets the transfer use whatever bandwidth the connection actually has. The second is that the upload must be resumable. Field signal comes and goes as a truck moves behind a ridge or a phone rolls to the next tower. An ordinary upload treats that as fatal and restarts from zero, so a 90-percent-complete LAZ is thrown away. A resumable upload breaks the file into parts, confirms each as it lands, and picks up from the last confirmed part when the signal returns, so a drop costs you the one part in flight, not the whole cloud. A packet composed with no signal at all can wait on the device and send itself once a connection is back.

Verify the file arrived whole

This is where raw survey files punish the careless. A truncated point cloud still opens in a viewer. A RINEX file cut short still has a header and looks valid. A total station job missing its last shots still loads. “It opened” is not “it is complete,” and with data you cannot recollect, the gap between those two is the whole risk.

The only way to know a transfer finished intact is to check the bytes against a fingerprint. A SHA-256 checksum is computed for each file on the device before it leaves, and the same hash is recomputed on the server after the bytes land. If the two match, every byte arrived. If they do not, the file is re-sent before anything counts. Only when all the files verify does the packet count as submitted, and only then does the crew get a numbered receipt listing the file count and the total verified size. That receipt is proof the delivery is whole, not a hope that it is.

Name and label it so the office can process it

A verified file the office cannot interpret is only half a delivery. Raw survey data is meaningless without the parameters it was collected under, and those parameters do not live inside every file. Put them on the cover sheet that travels with the packet so nobody in the office has to guess or call the field to ask.

• Datum and coordinate system. The horizontal datum and realization (for example NAD83 2011), the projection and zone, and any localization or site calibration applied in the field.
• Vertical datum and geoid. The vertical reference (such as NAVD88) and the geoid model used, so elevations are not off by the height of a hybrid model nobody recorded.
• Receiver and antenna. The receiver model, the antenna type for its phase-center model, and the measured antenna or rod height with the method used to measure it.
• Base and occupation detail. Base coordinates and how they were derived, occupation start and end times, and epoch interval for static or PPK work.
• File manifest. A plain list of what is in the packet and what each file is, so raw, processed, and reference files are never confused for one another.

None of this is new work; it is information the crew already knows at the point. Writing it down once, attached to the packet, is what lets the office process the job the first time instead of sending it back. The full set of checks worth running before a survey delivery leaves the truck is laid out in the survey data delivery checklist, which you can adapt for your own gear and datums.

Keep a write-once original nobody can overwrite

Raw observations are the evidence layer of a survey. A boundary can be contested years after the fieldwork, and when it is, the answer comes from the original occupations, not from a coordinate someone typed later. That is why the delivered raw files should be copied to a write-once archive the moment they are verified: a stored copy that retention rules never touch and no later edit can overwrite, still checkable against its original checksum. Processing happens against working copies; the archived original stays exactly as it came off the collector.

How to move raw survey files

Put it together and the routine is short. It works the same for a static GNSS network, a day of topo, or a scan project, and it never asks the crew to remember to be careful.

1. Export the true raw files.Pull the observation sessions, the raw total station job, and the scanner's native project, then add the processed products on top. Confirm you exported the record, not just a report.
2. Compose one packet. All the raw and processed files, a cover sheet, and the job number, gathered as a single delivery rather than sent in pieces.
3. Label the collection parameters. Datum and coordinate system, vertical datum and geoid, receiver and antenna height, base and occupation detail, and a file manifest.
4. Upload direct to storage, resumably. Stream straight to the bucket so the transfer uses the full connection, and let it pick up after a dropped signal instead of starting the LAZ over.
5. Wait for server-side verification and the receipt. The packet is not submitted until every checksum matches on the server. The numbered receipt is your proof the raw files arrived whole.
6. Let the office accept it, and keep the archived original. Ownership stays with the crew until an office tech accepts the packet by name; a write-once copy of the raw files is stored the same moment, untouched by anything that happens next.

The difference between a survey delivery that costs a return trip and one that does not is rarely transfer speed. It is whether the office received the real raw files, whole and verified, labeled well enough to process, with an original preserved in case the job is ever questioned. Move the big files with that in mind and the crew drives off knowing the work is not just sent, but delivered.