Organizing GNSS project folders for reliable processing and handover
A clear folder structure separates originals, processing inputs, review records and issued deliverables while keeping their relationships visible.
Organize around the measurement chain
A useful GNSS project structure follows how evidence becomes an accepted deliverable. Original observations, setup metadata, reference information, processing runs, quality review and issued files serve different purposes. Separate those roles clearly enough that a new analyst can understand the project without opening every file. The objective is traceability and reliable reuse, not a complicated hierarchy designed only to look orderly in a screenshot.
Begin with a small standard structure that fits the organization's actual workflow. Define what belongs in each location and who maintains it. A template becomes useful when staff can apply it consistently under field and office pressure. Too many ambiguous folders can encourage personal shortcuts, while one undifferentiated folder makes accidental overwrites and wrong input selection more likely as the project grows.
Continue learning Preparing GNSS data for PPK processing
Protect original field data
Store original receiver and controller files in a clearly identified area. Preserve their original names where practical, or maintain an explicit mapping if a naming convention requires changes. Link them to session and point identifiers in a manifest. Do not use the originals folder as a place for edited copies or trial exports, because that weakens its role as the authoritative record of what was collected.
Include setup records, antenna information, field notes and relevant photographs with clear relationships to the observations. A raw data file without its antenna height or mark identity can be difficult to process correctly. Keep metadata readable and avoid relying entirely on proprietary project files. The archive should retain enough context for future interpretation even if the original controller application is no longer readily available.
Continue learning Creating an audit trail for GNSS survey data
Separate reference and supporting inputs
Create a controlled location for reference station observations, navigation information, precise products, antenna calibrations and approved coordinate definitions used by the workflow. Record source, coverage and version identifiers. Distinguish inputs actually selected for the accepted solution from candidates downloaded during investigation. A large collection of plausible files is not a reproducible processing set unless their intended roles are documented.
For automatically retrieved inputs, retain a manifest or permitted copies. Document the processor's behavior so a later rerun does not silently select different products. Keep local transformations, geoid identifiers and project templates associated with the relevant coordinate framework. These are measurement inputs, not miscellaneous attachments, because changes to them can alter many delivered coordinates while leaving the original satellite observations unchanged.
Continue learning Designing a backup and recovery strategy for GNSS projects
Give processing runs stable identities
Use a run identifier for significant processing attempts and preserve the settings, input manifest and report for each. State the purpose, such as initial solution, diagnostic comparison or accepted production run. This prevents a temporary investigation output from being mistaken for the approved result. The newest modified file is not necessarily the correct file to issue, particularly when analysts revisit an older accepted solution to answer a question.
Avoid duplicating entire projects without a clear relationship between copies. Where a copy is needed, label its role and parent version. Keep derived exchange files separate from originals and record conversion or decimation. A reviewer should be able to follow a coordinate back through the selected run and derived input to the original observation without comparing several nearly identical directories by hand.
Continue learning Using GeoPackage for a structured GNSS survey archive
Make quality review a first class record
Provide a location for check comparisons, exception records, review decisions and acceptance summaries. Link them to point, session and run identifiers. A quality table should identify which coordinate version it evaluates. Otherwise a later processing change can leave an apparently complete review attached to an obsolete result, giving a misleading impression that the final export was independently checked when only an earlier version was assessed.
Keep rejected observations and superseded reports with clear status rather than deleting them to make the folder look clean. Their history can explain why a later solution was adopted. At the same time, prevent rejected files from being selected accidentally for production. Clear role labels and manifests are more reliable than relying on staff to remember that one particular spreadsheet contains values that should never be used.
Continue learning Preparing GNSS data for PPK processing
Control names and coordinate descriptions
Use a naming convention that includes stable project, session or version information without becoming unreadably long. Avoid ambiguous suffixes such as final2 or newest. Include coordinate framework metadata in a manifest and, where useful, in export names. A file named points.csv should not be the only clue to whether it contains geographic coordinates, projected coordinates, ellipsoidal heights or a local construction grid.
Keep units and axis order explicit in tabular exports. Use consistent date and time conventions and document them. If a file format cannot carry the full coordinate definition, include a readable companion record. Naming is helpful, but it does not replace metadata. The structure should remain understandable after the package is copied outside the original workstation and loses its surrounding project context.
Continue learning Creating an audit trail for GNSS survey data
Separate working files from issued deliverables
Maintain an issued area containing only approved packages and their manifests. Record issue identifiers, dates and supersession relationships through the organization's normal process. Working outputs can remain elsewhere with their review status. This reduces the chance that an analyst sends a diagnostic coordinate list simply because it was the easiest file to find or appeared beside the accepted report.
Check the issued package as a recipient would. Confirm that referenced files exist, coordinate definitions are included and unnecessary secrets or personal information are excluded. Open representative GIS, CAD and tabular files in suitable software where relevant. A tidy source folder does not guarantee that the copied handover package contains every dependency needed to interpret the final coordinates.
Continue learning Designing a backup and recovery strategy for GNSS projects
Plan collaboration and backup
Use organizational storage and a clear editing process when several analysts work on the project. Define how concurrent changes are handled and how approved versions are identified. A shared folder can still contain conflicting copies if staff use personal naming conventions or overwrite common reports. The structure should support the actual collaboration method rather than assume that only one person touches the dataset.
Back up the project according to its value and retention requirements, then test recovery. Include metadata and configuration, not only the largest raw files. A restored observation archive without the accepted transformation or review record may not reproduce the deliverable. Keep credentials in appropriate private storage and avoid copying them into general project packages merely to make a workflow convenient.
Continue learning Using GeoPackage for a structured GNSS survey archive
Test the structure with a traceability exercise
Ask another qualified person to select one issued point and locate its original observation, setup information, processing run and acceptance evidence. Record where the search becomes ambiguous. This practical exercise reveals whether the folder design supports real review better than a visual inspection of directory names. Use the findings to simplify unclear roles and improve manifests before the project is archived.
Good folder organization makes the measurement chain visible. It protects originals, preserves controlled processing and separates accepted outputs from working alternatives. The result is less time spent guessing which file is authoritative and more confidence that a future analyst can reproduce, investigate or reuse the GNSS data after the original team has moved on.
Continue learning Preparing GNSS data for PPK processing
Practical checklist
- Organize around the measurement chain.
- Plan collaboration and backup.
- Test the structure with a traceability exercise.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
