It’s been several months since the release of DIGGS v1.1 this past April. At the roll-out meeting we had anticipated having a version 1.2 ready by July. However, the changes in version 1.2 have required far more analysis and work than originally anticipated.

Recall that DIGGS v1.1 primarily addressed domain-independent issues (i.e. XML and GML schema issues) and was not intended to be used in practice. DIGGS v1.2 would address domain-specific issues and overarching schema structural issues. A review period for v1.2 by a broad group of stakeholders would then lead to the release of DIGGS v2.0, the first public version for implementation.

A small DIGGS team (Loren Turner, Dan Ponti, and Chris Bray) has been holding weekly workshops online with the contractor from Galdos (David Burggraf) over the past several months. In addition, there were three online workshops conducted in June and July with the four primary software vendors (gINT, Keynetix, Dataforensics, and Earthsoft) to build consensus on schema design decisions, and assure that DIGGS is moving in the right direction for integration into commercial software. More recently, work has begun to evaluate the existing codelists in DIGGS in the context of lab testing. Much more work will be needed in this area for v1.2 and I will be reaching out to the DIGGS community shortly for some assistance.

We’ve been working on several key features to be implemented in the DIGGS v1.2 release, including:

• A consistent approach to encoding all tabular data (e.g. CPT, geophysical) in a DIGGS file, built from the GML 3.2 “coverage” schema. The current WITSML structure, although similar, will no longer be used in DIGGS.
• A revised approach for encoding the process of sampling separate from the sample information itself.
• A method for encoding trial pits, trench walls, and other surfaces.
• A revised structure of the lab testing schemas to clearly differentiate test procedures from the test results.
• A method for encoding compound coordinate reference systems (eg. NAD83 and NAVD88, or WGS84 and Mean Sea Level) so that GML-aware applications can process the spatial data.
• Further reducing the number of schema files required for DIGGS by eliminating most the WITSML schemas and only keeping those needed to handle units-of-measure standards.
• A cleaned up set of codelists throughout the schema.

In addition, work will begin shortly on developing two initial tools that should help the DIGGS community evaluate example DIGGS files when 1.2 is rolled out. This includes an Excel-based worksheet that will allow users to open and read a DIGGS v1.2 file without the need to understand XML syntax. The other tool will allow a user to transform a DIGGS file into a Google Earth KML file for spatial visualization of DIGGS elements (as shown in the screenshot), showing borehole path, sample locations, and layers. The feasibility of both tools has been explored by Galdos, and it looks promising. I believe these tools will help the team review DIGGS v1.2 during the next phase of the project. A couple of other tools will need to be developed as well, including a web-based, form-driven, type of tool to allow users to create DIGGS files from scratch. Also, the COSMOS team developed a visualization tool that displays DIGGS data in a more traditional boring log format (as shown in the screenshot). This tool will be modified when DIGGS v1.2 is released. Again, all of these tools are intended to help the user quickly see the types of data in a DIGGS file. We’re really counting on the commercial software vendors to implement the advanced tools to more effectively utilize DIGGS data in routine practice.

In summary, it’s taking quite a bit of time to work out a lot these details in DIGGS. But we’re making significant progress and appreciate the continued support of the DIGGS community.