Geotech concept that can use gwml2:FluidBody

gwml2:FluidBody is identified to realize the geotech concept called FluidBody.

4.6.4. FluidBodySurface according to GroundWaterML2

From GroundwaterML2:

A surface on a fluid body within a local or regional area, e.g., piezometric, potentiometric, water table, salt wedge, etc.

Geotech concept that can use gwml2:FluidBodySurface

gwml2:FluidBodySurface is identified to realize the geotech concept called FluidBodySurface.

Proposed adjustments for geotech

Existing attributes:

<table><thead><tr><td>Attribute</td><td>Type and Multiplicity</td><td>Definition</td></tr></thead><tbody><tr><td>gwSurfaceSh ape</td><td>Surface</td><td>Geometry / position of the surface.</td></tr><tr><td>gwSurfaceTy pe</td><td>SurfaceType</td><td>Type of fluid body surface, e.g., piezometric, potentiometric, water table, salt wedge, etc.</td></tr><tr><td>gwSurfaceMe tadata</td><td>ObservationM etadata</td><td>Date, time, method, etc., of the observation or calculation of the surface.</td></tr></tbody></table>

Existing relations:

<table><thead><tr><td>Relati on</td><td>Source</td><td>Target</td><td>Description</td></tr></thead><tbody><tr><td>Associ ation</td><td>Entity: GW_ Divide</td><td>Entity: GW_ FluidBodyS urface</td><td>Relates a fluid body surface to a line on e.g., a water table or piezometric surface, on either side of which the groundwater flow diverges.</td></tr><tr><td></td><td>Role: gwSur faceDivide</td><td>Role: gwDiv ideSurface</td><td></td></tr><tr><td>Associ ation</td><td>Entity: GW_ FluidBodyS urface</td><td>Entity: GW_ FluidBody</td><td>Relates a fluid body to a surface hosted by the body, e.g., the top of the water table.</td></tr><tr><td></td><td>Role: gwBo dySurface</td><td>Role: gwSur faceBody</td><td></td></tr></tbody></table>
### 4.6.5. HydroGeoVoid according to GroundWaterML2

From GroundwaterML2:

Voids represent the spaces inside (hosted by) a unit or its material. E.g., the pores in an aquifer, or in the sandstone of an aquifer. Voids can contain fluid bodies. Voids are differentiated from 'porosity' in that porosity is the proportion of void volume to total volume, while voids are the spaces themselves. Voids are required in GWML2, for example, to capture the volume of fractures in an aquifer.

#### Geotech concept that can use gwml2:HydroGeoVoid

gwml2:HydroGeoVoid is identified to realize the geotech concept called Void.

The name HydroGeoVoid makes it very hydrogeology oriented, yet the definition is generic enough for the geotech purpose.

For man made voids (e.g., tunnels, gallery) the concept of Facility from LandInfra may also be used.

Existing attributes:

<table><thead><tr><td>Attribute</td><td>Type and Multiplicity</td><td>Definition</td></tr></thead><tbody><tr><td>gwVoidDescription</td><td>char</td><td>General description of the void</td></tr><tr><td>gwVoidHostMaterial</td><td>EarthMaterial [0..*]</td><td>The material that hosts the void, if specified. Note voids can be hosted by a unit (an aquifer) or its material (e.g., sandstone).</td></tr><tr><td>gwVoidMetadata</td><td>GW_Metadata</td><td>Metadata for the void.</td></tr><tr><td>gwVoidShape</td><td>Geometry</td><td>Shape and position of the void.</td></tr><tr><td>gwVoidType</td><td>PorosityType</td><td>Type of void e.g., fractured, intergranular, etc.</td></tr><tr><td>gwVoidVolume</td><td>Measurement</td><td>Volume of the void.</td></tr></tbody></table>

## 4.7. EPOS WP15

### 4.7.1. Introduction to EPOS

EPOS, the European Plate Observing System, is a multidisciplinary, distributed research infrastructure that facilitates the integrated use of data, data products, and facilities from the solid
Earth science community in Europe.

For a better overview of EPOS, please have a look to this paper: https://www.nature.com/articles/s41597-023-02697-9

## EPOS TCS GIM

Within the EPOS initiative, the Thematic Core Service (TCS) Geological Information and Modeling develops and consolidates the information and data infrastructures produced by the international community, primarily the European Geological Surveys. Shared reference datasets on geological maps, boreholes (vertical shafts constructed for water, oil, or gas extraction), 3D geological models, and mineral resources are accessible to the community through the EPOS multidisciplinary platform provided from the European Geological Data Infrastructure.

## Existing concepts proposed for reuse and extension for geotechnics

* `eposl:ModelView`

## 4.7.2. ModelView according to the EPOS datamodel

The ModelView approach is a creation by EPOS Thematic Core Service on Geological Information and Modelling aiming at providing descriptive information on 3D/4D models. It builds on GeoSciML Lite philosophy which is best thought of as a view of GeoSciML and O&M data that denormalizes the data and concatenates complex property values into single, human-readable, labels and returns single, representative, values from controlled vocabularies for properties multi-valued properties that can be used when generating thematic maps, or portrayals, of the data. The rationale targeted for ModelView is to have a complete corresponding UML model describing 3D/4D Models based on Observations and Measurements and the ModelView being a simplified View to support discovery of 3D/4D Models. ModelView triggered to move the original GeoSciML Lite philosophy from SF-0 to SF-1 to allow some element to appear multiple time.

### Definition

From the EPOS dedicated schema:

> Simplified view of a Model. A model is defined as the result of geoscience data processing or interpretation. Proposing either a spatial distribution of geoscientific objects with properties of interest (feature) or attempt of retranscribing natural/man-made behavior through mathematical functions or algorithms (process).

### Geotech concept that can use eposl:ModelView?

`eposl:ModelView` is intended as a realization of the `Geomodel` concept and especially one of its specialization the `GeotechSynthesisModel`
## 4.8. LandInfra and InfraGML

### 4.8.1. LandInfra and InfraGML

From the OGC website:

The scope of the Land and Infrastructure (LandInfra) Conceptual Model is land and civil engineering infrastructure facilities. Anticipated subject areas include facilities, projects, alignment, road, railway, survey, land features, land division, and “wet” infrastructure (storm drainage, wastewater, and water distribution systems). The initial release of this standard is targeted to support all of these except wet infrastructure.

The OGC InfraGML Encoding Standard presents the implementation-dependent, GML encoding of concepts supporting land and civil engineering infrastructure facilities specified in the OGC Land and Infrastructure Conceptual Model Standard (LandInfra), OGC 15-111r1. Conceptual model subject areas include land features, facilities, projects, alignment, road, railway, survey (including equipment, observations, and survey results), land division, and condominiums. InfraGML is published as a multi-part standard.

* Part 0 addresses the Core Requirements Class from LandInfra.

* Part 1 addresses the LandFeature Requirements Class from LandInfra.

* Part 2 addresses the Facility and Project Requirements Classes from LandInfra.

* Part 3 addresses the Alignment Requirements Class from LandInfra.

* Part 4 addresses the Road and RoadCrossSection Requirements Classes from LandInfra.

* Part 5 addresses the Railway Requirements Class from LandInfra.

* Part 6 addresses the Survey, Equipment, Observations and Survey Results Requirements Classes from LandInfra.

* Part 7 addresses the Land Division and Condominium Requirements Classes from LandInfra.

**Existing concepts proposed for reuse and extension for geotechnics**

* InfraGML:Alignment
### 4.8.2. Reusing LandInfra Alignment

The Alignment concept was developed in common between OGC and bSI in the LandInfra Domain Working Group.

It is part of the OGC InfraGML 1.0: Part 0 – LandInfra Core – Encoding Standard

Also a Logical model called InfraGML was developped on top of this Conceptual Model. This work is known as OGC InfraGML 1.0: Part 3 - Alignments - Encoding Standard.

An Alignment is defined as a:

PositioningElement which provides a Linear Referencing System for locating PhysicalElements. An Alignment shall be continuous, non-branching, and non-overlapping. If it is a Project Alignment, it is for a single alternative, as specified by its owning ProjectPart.

**Geotech concept that can use LandInfra:Alignment**

LandInfra:Alignment is identified to realize the geotech concept called Alignment.

**Geotechnical properties**

No additional geotechnical properties identified.

### 4.8.3. Extending LandInfra Facility and FacilityPart

In InfraGML, a Facility is defined as:

Buildings and civil engineering works and their associated siteworks. Civil engineering works, or infrastructure facilities, are construction works comprising a structure, such as a dam, bridge, road, railway, runway, utilities, pipeline, or sewerage system, or are the result of operations such as dredging, earthwork, and geotechnical processes.

In InfraGML, a FacilityPart is defined as:

Land and Infrastructure facility, such as a road or bridge. A facility has a life cycle, including planning, design, construction, maintenance, operation, and removal phases The design and construction phases are typically performed as part of a project. There may be multiple such projects during the life cycle of the facility to enable phased construction and incremental improvement.
**Geotech concepts that can use InfraGML:Facility and FacilityPart?**

InfraGML:Facility is identified to realize the geotech concept called Surrounding Construction

InfraGML:FacilityPart is identified to realize the geotech concept called GeotechTypicalSection

**Additional properties and constraints**

See Surrounding Construction and GeotechTypicalSection for properties to be added.

# 4.9. INSPIRE Theme III: Natural Risk Zone

## 4.9.1. INSPIRE

The INSPIRE Directive aims to create a European Union Spatial Data Infrastructure (SDI) for the purposes of EU environmental policies and policies or activities which may have an impact on the environment. This European Spatial Data Infrastructure will enable the sharing of environmental spatial information among public sector organisations, facilitate public access to spatial information across Europe and assist in policy-making across boundaries.

INSPIRE is based on the infrastructures for spatial information established and operated by the Member States of the European Union. The Directive addresses 34 spatial data themes needed for environmental applications.

**INSPIRE Theme III: Natural Risk Zone**

The approach taken to model Natural Risk Zones is generic in its treatment of each of hazard, exposure, vulnerability and risk, but five use cases have been created to demonstrate the fit of the model with specific examples for different types of hazard: - Floods (calculation of flood impact, reporting and flood hazard/risk mapping) - Risk Management Scenario (an example from a national perspective) - Landslides (hazard mapping, vulnerability assessment and risk assessment) - Forest fires (danger, vulnerability and risk mapping) - Earthquake insurance

**Existing concepts proposed for reuse and extend for geotechnics**

* NZ:HazardArea

* NZ:RiskZone

## 4.9.2. Hazard Area according to INSPIRE:NZ

From the INSPIRE Data Specification on Natural Risk Zones - Technical Guidelines

Discrete spatial objects representing a natural hazard.

**Geotech concept that can use this concept**

HazardArea is identified to realize the geotech concept called HazardArea.
## Proposed adjustments for geotech

See HazardArea for properties to be added.

### 4.9.3. What is an RiskZone according to INSPIRE:NZ?

From the INSPIRE Data Specification on Natural Risk Zones - Technical Guidelines

Discrete spatial objects representing the spatial extent of a combination of the consequences of an event (hazard) and the associated probability/likelihood of its occurrence.

## Geotech concept that can use this concept

RiskZone is identified to realize the geotech concept called RiskZone.

## Proposed adjustments for geotech

It is recommended to rely on ISO 19156 for the provision of the “LevelOrIntensity” estimation with the RiskZone being the FeatureOfInterest.
# Chapter 5. Implementation guide, resources, and examples

## 5.1. About implementation

Implementation is the state where concepts and ideas take a more concrete shape.

In data modeling, this means tools and technical solutions are provided in order to realize the conceptual model. Therefore implementation then participate in the validation of the conceptual model and of course enable to truly provide data (here geotech) in an interoperable way.

One must distinguish the capacity of exposing:

* vocabularies, codelists, or

* observations, measurements, and features description.

