Geotechnical information often moves between field teams, laboratories, consultants, clients, and software platforms. When each handover uses a different spreadsheet layout or a report that must be re-entered, teams spend time reconstructing structure and checking meaning. Structured geotechnical data exchange gives that handover an agreed framework.<\/p>\n\n\n\n
AGS and DIGGS are two important approaches to exchanging geotechnical information. They can support more consistent transfers, but a standards-based file is only one part of a dependable workflow. Teams still need to agree the required content, supported versions, mapping rules, and acceptance checks.<\/p>\n\n\n\n
The AGS format provides a standardized way to transfer geotechnical and geoenvironmental site-investigation data. Its defined structure helps senders and recipients organize related information consistently instead of designing a new layout for every handover. The British Geological Survey\u2019s AGS guidance<\/a> explains its role and provides practical advice on preparing and checking submissions.<\/p>\n\n\n\n For a project team, the main planning question is whether the sender and receiver agree on the version, required groups and fields, units, codes, and any permitted extensions. A request for an \u201cAGS file\u201d should be accompanied by enough detail to establish what a usable deliverable contains. Requirements imposed by a particular client or repository may go beyond the format itself.<\/p>\n\n\n\n DIGGS stands for Data Interchange for Geotechnical and Geoenvironmental Specialists. It uses a GML\/XML-based geospatial schema for exchanging information within and between organizations. The Geo-Institute\u2019s DIGGS resources<\/a> provide access to documentation and related tools.<\/p>\n\n\n\n As with any structured exchange, practical compatibility depends on the agreed schema version and the information represented by each application. A system\u2019s support for DIGGS should be evaluated against the actual project data and workflows, including the properties and relationships the receiving team needs to retain.<\/p>\n\n\n\n A source database and an exchange format do not necessarily divide information in the same way. One system may store a description as a single text field; another may separate material, classification, and remarks. One may allow a local code list that the receiver does not recognize. The exchange process needs an explicit treatment for these differences.<\/p>\n\n\n\n Before exporting, define a mapping specification covering identifiers, field meanings, units, reference systems, code translations, and relationships. Keep a record of information that cannot be represented directly. Decide whether it will travel as a supported extension, a linked document, a separate agreed deliverable, or an unresolved exception. Avoid silently dropping it.<\/p>\n\n\n\n Validation can identify problems such as malformed structure, missing required information, invalid types, or broken relationships, depending on the format and tool. Passing those checks does not establish that a coordinate reference is correct, a depth was measured accurately, or a test result was assigned to the right sample.<\/p>\n\n\n\n Engineering review should examine whether the content is plausible, complete for the intended use, and consistent with source evidence. It should also distinguish a genuine error from a documented historical limitation. A complete-looking file can still contain incorrectly mapped meanings; an incomplete historical record can still be useful when its limitations are clear.<\/p>\n\n\n\n A practical pilot follows representative data from source through export, validation, import, and use. Include ordinary boreholes and difficult cases such as repeated identifiers, qualified results, custom descriptions, missing values, and nonstandard historical records. Agree expected outcomes before running the transfer.<\/p>\n\n\n\n Compare source and destination counts, then trace individual records and their relationships. Check representative numerical values, units, dates, codes, and attachments. Review an output log or report where relevant. If the workflow requires a return export, test that too and document any transformations or losses. A successful round trip is evidence for the tested scope, not a guarantee for every future dataset.<\/p>\n\n\n\n A short written exchange specification reduces ambiguity between organizations. It should identify who prepares the data, who checks it, and who resolves exceptions. It should also distinguish mandatory acceptance criteria from improvements that can be completed later.<\/p>\n\n\n\n Before choosing an exchange route, ask the recipient what they need to do with the information. Producing a borehole log, assembling laboratory results, and building a regional dataset can require different levels of detail. Define a small set of real tasks and use them to decide which records, relationships, and supporting documents must be included in the handover.<\/p>\n\n\n\n This conversation should include both the person producing the file and the person importing it. An exporter may regard a field as optional because their own reports do not use it, while the receiver may need it to distinguish investigations or interpret a result. Agreeing the purpose first reduces the chance of discovering those differences after delivery.<\/p>\n\n\n\n Consider a hypothetical handover containing a borehole, two samples, and several laboratory results. One result has a qualifier, one sample has a revised identifier, and a supporting PDF refers to the original sample name. A useful test file preserves the borehole-to-sample relationships, the revised and original references, the result qualifier, and the link to the supporting document.<\/p>\n\n\n\n The sender and receiver should walk through that example together. Confirm where each item appears after import and how a user would retrieve it. If the receiver can load the numerical result but cannot identify the sample revision or interpret the qualifier, the file transfer has not yet met the operational requirement. Resolve the gap before expanding the test to a larger batch.<\/p>\n\n\n\n Keep the example and its expected results as a regression check for later changes. If an application upgrade or mapping revision alters the handling of those records, the team can repeat the same handover and compare the outcome. This is a practical way to test the particular workflow without claiming that a small example proves universal compatibility.<\/p>\n\n\n\n Many organizations have fields created for a particular client, contract, or historical workflow. Inventory those fields before selecting an exchange route. For each one, decide whether it has an appropriate standard representation, needs an agreed extension, belongs in a supporting document, or can be omitted with approval. Record the decision and the information that would be lost by omission.<\/p>\n\n\n\n Avoid placing unrelated information into a conveniently available standard field merely to make the file pass a check. A field that accepts text is not automatically an appropriate home for every unmapped value. The recipient needs to understand the information without reverse-engineering the sender\u2019s conventions. If an extension is used, provide its definition and confirm that the receiving process handles it as intended.<\/p>\n\n\n\n Give each delivery an identifiable revision and retain the exact file that was sent. Include a short manifest stating the source, extraction date, agreed format version, project scope, validation results, and known exceptions. Identify whether the delivery replaces a previous batch or supplements it. This prevents a recipient from accidentally combining overlapping exports or treating an incomplete update as a complete project.<\/p>\n\n\n\n For corrections, define how the receiving team will recognize changed, new, and withdrawn records. The agreed process might use a complete replacement or a controlled update mechanism, depending on the supported workflow. Whatever the method, test it with a small correction before relying on it for production data. Duplicate records introduced by an unclear update process can be difficult to diagnose later.<\/p>\n\n\n\n When discussing AGS or DIGGS support with a software provider, describe the actual exchange you need. Ask which versions and data groups or object types are supported, how units and code lists are handled, what happens to unrecognized fields, and whether import messages identify rejected or altered records. Request a demonstration using representative data rather than relying only on a general compatibility statement.<\/p>\n\n\n\n Also ask how the application exposes imported relationships and source references to users. Successful import is more useful when reviewers can inspect the information needed for acceptance. If a workflow includes export to another organization, check that the required context survives that next step as well. Compatibility should be evaluated across the complete chain of use.<\/p>\n\n\n\n Retain validation reports alongside a concise engineering review record. Identify the checks performed, the sampled records, the differences found, and how each material difference was resolved. The evidence should allow another reviewer to understand the conclusion without repeating the entire investigation. For recurring exchanges, use the same reporting structure so trends and repeated problems are easier to recognize.<\/p>\n\n\n\n When a file fails a check, send the producer a specific example with the relevant record reference and expected treatment. Vague feedback such as \u201cthe import failed\u201d makes correction slower. A clear feedback loop between producer and recipient turns standards-based exchange into a repeatable working process rather than an isolated export task.<\/p>\n\n\n\n AGS or DIGGS may form part of a migration route where the source and destination support the required exchange. Confirm the supported versions, coverage, and import\/export behavior for the particular product release. Do not assume that support for a format automatically includes every field or custom structure in an existing archive.<\/p>\n\n\n\n For WinLoG and GaeaSynergy projects, discuss the intended data and outputs with GAEA and validate the agreed route using a representative pilot. The planned GAEA Migration Center concerns future migration-related resources and workflows; unreleased capabilities remain upcoming and should not be treated as available features.<\/p>\n\n\n\n Visit GAEA\u2019s data migration information<\/a> or contact GAEA<\/a> to discuss current options. Structured exchange is most useful when it is paired with clear requirements, traceable mapping, and a receiving team that can verify the result.<\/p>\n","protected":false},"excerpt":{"rendered":" Geotechnical information often moves between field teams, laboratories, consultants, clients, and software platforms. When each handover uses a different spreadsheet layout or a report that must be re-entered, teams spend time reconstructing structure and checking meaning. Structured geotechnical data exchange gives that handover an agreed framework. AGS and DIGGS are two important approaches to exchanging […]<\/p>\n","protected":false},"author":1,"featured_media":93018,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2038],"tags":[358,41,361],"class_list":["post-93017","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-migration","tag-ags","tag-data-exchange","tag-diggs"],"yoast_head":"\nWhat DIGGS provides<\/h2>\n\n\n\n
A standard does not eliminate mapping decisions<\/h2>\n\n\n\n
Separate structural validity from engineering quality<\/h2>\n\n\n\n
\n
Test the full handover, not just the export<\/h2>\n\n\n\n
Agree an exchange contract for the project<\/h2>\n\n\n\n
\n
Start with the receiving workflow<\/h2>\n\n\n\n
Use a small exchange example to agree meaning<\/h2>\n\n\n\n
Manage local fields and extensions explicitly<\/h2>\n\n\n\n
Treat exchange files as controlled deliverables<\/h2>\n\n\n\n
Ask precise questions about software support<\/h2>\n\n\n\n
Choose acceptance evidence that can be reviewed<\/h2>\n\n\n\n
Apply the same discipline to software migration<\/h2>\n\n\n\n