Scott L Deaton, Ph.D., President, Dataforensics 

 

The 2025 DIGGS Code Jam brought together vendors and developers across the geotechnical data management space to put the DIGGS (Data Interchange for Geotechnical and Geoenvironmental Specialists) schema to the test — and the results were both encouraging and eye-opening. The DIGGS Code Jam was the first time multiple vendors attempted to import the most comprehensive DIGGS file produced to date. The file included over 8,000 pieces of data from multiple boreholes with well construction details and laboratory test data.  The challenge specified that vendors should import the example file provided by the DIGGS committee and then produce a variety of outputs based on the data.  Potential reports could include borehole logs, particle size distribution reports, Atterberg Limits report, tabular summary of lab data, and sitemaps.   

A Strong Showing Across the Industry 

Participants included Dataforensics/OpenGround, RSLog, EQuIS Geotech, NGI, Geotec, and Tablogs. All vendors successfully imported DIGGS files and generated mostly accurate reports. However, only one vendor out of seven was able to complete a full round-trip of the dataset — highlighting critical areas where the industry and standard still need work. 

Lessons from the Trenches 

The Code Jam was not just about success; it was a deep dive into the friction points of real-world DIGGS implementation. Several recurring issues emerged: 

Schema & Validation Issues 

• Many files didn’t validate properly against tools from Geosetta or Oxygen XML Editor. 

• There was inconsistent or incorrect use of code lists, which are essential for standardizing roles like drillers, loggers, and clients as well as test results. 

• Misuse of structural elements like <posList> and <testResults>, or failing to correctly associate objects via href links, led to broken data relationships. 

Coordinate System Confusion 

One of the most common pain points was coordinate systems: 

• The DIGGS committee had not updated documentation, leading to broken examples — especially for well sampling features. Some vendors used URNs, which are currently not resolvable and therefore invalid for DIGGS. 

• New compound 3D coordinate systems (e.g., OpenGIS Compound CRS) are gaining relevance but were not consistently applied. 

As a result, a new blog post from the DIGGS committee will be produced on how to handle these compound systems correctly. 

Units Must Be Explicit 

Every element that involves physical units — whether depth (ft), unit weight (pcf), latitude/longitude (degrees), or load (lb) — must have the unit specified. Omitting units resulted in misinterpretation and validation errors. 

Lithology System Misunderstandings 

DIGGS expects a single <lithologySystem> to represent a full interpreted column (e.g., all geologic or engineering layers). Multiple systems imply distinct interpretations (e.g., engineering vs. geologic vs. hydrogeologic). 

Symbology Not Solved 

DIGGS currently lacks a consistent way to handle symbology, making it difficult to transmit: 

• Lithology graphics 

• Water level symbols 

• Well construction details (above and below ground) 

• Sampler types 

This is a known limitation and ripe for improvement in future development. 

Code Lists: Ambiguity Still Exists 

There were specific issues around code lists — especially regarding whether vendors should transmit gml:id values or readable names for elements tied to code lists. This caused lookup complications and inconsistent usage. 

Moving Forward: Recommendations & Calls to Action 

Many lessons were learned by vendors and the DIGGS committee that help advance the standard and data interchange across the industry. Specifically,  

• DIGGS Committee: Needs to update documentation, clarify coordinate system usage, and provide better examples. 

• Vendors: Should improve validation discipline and adhere strictly to schema, documentation and code lists usage. 

• Community: Should consider contributing feedback, especially in areas like lithology interpretation and symbology transmission. 

Final Thoughts 

The DIGGS Code Jam 2025 was a clear step forward for the geotechnical data community — not because everything went smoothly, but because it highlighted the gaps that still need to be addressed. 

We commend all participating vendors for their transparency, engagement, and willingness to iterate. With continued collaboration, the DIGGS standard will become stronger, more interoperable, and more practical for the everyday needs of geotechnical professionals. 

Check out the blog posts from the DIGGS Committee on coordinate systems and code lists — and we’ll see you at the next Code Jam in August 2025!