Geotech Interoperability Experiment (IE)

• Geotech IE is a comprehensive initiative defining a minimal conceptual model to harmonize geotechnical data standards like GeoSciML, IFC, and SensorThings.
• It establishes formal mappings, robust serialization approaches, and validation protocols that enable seamless exchange and integration of diverse geotechnical datasets.
• The experiment supports digital geotechnics by integrating BIM and digital twin technologies, validated through extensive field, laboratory, and pilot studies.

The Geotech Interoperability Experiment (IE), coordinated under the auspices of the Open Geospatial Consortium (OGC), is an international initiative to establish a minimal, rigorous conceptual model for geotechnical engineering data that is compatible across existing OGC and buildingSMART International (bSI) standards, including but not limited to GeoSciML, GroundWaterML2, LandInfra/InfraGML, INSPIRE, and IFC. The principal objective is to bridge disparate specifications for describing factual data (site investigation), geological-interpretive, and design-reporting information pertaining to subsurface conditions and geotechnical structures. The OGC Geotech IE defines classes, formal mappings, serialization approaches, and validation results, and articulates critical challenges and future work items to serve digital geotechnics in the context of Building Information Modeling (BIM), Digital Twins, and cross-domain infrastructure projects (Beaufils et al., 11 Dec 2025).

1. Conceptual Model Structure

The Geotech IE conceptual model (detailed in Chapters 3 and 3.1–3.7) introduces a rigorously scoped suite of entities, their attributes, and relationships capable of capturing factual, interpretive, and design-centric geotechnical data (corresponding respectively to “Book A”, “Book B”, and “Book C” data categorization).

1.1 Core Classes

• Borehole: Central to site investigation, characterized by id, name, drillingMethod, collarGeometry (GM_Point), trajectoryGeometry (GM_LineString), startDate, and endDate. Relationships include 1:1 links to “Thing” instances for collar and trajectory, as well as association with 0..n samplings and observations.
• TrialPit: Analogous to Borehole, with linear referencing along the pit base.
• MaterialSample: Defined with id, name, source, and associatedFile; explicit lineage via derivedFrom permits representation of sub-sampling (e.g., split-spoon, core specimen).
• Observation (per OGC OMS/ISO 19156): Attributes include phenomenonTime, procedure, observedProperty, featureOfInterest, result (of any type), resultQuality, and validTime.
• ObservingProcedure: Codifies the procedure, with type flavors: in-situ, ex-situ, laboratory.
• ObservableProperty: Identifies measured or derived variable, registered by URI.
• SamplingFeature (inherits: Borehole, BoreholePoint, Core, CorePoint, etc.): Implements position via linear referencing.
• GeologicUnit, Fault, Fold, Contact: All derived or mapped from GeoSciML specification and supporting multiple geological semantics.
• HydroGeoUnit, FluidBody, FluidBodySurface: Adopted from GroundWaterML2 for hydrogeology; include key hydraulic and chemical properties.
• GeotechUnit: Specialization of GeologicUnit, introducing geotechnical properties (e.g., cohesion $c$, friction angle $\phi$, compressibility $C_c$, etc.).
• DiscreteDiscontinuity, Void: Capture major discontinuities and pore features relevant to engineering design.
• HazardArea, RiskZone: Natural risk and hazard representations following INSPIRE metaphors and semantics.

1.2 Formal Definitions (LaTeX)

Key geotechnical concepts are defined with universally recognized formulae:

• Gravimetric water content:

$w = \frac{m_w}{m_s}$

• Bulk density:

$$\rho_b = \frac{m_t}{V_t} \,,\;\rho_s = \frac{m_s}{V_t} \,,\;\rho_w = \frac{m_w}{V_t}$$

• Effective stress (Terzaghi):

$\sigma' = \sigma - u$

• Plasticity Index (Atterberg):

$PI = LL - PL$

• Compression index:

$$C_c = \frac{e_2 - e_1}{\log(\sigma_2) - \log(\sigma_1)}$$

• Ménard pressuremeter limit pressure:

$V(p_{LM}) = V_0 + 2V_0$

• Linear referencing for spatial features:

$L(s):= \{ x \in \mathbb R^n \mid x = L_p(s) \}$

2. Standards Mapping and Interoperability

Interoperability mandates explicit mapping to international standards, enabling cross-domain federation and machine-actionable data exchange:

Geotech IE Concept	GeoSciML/GSML	OGC/ISO	IFC / bSI	Other
Borehole	<gsml:Borehole>	OMS/SamplingFeature †	IfcBorehole (IFC4.4)	AGS LOCA, DIGGS:Borehole
TrialPit	<gsml:TrialPit>	OMS/SamplingFeature	IfcBorehole (alias)	AGS LOCA, DIGGS:TrialPit
MaterialSample	<oms:MaterialSample>	OMS/Sample	IfcMaterialSample	AGS SAMP, DIGGS:Sample
Observation	<om:Observation>	OMS/Observation, STA Obs.	IfcGeoscienceObs.	DIGGS:Measurement
…	…	…	…	…

† Any SamplingFeature may be instantiated by SensorThings Thing+Location.

2.1 Example Mappings

GeoSciML ↔ IFC (GeologicUnit)

• GeoSciML:

  <gsml:GeologicUnit gml:id="GU-001"> <name>Alluvial Deposit</name> <geologicUnitType>lithostratigraphic unit</geologicUnitType> <representativeLithology_uri>...</representativeLithology_uri> <shape>...</shape> </gsml:GeologicUnit>