The GeotechIE experimented with some OGC APIs to provide geotech data: [OGC APIs](https://www.ogcapi.ogc.org/)

## 5.2. OGC APIs

OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OGC API family of standards is organized by resource type.

See [https://ogcapi.ogc.org/](https://ogcapi.ogc.org/) for more details.

### 5.2.1. OGC APIs considered for geotechnics

The GeotechIE proposes reliance upon:

* OGC SensorThings API for the provision of Observations, Measurements and Sampling description; and

* OGC API Features for the provision of observed features like Borehole, TrialPit, MaterialSample, but also interpreted features like a GeologicUnit, Fault, HydrogeoUnit, etc.

#### OGC SensorThings API

The OGC SensorThings API provides an open, geospatial-enabled and unified way to interconnect the Internet of Things (IoT) devices, data, and applications over the Web. At a high level the OGC SensorThings API provides two main functionalities and each function is handled by a part. The two parts are the Sensing part and the Tasking part. The Sensing part provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems. The Tasking part is planned as a future work activity and will be defined in a separate document as the Part II of the SensorThings API.

See [https://ogcapi.ogc.org/sensorthings/](https://ogcapi.ogc.org/sensorthings/) for more details.
## OGC API - Features

OGC API - Features specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term 'feature' for things in the real world that are of interest.

See https://ogcapi.ogc.org/features/ for more details.

### 5.2.2. OGC APIs & INSPIRE

Both OGC SensorThingsAPI and OGC API - Features have been assessed as suitable to implement the INSPIRE Directive.

See:

* Extending INSPIRE to the Internet of Things through SensorThings API

* INSPIRE SensorThings API Good Practice

* additional materials are available at https://datacoveeu.github.io/API4INSPIRE

## 5.3. Introduction to FROST

The FRaunhofer Opensource SensorThings-Server (FROST) is an implementation of the OGC SensorThings API. It can be deployed as a Docker image, or directly on an existing Tomcat or similar server. Since version 2 it has a flexible data model implementation that allows the data model to be extended or even completely replaced with little effort. This makes FROST an ideal platform for data model experiments.

For the GeoTech IE, a plugin has been made for FROST that extends the STA core data model with extra entities. See FROST plugin for Geotech.

More details can be found at the FROST GitHub page or the FROST Documentation site.

## 5.4. FROST Plugin for geotech

### 5.4.1. A short intro to the OGC SensorThingsAPI data model

For those who are not (yet) familiar with the data model from the OGC SensorThings API, please visit: Introduction to SensorThingsAPI data model.

### 5.4.2. Extending STA for Geotech

Thanks to the DataStream concept, that is part of the core STA data model, STA is very suited for use cases where repeated observations and measurements are made. The support for time series is native and is the essence of STA. When it comes to address measurements along a trajectory, STA functions similarly to a time series, except the variable is space and not time.

In practice, measurements along a trajectory within a borehole are a kind of time series because the results are obtained one after the other as the hole is advanced. The difference is that the time parameter is not important whereas the location parameter is the important domain for the
measurement.

## Extended data model

To improve the support for boreholes, the core SensorThings data model has been extended. The conceptual background of this extension is explained in **STA Borehole Model**. This data model extension has been implemented as a FROST-Server plugin, together with a security extension that allows fine-grained access control to borehole data:

<figure><img src="image_24.png" /><figcaption>Figure 23. Core STA data model in blue, with the GeoTech data model extension in green and the security extension in yellow</figcaption></figure>

## Map geotech data to the STA data model

### Test (geotechnical in-situ)

Act (Sensor) carried out as part of a (Project)

Associated with a borehole (BhCollarThing) that follows a trajectory (BhTrajectoryThing)

### Observation / observation group

Obtained during a test (Sensor)

One or more parameter value(s) (ObservedProperty) measured at a given location (FeatureOfInterest)

These given locations are defined by sampling (BhSampling) along the trajectory (BhTrajectoryThing)
## Geotech data considered

This implementation is for delivering observations & measurements (aka Book A data. See: [Book-A-organization-and-components] for more details).

The study mainly focused on in-situ tests, including:

* Cone Penetration Test (CPT),

* Standard Penetration Test (SPT),

* Menard Pressuremeter Test.

It also addresses laboratory tests, including discussions about:

* Atterberg limits test.

## Download FROST GeoTech plugin

The FROST GeoTech plugin, with installation help, can be found at the [FROST GeoTech Plugin GitHub page](https://github.com/frost-geo-tech/FROST-GeoTech). The plugin can be used as a docker image. An [example DockerCompe file](https://github.com/frost-geo-tech/FROST-GeoTech/blob/master/ExampleDockerCompe.json) is provided with the plugin. To try it out without installing anything, a demo service is available at: [https://ogc.demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-GeoTech/v1.1/](https://ogc.demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-GeoTech/v1.1/) (use username/password read/read for read-only access)

## Entity creation order

Since some entities in the data model require other entities, like the Datastream requiring a Thing, there is a certain order in which these entities should be created. The general order is:

1. FeatureType (re-used often)

2. ObservedProperty (re-used often)

3. BhCollarThing + Location

4. BhTrajectoryThing + Location

5. BhSampler + BhSamplingProcedure (if present)

6. BhSampling

7. BhFeatureOfInterest

8. BhPreparationProcedure (if present)

9. BhPreparationStep (if present)

10. Sensor

11. Datastream

12. Observation

There are some things to take into account when populating the data model.

* The FeatureTypes and ObservedProperties are re-used often, and should only be created once per server.
* Things and FeaturesOfInterest are not directly created in the GeoTech data model extension. These entities are automatically populated from the BhCollarThing, BhTrajectoryThing and BhFeatureOfInterest.

* A Datastream is linked to either a BhCollarThing or a BhTrajectoryThing, but not to both.

* When creating an Observation, the id of the BhFeatureOfInterest should be given as FeatureOfInterest, otherwise FROST will try to generate a FeatureOfInterest, and fail. For example: `{ "phenomenonTime": "2017-12-31T23:00:00.000Z/2018-01-01T00:00:00.000Z", "result": 12.6, "Datastream": { "@iot.id": 42 }, "FeatureOfInterest": { "@iot.id": 99 } }`

A **demonstration Batch Request** is available that creates examples of all entity types, with their relations, in the correct order.

## Security Extension

The security extension that is part of the FROST GeoTech Plugin adds powerful project-management related access control features. The extension adds four extra EntityTypes to the data model:

* User

* Role

* Project

* UserProjectRole

The User entities represent users of the system. When combined with the BasicAuth authentication plugin (the Default in the docker image) users must be explicitly created with a username and a password. When combined with the KeyCloak plugin, User entities are automatically created, and don't have a password field. The password field can not be read by anyone, not even global admins.

The Project entities represent a unit of management that ties Users in one or more Roles to Entities. Projects are directly linked to Sensors and Things. All other entities in the data model are indirectly linked to Projects through a Thing. For instance, Observations belong to the Project of the Thing of their Datastream (Project → Thing → Datastream → Observation) and BhFeaturesOfInterest are linked to a Project through the Sampling (Project → BhTrajectoryThing → BhSampling → BhFeatureOfInterest). ObservedProperties are shared among all Projects and can only be created or modified by a global server admin. Finally, Projects can be either public or private through the property public. If the public property of a Project is true, then all users of the system can read entities associated to the Project. If the public property is false, then only Users that have the read right on that Project, or have global read rights, can read Observations associated with that Project.

The Role entities represent rights that a User can have. Roles can be directly linked to a User, or indirectly through a UserProjectRole Entity for a given Project. Roles that are directly connected to a User apply to the entire service. Roles that are linked to a user for a Project only apply to Entities of that Project. For instance, a User that has the global Role update can modify all Entities in the service. A user that has the update role for a given Project can only modify those Entities that are related to that specific Project.

A UserProjectRole entity gives a User a certain Role within a certain Project.

A normal user can only read the User Entity that belongs to their user account. Users that have a
project role of admin can read all User entities, since a project admin must be able to add Users to their Project. The password of a user (when BasicAuth is used) can only be changed by the User themselves, or by a global admin.

The rights for the different user types:

<table><thead><tr><th></th><th>Admin<br>(admin,<br>c,r,u,d)</th><th>Geotech<br>Expert<br>(r,c,u,d)</th><th>Public<br>(for open<br>projects)</th><th>Public<br>(for<br>private<br>projects)</th><th>Project<br>manager<br>(a,c,r,u,d)</th><th>Project<br>contribut<br>or<br>(r,c,u,d)</th><th>Project<br>member<br>(read)</th></tr></thead><tbody><tr><td>Project</td><td>CRUD</td><td>R</td><td>R</td><td></td><td>R</td><td>R</td><td>R</td></tr><tr><td>User</td><td>CRUD</td><td>R (self)</td><td></td><td></td><td>R (all)</td><td>R (self)</td><td>R (self)</td></tr><tr><td>Role</td><td>CRUD</td><td>R (self)</td><td></td><td></td><td>R (all)</td><td>R (self)</td><td>R (self)</td></tr><tr><td>UserProjectRole</td><td>CRUD</td><td>R (self)</td><td></td><td></td><td>CRUD<br>(project)</td><td>R (self)</td><td>R (self)</td></tr><tr><td>ObsProp</td><td>CRUD</td><td>CRUD</td><td>R</td><td>R</td><td>R</td><td>R</td><td>R</td></tr><tr><td>Sensor</td><td>CRUD</td><td>CRUD</td><td>R</td><td></td><td>CRUD</td><td>R</td><td>R</td></tr><tr><td>Thing &<br>Location</td><td>CRUD</td><td>CRUD</td><td>R</td><td></td><td>CRUD</td><td>R</td><td>R</td></tr><tr><td>FOI, Sampling,<br>Preparation</td><td>CRUD</td><td>CRUD</td><td>R</td><td></td><td>CRUD</td><td>CRUD</td><td>R</td></tr><tr><td>Stream</td><td>CRUD</td><td>CRUD</td><td>R</td><td></td><td>CRUD</td><td>CRUD</td><td>R</td></tr><tr><td>Observation</td><td>CRUD</td><td>CRUD</td><td>R</td><td></td><td>CRUD</td><td>CRUD</td><td>R</td></tr></tbody></table>

* The admin user type has global Admin, Create, Read, Update and Delete rights.

* The Geotech Expert user type has global Create, Read, Update and Delete rights, and can thus create Observed Properties and access all data in the server, but not manage users.

* The Project user types do not have any global roles, only project-related roles.

## 5.5. Exposing geotech investigation data with OGC SensorThings API

### 5.5.1. Approach for borehole logs

A borehole log is a record detailing the in-situ conditions and aspects of geotechnical exploration activities associated with the drilling and sampling of a borehole. It is typically a graphical representation of the data collected from various locations within the hole, along with properties associated with the borehole, its construction, and associated metadata.

**Data presented on geotechnical borehole logs**

The specific kinds of data presented on geotechnical borehole logs varies greatly depending on the application, but most typically include descriptions of the earth materials encountered in the
borehole at locations along the borehole's trajectory (lithologic descriptions, perhaps including geological units encountered), location and identification of any material samples collected, summary results of any tests performed in the borehole or on the samples, and related information about the borehole as a whole (eg. name, location), construction/destruction information that may vary along its trajectory, installations, and other metadata.

The following example shows a portion of a representative geotechnical borehole log produced for a landslide investigation by the US State of Ohio Department of Transportation (ODOT), and illustrates the types of information that may be included in such a log:

<table><caption>Figure 24. ODOT Borehole Log. Log courtesy of DataForensics, LLC and Ohio Department of Transportation. Project and location data have been anonymized, and some data altered or manufactured.</caption><thead><tr><th>PROJECT:</th><td colspan="2">TEST</td><th>DRILLING FIRM / OPERATOR:</th><td colspan="2">ODOT / CAREY</td><th>DRILL RIG:</th><td colspan="2">CME 55 TRUCK</td><th>STATION / OFFSET:</th><td colspan="2">131+46, 7" RT.</td><th>EXPLORATION ID</th><td rowspan="2">PAGE</td></tr><tr><th>TYPE:</th><td colspan="2">LANDSLIDE</td><th>SAMPLING FIRM / LOGGER:</th><td colspan="2">ODOT / WILLIAMS</td><th>HAMMER:</th><td colspan="2">CME AUTOMATIC</td><th>ALIGNMENT:</th><td colspan="2">CL SR 676</td><th>B-001-0-20</th></tr><tr><th>PID:</th><td colspan="2">1116</td><th>DRILLING METHOD:</th><td colspan="2">3.25" HSA / NQ2</td><th>CALIBRATION DATE:</th><td colspan="2">4/15/20</td><th>ELEVATION:</th><td colspan="2">818.6 (ft)</td><td>EOB:</td><td colspan="2">41.0 ft.</td></tr><tr><th>START:</th><td colspan="2">1/11/21</td><th>SAMPLING METHOD:</th><td colspan="2">SPT / NQ2</td><th>ENERGY RATIO (%):</th><td colspan="2">84</td><th>LAT / LONG:</th><td colspan="2">39.474660, -81.796858</td><th></th><td colspan="2">1 OF 2</td></tr><tr><th>MATERIAL DESCRIPTION<br>AND NOTES</th><th>ELEV.<br>818.6</th><th>DEPTHS</th><th>SPT/<br>RQD</th><th>N<sub>to</sub></th><th>REC<br>(%)</th><th>SAMPLE<br>ID</th><th>HP<br>(tsf)</th><th>GRADATION<br>(%)</th><th>ATTBERG</th><th>WC</th><th>ODOT<br>CLASS (GI)</th><th>SO4<br>ppm</th><th>BACK<br>FILL</th></tr></thead><tbody><tr><td><strong>ASPHALT (18")</strong></td><td>817.1</td><td></td><td>1</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="3">STIFF, REDDISH BROWN, SANDY SILT SOME<br>STONE FRAGMENTS, LITTLE CLAY, DAMP</td><td rowspan="3">814.1</td><td></td><td>2</td><td>9</td><td>24</td><td>72</td><td>SS-1</td><td>1.75</td><td>23</td><td>7</td><td>31</td><td>25</td><td>14</td><td>24</td><td>20</td><td>4</td><td>13</td><td>A-4a (1)</td><td>-</td></tr><tr><td></td><td>3</td><td>8</td><td>9</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>4</td><td>4</td><td>3</td><td>48</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="5">MEDIUM DENSE, REDDISH BROWN AND BROWN,<br>STONE FRAGMENTS WITH SAND, SILT, AND<br>CLAY, DAMP<br>@6.0"; DENSE<br>@6.0" - 9.0"; NO RECOVERY; AUGER CUTTINGS<br>TAKEN</td><td rowspan="5">Alluvium</td><td></td><td>5</td><td>23</td><td>12</td><td>7</td><td>27</td><td>100</td><td>SS-3</td><td>-</td><td>66</td><td>2</td><td>8</td><td>10</td><td>14</td><td>32</td><td>16</td><td>16</td><td>A-2-6 (1)</td><td>-</td></tr><tr><td></td><td>6</td><td>13</td><td>7</td><td>43</td><td>0</td><td>SS-4</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>19</td><td>A-2-6 (V)</td><td>-</td></tr><tr><td></td><td>7</td><td>17</td><td>14</td><td>12</td><td>39</td><td>0</td><td>SS-5</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>13</td><td>A-2-6 (V)</td><td>-</td></tr><tr><td></td><td>8</td><td>14</td><td>14</td><td>14</td><td>39</td><td>0</td><td>SS-5</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>6</td><td>A-2-6 (1)</td><td>-</td></tr><tr><td></td><td>9</td><td>48</td><td>13</td><td>11</td><td>34</td><td>22</td><td>SS-6</td><td>-</td><td>65</td><td>7</td><td>6</td><td>7</td><td>15</td><td>34</td><td>16</td><td>18</td><td>6</td><td>A-2-6 (V)</td><td>-</td></tr><tr><td rowspan="4">HARD, BROWN AND YELLOWISH BROWN, CLAY<br>SOME SILT, LITTLE SAND, LITTLE STONE<br>FRAGMENTS, MOIST<br>@12.0"; MOTTLED BROWN AND GRAY</td><td rowspan="4">808.1</td><td></td><td>10</td><td>11</td><td>9</td><td>25</td><td>100</td><td>SS-7</td><td>4.25</td><td>11</td><td>5</td><td>7</td><td>27</td><td>50</td><td>48</td><td>19</td><td>29</td><td>23</td><td>A-7-6 (17)</td><td>-</td></tr><tr><td></td><td>12</td><td>11</td><td>9</td><td>36</td><td>100</td><td>SS-8</td><td>4.50</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>20</td><td>A-7-6 (V)</td><td>-</td></tr><tr><td></td><td>13</td><td>10</td><td>16</td><td>14</td><td>38</td><td>89</td><td>SS-9</td><td>3.00</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>20</td><td>A-7-6 (V)</td><td>-</td></tr><tr><td></td><td>14</td><td>14</td><td>13</td><td>18</td><td>38</td><td>89</td><td>SS-9</td><td>3.00</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>9</td><td>Rock (V)</td><td>-</td></tr><tr><td rowspan="2">@9.0"; GRAY, DRY</td><td rowspan="2">808.1</td><td></td><td>15</td><td>14</td><td>60</td><td>104</td><td>89</td><td>SS-10</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>11</td><td>Rock (V)</td><td>-</td></tr><tr><td></td><td>16</td><td>46</td><td>25</td><td>80</td><td>100</td><td>SS-11</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>13</td><td>Rock (V)</td><td>-</td></tr><tr><td rowspan="2">@13.5"; VERY STIFF</td><td rowspan="2">803.6</td><td></td><td>17</td><td>22</td><td>32</td><td>101</td><td>100</td><td>SS-12</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>13</td><td>Rock (V)</td><td>-</td></tr><tr><td></td><td>18</td><td>24</td><td>48</td><td>150</td><td>100</td><td>SS-13</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>9</td><td>Rock (V)</td><td>-</td></tr><tr><td>CLAYSTONE, VARIEGATED YELLOWISH BROWN<br>AND REDDISH BROWN, MODERATELY<br>WEATHERED, VERY WEAK, THICK BEDDED,<br>CALCAREOUS, BLOCKY, GOOD; RQD 59%, REC<br>100%.</td><td>797.6</td><td>Dunkard<br>Group</td><td>21</td><td>22</td><td>23</td><td>78</td><td>100</td><td>NQ2-1</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>9</td><td>Rock (V)</td><td>-</td></tr><tr><td></td><td></td><td></td><td>24</td><td>25</td><td>26</td><td>38</td><td>100</td><td>NQ2-2</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>9</td><td>Rock (V)</td><td>-</td></tr></tbody></table>

From the log, it can be seen that the borehole was advanced by a 3.25" diameter hollow stem auger with continuous Standard Penetration Test sampling to a depth of 21 feet, at which point the advancement method was switched to rotary drilling with continuous rock coring (NQ2). Material descriptions and RQD results were made by visual inspection of samples recovered from the hole while it was being advanced, and other information resulted from laboratory testing of the recovered samples. The log contains the following information:

### Properties and metadata that apply to entire borehole

1. Name, number and type of the project for which the borehole was drilled (eg. Project, PID, Type)

2. Beginning and end date for the drilling (Start, End)
3. Location data (Station/Offset, Alignment, Elevation, Lat/Long)

4. Borehole ID (Exploration ID)

5. Borehole length (EOB)

Properties and metadata that apply to points or segments of the borehole and describe construction/destruction activities or information that does not directly apply to the earth materials encountered

1. Depth-specific remarks (notes) taken during drilling that note drilling or sampling conditions

2. Drilling methods (Drilling Method)

3. Drill rig operators (Drilling Firm, Operator)

4. Drilling equipment (Drill Rig)

5. A graphic column illustrating the depth-interval defined materials used to backfill the hole (in this case a bentonite/cement slurry)

Observations of earth materials that occur while advancing the hole (in-situ observations)

1. Depth-interval defined material descriptions, including lithology and physical properties

2. Depth-specific remarks that note changes in material properties within a lithologic interval

3. A graphic column illustrating the depth-interval defined primary lithology (eg, Sandy Silt, Shale)

4. A graphic column illustrating depth-interval defined geologic units encountered (eg. Dunkard Group)

5. Drive set blow counts and N60 result values from SPT tests (SPT/RQD column above 21 ft depth, N60 column).

Sampling and drilling activities that occur while advancing the hole

1. Drilling and Sampling methods (Drilling Method, Sampling Method)

2. Samplers/Observers (Sampling Firm, Logger)

3. Observing equipment and associated metadata (Hammer, Calibration Date, Energy Ratio)

4. Sample identifiers with their locations down hole, and recovery percentages (Sample ID, Rec columns)

Observations from laboratory tests on samples that occur ex-situ

1. Results from the following tests on the samples: a) compressive strength from hand penetrometer (HP column), b) particle size gradation (Gradation columns), c) Atterberg Limits (Atterberg column, LL=liquid limit, PL=plastic limit, PI=plasticity index), d) natural water content

2. Soil classification of samples above 21 ft depth (ODOT Class (GI) column). This is a modified AASHTO classification assigned based on results of the particle size and Atterberg limits tests

3. RQD result from samples (SPT/RQD column below 21 ft)
## Application to the STA model

A borehole log is typically a collection of several Observations and Sensors, along with data that are not directly observation-related, but all associated with one Thing (the borehole). To expose the data necessary to construct a borehole log, multiple queries to the FROST server related to the BhCollarThing of interest must be made to extract the information needed to populate the various components of the log. For the log components in the above example, below are recommended mappings to STA objects. With the exception of SPT and Atterberg limits discussed above, the other log information have not been considered in detail in this IE. It is also worth noting that the current Geotech data model and STA do not have objects specifically designed to handle activity information and installations that vary with position in the hole (eg. drill advancement data, backfill materials, installed casings, wells or instrument locations), or hole-point and hole-segment specific annotations that are not properties of earth materials. This information can be included within FROST as Observations or as properties of existing STA objects, but further evaluation of the data model and its STA implementation to accommodate these types of information is needed.

## Project

Although developed as a security extension to represent a unit of management that ties Users in one or more Roles to Entities, the Project object in STA can be reasonably used to represent the geotechnical concept of a project, which is a business activity that encompasses a collection of activities, material samples, and observations that occur within boreholes and other sampling features. Example for the log above (item 1):

```json
{
  "@iot.id": 5,
  "description": "Route 676 Improvements",
  "name": "TEST",
  "properties": {
    "pid": 1116,
    "type": "LANDSLIDE"
  }
}
```

**NOTE:** Keys within the properties object should come from a controlled list of property terms for the Project. Different organizations and existing transfer standards (such as AGS and DIGGS) have their own keys for Project properties; this IE has not attempted to harmonize them to develop a standard codelist for Project:properties keys. For full interoperability, this harmonization is important. A workaround at present could be to define the context for the properties keys using json-ld.

## Sensor

A Sensor instance should be created for each observation procedure in the log:

* **Material Descriptions** (items 11, 12, 13 above)

Example:
```json
{
  "iot.id": 15,
  "description": "Ohio Department of Transportation Soil and Rock Descriptions",
  "encodingType": "application/pdf",
  "metadata"
  :"https://www.transportation.ohio.gov/working/engineering/geotechnical/manuals/geotechnical-explorations/app/app-a",
  "name": "Visual Soil and Rock Classification",
  "sensorType": "Lithology Description",
  "Projects": [
    {"iot.id": 5}
  ]
}
```

* **Geologic Units** (item 14) Example:

```json
{
  "iot.id": 16,
  "description": "Ohio Department of Transportation Soil and Bedrock Classification",
  "encodingType": "application/html",
  "metadata": "https://mrdata.usgs.gov/geology/state/fips-unit.php?state=OH",
  "name": "Geologic units in Ohio (state in United States)",
  "sensorType": "Lithostratigraphy",
  "Projects": [
    {"iot.id": 5}
  ]
}
```

* **SPT Tests** (item 15 above) See this discussion for example.

* **Hand Penetrometer Tests** (item 20a above) Example

```json
{
  "iot.id": 17,
  "description": "Method is used to evaluate consistency and approximate unconfined compressive strength of soils by means of using a pocket penetrometer.",
  "encodingType": "application/html",
  "metadata": "https://www.astm.org/workitem-wk27337",
  "name": "Pocket Penetrometer",
  "sensorType": "Hand Penetrometer test",
  "Projects": [
    {"iot.id": 5}
  ]
}
```

* **Particle Size Tests** (item 20b above) Example:
```json
{
  "@iot.id": 18,
  "description": "Method used to separate particles into size ranges and to determine quantitatively the mass of particles in each range. These data are combined to determine the particle-size distribution (gradation).",
  "encodingType": "application/html",
  "metadata": "https://www.astm.org/d6913-04r09e01.html",
  "name": "Particle-Size Distribution (Gradation) of Soils Using Sieve Analysis",
  "sensorType": "Particle size distribution",
  "Projects": [
    {"@iot.id": 5}
  ]
}
```

* Atterberg Limits Tests (item 20c above) See this discussion for example.

* Water Content Tests (item 20d above) Example:

```json
{
  "@iot.id": 19,
  "description": "Method used to determine the water (moisture) content by mass of soil, rock, and similar materials where the reduction in mass by drying is due to loss of water, method A.",
  "encodingType": "application/html",
  "metadata": "https://www.astm.org/d2216-19.html",
  "name": "Natural water content, Method A",
  "sensorType": "Water content measure",
  "Projects": [
    {"@iot.id": 5}
  ]
}
```

* ODOT Classification (item 21 above) Example:

```json
{
  "@iot.id": 20,
  "description": "Ohio Department of Transportation Soil Classification. ODOT utilizes a modified AASHTO classification system based on gradation and plastic index (PI). Percentages are based on: dry weight not volume.",
  "encodingType": "application/pdf",
  "metadata": "https://www.transportation.ohio.gov/working/engineering/geotechnical/manuals/geotechnical-explorations/app/app-a",
  "name": "ODOT Soil Classification",
  "sensorType": "Soil Classification",
  "Projects": [
    {"@iot.id": 5}
  ]
}
```
* Projects links to the associated Project object (see above).

## BhTrajectoryThing

BhTrajectoryThing links to BhCollarThing and exposes the borehole lengths (item 5 above) and any offsets for downhole measurements. Example:

```json
{
  "@iot.id": 11,
  "description": "Trajectory of Borehole B-001-0-20",
  "name": "B-001-0-20 Trajectory",
  "lengthCore": 41.0,
  "lengthHole": 41.0,
  "offsetCore": 0,
  "offsetHole": 0,
  "uom": "ftUS",
  "BhCollarThing": [
    {"@iot.id": 10}
  ],
  "Projects": [
    {"@iot.id": 5}
  ]
}
```

## NOTES:

* Projects links to the associated Project object (see above).

## Location

The Location object provides the geographic locations of the BhCollarThing and its associated BhTrajectoryThing (item 3 above). Non-coordinate location information is provided in the Location instance associated with BhCollarThing. Examples:

### Location for BhCollarThing

```json
{
  "@iot.id": 10,
  "name": "B-001-0-20 Collar Location",
  "description": "Location of Borehole B-001-0-20 collar",
  "encodingType": "application/geo+json",
  "location": {
    "type": "Point",
    "coordinates": [
      -81.796858,
      39.47466,
      249.50928
    ]
  },
}
```
```json
"properties": {
    "station": "131+48",
    "offset": "7' RT",
    "alignment": "CL SR 676"
},
"BhCollarThings": [
    {"@iot.id": 10}
]
}
```

NOTES:

* BhCollarThings links to the associated BhCollarThing object (see above).

* Keys within the properties object should come from a controlled list of property terms for the Location. Different organizations and existing transfer standards (such as AGS and DIGGS) have their own keys for Location properties; this IE has not attempted to harmonize them and develop a standard codelist for Location:properties keys. For full interoperability, this harmonization is important. A workaround at present could be to define the context for the properties keys using json-ld.

* Current implementation of STA only supports geoprocessing for geometries encoded as application/geo+json which requires coordinates to be in WGS84. Many geotech organizations maintain location data in projected CRS's (e.g., UTM, State Plane) and local vertical datums, and many at times use local (engineering) coordinate systems. Until STA is capable of working with additional geometry encodings, coordinate conversions may be necessary and in some cases may be impossible.

Location for BhTrajectoryThing

```json
{
    "@iot.id": 11,
    "name": "B-001-0-20 Trajectory Location",
    "description": "Location of Borehole B-001-0-20 trajectory",
    "encodingType": "application/geo+json",
    "location": {
        "type": "LineString",
        "coordinates": [
            [
                -81.796858,
                39.47466,
                249.50928
            ],
            [
                -81.795909,
                39.475026,
                237.01248
            ]
        ]
    },
```
```json
"BhTrajectoryThings": [
    {"@iot.id": 11}
]
}
```

### NOTES:

* BhTrajectoryThings links to the associated BhTrajectoryThing object (see above).

### BhSampler

Bh Sampler implements the concept of a Sampler, which is a device or entity (including humans) that is used by, or implements, a SamplingProcedure to create or transform one or more samples (FeaturesOfInterest). In the above log example, borehole drilling and sampling of the Borehole-Hole only (e.g., SPT testing) is accomplished by the Drilling Firm/Operator (item 7 above) using a drill rig (item 9 above), whereas sampling of the borehole material itself (Core) is accomplished by the Sampling Firm/Logger (item 17). Examples:

```json
{
    "@iot.id": 15,
    "description": "Drilling Personnel",
    "name": "ODOT/CAREY",
    "samplerType": "Drilling Firm/Operator"
    "properties": {
        "equipment": [
            {
                "name": "CME 55 TRUCK",
                "class": "Drill Rig"
            }
        ]
    }
}
```

and

```json
{
    "@iot.id": 16,
    "description": "Sampling Personnel",
    "name": "ODOT/WILLIAMS",
    "samplerType": "Sampling Firm/Logger"
}
```

### NOTES:

* STA allows only one Sampler per Sampling (sampling activity) and at present does not allow Samplers to relate to each other, which necessitates combining the drilling/sampling personnel and related equipment into a single Sampler instance. More flexibility in this regard should be
considered in a future IE.

* The samplerType values and property keys should come from controlled lists of terms. Different organizations and existing transfer standards (such as AGS and DIGGS) have their own keys and allowable values for samplerType and Sampler properties; this IE has not attempted to harmonize them or develop standard codelists for these properties.

## BhSamplingProcedure

BhSamplingProcedure is the process used to perform a sampling activity. Both drilling and the collection of samples constitute sampling activities as both expose FeaturesOfInterest for observation. The example log defines four such procedures (item 15 above). Examples:

* Hollow stem augering (uppermost 21 ft of the hole). Cuttings samples produced by the drilling may be collected for testing or observed from the auger flights.

```json
{
  "iot.id": 13,
  "description": "Drilling with 3.25" hollow stem auger",
  "name": "3.25" HSA",
  "properties": {
    "type": "Drilling Method"
  }
}
```

* Rotary drilling using a NQ2 diamond core system (below 21 ft). Cuttings produced by the drilling.

```json
{
  "iot.id": 14,
  "description": "Drilling with NQ2 diamond core system",
  "name": "NQ2",
  "properties": {
    "type": "Drilling Method"
  }
}
```

* Soil sampling collected as a result of performing an SPT test (uppermost 21 ft of the hole), producing disturbed core samples.

```json
{
  "iot.id": 15,
  "description": "Sampling resulting from SPT testing",
  "name": "SPT",
  "properties": {
    "type": "Sampling Method"
  }
}
```
}

