How Survey Crews Should Deliver Field Data to the Office

The gap between a good day in the field and a clean day in the office is the handoff. A crew can run flawless observations, hold tight to spec, and close every loop, and still hand the office a folder it cannot process, because one raw file stayed on the data collector or a job number never made it onto anything. The office calls the crew, the crew is on the next site, and a two-hour job in the field turns into a two-day delay in processing. Worse, a control point that was never exported is a point somebody has to drive back out and re-occupy.

Delivering survey data well is a routine, not a talent. It is the last twenty minutes on site done the same way every time, so the office gets a complete, labeled, verified packet and never has to guess. This post lays out that routine: what belongs with your raw observations, how to label it so it processes without a callback, and how to confirm the office actually has all of it before you pull off the site. It fits inside the broader picture of getting survey work from the field to the office, which is the workflow this routine plugs into.

What a complete observation packet contains

The office cannot process what it cannot see, and it cannot ask for what it does not know is missing. The most common processing delay is not a corrupt file, it is a file that never left the truck. A complete packet is everything the office needs to reduce the day's work without a single follow-up call, gathered before you leave. For a typical survey day that means:

• Raw GNSS files from every receiver. Not just the rover. Base files, every occupation, and each receiver that logged, so nothing that contributed to a vector is missing when the office post-processes.
• Static occupation files, with heights. Each static session as its own logged file, and the antenna height and measurement method recorded for every one. A vector with no height is a vector the office cannot use.
• The data collector job file. The full job, not a stripped export. The office wants the codes, the stakeout records, and the field-computed points, not only a coordinate list typed back in by hand.
• Total station raw data. The raw angle and distance records from any conventional work, so the office can re-reduce rather than trust a field coordinate.
• The control sheet. Which points are control, what was held, what was checked into, and the datum or adjustment the crew worked on.
• Field notes and photos.The sketch, the monument descriptions, the “found 5/8 rebar, no cap” details that turn a number into a decision the office can defend later.

The exact list varies by firm and by job. The discipline does not: write your own list once, and run it every day so the packet is complete by habit rather than by memory. The survey data delivery checklist is a ready-made starting point you can edit to match how your crews actually work.

Label it so it processes without a callback

A complete packet the office cannot identify is barely better than an incomplete one. Raw GNSS files often carry cryptic receiver-assigned names, static sessions blur together, and a folder of .dat and .T02 files means nothing without context. Labeling is what lets the office open the packet cold and start working, weeks later, without reconstructing the day from memory.

Put the identity of the work on the packet itself, not in a separate email that gets detached from the files. At minimum, every delivery should carry the job number and name, the date and crew, the datum or coordinate system worked in, and a short note on what the office needs to do next: reduce and adjust, stake back out, or just archive. Point IDs and control designations should be unambiguous, so a point the crew calledCP1 is the same CP1 the office expects. This is exactly the job a cover sheet does: it rides with the files and answers the questions the office would otherwise call to ask.

Export everything off the data collector

The single most expensive habit in survey delivery is leaving data on the device. A job that lives only on the data collector is one dropped controller, one failed card, or one overwritten job away from gone, and until it is exported and delivered, the office has nothing. “It's on the collector” is not delivered. It is a copy in one place, on the most fragile hardware on the truck.

Before you leave, export the full job and every raw file off the collector and into the packet. Not a coordinate report, the raw files: the ones the office needs to post-process and re-reduce. Confirm the export actually wrote by checking the file count and that the sizes are non-zero, not merely that the export dialog closed. The goal is simple and absolute: when you drive away, nothing that matters exists only on the device in your hand.

Verify the big files uploaded completely

Survey files are large and unforgiving. A point cloud runs to gigabytes, a full day of raw GNSS across several receivers is not small, and site connections are exactly where a big upload stalls. The trap is that a truncated file often still opens. A point cloud missing its last scans, or a raw file cut off mid-session, looks like a file and fails only when the office tries to process it, long after the crew has gone.

So do not trust that “uploaded” means “complete.” The reliable check is a checksum: a fingerprint computed for each file before it leaves the device and recomputed on the server after the bytes land. If the two match, every byte arrived; if they do not, the file re-sends. Uploads that go direct to storage and resume from the last confirmed part after a dropped signal are what make this practical on one bar of service. The mechanics of moving these specific files intact are covered in the companion piece on transferring GNSS, point cloud, and raw files, which goes deeper on packaging and verification.

Confirm the office has it before you leave

The last step is the one crews skip, and it is the one that saves the return trip. “I sent it” is a statement about the outbox, not the office. Before the site is behind you, you want positive confirmation that a complete, verified packet actually landed, while you are still close enough to fix it if it did not.

That confirmation should be a receipt, not a hope. When the packet is submitted to a single intake queue and its files verify server-side, the crew gets a numbered receipt with the file count and the total verified size. That is a concrete answer to “did you get all of it,” produced automatically, before anyone at the office has to open a folder and count. Because responsibility stays with the crew until an office tech deliberately accepts the packet, nothing goes quietly missing in the gap between sent and received. That deliberate handoff, and why it protects both sides, is the subject of chain of custody for survey data.

The before-you-leave routine

Put it together and the routine is short enough to run every day without slowing the crew down. It works whether the day was pure GNSS, conventional, or a mix.

1. Close out the field work. End the last occupation, confirm your control checks, and finish the field notes and sketch while the site is in front of you.
2. Export the full job and every raw file off the collector. Raw GNSS from every receiver, static sessions with heights, total station raw, the data collector job. Confirm the files wrote, with real sizes, before moving on.
3. Assemble one packet. All the files together, plus the control sheet and field notes, treated as a single delivery rather than a scatter of separate sends.
4. Label it. Job number and name, date and crew, datum, and what the office should do next, on a cover sheet that travels with the files.
5. Upload and let it verify.Send to one intake queue, let big files resume through any signal drops, and wait for each file's checksum to match on the server.
6. Get the receipt before you drive off. Confirm the numbered receipt, with the file count and verified size, so you know a complete packet landed while you can still act if it did not.

Notice what this routine never asks: no reconstructing the day from a coordinate list, no callback because a base file stayed on the collector, and no return trip to re-occupy a point that was already observed but never delivered. The completeness, the labeling, and the proof are built into the last twenty minutes on site, so the office starts processing the moment the packet arrives instead of starting a phone call. When the crew pulls off the site, the office already has everything, knows exactly what it is, and has a receipt to prove it.