• IFC (STEP format):

  #201 = IFCGEOGRAPHICELEMENT('GU-001',...) #203 = IFCSHAPEMODEL('Alluvial',#304);

• Mapping Synopsis:

| GeoSciML Property | IFC Entity/Property | |-------------------------|-----------------------------------------| | id | OwnerHistory; GUID | | name | IFCLabel (#label_) | | geologicUnitType | IFCClassification (RelAssociatesClass.) | | representativeLithology | usesIfcMappedItem | | shape | IfcSurface / IfcShell |

SensorThings ↔ IFC (Borehole)

• STA JSON:

  { "name": "BH-AMG-01", "description": "Borehole AMG-01 collar", "position": { "type": "Point", "coordinates": [4.860, 45.778, 300.0] }, "Project": { "@iot.id": 5 } }

• IFC snippet:

  #150 = IFCBOREHOLE('','','','vertical','in-situ',#46,...,'completed');

• Property mapping is direct for name, description, and geometric placement.

3. Serialization and Encoding Approaches

The Geotech IE supports and validates multiple serialization paradigms:

• GML/XML (ISO 19136): Direct mapping of conceptual schema to GeoSciML, GWML2, and INSPIRE GML. Enables inclusion of spatial geometries, attributes, and relationships as XML elements and attributes.
• GeoPackage (OGC 18-000): Relational encoding with vector tables for entities such as borehole collar, trajectory, and associated observations. Example schemas are provided for direct implementation.
• SensorThings API / JSON: For streaming and high-volume observational data, core JSON and pseudo-JSON-LD encodings support Observation, Thing, Datastream, and FeatureOfInterest structures.
• INSPIRE GML: For regulations-compliant hazard and risk zone representation.
• IFC STEP-file: For inclusion in BIM and interoperability with digital twin authoring and viewing tools.

Consistent round-trip conversion mechanisms (GML↔JSON↔GeoPackage) are validated for information fidelity.

4. Validation, Experimentation, and Real-World Use Cases

4.1 Borehole Interoperability Experiment

Conducted 2018–2024, the experiment federated borehole and observational data across GeoSciML, IFC, SensorThings, AGS, and DIGGS, producing:

• Unified UML class models
• Public GML/XML schemas/examples
• FROST-server Geotech plugin for JSON/STA delivery
• Detailed implementation guidance

Validation outcomes include cross-comparison of over 100 test cases (covering CPT, SPT, pressuremeter, Atterberg), with automated round-trip conversions between encodings and performance benchmark: 1,000,000 observations served in less than 4 seconds.

4.2 SensorThings API Pilots

Operational pilots validated conveying “Borehole as Thing/FeatureOfInterest”, implementing linear referencing over DataStreams, and demonstrated batch-processing capability of approximately 2,500,000 observations per minute on commodity virtual hardware.

4.3 Laboratory and Field Trial Use

Compound observations and derived parameters (e.g., from Atterberg limits) were prototyped and linked via OData queries. Key industry partners and large-scale datasets (UK AGS logs with 500,000 records, French MINnD models, and US DOT SPT/CPT datasets) substantiated interoperability with widespread geo-software, including QGIS, GeoServer, and IFC viewers.

5. Open Challenges and Future Recommendations

Key technical and organizational challenges, along with recommended actions, are as follows:

• Semantic Complexity: The full OMS/STA model presents considerable depth, potentially hindering novice uptake. It is recommended to establish “semantic transposition” profiles, enabling flattening into GeoJSON/CSV for mainstream usage.
• Entity Role Ambiguity: The Thing vs. FeatureOfInterest distinction in SensorThings proved ambiguous in some domain-specific cases. Harmonization through a new FeatureType entity is proposed for SensorThings v2.0.
• Codelist and Registry Divergence: Divergent codelists (AGS, DIGGS, CGI, EGS, etc.) persist. A unified, linked-data JSON-LD GeoTech Registry is recommended for harmonization of ObservedProperty, Procedure, and measurement Units.
• Multidimensional Geometry: Current standardization favors 1D and 2.5D (surface) models. To meet emerging requirements for 2D cross-sections and 3D block/voxel models, exploration of CityGML3D, GeoPackage Tiles, ESRI Scene, and integration with evolving 4D geotechnical concepts is required.
• Semantic Markup (JSON-LD): Current SensorThings responses lack embedded context, impeding direct JSON-LD integration. Adoption of lightweight @context markups is recommended.
• End-User Workflows: To facilitate routine laboratory and site data import (e.g., from SPT/CPT labs) by non-expert users, development of wizard-driven CSV→STA ingestion utilities is recommended.
• IFC and Digital Twin Integration: The GeotechSynthesisModel in IFC-IFC4.4 is nascent; formalization within the Model View Definition (MVD) process and involvement of buildingSMART InfraProjects is necessary for robust BIM integration.

Future technical streams include development of GeoSciML 5.0, GroundWaterML2 3.0 (OMS-compliant), SensorThings v2.0 (OGC API–JSON, JSON-LD, and tabular profiles), and 3D/4D integration via CityGML, WBML, Geo3DML, and voxel-based encoding (Beaufils et al., 11 Dec 2025).

6. Significance and Roadmap for Standardization

The Geotech Interoperability Experiment sets foundational precedents for multi-domain geotechnical data modeling, aligning engineering and geological semantics for seamless exchange between spatial data infrastructures and digital twins. The project’s approach of minimal yet extensible conceptual modeling, rigorous standards mapping, schema-driven validation, and procedural recommendations offers a critical roadmap for ongoing and future standardization efforts at the intersection of OGC, bSI, and related global initiatives (Beaufils et al., 11 Dec 2025).