* Rock core sampling using a double tube NQ core barrel below 21 ft. This procedure produces solid rock core

```json
{
  "iot.id": 16,
  "description": "Core sampling using a double tube NQ core barrel",
  "name": "NQ2",
  "properties": {
    "type": "Sampling Method"
  }
}
```

### NOTES:

* The properties:type is defined to distinguish sampling procedures that specifically are designed to collect material samples (Sampling Method) from those that are primarily designed to advance the hole (Drilling Method).

### BhFeatureType

BhFeatureType is used to classify different kinds of BhFeaturesOfInterest. A BhFeatureOfInterest may be associated with any number of BhFeatureTypes. From our previous discussion on Borehole Sampling, five dedicated generic feature types are defined for features of interest within a borehole (a BhFeatureOfInterest):

* Hole

* Core

* Point

* Segment

* Entirety

These feature types are used in combination to provide the appropriate context for the feature. Features that derive from the Hole (thus simply locations where observations are made in-situ), are assigned a feature type of Hole, plus a feature type of either Point, Segment, or Entirety depending on the feature's linear extent. Material samples recovered from the hole (features of interest typically subjected to ex-situ observation), are assigned a type of Core, plus a Point, Segment, or Entirety feature type as with Hole features. Instances for these dedicated types are:

### Hole

```json
{
  "iot.id": 1,
  "definition": "https://ogc.org/Hole",
  "description": "A Sample from a Borehole-Hole",
```
```json
"name": "Hole"
}
```

## Core

```json
{
  "iot.id": 2,
  "definition": "https://ogc.org/Core",
  "description": "A Sample from a Borehole-Core",
  "name": "Core"
}
```

## Point

```json
{
  "iot.id": 3,
  "definition": "https://ogc.org/Point",
  "description": "A Sample obtained at a Point",
  "name": "Point"
}
```

## Segment

```json
{
  "iot.id": 4,
  "definition": "https://ogc.org/Segment",
  "description": "A Sample obtained at a Segment",
  "name": "Segment"
}
```

## Entirety

```json
{
  "iot.id": 5,
  "definition": "https://ogc.org/Entirety",
  "description": "A Sample taken from the Entirety",
  "name": "Entirety"
}
```

For BhFeaturesOfInterest that are material samples, it is often important to distinguish by type the primary samples from those that are derived from collected samples either by subsampling (Subsample) or aggregation (Amalgamate). In addition, for the example borehole log, samples subject to laboratory testing are extracted from source samples and prepared in various ways prior to testing. These samples are commonly called specimens and should be identified as such by a BhFeatureType:
## Specimen

```json
{
    "iot.id": 6,
    "definition": "https://ogc.org/Specimen",
    "description": "A Sample prepared from an existing Sample for testing purposes",
    "name": "Specimen",
}
```

The processing used to produce a specimen is described in `BhPreparationProcedure` and `BhPreparationStep` (see Atterberg limits).

**NOTES:** `BhFeatureType` names should come from a controlled list of terms. Different organizations and existing transfer standards (such as AGS and DIGGS) have their own keys and allowable values for sample types (eg. disturbed, remolded, soil, rock, etc.). Beyond the generic feature types discussed above, this `IE` has not attempted to harmonize other sample types or develop standard codelists for `BhFeatureType` names.

## BhSampling and BhFeatureOfInterest

`BhSampling` is used to expose the location of a sampling activity within the borehole and therefore must be associated with a borehole trajectory (`BhTrajectoryThing`). `BhSampling` is also optionally associated with both a `BhSampler` and a `BhSamplingProcedure` and produces one or more `BhFeaturesOfInterest`. `BhFeatureOfInterest` is associated with an Observation and can either be a material sample (`BhFeatureType` of Core, Core Point or Core Segment) or in the case of an in-situ observation, an Observation location (`BhFeatureType` of Hole, Hole Point or Hole Segment). Many `BhSampling` and `BhFeatureOfInterest` instances are required to represent the data in the example borehole log. Below are example instances of `BhSampling` and `BhFeatureOfInterest` for selected elements of the example log.

## MATERIAL DESCRIPTIONS FROM 4.5 TO 10.5 FT DEPTH

**BhSampling** (*Sampler*="ODOT/CAREY", *Sampling Procedure* = "3.25" HSA)

```json
{
    "iot.id": 299,
    "description": "Material description layer",
    "name": "Auger interval 3",
    "fromPosition": 4.5,
    "toPosition": 10.5,
    "positionUom": "ftUS",
    "BhTrajectoryThing": {"@iot.id": 11},
    "Bh Sampler": {"@iot.id": 15},
    "BhSamplingProcedure": {"@iot.id": 13}
}
```

**BhFeatureOfInterest** (*Feature Type*="CORE, SEGMENT")
```json
{
    "@iot.id": 300,
    "description": "Cuttings observed from 4.5-10.5 ft",
    "name": "Cuttings 4-10.5 ft",
    "BhSampling": {"@iot.id": 299},
    "BhFeatureTypes": [{"@iot.id": 2},{"@iot.id": 4}]
}
```

## PHYSICAL PROPERTY CHANGE AT 6 FT DEPTH

### BhSampling (Sampler="ODOT/CAREY", Sampling Procedure = "3.25" HSA")

```json
{
    "@iot.id": 300,
    "description": "Change in density remark",
    "name": "Physical Property Remark 1",
    "atPosition": 6,
    "positionUom": "ftUS",
    "BhTrajectoryThing": {"@iot.id": 11},
    "BhSampler": {"@iot.id": 15},
    "BhSamplingProcedure": {"@iot.id": 13}
}
```

### BhFeatureOfInterest (Feature Types="HOLE, POINT")

