Defining soil layers with interpreted engineering properties

[nickmachairas]

Dan,

Consider the following:

I am working on the deep foundation schema and for pile (and other) capacity calculations it is important to have information on the soil profile as shown above. I looked into the DIGGS schema but other than backfill I did not see any object that could accommodate layers, perhaps I missed it.

Scott used a good work for this, "interpreted". We might have schema elements that handle linear measurements for SPT, CPT, WC, etc but interpretation of these values in order to delineate and define individual layers and by extension stratigraphy would be really really great.

I am up for creating the new elements but wanted to check with you first.

Thanks!

-Nick

[dponti]

Hi Nick - Sorry for the delay in response. The encoding of qualitative or interpreted properties that would be related to a layer of soil or rock in the subsurface (an interval or zone, depending on the type of sampling feature from which the observation is made) is handled under the <observation> property, which is one of the top-level properties that reside within the Diggs object in an xml instance. The observation property can hold a number of types of Observation Systems. Currently defined systems are ColorSystem, ConstituentSystem, DiscontinuitySystem, LithologySystem, OrientationSystem, OtherObservationSystem, and StratigraphySystem.

For the example you show, you would use the LithologySystem object to encode the soil description layers (column TYPE) and the OtherObservationSystem to encode the engineering properties that you are assigning to each of the layers. Presumably, there would be samples with test data that produce the values that you would then be using for those assignments - those results would be encoded under the top level <measurement> property as they are directly derived. The OtherObservationSystem object was created as a "catch-all" to allow for encoding of any kind of property that one would assign to a layer of earth material that doesn't fall within the defined types above. Within each of the system objects are Observation objects, where the actual observations (or interpretations in the case of the OtherObservationSystem) are recorded, along with the depth interval (or more generically, the location) of the assigned layer. The OtherObservations record the actual properties (eg., WC, LL, etc.) as name-value pairs within a Parameter object. The name of the parameter (eg. LL) is of type gml:CodeType, meaning that you can provide an attribute with a pointer to a dictionary or to the name of an authority where that parameter name is defined. For these types of data, it might be best to point to the DIGGS test property dictionary that is used to control the names of parameters reported from tests. This would be best practice, but not required, if a standard or common name is used for the parameter name (eg. Liquid Limit instead of LL), it would be ok to leave out the codespace, but not preferred.

I've attached an example xml instance to show you how you would encode the first two layers of the example you've provided. A few notes about the file:

1. The lithology and other observation systems have properties that reference these objects to the project (required) and the sampling feature (eg. borehole) that is associated with these data, by using the xlink:href attribute to point to the ids of the specific project and borehole. In the example, the project referenced has an id of p1 and the borehole an id of bh1. The referencing syntax I used implies that those objects are in the same xml instance as the observations, but that, of course, is not the case in this example.

2. The observation objects must contain a location property that refers to the absolute position of the defined layer within the borehole as defined within the borehole's linear reference system. The borehole's linear referencing system is defined in the borehole object(which is missing from the example). In the example, the id of the borehole's linear reference system is lsr1 and it's referenced in the gml:posList property. The value of gml:posList records the top and base of the layer. Since you only recorded the thickness of the layer (height) I assumed that layer 1 goes from 0 - 8 ft depth downhole and layer 2 from 8 - 25.5 ft downhole. Layer thickness is not explicitly recorded in DIGGS but can be derived from the top and base locations of the layer.

3. For the soil lithology/description, I assumed that the terms are those as defined by ASTM 2487D (Unified Soil Classification)

4. Unit of measurement symbology for the property parameters) in DIGGS derive principally from the Energistics Unit of Measure Dictionary, although we do include some geotech specific units of measure in the DIGGS schema that are not included in the Energistics dictionary. Energistics has taken over from POSC, I believe, in managing the WITSML schemas and associated units dictionaries. We've updated to WITSML 2.0 and their updated dictionaries, including Energistics' unit extension type syntax in the current development v 2.6 of DIGGS. The example is written against this version (DIGGS v. 2.6).

In your example, pcf (pounds-force per cubic ft) does not follow Energistics' symbology - the appropriate symbol is lbf/ft3. Unit type ksf (kips/square ft) does not exist explicitly in the Energistics dictionary, but they do define a unit of pounds-force per square ft that is derived from their base unit (Pascal). In the example, I used this unit of measure (lbf/ft2) and multiplied your reported values by 1000. Also, bl/ft (blows per foot) that are used for your N and N1 values is not a currently defined unit type. In order to ensure a valid XML document, the example utilizes Energistics' extension syntax to allow for extending their units dictionary. The units of measure extension syntax consists of [authority]:[symbol] where [authority] and [symbol] can be any characters whereas the colon is mandatory. Because I'm not sure what "authority" would sanction blows/ft as a unit of measure, I used "Other:blows/ft" in the example, which implies a unit of measure not formally defined, and validates under DIGGS v. 2.6. This value could, I suppose, also be left unitless since that is how it is often reported. We could, if we think it's useful, add blows/ft to DIGGS' geotech specific units of measure symbology in the current development version of DIGGS.

I hope this explanation helps. Please post any follow up questions and I'll try to be more timely in my response :-).
OtherObservationExample.xml.zip