DIGGS is pleased to report the successful completion its first US Environmental SIG meeting in New Orleans on the 13th March 2008. The aim of the day was to introduce the structure and principles of the DIGGS group and how the DIGGS format will meet the needs of the environmental community.

Presentations were made by Kim Stagg and Roger Chandler. These presentations can be downloaded here.

Over the last 12 months I have been testing the schemas by creating example files. I can now create them quite quickly using a program called Oxygen, but I know how daunting it can appear when you get started, especially if you start by looking at the schema files!

The introduction of the Monitoring groups in the AGS data interchange format was a big step forward. Instead of creation of different data groups for different time-related monitoring instruments (piezometers, slope inclinometers, settlement gages, etc.), one set of data groups was created to accommodate all such data. This made the format expandable with just the addition of new instrument types in the pick list. This avoided creation of new groups and issuance of updated formats.

The DIGGS format currently has taken an approach opposite of the Monitoring groups in the AGS.

In the AGS data interchange format, and in many other formats, particular fields, termed “key” fields, are used as unique identifiers for each record. These keys are fields with meaning to the data, e.g., hole identifier, depth, date/time, etc. Currently in the DIGGS format, an arbitrary but unique identifier is currently required for every record in a transmission. These identifiers are to be unique within a file and replace key fields.

After version 0.9.2 DIGGSML was split into several parts to aid its development and there have been some problems with using the schemas in various different parsers, many stemming from the xsi:schemaLocation attribute and it's varied implementation.

This article explains reasons behind the move from relative paths to canonical URI's and how to use the included catalog file to tell your parser where to find your local copy of the schemas.

Development Environment

Most of our XML development to date ( KML for Google Earth, LandXML ) has been done with Microsoft Visual Studio 2005. We have recently implemented some very powerful commercial tools such as XMLSpy.

Our development environment at gINT Software is primarily Microsoft Windows, from Windows XP on the developer desktops to Windows Server 2003 R2 and Windows Vista Enterprise on the servers.

After Monitoring and the SamplingPoint object - Part 3 we had reviewed various methods of encoding blocks of tabular data in XML and identified a number of previous implementations of this construct (WITSML, SensorML).

This article details how DIGGSML builds on the implementations in WITSML and SensorML and implements a generic Table structure for storing lots of repeating Monitoring data.

DIGGSML is an international standard, and since many people all over the world speak different languages DIGGSML must respect this. Whilst the element names themselves are in "international English" their content can often be in one (or more) different languages.

This article will explain the best practices for internationalising a DIGGSML file, including how to implement a bi-lingual file.

After Monitoring and the SamplingPoint object - Part 2 we left the Monitoring section of DIGGSML in a workable state.

There is however a problem associated with this method, it's verbosity, adding a large amount of data will rapidly produce a prohibitively large file.

This article details how this problem arises and two possible solutions, using a space separated lists of values, and using a tabular system proposed by John Bobbitt of the Petrochemical Open Standards Consortium (POSC) as well as taking looking at the OGC's standard for this type of data, SensorML.

As of Friday 10th August 2007 DIGGSML v0.9 has been released for internal review.

See inside for a comprehensive list of changes and instructions on how to obtain this release.