```json
{
    "@iot.id": 301,
    "description": "Observation location at 6 ft",
    "name": "Location at 6 ft",
    "BhSampling": {"@iot.id": 300},
    "BhFeatureTypes": [{"@iot.id": 1},{"@iot.id": 3}]
}
```

## SPT TEST FROM 1.5 TO 3 FT DEPTH (Multiple features of interest are associated to one sampling location)

### BhSampling (Sampling Procedure = "SPT", Sampler="ODOT/WILLIAMS")

```json
{
    "@iot.id": 301,
    "description": "SPT Test at 1.5 ft",
    "name": "SPT 1.5",
    "fromPosition": 1.5,
    "toPosition": 3.0,
    "positionUom": "ftUS",
    "BhTrajectoryThing": {"@iot.id": 11},
    "Bh Sampler": {"@iot.id": 16},
```
```json
"BhSamplingProcedure": {"@iot.id": 13}
}
```

### BhFeatureOfInterest #1 (Feature of interest for SPT observation itself, Feature Types="HOLE, SEGMENT")

```json
{
  "@iot.id": 302,
  "description": "Observation location 1.5 to 3 ft",
  "name": "Location from 1.5-3.0 ft",
  "BhSampling": {"@iot.id": 301},
  "BhFeatureTypes": [{"@iot.id": 1},{"@iot.id": 4}]
}
```

### BhFeatureOfInterest #2 (Sample collected from the SPT test, Feature Types="CORE, SEGMENT")

```json
{
  "@iot.id": 303,
  "description": "SPT Sample 1.5 to 3 ft",
  "name": "SS-1",
  "length": 1.08,
  "lengthUom": "ftUS",
  "recoveryPercentage": 72,
  "BhSampling": {"@iot.id": 301},
  "BhFeatureTypes": [{"@iot.id": 2},{"@iot.id": 4}]
}
```

### BhFeatureOfInterest #3 (Specimen created for particle size testing, Feature Type="SPECIMEN", Source sample (BhSampledFeature) = "SS-1")

```json
{
  "@iot.id": 304,
  "description": "Particle size specimen 1.5 to 3 ft",
  "name": "Acme 123",
  "BhSampling": {"@iot.id": 301},
  "BhFeatureTypes": [{"@iot.id": 2},{"@iot.id": 4},{"@iot.id": 6}],
  "BhSampledFeatures": [{"@iot.id": 303}]
}
```

### NOTES:

* In the example log, a Specimen BhFeatureOfInterest instance is required each time a source sample (eg. SS-1) is prepared for testing (eg. particle size, Atterberg limits, etc.).

* A Specimen is assumed to be subsampled from its source sample(s).

* A Specimen that constitute the entire spatial extent of its source sample may link to the same BhSampling entity as its source sample. However, if a specimen is extracted from only a portion
of a source core sample, an additional BhSampling instance would be required to identify the specific location of the Specimen within the borehole trajectory.

* A Specimen BhFeatureOfInterest instance need not be created if the entire source sample is consumed in testing.

## ObservedProperty

ObservedProperty identifies the properties of the BhFeatureOfInterest that is observed by the Sensor (observing procedure). One ObservedProperty instance should exist for each Observation result type that is obtained. For the example log above the observed properties are:

<table><thead><tr><td>Sensor/Observing procedure</td><td>Observed Properties (see Observable Properties)</td></tr></thead><tbody><tr><td>Visual Soil and Rock Classification</td><td>lithology description<br>lithology classification<br>lithology symbol</td></tr><tr><td>Geologic units in Ohio (state in United States)</td><td>unit name</td></tr><tr><td>SPT test</td><td>see Approach for SPT</td></tr><tr><td>Pocket penetrometer</td><td>uniaxial compressive strength</td></tr><tr><td>Particle size distribution</td><td>gravel content<br>coarse sand content<br>fine sand content<br>silt content<br>clay content</td></tr><tr><td>Atterberg limits</td><td>see Approach for Atterberg limits</td></tr><tr><td>Natural water content, Method A</td><td>natural water content</td></tr><tr><td>ODOT Soil Classification</td><td>lithology classification</td></tr><tr><td>Rock Quality Designation</td><td>rqd rock quality designation</td></tr></tbody></table>

Below are example instances for the observed properties associated with soil and rock classification and pocket penetrometer:

```json
{
  "iot.id": 29,
  "name": "lithology classification",
  "definition": "https://github.com/opengeospatial/Geotech/wiki/ObservedProperties",
  "description": "The value that describes the lithology as a controlled term"
}
```

```json
{
  "iot.id": 30,
  "name": "lithology description",
```
```json
"definition":
"https://github.com/opengeospatial/Geotech/wiki/ObservableProperties",
"description": "Descriptive information about the soil or rock lithology"
}
```

```json
{
  "iot.id": 31,
  "name": "lithology symbol",
  "definition":
  "https://github.com/opengeospatial/Geotech/wiki/ObservableProperties",
  "description": "A string or numeric value that is used to define a graphic pattern"
}
```

```json
{
  "iot.id": 32,
  "name": "uniaxial compressive stress",
  "definition":
  "https://github.com/opengeospatial/Geotech/wiki/ObservableProperties",
  "description": "The maximum axial compressive stress that a right-cylindrical sample of material can withstand under unconfined conditions"
}
```

**NOTE:** Ideally, the definition property should link to a registry or online dictionary that provides a definition and full context for the observed property.

## Datastream

The Datastream object serves to link individual observation results to their associated observed properties and observing procedures (Sensors). It also is used to provide additional context to the observation result (such as unit of measure) and to the observed property. One Datastream instance is required for each unique combination of BhTrajectoryThing, Sensor, and ObservedProperty. The following are a few example Datastream instances for the borehole log above:

* Datastream for ObservedProperty = "lithology description" and Sensor = "Visual Soil and Rock Classification"

```json
{
  "iot.id": 29,
  "description": "Datastream for B-001-0-20 lithology description",
  "name": "B-001-0-20 Lithology description",
  "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement",
  "unitOfMeasurement": {},
  "Sensor": {"iot.id": 15},
  "ObservedProperty": {"iot.id": 30},
  "Thing": {"iot.id": 11}
}
```
}

* Datastream for ObservedProperty = "uniaxial compressive stress" and Sensor = "Pocket Penetrometer"

```json
{
  "iot.id": 30,
  "description": "Datastream for B-001-0-20 Pocket penetrometer",
  "name": "B-001-0-20 Pocket penetrometer/uniaxaal compressive stress",
  "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement",
  "unitOfMeasurement": {
    "name": "tonf[US]/ft2",
    "symbol": "tonf[US]/ft2",
    "definition": "US tons force per square foot"
  },
  "Sensor": {"@iot.id": 17},
  "ObservedProperty": {"@iot.id": 32},
  "Thing": {"@iot.id": 11}
}
```

* Datastream for ObservedProperty = "lithology classification" and Sensor = "ODOT Soil Classification"

```json
{
  "iot.id": 31,
  "description": "Datastream for B-001-0-20 ODOT Soil Classification",
  "name": "B-001-0-20 ODOT Soil Classification",
  "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement",
  "unitOfMeasurement": {},
  "Sensor": {"@iot.id": 20},
  "ObservedProperty": {"@iot.id": 29},
  "Thing": {"@iot.id": 11}
}
```

* Datastream for ObservedProperty = "lithology classification" and Sensor = "Visual Soil and Rock Classification"

```json
{
  "iot.id": 32,
  "description": "Datastream for B-001-0-20 Soil Classification for Graphic Log",
  "name": "B-001-0-20 Soil Classification for Graphic Log",
  "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement",
  "unitOfMeasurement": {}
},
```
```json
"Sensor": {"@iot.id": 15},
"ObservedProperty": {"@iot.id": 29},
"Thing": {"@iot.id": 11}
}
```

## Observation

The Observation object holds the result of an ObservedProperty for a BhFeatureOfInterest. Each Observation instance links directly to a BhFeatureOfInterest instance and indirectly to the result's ObservedProperty through the Observation's associated Datastream.

On the example borehole log, every numeric, text or graphic entry below the log's header (with the exception of depth and elevation information) is the result of an individual Observation instance. Below are a few examples: * Observation for material description at depth interval between 4.5 and 10.5 feet

```json
{
  "@iot.id": 881,
  "phenomenonTime": "2021-01-11T00:00:00-05",
  "result": "MEDIUM DENSE, REDDISH BROWN AND BROWN, STONE FRAGMENTS WITH SAND, SILT, AND CLAY, DAMP",
  "FeatureOfInterest": {"@iot.id": 300},
  "Datastream": {"@iot.id": 29}
}
```

* Observation for graphic log symbolization at depth interval between 4.5 and 10.5 feet

```json
{
  "@iot.id": 882,
  "phenomenonTime": "2021-01-11T00:00:00-05",
  "result": "STONE FRAGMENTS WITH SAND, SILT, AND CLAY",
  "FeatureOfInterest": {"@iot.id": 300},
  "Datastream": {"@iot.id": 32}
}
```

* Observation for material description (physical property change) at 6 ft depth

```json
{
  "@iot.id": 883,
  "phenomenonTime": "2021-01-11T00:00:00-05",
  "result": "@6.0'; DENSE",
  "FeatureOfInterest": {"@iot.id": 301},
  "Datastream": {"@iot.id": 29}
}
```

* Observation of uniaxial compressive strength, from hand penetrometer test on sample
from 1.5 to 3 ft depth

{ "@iot.id": 884, "phenomenonTime": "2021-01-11T00:00:00-05", "result": 1.75, "FeatureOfInterest": {"@iot.id": 303}, "Datastream": {"@iot.id": 30} }

• Observation of ODOT Soil Classification, from sample collected from 1.5 to 3 ft depth

{ "@iot.id": 885, "phenomenonTime": "2021-01-11T00:00:00-05", "result": "A-4a (1)", "FeatureOfInterest": {"@iot.id": 303}, "Datastream": {"@iot.id": 31} }

NOTES:

• The Observation property "phenomenonTime" is required and will default to the server time if the phenomenonTime is not provided when an Observation instance is created. In geotechnics, the time of an observation is often not reported for laboratory tests and many in-situ tests. If the observation time is unknown to the data provider, phenomenonTime must be estimated to circumvent the default behavior. In either case, an estimated or default phenomenonTime for an observation should be identified as such in an additional Observation property.

• Some kinds of tests, such as SPT and Atterberg limits, produce complex sets of Observation results that require that links be created to group related Observations and Datastreams together in order to distinguish interim or procedural observations from the final reported test results. Examples of these are shown in the detailed discussions for SPT and Atterberg limits tests.

5.5.2. Approach for CPT

Cone Penetration Testing (CPT) is a technique used to evaluate subsurface stratigraphy and material
properties. An instrumented probe is advanced into the soil by direct-push techniques from a
reaction system, which is often a heavy vehicle but may be an independent frame with soil reaction
anchors. Measurements from probe sensors are recorded on the probe or transmitted in real-time
to an up-hole data collection and processing system at frequent intervals. Unlike many other in-situ
geotechnical investigation techniques, the system does not use rotary drilling. CPT is frequently
used both independently and as a companion to borehole drilling. Cone penetration testing is used
worldwide but is generally less common than rotary drilling and related testing (such as SPT) due
to the ubiquity of drill rigs and the ability of drills to penetrate nearly all geomaterials for site
characterization. CPT rigs may be mounted on skids, wheeled or tracked vehicles, or reaction
frames which can be moved into place manually or using light vehicles and small equipment.
Vehicles and frames may use earth anchors to provide reaction for the probe push system. CPT systems can also be deployed in marine environments using specialty systems.

Most modern CPT probes are configured with sensors to measure the force acting on the cone tip, force acting on a nearby friction sleeve, pore water pressure, and probe vertical tilt (used primarily to evaluate the probe position and inclination for terminating a push if verticality is not well maintained).

The technique has several advantages.

* Probe sensors are generally robust and easy to check for proper calibration; measurements are often highly repeatable and less operator dependent than other techniques.

* Data is collected electronically at frequent time/depth intervals creating a near-continuous record.

* The technique is relatively fast with a standard advance rate of 20mm/sec.

* Probes are available in several shapes and sizes for targeted applications.

* The technique is well suited for both land and marine applications.

* Many systems are automated to varying degrees.

* Probes may be configured with a variety of additional sensors:

* Multi axial or multiple location geophones (seismic wave speed; pressure and shear wave measurement)

* Video cameras

* Electrical conductivity or resistivity

* Fuel fluorescence

* Gamma radiation detectors

* Magnetometers

* Multiple friction sleeves

* Relative safety.

* Rigs are often enclosed with protection from weather, traffic, dust, and other conditions.

* There are no rotating parts in the operational area greatly minimizing operator hazards

* Reaction force may come from dead-weight or a variety of anchoring systems

* Rigs exist in a wide range of sizes and configurations

* The operation results in relatively little disturbed ground and spoil and is well suited to environmentally sensitive sites.

CPT systems record near-continuous readings of measured sensor output. These readings are then processed using calibration conversions to engineering units, usually in real time during the advance of the probe for operator observation and reaction. Some probes have an onboard memory system and the probes are pushed and retrieved without real-time information [limiting issues related to wires and wireless commination]. Proprietary output files usually contain a variety of metadata, calibration information, and probe measurements. Additional supporting files may be created if standard testing is paused to conduct specialty time-domain tests at specified
depths, such as pore water pressure dissipation tests or shear wave velocity tests. Recorded
measurements are usually post-processed to develop a variety of engineering parameters based on
calculations, theoretical, or empirical relationships.

Basic measurement output from modern electronic CPT systems includes:

* Time

* Depth [measured by an up-hole sensor]

* Tip stress

* Sleeve friction

* Pore-water pressure*

* X-Y Inclination [measured by a pair of accelerometers]

Other measured real-time values could include the measured down pressure of the drive system
from pressure transducers included in the hydraulic system. A common calculated real-time value
is the Friction Ratio. The pore pressure is typically measured immediately behind the tip element at
the cone shoulder (the u2 position). Some specialty cones have the pore pressure element at the
cone nose tip (the u1 position) or behind the friction sleeve (the u3 position), though these are far
less common in non-research [production] applications. The location of the pressure sensor
element is usually included in the test metadata. The CPT test measurements are usually post-
processed and information about the site location (coordinates and elevation) is often added into
the file along with other site information, such as the sounding number, time, weather, rig
identification, etc. Complete depth-based post-processed output frequently includes corrected
measurements and calculated parameter values:

* Corrected Tip stress

* Friction Ratio

* Resistivity/Conductivity

* Seismic arrival times (P, S1, S2 waves at intervals)

* Correlated parameters (by one or more methods)

* Soil Behavior Type (SBT)

* Soil Material Index (Ic)

* Effective Friction Ratio (phi prime)

* Undrained Shear Strength (su)

* Unit weight

* Preconsolidation Stress (sigma prime sub p)

* Yield Stress Ratio (YSR)

* Lateral Stress Coefficient (Ko)

* Constrained Modulus (D')

* Drained Young's Modulus (E')

* Bulk Modulus (K')
* Subgrade Reaction Modulus (ks)

* Resilient Modulus (ks)

* Small Strain Shear Modulus (Gmax)

* Coefficient of Permeability (k)

* Coefficient of Consolidation (Cv)

Some specialty tests are performed at intervals during a regular CPT advance. Pore water pressure dissipation tests may include the time and a series of pore pressure measurements taken at a specific depth. These time-domain tests are typically conducted at selected depths (rather than at regular intervals) and may take a few minutes to several hours to complete. The test data is typically recoded in a separate CPT data file, at each depth where a test is conducted, with a different data structure, associated with the main data file by test ID.

Similarly, seismic tests may include the time and geophone response at a specific depth. Other specialty measurements (or data streams) may be recorded with the basic measurements with additional sensors on the probe, such as electrical conductivity or magnetometers. Similar to pore water pressure dissipation, the test data is typically recoded in a separate CPT data file at each depth where a test is conducted, with a different data structure, associated with the main data file by test ID.

A video feed from a camera mounted within the probe may be recorded as a separate data stream. Video cones are outfitted with depth encoders to include the depth on the video recording (which may be recorded separately as an analog or digital format companion file). Typically CPT logs contain the basic test data and dissipation and seismic data is processed separately and the calculated "results" (such as permeability (k) or pressure or shear wave velocity) are indicated on the log.

CPT operators often also have the capability to advance a soil sampler using the same reaction, advance system, and rods in an adjacent sounding. Samples are obtained and companion information from samples, such as photographs, moisture assessments, stratigraphic notes, soil identification and classification may accompany the digital record.

In addition to the advantages described for data acquisition in the field, the relative robustness of the data is useful for correlations and assessments of site variability. CPT data is often used to characterize site stratigraphy [with a high degree of confidence], model liquefaction potential, or to model the design performance of both deep and shallow foundation systems. Often, CPT measurements are correlated to traditional Mohr-Coulomb (phi-c) engineering design parameters, but some modern design techniques use direct-design from original measured CPT engineering values (without the correlation step). There are dozens of direct CPT design methods, making the exchange and interoperability of CPT data especially valuable for use when importing values into design software.
<figure><img src="image_25.png" /><figcaption>Figure 25. CPT rods being added as a probe is advanced at a project site. Photo courtesy of Minnesota Department of Transportation.</figcaption></figure>
<figure><img src="image_26.png" /><figcaption>Figure 26. Operator controlling the push rate as a CPT probe is advanced and data is automatically recorded by a data acquisition system. Photo courtesy of Minnesota Department of Transportation.</figcaption></figure>
<figure><img src="image_27.png" /></figure>

Figure 27. A medium-sized truck-mounted CPT direct-push rig characterizing soils near an existing culvert. The truck is leveled on a set of jacks and the cone is pushed from a location near the center of gravity of the carrier. Photo courtesy of Minnesota Department of Transportation.

<figure><img src="image_28.png" /></figure>

Figure 28. A typical CPT output plot showing Sleeve Stress, Tip Stress, Friction Ratio, Pore Pressure and a calculated Soil Behavior Type (SBT). Figure courtesy of Minnesota Department of Transportation.

The applicable US Standard is ASTM D5778-20, Standard Test Method for Electronic Friction Cone and Piezocone Penetration Testing of Soils
## Exposing CPT with the FROST Geotech Plugin

A typical CPT sounding includes the measurement of several soil properties at numerous closely spaced points as the CPT probe is advanced into the subsurface. To demonstrate how CPT measurements and related metadata are stored and organized within the FROST server, we offer the following example of a simple CPT sounding where three properties are measured:

### GENERAL TEST INFORMATION

1. Test procedure: ASTM D3441-16, Standard Test Method for Mechanical Cone Penetration Testing of Soils

2. Sounding info: C-10, 15.03 ft sounding depth, top of sounding located at lan/lon 39.475026/-81.795909, elevation 252.61824 meters (WGS84).

3. Cone Serial Number: 128.074

4. Tip area: 15 cm²

5. Distance between tip and sleeve transducers: 15 cm

6. Probe Penetration Rate: 1 cm/s

7. Net Area Ratio Correction: 0.8

### OBSERVATIONS MADE DURING THE TEST

Below is a sampling of the data generated. There are 263 sounding points total

<table><thead><tr><td>Depth (ft)</td><td>Tip Resistance (tsf)</td><td>Sleeve Friction (tsf)</td><td>u2 Pore Pressure (tsf)</td></tr></thead><tbody><tr><td>0.153</td><td>16.1</td><td>0</td><td>0.06</td></tr><tr><td>0.211</td><td>26.2</td><td>0</td><td>0.06</td></tr><tr><td>0.292</td><td>41.8</td><td>0.35</td><td>0.07</td></tr><tr><td>..</td><td>...</td><td>...</td><td>...</td></tr><tr><td>3.357</td><td>32.2</td><td>1.2</td><td>-0.1</td></tr><tr><td><strong>3.41</strong></td><td><strong>32</strong></td><td><strong>1.19</strong></td><td><strong>-0.1</strong></td></tr><tr><td>3.461</td><td>31.9</td><td>1.19</td><td>-0.09</td></tr><tr><td>3.516</td><td>31.6</td><td>1.16</td><td>-0.09</td></tr><tr><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><td>14.765</td><td>84.1</td><td>0.47</td><td>0.22</td></tr><tr><td>14.824</td><td>84.6</td><td>0</td><td>0.23</td></tr><tr><td>15.034</td><td>78.1</td><td>0</td><td>0.23</td></tr></tbody></table>

### Instance Diagram

Object instances and the associations required to properly expose the example test data with the FROST Geotech Plug-in are shown in the following object diagram. This shows data for only sounding point at depth of 3.41 ft:
<figure><img src="image_29.png" /><figcaption>Figure 29. CPT</figcaption></figure>

The following summarizes the various entities in the diagram:

## Sensor

The Sensor object serves as the observing procedure in STA. One object instance is needed for this example (top center of diagram), and in this example holds the information about the test procedure, test parameters, equipment used and other metadata about the test. The general test data above (except for item 2) are all stored in the properties object of this Sensor instance. One Sensor instance is needed for all CPT tests conducted in one or more soundings provided that the same procedure, test parameters and test equipment is used for all tests.

## ObservedProperty

The ObservedProperty object instances identify the properties that are observed by the CPT test. These are: - tip_resistance - sleeveFriction - pore_water{j,pressure_u2

As with Sensor, the ObservedProperty instances can be reused for multiple tests.

## DataStream

All of the object instances in the diagram are linked to the Sensor and ObservedProperty instances via Datastream instances (below the ObservedProperty objects on the diagram), which serve to associate observation results obtained from a feature of interest to its observed property, observing procedure, and the sounding's trajectory.

Three Datastream instances are needed, one for each ObservedProperty instance.

## BhCollarThing, BhTrajectoryThing and Location

The DataStreams all link to the sounding via its BhTrajectoryThing object instance. BhTrajectoryThing (left edge of diagram) represents the sounding's geometry and contains the sounding length and information for linear referencing. The trajectory's geometry is given in the associated Location instance. BhTrajectoryThing is associated with a BhCollarThing instance, which represents the sounding as a whole. All general metadata about the sounding is contained in the
BhCollarThing object instance; it's geometry is represented by an associated point Location object instance.

More detail about properties of BhCollarThing and BhTrajectoryThing can be found in the Borehole log discussion.

## BhSampling and BhFeatureOfInterest

Sampling in the context of a CPT test or any in-situ test is the act of observing properties at a point or segment of the BhTrajectoryThing. The single BhSampling object instance (below and to the right of the BhTrajectoryThing in the diagram) holds the depth information of this sounding point (atPosition=3.41) and links to BhTrajectoryThing in order to affix the linear referenced sampling positions to the trajectory geometry.

BhSampling produces a BhFeatureOfInterest object, which represents the sampling location within the sounding (to the right of the BhSampling object instance in the diagram).

## Observation

The remaining entities on the diagram are Observation instances that provide the results for their associated observed properties. Each Observation instance links to the BhFeatureOfInterest (sampling location) and to the Datastream instance associated with the appropriate ObservedProperty. As the results of each observed property are independently measured by sensors on the CPT probe, they are independent and therefore there are no related observations.

To add data from more sounding points, this requires adding a new BH_Sampling and BH_FoI in addition to the three new Observations for each sounding point. In the diagram below, we have added an additional sounding point (the next one in the depth series). These additions are shown in grey to distinguish them from the objects already displayed in the simpler diagram above.

<figure><img src="image_30.png" /><figcaption>Figure 30. CPT Observation</figcaption></figure>
### 5.5.3. Approach for SPT

The Standard Penetration Test (SPT) is a very widely used in-situ geotechnical test often applied in combination with other tests during the advance of a borehole by various rotary drilling techniques. The boreholes may also be advanced by sonic or direct push techniques, but these are far less common. The test is typically conducted at discrete intervals following separate drilling operations.

The test is valued for its ability to retrieve a sample and a simultaneous measurement of soil strength, as well as its relatively low cost, simple test protocol, wide-availability, and compact data set which can be easily manually recorded and transmitted. The sampler is relatively robust and can be used in nearly any geo-environment: soft to hard soils, cemented soils, regional geomaterials, urban fill, and soft rock.

The test is commonly used to evaluate the strength of soils through correlations to the angle of internal friction of granular materials and soil relative density. Over the decades of use of SPT, researchers have also amassed correlations to most every commonly used engineering parameter, with variable reliability, precision, and accuracy. Caution is advised when making interpretations about strength and other behaviors in environments where the test is not well suited, as described in governing standard test methods and other manuals of practice. While the SPT can collect samples in most materials it is not well suited to determining material strength properties of complex geotechnical materials such as peats, clays, and relatively large aggregates (as compared to the sampler size).

The SPT test is typically conducted across an interval of 18-inches [450 mm], creating a measurement associated with that sample length. Extremely soft or extremely hard materials may influence the test interval and measurement reporting. While back-to-back (continuous) SPT sampling is possible, the test is commonly conducted at intervals specified by the owner or agency. Often 2.5 ft., 5 ft., or 10 ft. intervals (or SI equivalent) during the advance of a borehole and is typically conducted at increasingly wider intervals as borings advance deeper owing to the need to alternate the drilling bit or tools with the sampler by pulling the complete string of drilling rods in and out of the hole.

The SPT test is considered a "disturbed sample" test as the sampler has a comparatively narrow aperture to collect the sample and thick outer wall. The basic mechanics of the test involve driving the soil sampler, at the base of the drill string, through the ground by a series of dynamic hammer drops applied to the top of the drill rods. The number of blows taken to drive the rods in measured depth intervals is recorded.

A variety of hammers and hammer systems can be used. Mechanical trip hammers, donut hammers, winch hammers, and safety hammers are in use worldwide. The test method prescribes a weight of 140 lbs [63.5 kg] and a drop height of 30 inches [750 mm]. Some hammer systems, such as rope and cathead hammers are operatory dependent and energy can vary widely. For improved performance and consistency, hammer systems should be calibrated to determine the energy transfer ratio (ETR), with the energy reported on boring logs for use in design [this is optional in the US standard].

For a typical test, a boring is advanced to the desired test depth (or elevation). The drilling tooling is pulled from the hole and the drill bit replaced with the SPT sampler. The sampler is lowered back
into the borehole and the test begins. The top of the drill rod is marked off in three (3) 6-inch [750 mm] increments. The test consists of recording the number of blows to advance the sampler in each of three (3) consecutive 6-inch [150 mm] intervals. The sample tube is driven the first 6-inches and the number of blows needed to penetrate that interval is recorded. The procedure similarly repeats for the second 6-inch [150 mm] and third 6-inch [150 mm] intervals. After the sampler has advanced to a depth of 18-inches [450 mm] the test concludes. The three penetration "blow" numbers are recorded. A calculated value, the sum of the number of blows associated with the second 6-inch [150 mm] and third 6-inch [150 mm] intervals is reported as the "standard penetration resistance", "N-value" or "SPT blow count"

Notably, there are a number of “special cases” where the N-value may be unusual. If the sampler is driven less than the full extent the number of blows for each full increment or partial increment is recorded. The number of blows in a given increment are counted until a test termination condition is reached:

* The sampler penetrates 6 inches (150 mm);

* The sampler is driven 50 blows in any of the 3 increments;

* The sampler is driven a total of 100 blows; or

* The sampler does not advance after 10 consecutive blows.

Additionally, if the sampler advances under the weight of the sampler and rods (or the sampler, rods, and hammer assembly) conditions of “weight of rods” or “weight of hammer” are noted rather than a “N-value.”

An additional component of the test is the “Sample Recovery” which is a visual observation and manual measurement of the sample recovered in the SPT sampler once the sampler is brought to the ground surface for recovery of the obtained sample within the SPT sampler.

A variety of metadata is required by the US and other standards. Applicable standards also specify the minimum precision associated with the reported values among other aspects of the testing procedures and equipment. Basic measurement output from a SPT test includes:

Basic measurement output from a SPT test includes:

* Depth of each test location along the extent of the borehole [measured by the operator based on the amount of drilling tooling in the ground and the ground elevation],

* The increment blow values of the 1st, 2nd, and 3rd increments, in addition to any special notations associated, such as the distance penetrated if less than 6-inches [150 mm]

* Notations if any of the termination criteria are reached other than penetration or if the sampler advances under the weight of rods or hammer

* The % recovery of each sample within the SPT sampler

* Other driller notations such as equipment and tooling, method of keeping the borehole open, depth of the water surface, size of casing, hammer systems used, etc.

In addition, the calculated N-value is the primary output from the test:

* The “standard penetration resistance”, “N-value” is calculated as the sum of the number of
blows associated with the second 6-inch [150 mm] and third 6-inch [150 mm] intervals.

* If the sampler is driven less than 18-inches [450 mm], the number of blows per each complete 6-inch [150 mm] increment and each partial increment is recorded. In this circumstance there is not an N-value associated with that depth.

The N-value is often reported along with a calculated value, N60, where the measured N-value is adjusted to a 60% drill rod energy transfer ratio. Depending on owner and agency test procedures, SPT measurements can further be corrected prior to their use in engineering calculations based on a variety of variables. Corrections may be applied based on:

* Rod type (A rod vs. N rod)

* Use of liners within the SPT sampler

* Short rod lengths

* Boring diameter

* Other factors

The SPT measurements (N-value or other partial penetration and blow measurements) are often recorded in the field on a boring log in a discrete column of data. This information is then supplemented with other field or lab data which may include the drilling operations, soil type by observation or identification or classification system evaluation techniques, and frequently moisture content evaluated from a portion of the sample recovered in the soil sampler. SPT measurements are commonly reported and associated on a boring log with other depth-based data at the same location:

* Soil moisture contents

* % sample recovery

* A text-based soil identification or classification value derived from the sample

* Symbology associated with a soil identification or classification

* A drilling operation (casing, plug drilling, etc.)

A challenge for this common test is that while the basic data is often relatively simple and concise, there are a large number of supporting informational elements either associated with the site, the borehole, or the test. Many of these details are required by the test standard in the report for a proper and complete understanding of the measurement data.

Driller and lab technician comments can be important to interpreting otherwise unusual values, when compared with other in-situ tests or laboratory tests on collected samples conducted in association with the SPT testing. As such, the numeric measurements associated with the SPT test are frequently associated with supplemental text-based notes and comments, which may not be consistent among organizations, drilling staff, or even an individual driller.
<figure><img src="image_31.png" /><figcaption>Figure 31. A SPT drill rig on a project site; a work table with a SPT sampler is in the foreground. Photo courtesy of Minnesota Department of Transportation</figcaption></figure>
<figure><img src="image_32.png" /><figcaption>Figure 32. A SPT sampler rests on a work table, ready to be attached to the drill rods when the drill tooling is removed at the desired sample depth. Photo courtesy of Minnesota Department of Transportation.</figcaption></figure>

The applicable US Standard is ASTM D1586/D1586M-18e1 Standard Test Method for Standard Penetration Test (SPT) and Split-Barrel Sampling of Soils.

## Exposing SPT with the FROST Geotech Plugin

To demonstrate how the final results, interim test information and related metadata are stored and organized within the FROST server, we offer the following example SPT test for a single test interval. Relevant data are:

### GENERAL TEST INFORMATION

1. Test procedure used: ASTM D1586/D1586M-18e1 Standard Test Method for Standard Penetration Test (SPT) and Split-Barrel Sampling of Soils

2. Location: Test run from 1.5 to 3 ft depth in borehole B-001-0-20

3. Borehole is 41 ft deep and its collar is located at lat/lon 39.47466/-81.796858, elevation 249.50928 meters (WGS84)

4. Hammer used: CME Automatic

5. Hammer Efficiency: 84%

### OBSERVATIONS MADE DURING THE TEST

<table><thead><tr><td>Drive Set Number</td><td>Blow Count</td><td>Penetration (ftUS)</td></tr></thead><tbody><tr><td>1</td><td>9</td><td>0.5</td></tr></tbody></table>
<table><thead><tr><td>Drive Set Number</td><td>Blow Count</td><td>Penetration (ftUS)</td></tr></thead><tbody><tr><td>2</td><td>8</td><td>0.5</td></tr><tr><td>3</td><td>9</td><td>0.5</td></tr></tbody></table>

FINAL REPORTED RESULTS * N-Value: 17 * N1-60: 24

Note: This example focuses only on the in-situ test procedure and its results; it does not provide any information regarding the recording of any material samples that may have been recovered as a result of the test. Use of the FROST plug-in for recording material sample information is discussed in Approach for Atterberg limits

Instance Diagram

Object instances and the associations required to properly expose the example test data with the FROST Geotech Plug-in are shown in the following object diagram:

<figure><img src="image_33.png" /><figcaption>Figure 33. SPT Example</figcaption></figure>

The following summarizes the various entities in the diagram:

Sensor

The Sensor object serves as the observing procedure in STA. One object instance is needed for this example (top center of diagram), and in this example holds the information about the test procedure, test parameters, equipment used and other metadata about the test. In this example, the hammer information and hammer efficiency data would be held in the properties object of the Sensor. One Sensor instance is needed for all SPT tests conducted in one or more boreholes provided that the same procedure, test parameters and test equipment is used for all tests.

ObservedProperty

The ObservedProperty object instances identify the properties that are observed by the SPT test. There are 5 ObservedProperty instances (top of diagram, below Sensor):
**two properties observed that constitute the final reported summary results of the test:**

1. `n_value` (standard penetration resistance)

2. `n1_60` (standard penetration resistance corrected for hammer energy and overburden conditions)

**three properties observed as the test is being run**

3. `driveSetIndex` (a counter for each set of hammer blows to drive the rod 150 cm)

4. `blowCount` (number of blows during the drive set (increment))

5. penetration (the distance the sampler travels during the drive set).

As with Sensor, the `ObservedProperty` instances can be reused for multiple tests.

## DataStream

All of the object instances in the diagram are linked to the Sensor and `ObservedProperty` instances via Datastream instances (below the `ObservedProperty` objects on the diagram), which serve to associate observation results obtained from a feature of interest to its observed property, observing procedure, and the borehole.

Five Datastream instances are needed, one for each `ObservedProperty` instance.

## BhCollarThing, BhTrajectoryThing and Location

The DataStreams all link to the borehole via its `BhTrajectoryThing` object instance. `BhTrajectoryThing` (left edge of diagram) represents the borehole's geometry and contains the borehole length and information for linear referencing. The trajectory's geometry is given in the associated Location instance. `BhTrajectoryThing` is associated with a `BhCollarThing` instance, which represents the borehole as a whole. All general metadata about the borehole is contained in the `BhCollarThing` object instance; its geometry is represented by a point Location object instance.

More detail about properties of `BhCollarThing` and `BhTrajectoryThing` can be found in the Borehole log discussion.

## BhSampling and BhFeatureOfInterest

Sampling in the context of an SPT test or any in-situ test is the act of observing properties in a segment of the hole. The single `BhSampling` object instance (below and to the right of the `BhTrajectoryThing` in the diagram) holds the depth information of the test run (`fromPosition=1.5`, `toPosition=3`) and links to `BhTrajectoryThing` in order to affix the linear referenced sampling positions to the trajectory geometry.

`BhSampling` produces a `BhFeatureOfInterest` object, which represents the sampling location within the borehole (below the `BhSampling` object instance in the diagram).

## Observation

The remaining entities on the diagram are Observation instances that provide the results for their
associated observed properties. Each Observation instance links to the BhFeatureOfInterest (sampling location) and to the Datastream instance associated with the appropriate ObservedProperty.

This SPT test consists of 11 individual observations. Two of them (results for n_value and n1_60) are reported summary results that derive from the driveSet (blowCount and penetration) results that are observed directly during the test. The links shown in the diagram that relate observations to each other provide the means for distinguishing between the driveSet and summary/derived results.

Each driveSet increment is a set of three observation results. These results are useless independently - for example, the blowCount in a driveSet has no meaning without the associated penetration result for that drivesetIndex, and vice versa. To model the driveSet, the driveSetIntex result is linked to its associated blowCount and penetration results, and the blowCount result is linked to its associated penetration result. These three observations, as a set, contribute to the determination of the final n_value result, and to model that association, the driveSetIndex observations are linked to the n-value observation. In this way, one can traverse from the n_value observation to access those blow count and penetration observations that contributed to the n_value result.

Finally, the n1_60 observation instance is linked to the n_value observation instance to demonstrate that the n1_60 result relies on n_value.

To provide the most flexibility for querying, Datastream object instances associated with the Observations are linked in the same manner as their associated Observations, as seen in the diagram.

The current STA model does not provide for one-way links where an association role can be assigned. Such capability would be useful in modeling even more complex geotechnical test results.

### 5.5.4. Approach for Pressuremeter test

#### Principle

The principle of the test is to carry out an in-situ loading test, using an expandable cylindrical probe which is placed within the ground in a borehole. This probe, made up of three cells, is inflated with water and compressed air, thus exerting strictly uniform pressures on the wall of the borehole.

The strain of this wall are therefore accompanied by an increase in the volume of the probe which is then read, for each of the pressures, as a function of time. Thus, the pressuremeter allows to obtain a relationship between stress (applied pressure) and deformation (variation in the volume of water in the probe, directly linked to the strain of the soil).

Please note that unlike others in-situ test such as the CPT test, the pressuremeter test give «ponctual information», determined by the measurement step chosen by the experimenter. This measurement step is itself limited by the size of the probe, and it can be, generally, at least one meter or more.

The purpose and main interest of the pressuremeter test is to measure, through the same test
quantitative parameters of strength and deformation of the ground tested.

These parameters, calculated after the results of the test, are the following:

* _p_LM : Ménard pressuremeter limit pressure ;

* _p_f : p pressuremeter creep pressure ;

* _E_M : Ménard pressuremeter modulus.

These parameters could be used to do geotechnical calculations:

* Directly, through semi-empirical methods, example: foundation calculations; and

* Indirectly, through the determination of others geotechnical parameters, for example, the Young Modulus of the soil used in numerical approach, which can be obtained from the Menard pressuremeter modulus

Indirectly, it is possible to link these parameters to a lithology, in particular the couple _p_LM_ / E_M, which could be used in the Pressiorama® (Baud, 2005), NF-P 94-262 annex B.

<figure><img src="image_34.png" /><figcaption>Figure 34. Pressiorama® diagram (Baud, 2005, extracted from NF-P 94-262 annex B)</figcaption></figure>

Please note that the diagram is defined for a range of _p_LM_ up to 10 MPa, which corresponds to the actual application domain of the pressuremeter:

* _p_LM < 5 MPa : Range of values measurable by a « classic probe », corresponding to the values encountered in most soil type, to soft and weathered rocks.
* 5 MPa < _p_LM_ < 8 MPa: Range of values measurable by a « specific probe », corresponding to the values encountered in most soft and weathered rocks.

* _p_LM_ > 8 MPa: This range of values couldn't be measured with the actual equipment, and correspond to a rocky domain

In conclusion, keep in mind that the pressuremeter has a relatively wide range of application, from all types of soils to soft and weathered rocks. However, it could not be properly use for the characterisation of solid rocks.

## Equipment

The following is mostly extracted from the standard NF EN ISO 22476-4, which is about the Ménard procedure of the pressurometer test (the « classical » procedure). Please notice the existence of some variants of this procedure, depending principally of the way to instal the probe within the ground. These others specific procedures are exposed on the norms listed at the end of this page.

### 1. General description

The pressuremeter shown schematically in §2.2 shall include:

* the pressuremeter probe;

* the string of rods to handle the probe;

* the control unit (CU);

* The connecting lines between the control unit and the probe.

Some means of measuring the depth of the test with appropriate measurement error shall be provided.
<figure><img src="image_35.png" /><figcaption>Figure 35. Photograph of a pressuremeter set (extracted from https://www.apageo.com).</figcaption></figure>

## 2. Probe description

If expansion is followed by the volume of the measuring cell, the measuring cell shall be inflated by injecting a liquid of low compressibility. Alternatively air can be used to inflate the measuring cell and the expansion followed by displacement transducers.
<figure><img src="image_36.png" /><figcaption>a) Tri-cell probe, G type, with measurement of volume of the measuring cell</figcaption></figure>

<figure><img src="image_37.png" /><figcaption>b) Tri-cell probe, E type, with measurement of volume of the measuring cell</figcaption></figure>

<figure><img src="image_38.png" /><figcaption>c) Mono-cell probe, with measurement of radial displacement (optional)</figcaption></figure>

<figure><img src="image_39.png" /><figcaption>d) Tri-cell probe, with measurement of radial displacement</figcaption></figure>

Figure 36. Diagram of a Ménard pressuremeter (extracted from NF EN ISO 22476-4).

## Key

* 1a pressurization, differential pressurization and injection devices

* 1b pressure and volume measuring devices

* 1c acquisition, storage and printing out of the data (required for CU type B and C)

* 2 connecting lines:
  * 2a line for liquid injection

* 2b line for gas injection
* 3 depth measurement system 2b line for gas injection

* 4 rods

* 5 pressuremeter probe:

* 5a upper guard cell

* 5b central measuring cell

* 5c lower guard cell

* 6 ground

* 7 pressuremeter test pocket

* 8 hollow probe body

* 9 probe rod coupling

* 10 transducers

### 3. Pressure and volume control unit

The control unit shall include:

* equipment to pressurize, and so to inflate the probe, and to maintain constant pressures as required during the test;

* equipment to maintain an appropriate pressure difference between the central measuring cell and the guard cells, if relevant;

* device which permits, according to the type defined in Table 1, the reading and recording of the parameters to be measured: time, pressure and volume.

<table><caption>Figure 37. Types of pressuremeter control units (Extracted from NF EN ISO 22476-4).</caption><thead><tr><td>Type of control unit</td><td>Type of test regulation</td><td>Type of reading and recording</td></tr></thead><tbody><tr><td>A</td><td>manual</td><td>manual</td></tr><tr><td>B</td><td>manual</td><td>automatic</td></tr><tr><td>C</td><td>automatic</td><td>automatic</td></tr></tbody></table>

The control unit shall control the probe cell expansion and permit the simultaneous reading of liquid and/or gas pressures and injected liquid volume or radius of the measuring cell as a function of time.

The pressurizing device shall allow:

* reaching the pressuremeter limit pressure or a pressure p r at least equal to the maximum pressure defined for the test;

* holding constant each loading pressure level in the measuring cell and in the guard cells during the set time;

* implementing a pressure increment of 0,5 MPa in less than 20 s as measured on the control unit;

* controlling the pressure difference between the measuring cell and the guard cells;

* injecting a volume of liquid in the measuring cell larger than at least its volume at rest V c,
i.e. 700 cm 3 for a 60 mm pressuremeter probe.

If volumetric measurement is used, a valve between the volumeter and the pressure measuring device shall allow stopping the injection.

4. String of rod/connecting lines

Not described here, to have information regarding this subject, please consult the norm.

Test procedure

The test procedure will not be detailed her, to consult the exact procedure, please consult the
associate norm.

However, the principle is to establish a loading program in at least 8 to 10 steps, in which the volume of the probe increases, leading to a raising of the radial stress imposed to the ground. In each step, a constant stress is applied to the ground, during a certain time increment.

A template of loading program is exposed in the following figure, extracted from the norm.

<figure><img src="image_40.png" /></figure>

Key

p_t target pressures

Δp pressure increment

p_r pressure step during t_h

C loading phase
t time

Δtᵢ pressure increment duration

t_h duration of a pressure step

D unloading phase

<caption>Figure 38. Pressuremeter test procedure</caption>

## Results and interpretation

### 1. General

The application of the loading programme results in a raw pressuremeter curve. Some correction should be applied to this raw curve in order to avoid experimental biases. The corrections procedure are well detailed in the norm.

After this step, the corrected pressuremeter curve is used to calculate the pressuremeter parameters described above. A typical pressuremeter curve is presented in the figure below.

At least three data points in the second group of readings and three data points in the third group shall be available to determine all three parameters p f, p LM and E M.

If in a test, one group of readings is incomplete or missing, the following effects on the determination of the three parameters shall be considered:

* when the pressuremeter curve includes only the second and third groups of readings and with fewer than two data points in the second group, values of E M and p f cannot be obtained;

* when the pressuremeter curve includes only the first and second groups of readings (i.e. only one or no points in the third group), p LM and p f cannot be obtained.
<figure><img src="image_41.png" /></figure>

Key

1 first group of readings

2 second group of readings

3 third group of readings

<caption>Figure 39. Groups of pressuremeter readings</caption>

In the following, the methods of determination of the parameters will be synthesized to give a brief overview of the process, and may not be exhaustive. Please consult the norm to have the complete procedure of determination

## 2. Pressuremeter creep pressure $p_f$

If there are at least two sets of readings both in the second and in the third group, the creep pressure $p_f$ shall be estimated, using the following graphical analysis of the ($p, V$ 60/30) diagram: 2 straight lines shall be drawn on the ($p, V$ 60/30) graph, one involving the data points in the second group, the second one involving the data points in the third group, as illustrated on Figure D.4; the abscissa of the intersection of the 2 straight lines give $p_f$.
<figure><img src="image_42.png" /><figcaption>Figure 40. Pressuremeter creep pressure determination (Extracted from NF EN ISO 22476-4).</figcaption></figure>

### 3. Ménard pressuremeter limit pressure p LM

The Ménard pressuremeter limit pressure is conventionally defined as the pressure leading to the doubling of the initial volume of the pocket.

It can be either obtained by direct measurement or determined using extrapolation methods.

<figure><img src="image_43.png" /><figcaption>Figure 41. Ménard pressuremeter limit pressure, with reciprocal fitting and extrapolation method (extracted from NF EN ISO 22476-4).</figcaption></figure>

### 4. Ménard pressuremeter modulus E M

The Ménard pressuremeter modulus is defined as the modulus of the pseudo-elastic part of the
curve. The determination of this parameter should be done with great precaution and following the recommendation of the norm, that could not be detailed here.

<figure><img src="image_44.png" /><figcaption>Figure 42. Plot of a corrected pressuremeter curve, creep curve and slopes (Extracted from NF EN ISO 22476-4).</figcaption></figure>

Please note that the The Ménard pressuremeter modulus is not a Young Modulus of the tested soil. This Young Modulus could be calculated using the rheologic coefficient α, defined by Ménard, and depending on the soil type.

In addition, please note that the young modulus of soils depend on the strain level : it should be corrected to be properly use in geotechnical calculation.

<figure><img src="image_45.png" /><figcaption>Figure 43. Variation of the deformation modulus in function of the strain level (Reiffsteck 2002)</figcaption></figure>
<figure><img src="image_46.png" /><figcaption>Figure 44. Degradation laws E/EM = f(ε) (ARSCOP, 2017)</figcaption></figure>

## Normalization / Variants

There are different variants of this kind of geotechnical test, depending mostly on the probe type and on the method to insert this probe within the ground. These variants are described in the following norms :

* NF EN ISO 22476-4, septembre 2021, Index : P 94-521-4, P 94-521-4 : Geotechnical investigation and testing - Field testing - Part 4 : prebored pressuremeter test by Ménard procedure

* NF EN ISO 22476-5, French Standard approved and published by AFNOR, 2023-04-12 : Geotechnical investigation and testing - Field testing - Part 5: prebored pressuremeter test

* NF EN ISO 22476-6, octobre 2019, Index P 94-521-6, ICS : 93.020 : Geotechnical investigation and testing - Field testing - Part 6 : self boring pressuremeter test**

* NF EN ISO 22476-8, janvier 2018, Index : P 94-521-8, ICS : 93.020 : Geotechnical investigation and testing - Field testing - Part 8 : full displacement pressuremeter test

## Exposing Pressuremeter test with the FROST Geotech Plugin

### Sensor

The PressimeterTest instance has to be declared as a Sensor with a SensorType referring to its nature, eg. https://data.geoscience.fr/ncl/Proc/94
### ObservedProperty and DataStream

For each PressuremeterTest performed, one DataStream shall be declared per ObservedProperty.

### BhCollarThing and BhTrajectory

BhCollarThing and BhTrajectory shall be used to respectively describe the Borehole and its trajectory

### BhSampling and BhFeatureOfInterest

BhSampling enable to declare each depth at which a test has been performed. For example, if a test has been performed from the Depth 1m to the Depth 10m every 1m, then there shall be BhSamplings for the Depths = 1m, 2m, ..., 9m, 10m.

One BhFeatureOfInterest shall then be declared per Sampling.

As a PressuremeterTest is an in-situ test with ponctual measures (at depth), the BhFeatureTypes that shall be declared are: Hole & Point

### Observation and result

#### For interpreted or calculated values

In this case, there shall be one Observation and Result per combination of DataStream / FeatureOfInterest. For example, if there are 3 DataStreams (the different ObservedProperties) and 10 FeaturesOfInterests (the different depth), then there shall be 30 Observations declared.

#### For raw measurements

The Pressuremeter test imply several measurements of the same parameter at the same depth. Each measurement being associated to a step. In this case, there shall be for each FeatureOfInterest (the different depth) as much Observations as steps. For example, if the test imply 10 steps at one depth, then there shall be 10 observations associated to that depth. The number of the step shall be declared as a Parameter of the Observation.

### 5.5.5. Approach for Atterberg Limits

The collection of "Atterberg Limit" tests establish the moisture contents at which a fine-grained clay and silt soil sample transitions between behavior as a solid, semi-solid, plastic, and liquid material. Atterberg created a series of test procedures and definitions to provide reproducible results among soil samples. One of the principal uses of the system is to differentiate silty soils from clayey soils. The values obtained using the prescribed procedures can also be used to help characterize shrink-swell [expansive] soils, which are particularly problematic.

These values are important and common index tests in geotechnical engineering and are used to classify soils and compare the behaviors of different soils and relate soil plasticity behaviors to other performance qualities such as strength, stiffness, and permeability through empirical correlations. The tests are especially common for shallow foundations, roadway embankment construction, and pavement support. The tests are somewhat less common for deep foundation design and slope stability.
The tests are conducted on specimens taken from disturbed or undisturbed field samples and are usually conducted in a laboratory environment at a time following field sample acquisition, shipping, and subsequent lab extrusion or opening. The samples are remolded as part of the testing procedures; original intact samples are not required.

There are three (3) limits, each with a distinct corresponding laboratory test to establish the moisture content associated with a specific defined observed behavior of the sample. The tests are:

* The Liquid Limit (LL)

* The Plastic Limit (PL)

* The Shrinkage Limit (SL) *

The Shrinkage Limit test is less common and is not typically conducted or used in common soil identification and classification systems.

A calculated value, the Plasticity Index (PI), is included in the reporting of the Liquid Limit and Plastic Limit. The PI is the Liquid Limit minus the Plastic Limit, $PI = (LL - PL)$. Values of all parameters are reported in whole numbers.

Importantly, the commonly termed “Atterberg Limits” (generally including the LL, PL, and PI values) are used in several formal soil classification systems to determine classifications associated with plastic and non-plastic clayey and silty soils.

* A plasticity chart is available for the Unified Soil Classification System (USCS) which uses a soil's Plasticity Index (PI) and the Liquid Limit (LL) to determine its classification.

* The PI and LL are also used in the American AASHTO classification system used for highway construction. This system rates soils for their suitability for highway construction. Transportation and other agencies may have their own specifications with identification and classification systems.

The Liquid Limit (LL) is the water content at which the behavior of a clayey soil changes from the plastic state to the liquid state. Depending on the mineral composition, particle size, and nature of the pore fluid, the transition from plastic to liquid behavior occurs over a range of water contents. The definition of the liquid limit for geotechnical purposes is based on a standard test procedure developed by Arthur Casagrande. His standardized methods for determining the liquid, plastic, and shrinkage limits are used today.

Casagrande standardized Atterberg's original liquid limit test by developing a hand cranked (or motor driven) specialty apparatus with a brass cup and resilient base. A rotating cam mechanism creates a reproducible drop height of 10 mm. A mass of soil is placed into the brass Casagrande cup portion of the device. A groove created using a standardized tool through the center of the specimen. The cup is repeatedly dropped at a standard rate of 2 revolutions per second. During the process the soil groove closes gradually at the base, as a result of the impacts. The number of blows necessary for the groove to close 1/2-inch [13 mm] at 25 blows of the apparatus is desired.

The US Standard has both a single point and multipoint method to determine the Liquid Limit. Using the multipoint method, the test is progressively conducted at several moisture contents, and the moisture content which requires 25 blows to close the groove is interpolated from the test results. The single point test method also allows the use of a single test, where 20 to 30 blows are
required to close the groove. A factor, k, provided in the standard, is applied to obtain the liquid limit from the moisture content. Two specimens are required for the single point test, with the Liquid Limit (LL) reported as the average value of the tests, reported to the nearest whole number.

The Plastic Limit (PL) is determined by hand rolling a small mass of a soil sample, creating a roughly cylindrical “thread” of soil on a flat ground glass plate. Plastic behavior is exhibited if the soil thread retains its shape when rolled progressively thinner to a diameter of 1/8-inch [3.2 mm]. At this diameter the rolling is discontinued, and the same sample is remolded into a larger thread and the test procedure repeated, rolling the newly remolded thread to progressively smaller diameters. As the moisture content lessens due to evaporation and loss of moisture along the technician's hands and the glass plate, the thread will begin to break apart at larger diameters. At the point the thread can no longer be rolled into 1/8-inch [3.2 mm] thread, after having previously been rolled to that diameter, the test is considered concluded. The sample is collected and placed in a container with other tested samples until two specimen containers of at least 6 grams of material are obtained and the moisture content can be evaluated. The water content of the soil is measured using approved test methods. A soil sample is reported as non-plastic (NP) if a thread cannot be rolled out down to 1/8-inch [3.2 mm] at any moisture condition.

The Shrinkage Limit (SL) is the water content where additional loss of specimen moisture will not result in additional soil volume reduction. Determination of the shrinkage limit is a more involved, and far less common process than the other two limits. Information on test procedures is in the associated standards.

Final reported [calculated] properties are typically:

* Liquid Limit (LL),

* Plastic Limit (PL),

* Plasticity Index (PI), and in much less frequent cases,

* Shrinkage Limit (SL)

Values are in whole numbers, unless the test result is that the soils are non-plastic, in which case rather than the numeric values a classification of “NP” is assigned.

Reporting of the final test values*, following application of the defined test procedures, is generally straightforward. Calculated result values are expressed as whole numbers. Unlike the SPT test, values for Plastic Limit (PL), Liquid Limit (LL) and the calculated Plasticity Index (PI) are generally well-behaved numeric data without non-numeric possibilities, other than the potential outcome of a non-plastic (NP) soil. If either the liquid limit (LL) or plastic limit (LL) could not be determined, or if the plastic limit is equal to or greater than the liquid limit, the soil is designated non-plastic (NP).

It is common to have these test results reported in conjunction with other test results from a single extracted soil sample (such as moisture content, direct shear, and unconfined compression) and a soil description- often obtained from grain size analysis and Atterberg Limits testing. Different specimens (subsets of the sample) are prepared for each type of testing.

*Typically, only final calculated values are reported and transmitted in log formats. Original measured values, calculations, and interim testing information is usually preserved in the original test records but not included as part of geotechnical design memoranda (although it could appear
in comprehensive report appendices). The information may be included in geotechnical data reports which may contain complete field and laboratory testing data.

The applicable US Standard is ASTM D4318-17e1 Standard Test Methods for Liquid Limit, Plastic Limit, and Plasticity Index of Soils The applicable US Standard is ASTM D4943-18 Standard Test Method for Shrinkage Factors of Cohesive Soils by the Water Submersion Method

## Exposing Atterberg limits with the FROST Geotech Plugin

To demonstrate how the final results, interim test information and related metadata are stored and organized within the FROST server, we offer the following example Atterberg limits test for a single sample. Relevant data are:

### GENERAL TEST INFORMATION

1. Test procedure used: ASTM D4318-17, Method A (multipoint method)

2. Name of sample tested: 1

3. Sample location: Collected from a depth of 1.5 to 3 ft from borehole B-001-0-20

4. Borehole is 41 ft deep and its collar is located at lat/lon 39.47466/-81.796858, elevation 249.50928 meters (WGS84)

5. Device used to collect sample: Geoprobe Interlocking Split-spoon sampler

6. Length of sample recovered from the hole: 1.08 ft (72% recovery).

7. Specimen preparation method: Wet Preparation Method described in Sec. 10.1, ASTM Standard D4318-17

8. Weight of specimen prior to testing: 65 grams, wet weight.

### CASAGRANDE TEST RESULTS FOR DETERMINING LIQUID LIMIT

<table><thead><tr><td>Increment Number</td><td>Blow Count</td><td>Water content (%)</td></tr></thead><tbody><tr><td>1</td><td>16</td><td>35.2</td></tr><tr><td>2</td><td>22</td><td>28.6</td></tr><tr><td>3</td><td>27</td><td>23.1</td></tr><tr><td>4</td><td>32</td><td>17.4</td></tr></tbody></table>

### PLASTIC LIMIT WATER CONTENT MEASUREMENTS

<table><thead><tr><td>Increment/Container Number</td><td>Water content (%)</td></tr></thead><tbody><tr><td>1</td><td>11.9</td></tr><tr><td>2</td><td>11.7</td></tr><tr><td>3</td><td>11.4</td></tr></tbody></table>

Note: A third trial was run because of concerns that the second container was not properly sealed before measurement
# FINAL REPORTED RESULTS

* Liquid limit: 25

* Plastic limit: 12

* Plasticity Index: 13

## Instance Diagram

Object instances and the associations required to properly expose the example test data with the FROST Geotech Plug-in are shown in the following instance diagram:

<figure><img src="image_47.png" /><figcaption>Figure 45. Atterberg Object Diagram</figcaption></figure>

The following summarizes the various entities in the diagram:

### Sensor

The Sensor object serves as the observing procedure in STA. One object instance is needed for this example (top center of diagram), and in this example holds the information about the test procedure used. One Sensor instance is needed for Atterberg limits tests and the test procedure is specified in its sensorType property and fully referenced in its metadata property. As constructed, this Sensor instance can be reused for multiple Atterberg tests.

### ObservedProperty

The ObservedProperty object instances identify the properties that are observed by the Atterberg limits test. There are eight ObservedProperty instances (top of diagram, below Sensor):

**3 properties observed that constitute the final reported results of the test:**

1. liquid_limit
2. plastic_limit

3. plasticity_index

**3 properties observed for the Casagrande (liquid limit) measurements:**

4. manualCasagrandeTrialNumber (the Increment Number column in the above table)

5. blowCount

6. waterContent

**2 properties observed for the plastic limit measurements:**

7. manualPlasticLimitTrialNumber (the Increment/Container Number column in the above table)

8. plWaterContent

*Note: The plWaterContent observed property is not necessary (and probably should not be used) as it is identical to waterContent, but is included in this example to better distinguish the water contents determined for liquid limit from those for plastic limit*

As with Sensor, the ObservedProperty instances can be reused for multiple tests.

## DataStream

All of the object instances in the diagram are linked to the Sensor and ObservedProperty instances via Datastream instances (below the ObservedProperty objects on the diagram), which serve to associate observation results obtained from a feature of interest to its observed property, observing procedure, and the borehole.

Eight Datastream instances are needed, one for each ObservedProperty instance.

*Note: if the plWaterContent ObservedProperty were not used, there would still need to be 8 Datastream instances. Two DataStreams would link to the waterContent ObservedProperty instance. One of these DataStreams would link to the liquid limit water content Observation instances, the other to the plastic limit water content Observation instances.*

## BhCollarThing, BhTrajectoryThing and Location

The DataStreams all link to the borehole via its BhTrajectoryThing object instance. BhTrajectoryThing (left edge of diagram) represents the borehole's geometry and contains the borehole length and information for linear referencing. The trajectory's geometry is given in the associated Location instance. BhTrajectoryThing is associated with a BhCollarThing instance, which represents the borehole as a whole. All general metadata about the borehole is contained in the BhCollarThing object instance; its geometry is represented by a point Location object instance.

More detail about properties of BhCollarThing and BhTrajectoryThing can be found in the Borehole log discussion.
## BhSampling and BhFeatureOfInterest

The act of collecting a sample from the borehole for testing is represented by the single BhSampling object instance (below and to the right of the BhTrajectoryThing in the diagram). BhSampling holds the sample depths (fromPosition=1.5, toPosition=3) and links to BhTrajectoryThing in order to affix the linear referenced sample positions to the trajectory geometry. In addition, BhSampling also links to a BhSampler object instance which identifies the type of sampler used in the sampling act (eg. the Geoprobe split-spoon sampler).

BhSampling produces a BhFeatureOfInterest object, which represents Sample 1 that is collected from the borehole (below and to the right of the BhSampling instance object). This object holds the sample length and recovery percentage of the sample. That this BhFeatureOfInterest is a physical material sample from the borehole is given by the associated BhFeatureType Core and Segment instances.

As part of the Atterberg limits test procedure, a 65 gram specimen of Sample 1 is prepared using the “Wet method”. This is represented by an additional BhFeatureOfInterest object instance linked to Specimen, Core and Segment feature types. The linked BhPreparationStep object instance holds the specimen weight, and the further linked BhPreparationProcedure object carries the procedure method used to obtain the specimen.

## Observation

The remaining entities on the diagram are Observation instances that provide the results for their associated observed properties. Each Observation instance links to the prepared specimen that was tested and to the Datastream instance associated with the appropriate ObservedProperty.

This Atterberg limits test consists of 18 individual observations but only three of them (results for liquid limit, plastic limit and plasticity index) are the primary reportable results. The other observations are interim observations, made as part of the test procedure, that result in the determination of the primary results. The links shown in the diagram relating observations to each other provide the means for distinguishing among the various types of observations.

Starting with the Observation instances associated with the Casagrande liquid limit measurements, each test increment is a set of three observation results. These results are useless independently - for example, the blow count in a Casagrande trial has no meaning without the associated water content observation, and vice versa. To model the observation set, the increment result is linked to its associated blow count and water content results, and the blow count result is linked to its associated water content result. These three observations, as a set contribute to the determination of the final liquid limit result, and to model that association, the increment observations are linked to the liquid limit observation. In this way, one can traverse from the liquid limit observation to access only those blow count and water content observations that contributed to the liquid limit result.

A similar link structure is also made for the interim water content observations that contribute to the plastic limit result.

Finally, the plasticity index observation instance is linked to both the liquid limit and plastic limit observation instances to demonstrate that plasticity index relies on those values for its results.
Note that the liquid limit and plastic limit observation instances are correctly not linked to show
that those results are derived independently from each other.

To provide the most flexibility for querying, Datastream object instances associated with the
Observations are linked in the same manner as their associated Observations as seen in the
diagram.

The current STA model does not provide for one-way links where an association role can be
assigned. Such capability would be useful in modeling even more complex geotechnical test results.

5.5.6. AGS & DIGGS mapping to STA

This chapter provides a road map for how to map AGS and DIGGS data to the OGC SensorThingsAPI
data model.

Overview of the AGS format / data organization

The AGS format is a data transfer format for ground data that is routinely used in the United
Kingdom. It has also been adopted and adapted for use in some other countries including Hong
Kong and Australia.

AGS was created and is maintained by the Association of Geotechnical and Geoenvironmental Specialists, a UK based industry organization. Documentation can be found here.

The scope of the AGS data transfer format is limited to factual ground investigation data (typically
'Book A' data, adopting the terminology used in this Wiki). However, interpretative/design data and
ground models are covered by AGSi, a separate relatively new transfer format created by AGS.

The AGS data transfer format adopts a CSV-like format for output. The data structure does not adopt
an object model approach as such, but is broadly comparable comprising Groups (-> objects /
database tables) and Headings ( -> attributes / table fields) and utilizing parent-child relationships
between groups. The AGS 'data dictionary' is very comprehensive, covering almost all field and
laboratory test data that may be published in a factual ground investigation report. There are about
150 Groups and over 2000 Headings.

AGSi (for ground models and interpretative/design data) is object model based and the output is
JSON. AGSi adopts a concise but very flexible data model. It does not include schema for complex
geometry, instead allowing users to adopt existing standards for model geometry.

Overview of the DIGGS format / data organization

DIGGS is an XML-based schema and associated dictionaries for the storage and transfer of the
properties of real-world objects and activities, and their associations, that occur within the
geotechnical and geoenvironmental domains. DIGGS is designed as a GML application schema
insofar as all objects within the DIGGS namespace derive from GML abstract types and encoding
follows GML's object-property convention. Additionally, it incorporates GML 3.3 objects to support
linear referencing for linear sampling features like boreholes, and vector linear referencing for 2D
and 3D objects. DIGGS also relies on another XML vocabulary, WITSML, developed for the oil
industry, for measure types and units symbology which allows for schema validation of unit
symbols for measure type properties.
DIGGS has been adopted as the “Provisional Standard Practice for Digital Interchange of Geotechnical Data” by AASHTO. It builds off of the AGS data dictionary for its test procedure objects, but is capable of handling more complex sampling feature geometries, testing and sampling protocols, and construction activities.

<figure><img src="image_48.png" /><figcaption>Figure 46. Generalized DIGGS data model showing the major object classes. These classes are of abstract type and they serve as the head of substitution groups that allow for specialized concrete features.</figcaption></figure>

The DIGGS data model consists of a set of object classes that share some similarity, conceptually, with OMS objects. Most relevant to interfacing with OGC's Geotech efforts are:

**SamplingFeature** - A physical object or location through which we observe or measure properties of an investigation target, or perform some type of activity. It serves to define the dimensionality, extent, and local spatial reference system for zones where observations or activities take place. DIGGS has developed a number of concrete sampling feature types, including Borehole, Sounding, TrenchWall.

**SamplingActivity** - The action taken to obtain or produce a material sample, even if the activity does not produce a sample (eg. a core run that produces no recovery). This activity typically occurs at a location on a sampling feature, or could occur elsewhere (eg. a laboratory) in the case of test or blank samples, or can produce aggregate samples where the location of the samples produced have no meaning. All material samples must refer to a SamplingActivity.

**Sample** - A material sample, solid, fluid, or gas that is obtained as a result of a sampling activity, for the purpose of observation and/or testing.

**Measurement** - An observation where the result derives principally from the use of testing equipment and/or sensors. Results are typically objective with high precision results as long as procedures are followed and equipment is operating appropriately. Results are usually numeric
values, although category assignments can be calculated from numeric results.

**Observation** - An observation where the result derives from direct human interaction, judgment or analysis. These results are typically subjective; and often category based. Typical observation results are descriptive, interpretive, or involve generalization or modeling.

DIGGS' distinction between observations and measurements has resulted in these two object classes to be structurally quite different. DIGGS measurements are structured such that measurement components (results, observed properties, features of interest) map in a fairly straightforward way to the OGC SensorThings API data model extension for Geotechnics. Mapping DIGGS observation results to the OGC SensorThings API data model poses more of a challenge although quite feasible.

## Mapping information

Mapping from the various AGS and DIGGS formats to a proposed harmonized GeoTech Model can be illustrated by the following mapping to STA.

### Mapping from AGS data

AGS data can be mapped to the STA data model by adopting the following general rules:

For field observations/in situ tests:

* Nature of observation/test, e.g., SPT = Sensor: name = AGS Group, e.g., ISPT

* LOCA_ID = BHCollarThing: name

* Depth (e.g., to test):
  * BHSampling: from/to, and

* BHFeatureOfInterest

* fields providing metadata about the test or observation = Sensor: properties comprising a JSON object that uses the AGS Headings as keys

* other data, i.e., results = Observation:
  * result from the DataStream that has as ObservedProperty: name = AGS Heading, e.g., ISPT_NVAL

Geology information (GEOL, DETL) and borehole field observations (e.g., PTIM, CHIS) also adopt this general approach.

Note that BHSampling is used for both insitu and lab test, despite in situ tests not using sampling as such.

For a lab test, the mapping is similar to the above but with the following differences: - BHSampling along with BHSampler and BHSamplingProcedure are be used for the sample (SAMP data) - BHFeatureOfInterest used for the specimen (defined in lab test results in AGS) but note that it is not currently possible to map the specific from/to depths of the specimen reported by AGS data.

Where there is a set of 'child' readings within a 'parent' result, e.g., compaction test points (CMPT) within a compaction test (CMPG) then the results for each point are provided as sets of
RelatedObservations where the first Observation would logically be the test/point number.

The approach described here is in keeping with the intent of SensorThings. However, there is a
difficulty in practice as a judgement has to be made about whether a field represents test metadata
or a test result. Sometimes this is obvious, but quite often it is not and this introduces the risk of an
inconsistent in approach between users. This could be addressed by the publication of an official
mapping, but it would be an onerous tasks to cover the entire AGS data dictionary as no such thing
exists at present. Applications would also need to be able to deal with this programmatically.

An alternative approach would be to map all metadata as results, i.e., everything is treated as an
Observation. This would make implementation easier, for both loading and querying data.
However, it is not true to the intent of the SensorThings model.

Mapping from DIGGS data

Sample XML instances with proposed mapping of elements to the SensorThings API objects are
provided here for DIGGS Test objects (a type of DIGGS measurement) for CPT, SPT and Atterberg
limits tests. Although some effort has gone in to mapping a limited portion of DIGGS'
ObservationSystems for category-based data to STA (specifically for Lithology observations),
considerably more effort is needed. These observations ,as well as mapping to additional test types
such as compaction tests, and triaxial tests will continue to be developed.

As can be seen from the mapping examples, the DIGGS Test object, which handles all in-situ and
laboratory based measurements that are not time-domain measurements (those are handled in a
similarly structured Monitor object) are comprised of three main components 1. Measurement
metadata with time of test and roles 2. Outcome, which further is subdivided into: Location and
 ResultSet objects. The Location object carries the feature of interest's location information while the
 ResultSet holds the observed properties and observation results. 3. A procedure property that can
 hold any number of Procedure objects that describe how the test was performed but also contain
 metadata and interim observations that are procedure-specific.

In general, for the Test object:

* Test metadata properties will map to Sensor, unless the same information is provided in the procedure object;

* Location information will map to BhSampling and BhFeatureOfInterest;

* ResultSet properties map to Observed Property and Datastream (for units of measure);

* ResultSet datavalues property maps to Observation; and

* Procedure object maps to Sensor, except for included interim observations, where those elements will map to ObservedProperty and Observations.

As for other DIGGS objects:

* DiGGS linear sampling features such as boreholes and soundings map to properties in BhCollarThing, BhTrajectoryThing and the associated Location object;

* DIGGS SamplingActivity maps to BhSampling and BhSamplingProcedure;

* DIGGS Sample maps to BhFeatureOfInterest; and
* DIGGS Specimen objects map to BhFeatureOfInterest.

### 5.5.7. STA endpoints

#### Fraunhofer Endpoint

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-GeoTech/v1.1/

#### BRGM Endpoint

https://frost4geotech.brgm-rec.fr/FROST-Server/v1.1/

### 5.5.8. Play with the FROST Geotech plugin

The SensorThings API has very powerful query features that keep easy things easy, but still allow very complex requests. A good starting explanation on how to query the SensorThings API can be found at the Getting Data section on the FROST-Documentation website.

This page is about relevant queries you may do with the FROST Geotech plugin

#### Simple queries

##### Lists

The simplest queries are those that fetch a list of all entities of a type. For instance, getting a list of all the geotechTests (Mapped to Sensor in STA):

https://[FrostGeotechServerAddress]/v1.1/Sensors

Or to get all borehole collars:

https://[FrostGeotechServerAddress]/v1.1/BhCollarThings

##### Single Entities

To get a single entity from a list, add `<id>` to the URL of the list. To get the geoTechTest (Sensor) with id 1:

https://[FrostGeotechServerAddress]/v1.1/Sensors(1)

Or to get the borehole collar with id 42:

https://[FrostGeotechServerAddress]/v1.1/BhCollarThings(42)
## Related Lists

To get a list of entities related to a certain entity, one can navigate along relations. For instance, to get all Datastreams for Sensor (geoTechTest) with id 1:

https://[FrostGeotechServerAddress]/v1.1/Sensors(1)/Datastreams

Or to get the Trajectories related to borehole collar 1:

https://[FrostGeotechServerAddress]/v1.1/BhCollarThings(1)/BhTrajectoryThings

Or to get the Datastreams related to a Trajectory 1:

https://[FrostGeotechServerAddress]/v1.1/BhTrajectoryThings(1)/Datastreams

And from there, to get the Observations related to a Datastream 1:

https://[FrostGeotechServerAddress]/v1.1/Datastreams(1)/Observations

## Filtering Lists

All lists can be filtered using the filter parameter. To get a list of all the geotechTests that are of type CPT (sensorType https://data.geoscience.fr/ncl/Proc/86):

https://[FrostGeotechServerAddress]/v1.1/Sensors?]filter=sensortype eq
'"https://data.geoscience.fr/ncl/Proc/86"'

## More complex queries

Get the results of the available DataStreams associated to my Geotechtest organised this way :
(Depth, Result for property 1, Result for property 2, ...)

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-
GeoTech/v1.1/BhTrajectoryThings(9)?
$select=name& $expand=BhSamplings( $orderBy=atPosition;
$select=atPosition,time; $expand=BhSamples( $top=1; $select=name;
$expand=Observations( $top=3; $selectresult,phenomenonTime;
$expand=Datastream( $select=unitOfMeasurement; $expand=ObservedProperty(
$select=name ) ) ) ) )

Get this same result in csv

_Currently not possible unfortunately, but plans to add this functionality are in_
place.

Get the CPT tests in this perimeter that match this lithology (Rock)

Given that BhTrajectoryThings(9) is the trajectory with the CPT test:

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-GeoTech/v1.1/BhTrajectoryThings(9)/BhSamplings?
$filter=BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplings/BhSamples/Observations/result
eq ``Rock'' and atPosition gt
BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplingsFROMPosition
and atPosition lt
BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplings/TOPosition

Get the results of those same CPT tests

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-GeoTech/v1.1/BhTrajectoryThings(9)/BhSamplings?
$filter=BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplings/BhSamples/Observations/result
eq ``Rock'' and atPosition gt
BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplingsFROMPosition
and atPosition lt
BhTrajectoryThing/BhCollarThing/RelatedBhCollarThings/BhTrajectoryThings/BhSamplings/TOPosition&
latexmath:[expand=BhSamples() expand=Observations) ``

## 5.6. Semantics for geotech

Controlled vocabularies are a key component of interoperability to ensure each terms are non ambiguous.

In geotechnics, multiple controlled vocabularies can be set. This includes: - Procedure: this is to indicate a particular method or technic that have been applied to get a result, - Observable Property: this is to indicate which parameter was measured or observed, - Units of measurements: this is to characterize the (generally numerical) value that come with the result.

### 5.6.1. Registries

Several registries already exist and may help you to describe the test you made.
## BRGM GeoScience Linked Data Registry

https://data.geoscience.fr/ncl/?lang=en

Codelist for Methods, as described in *ObservingProcedure*: https://data.geoscience.fr/ncl/Proc?
lang=en

Codelist for Observable Properties, as described in *ObservableProperties*: https://data.geoscience.fr/
ncl/ObsProp?lang=en

## GeoScience EU Registry

https://data.geoscience.earth/ncl/

## 5.6.2. DIGGS Dictionaries/Schemas

**Observation Procedures:** For DIGGS measurements (observations with numerical results), procedures are defined in the XML schema as concrete objects (XML elements of complex type) that derive, ultimately from gml:AbstractGMLType. These objects are defined in the following schema file: https://www.diggsml.org/schemas/2.5.a/Geotechnical.xsd.

For DIGGS observations (category-based results), the observing procedure can be described using a Specification object for the entire ObservationSystem (a collection of observations of the same class), although this does not require a controlled term, or by using the howDetermined attribute of an individual Observation (see: https://diggsml.github.io/index.html#DescriptorMethodEnumType).

**Observed Properties:** For DIGGS measurements (observations with numerical results), observed properties are defined in an XML dictionary file: https://www.diggsml.org/dictionaries/DIGGSTestPropertyDefinitions.xml

For DIGGS observations (category-based results), observed properties are hard-coded XML elements, dependent on the class of observation. These can be found in the following schema file: https://www.diggsml.org/schemas/2.5.a/Kernel.xsd.

**Units of Measurement:** All DIGGS elements of measure type (consisting of a numerical value plus a unit of measure) use units symbology defined in the Energistics Units of Measurement dictionary described here: https://www.energistics.org/energistics-unit-of-measure-standard.
# Chapter 6. Conclusions and future work

## 6.1. Plans for Future Work

"Paths are made by walking" - Franz Kafka

### 6.1.1. GeoSciML Update

The O&M based GeoSciML was last updated to V4.1 in 2017. This standard should be revisited in light of the developments in both O&M (updated to OMS) as well as the use of SensorThings API.

### 6.1.2. GroundWaterML2 Update

While GroundWaterML (OGC WaterML 2: Part 4 - GroundWaterML 2 (GWML2)) was last updated in 2019, this was before the introduction of OMS. Revisiting this standard in order to integrate the new concepts from OMS would be valuable.

### 6.1.3. JSON-LD Context for properties

Adding JSON-LD features to the SensorThings API has been a feature request for a long time, but making the entire API compatible with JSON-LD is not likely to happen very soon. A possible intermediate approach may be to add a JSON-LD context to the properties of each entity type. This won't make the entire response JSON-LD compatible, but may help with interpreting the free-form properties objects available in the SensorThings API.

### 6.1.4. Thing vs. FeatureOfInterest

In this edition of the GeoTech IE (assuming there will be more) borehole collars and trajectories are mapped to Things, while all samples are mapped to FeatureOfInterest. Although this split works, it is not ideal, and thus in the WaterQuality IE an experiment is being done with mapping all domain features into the FeatureOfInterest entity type, together with a new FeatureType entity type. This moves slightly further away from the STA core model, but results in a cleaner model and is currently considered as a basis for the SensorThings API version 2.0.

The Sampling, Sampler, SamplingProcedure, PreparationStep and PreparationProcedure entity types from this GeoTechIE have been taken up and improved by the WaterQualityIE, and are very likely to also be adopted as standard extensions to the SensorThings API v2.0.

The many extra self-relations that were added to many entities (RelatedBhCollarThings, RelatedDatastreams, RelatedObservations and RelatedFeatures) have also been improved upon in the WaterQualityIE and will most likely also be added as a standard extension to version 2 of the SensorThings API.

### 6.1.5. Geophysics, Profiles and 2D sections, 3D subsurface models

This work was mainly semantic focused with the principal intention to harmonize geotech concepts. A next focus should be made on the provision of geometry, including notably the capacity to share and query cross sections and 3D models. This topic, as well as Geophysics are in discussion
as possible new activities of the OGC GeoScienceDWG.

### 6.1.6. Semantic transposition

OMS allows for provision of explicit information on observational or measurement data, providing detailed information on how these observations were created. Such additional measurement metadata is essential in order to determine if a specific dataset is fit for purpose within a specific use case. However, the complexity of the underlying data models can make interaction with OMS based systems difficult for inexperienced users, who can easily get lost in the many options. Based on these reflections, we came to the insight that within individual use cases, there are often two very different user groups interacting with OMS data: - Thematic experts analyzing the data for usefulness within the UC. These experts require access to the full complexity of the underlying OMS data model to understand if the data being provided is truly fit for purpose. - Data analysts or developers utilizing an already vetted dataset no longer need the details provide by the OMS model, for their purposes all they need is a geometry and some numbers, as shown in the example below.

```json
{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [
      125.6,
      10.1
    ]
  },
  "properties": {
    "O3": {
      "value": 24.3,
      "uom": "mg/L"
    },
    "NO2": {
      "value": 16.8,
      "uom": "ppb"
    }
  }
}
```

The challenge in such a transformation pertains to how to transfer the content of the ObservableProperty (name="O3" or name="NO2") to the data structure of the simplified view, as this is transferring information from data content to structure. For this purpose, the term "Semantic Transposition" has been coined, defined in View points on data points: A shared vocabulary for cross-domain conversations on data and metadata

Within the current work on updating SensorThings API to V2.0, integration of Semantic Transposition will be investigated.
### 6.1.7. Simple import options for complex models

In order to enable simple import to the complex models defined utilizing OMS and STA, once the structure for standard tests has been defined, simplified tools enabling data providers to easily provide their data must be investigated. Simple wizards could be of great help in enabling data provision.

### 6.1.8. Tabular options for complex models

Related to the points above on Semantic Transposition and simplified import, a further approach to simplified interaction with STA endpoints pertains to tabular views. This approach can be useful both in provided data as well as accessing data.

* On data provision, work is ongoing at the European Environment Agency (EEA) on how to enable provision of OMS data via tabular views, especially in cases where most of the observational metadata has default values, as common under reporting obligations (e.g., the UoM and measurement methodology are predefined.

* On data access, once the observational metadata has been checked by the relevant experts, a simple tabular download format would be valuable for further analysis as well as portrayal.

### 6.1.9. Visualization options for results

Within this IE, the focus was on utilizing the OMS model as well as the STA implementation for sharing of borehole data. A next step involved implementing various visualization options for better access to the retrieved data.