Borehole

[mbeaufils]

Definition source : from IUGS and OGC GeoSciML, also candidate for IFC.

A Borehole is the generalized term for any narrow shaft drilled in the ground, either vertically, horizontally, or inclined.

[AC107]

In DIGGS, a non linear borehole can also be accommodated by identifying discrete segments. This is important particularly for deep holes that tend to deviate during drilling and thus your deeper data points would be incorrect in their final location

[LucasoilCloud]

The case of invistagations made with excavators must be covered as well. Geotechnical investigations are not only boreholes. What is common to any site investigation (borehole, excavation pit, CPTs, ...) is:
- Coordinates (X, Y)
- Elevation
- Name
- Date
- Operator
- ...

So, maybe, rather than discussing about the 'borehole' object we should introduce the more general 'in-situ investigation' object.

Happy to discuss that with you

[AC107]

Include options for different sample methods, but don’t lump them all together. Boreholes are different than test pits or trenches and should be captured differently to understand their full meaning. — Allen Cadden / Principal From: LucasoilCloud ***@***.***> Sent: Friday, February 25, 2022 12:18 PM To: opengeospatial/Geotech ***@***.***> Cc: AC107 ***@***.***>; Comment ***@***.***> Subject: Re: [opengeospatial/Geotech] Borehole (Issue #10) The case of invistagations made with excavators must be covered as well. Geotechnical investigations are not only boreholes. What is common to any site investigation (borehole, excavation pit, CPTs, ...) is: - Coordinates (X, Y) - Elevation - Name - Date - Operator - ... So, maybe, rather than discussing about the 'borehole' object we should introduce the more general 'in-situ investigation' object. Happy to discuss that with you — Reply to this email directly, view it on GitHub<#10 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGJD4CPYD5ZN4CU6QYX75ALU462TTANCNFSM5PD2BXCA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[LucasoilCloud]

I have prepared few elements to start our reflexion regarding the common conceptual model for Book A. I have tired to be as exhaustive as possible. Maybe some information are useless. For the moment, I have focused only on the 'In-situ investigation' object. But we will have to discuss regaring the tests as well (in-situ and laboratory).

Common conceptual Model.docx
Common Conceptual Model.pptx

[mbeaufils]

Some clarification about the perimeter of this issue / topic.
This is "only" about the definition of the borehole object itself as a "hole in the ground".
Please stay focus :-)

Observations and measurements made on boreholes or other observation supports (as defined in #12) will be adressed separately.

In DIGGS, a non linear borehole can also be accommodated by identifying discrete segments. This is important particularly for deep holes that tend to deviate during drilling and thus your deeper data points would be incorrect in their final location

Yes the propose definition for Borehole does not mention any restriction to borehole shape.

[neilchadwick-dg]

Some good discussion so far. This subject is more difficult that it looks. Some advice based on our experience with AGS...

In the AGS format we have the concept of an exploratory hole (or location) that can represent any type of investigation hole, test or sample location. The type of hole/test is then provided as an attribute. At the last count we had codes for about 35 different types of exploratory hole (LOCA_TYPE). We are still getting requests for new codes. And we are only covering common UK techniques.

In addition, a situation that must be accommodated is that it is common for a 'hole' to change type with depth. For example, in the UK we often have a cable percussion borehole in soft ground changing to rotary coring at depth in harder ground. This hole, like most, may also start out as an inspection pit. Another example is multiple push CPT carried out within boreholes. AGS has found a way to deal with this via the HDPH table where the hole is divided up into depth sections with type and other metadata provided for each. A concatenation of relevant codes can be used for the parent hole LOCA_TYPE to provide an overview.

Note: this extra table HDPH is only found in the main AGS (factual) data format. In AGSi (our developing ground model format) we only include attributes for the headline hole type (concatenated codes) as we do not intend for AGSi to carry all of the GI data (we prefer the concept of linking to detailed data).

The AGS solution is not perfect, mainly because it has evolved over time (and we have to respect backward compatibility) but it works well in practice.

Before we come up with the best data model, we should try to agree on terminology. In the UK the term borehole has a specific meaning for many, and I would caution using this term to represent many different types of hole/pit/test/sample/whatever. The AGS term exploratory hole is better, but far from perfect as CPT, probes etc. are not really 'holes'.

I am not sure that having separate objects for borehole, pit etc. is the correct approach. If we do this, then where do we stop?

Perhaps discuss next meeting. I think this is a good subject to get us thinking together about the conceptual model.

[mbeaufils]

In the AGS format we have the concept of an exploratory hole (or location) that can represent any type of investigation hole, test or sample location.

This looks that "LOCA" in AGS is quite close to the ObservationSupport concept discussed in #12 and I guess this is why it is not called "HOLE" anymore.

[dponti]

DIGGS has done considerable work on this topic and has a fairly detailed data model for boreholes that might help guide our larger scale conceptual model, so I'll summarize briefly here and can discuss more fully in subsequent discussions. DIGGS considers a borehole to be a specialization of what it terms a "sampling feature" (apologies for any confusion in the vocabulary with respect to other OGC features), which is defined as: A physical object or location through which we observe or measure properties of an investigation target or perform some type of activity.

Sampling features are therefore the "lenses" through which observations are made. DIGGS currently has defined three abstract types of sampling feature objects based on their geometries: 1) AbstractLinearSamplingFeature (modeled by a line string), 2) AbstractPlanarSamplingFeature (modeled as a 2D planar surface), and 3)AbstractPointSamplingFeature (modeled as a point). These abstract types allow for derivation of concrete objects with their own specific properties (eg. boreholes, soundings, test pits, etc.) but that can share common geometry and other metadata and referencing properties. All direct (not modeled) observations, interpretive classifications, measurements, samples, monitoring activities etc. that have location relevance are referenced to their associated sampling feature and position(s) on that sampling feature.

The following are the concrete sampling features currently defined in DIGGS and that can appear in data instances:

Derived from AbstractLinearSamplingFeature:

1. Borehole: A sampling feature feature that is a deep, narrow excavation made by
   drilling and/or extraction of earth material. Boreholes are constructed typically
   for the purpose of investigating subsurface geologic or geotechnical conditions,
   exploring for water or oil, for installation of wells or other downhole monitoring
   installations, or for construction activities such as grouting, piling installation, etc.
2. Sounding: A sampling feature feature that is created by a measurement activity
   through insertion of a probe into the ground. (used for CPT, Flat Plate Dilatometer tests, etc.)
3. Transect: A generic linear sampling feature that extends along the surface of an
   investigation target; used for such features as transects, measured sections,
   etc.
4. Trial Pit: A relatively shallow excavation into the earth's surface, dug either
   manually or by a mechanical excavator. Samples, observations and tests in the trial
   pit are referenced in a linear referencing system only (1D). This is a legacy
   sampling feature to support AGS trial pit constructs. The trench wall sampling
   feature should be used to represent more detail on walls of pits or trenches in
   2D.
5. Well: A sampling feature that is an installation within a borehole or sounding,
   used for observing, withdrawing, or injecting fluids. Although wells are discrete
   sampling features in their own right, they are installed within boreholes or
   soundings, and must reference the parent borehole or sounding feature within a
   mandatory samplingFeatureRef property.

(Note, wells represent a specific sub-type of a sampling feature that derives from AbstractLinearInstallation, a generic construct that seems to be similar to the EnvironmentalMonitoringFacility #17 concept.)

Derived from AbstractPlanarSamplingFeature:

1. TrenchWall: A wall of a trench or pit dug into the ground and represented by a planar
   surface.

Derived from AbstractPlanarSamplingFeature:

1. Station: A sampling feature that is a point in or on the earth's surface where
   observations or tests are performed, where samples are collected, or where
   monitoring devices are installed.

Attached here is an image showing properties of DIGGS borehole object as an example of how these look in the XML schema. Note many of the properties themselves contain objects (not shown in the diagram) with additional properties. Borehole properties not only describe the physical borehole, but also provide information about its construction. For example, the borehole property constructionMethod allows for description of methods of borehole construction (eg. cable percussion, rotary, etc.) defined over different depth ranges of the hole - eg. essentially equivalent to AGS's HDPH table).

[IHalfon]

To stay focus on the definition, what about : "A Borehole is the generalized term for any narrow shaft drilled in the ground, either vertically, horizontally, inclined, or composed of discrete segments to represent the possible deviation."

[Didymograptus]

Or, to make it even more generic, let's start with:
"A Borehole is the generalized term for any narrow shaft ."

[jjkaelin]

In my experience, a semantic approach can simplify borehole data a lot,
e.g. using predicates such as
isPiezometer (Boolean)
hasCorelog (Boolean).

This can easily be extended.

[mbeaufils]

A Borehole is the generalized term for any narrow shaft drilled in the ground

[dponti]

My problem with the above definition is:

1. A borehole in geotech-speak is not a generic concept but a specific object with specialized properties. It is too easy to conflate a borehole with other narrow shafts drilled into the ground (such as a tunnel or mine shaft) with this definition.
2. "narrow" is relative. What we mean is that boreholes are narrow enough that we practically only make observations along a borehole's length (we don't typically map a borehole wall like we can a mine shaft or tunnel).

So here's an attempt to address this:

A borehole is a narrow excavation created by the removal of earth material by boring into the ground with a drill. A borehole is sufficiently narrow, such that observations made within it can be related only to a point or interval measured along the borehole's axis.

Stating that boreholes are created through removal of earth material distinguishes a borehole from a CPT sounding or other feature created by displacing material via a probe.

There was discussion today that a well or drilled pile is similar to a borehole. While that is true in terms of their geometry, I would argue that wells (piezometers) and drilled piles are installations within a borehole - you need to create the borehole first. Therefore I think we should consider a different class of objects that are installations within other types of "ObservationSupport" objects (boreholes, pits, etc.). The Environmental MonitoringFacility #17 would also be an Installation, it would seem to me.

[jjkaelin]

I suggest that the definition be kept simple and expressed in a way that would easily be understood by site engineers or included in technical specifications. I checked 'my' definition against the dictionary definition and then adjusted slightly.

A borehole is a hole bored into the ground whose purpose includes exploration, related testing and/or sample recovery.

Note that this definition purposefully includes groutholes, anchor holes, drilled shafts for piles etc. which include exploration (e.g. layer breaks), related testing (e.g. Lugeon test or grout takes) or sample recovery. These are important and valid observations and form part of the data set.

[LucasoilCloud]

Hello everyone,

I do think that we do not go on the right direction focusing on the definition of the 'borehole'. My position is very similar to Neil's one (see above). The aim of this working group is to experiment interoperability between two computing systems (GIS to BIM model for example). Therefore, we have to think as a 'computer' and so, the definition of a borehole should not be important. What it is important, in my mind, is to define how to organize the things to be interoperable.

From a computer science perspective, a CPT and a borehole look very similar (position, angle, elevation, depth reached, tests attached to them,...) so those ones could be defined as a same type of object but with different properties (Type:= CPT or Type:= borehole).

What I sugest is to create more global Object, for example:
- Ponctual site investigation ==> For borehole, CPT, SPT, pit, anchors, piles, ...
- Linear site investigation ==>For electrical panels, georadar, D-wall, ..
- Surface investigation ==>For tunnel face observations

Then, by implementing properties to these objects we could cleary define that the object is a borehole.

To conclude, my definition of a borehole is 'Ponctual site investigation defined as a borehole'

[jjkaelin]

I support the comment by dponti for linear features for exploration:

• borehole
• sounding
• trial pit
• transect

(a well [here meaning piezometer, I believe] can be handled as an additional attribute).

Individual observation points (e.g. strike and dip of a rock joint) and surface observations (e.g. a mapped outcropping geological formation) should be considered separately.

We should also recognize that semantically a borehole may have several attributes, e.g:

• isBorehole
• isLinearFeature
• isPiezometer
• hasCorelog.

An augered hole with SPT testing (sounding) is expressed semantically:

• isBorehole
• isSounding.

At this point we should be thinking semantically and not be too rigid about object containers.

[Didymograptus]

My very last comment on Borehole: I put it to you that a geotechnical conceptual model can be developed without borehole information, e.g. through geological maps and local geotechnical knowledge. As this is the case the definition of a borehole is not integral to the model and does not need to be set out. (it is metadata) As long as we can reference a source for the data (if direct data is used) the user can view the source and make up their own mind about the origins of the data.

[neilchadwick-dg]

I agree with the initial comment from @LucasoilCloud that we are perhaps focussing too much, at this early stage, on the precise definitions of things. We should be focussing on the broad semantics, the ontology if you prefer. We need to identify the things* and their relationships first. If we can't agree on a name or definition of a thing straight away, then we should use a a placeholder name and/or definition, which may be messy and/or verbose - but something that we all understand clearly - with the formal name and definition to follow later.

Here the thing is a borehole and I think we all understand that we mean. The real issue here is the overall hierarchy. I will return to this, and my views on the precise definition, another day as I believe the main focus of the next meeting was elsewhere.

*I hesitate to use the word object as that implies an object in a data schema sense. This is not necessarily the case - some of the 'things' mentioned in these issues may just end up as object attributes (I can give examples of this from AGSi). However, I think ontology uses the term object, so I guess we may be stuck with it.

[neilchadwick-dg]

I re-iterate that I think that attempts to categorise all of our investigation holes/tests/things into object superclasses like borehole, pit, sounding etc. are misguided, and will only cause trouble later.

Reasons:

• I said superclass because, for practical use, 'borehole' is nowhere near precise enough. There are many different types of borehole, so further information would be needed. In which case, why bother with the superclass?
• Some investigation locations/things will not fit into one class. e.g. a pit which then has a dynamic probe done from its base (not uncommon). or a CPT done within a borehole. Also, almost all boreholes in the UK are started as a pit (an inspection pit).
• Some investigation types will defy clear categorisation, e.g. pressuremeter, of which there are many variants. Borehole or sounding?
• Why? I can see that boreholes have a particular linear type geometry, but so do soundings, and pits can too (if only simply logged - which many are). SOME pits may have detailed logging of their walls, but by no means all.

I think we should just have a generic ground investigation location/activity/thing object, with attributes used to say what the actual hole/test type is. The challenge then is how to deal with 'holes' that change type with depth (which is very common), so we probably need a similarly generic child object.

@dponti curious to know how DIGGS deals with the composite type issue

[dponti]

@neilchadwick-dg

I do not see boreholes, soundings, trial pits, etc. as super classes. They are specializations of a "SpatialSample" or SamplingFeature (my preferred term from O&M Edition 1). These types of objects can be man-made, or natural features like an outcrop, or virtual ones, like a transect or a cross-section. These different sub-types or specialties would have different properties (but all would inherit from the main SpatialSample). SpatialSamples, like borehole, sounding, etc., would inherit the geometry properties of a linear SpatialSample class as their geometries would be defined by the same properties (eg. reference point and centerline or path). The additional properties for a borehole relative to a sounding or transect would largely involve its construction. eg casings, backfills, etc. See the diagram I posted above.

@dponti curious to know how DIGGS deals with the composite type issue

From your examples above:

1. Pit dug and then dynamic probe pushed from the base (or a borehole drilled starting at the base of the pit). This would logically be encoded in DIGGS as two sampling features - a trial pit (if information is logged in 1D only as depth, or some combination of 2D surfaces if details are mapped on the walls and that info is encoded in xml, csv (or other digital encoding) and not just "information" in an external graphic file (eg. cad or pdf). The dynamic cone measurement (the observation) would be associated to a sounding sampling feature that starts (eg. reference point elevation) from the base of the pit. DIGGS has a group property (like a collection) that would allow one to associate the two sampling features together and give the collection a single name. But each sampling feature would have its own reference point and path geometries (assuming both are modeled as linear features).
2. CPT done in a borehole. I assume this is where a CPT probe is pushed starting from the bottom of the hole as it makes no sense to do a CPT in an open hole ;-). This could be handled two ways depending on the circumstances. Let's say for example, you drill a borehole to 10 m. Push a CPT probe from 10 m to 30 m, and then go back in and drill to 40 m. Option 1: there would be two sampling features. First would be a borehole with a reference point at ground level and a path from 0 depth to 40 m (assuming vertical here). Second would be a sounding with a reference point that begins at an elevation 10 m below the borehole's reference point elevation and a path extending for 20 m to an elevation 30m below ground surface. Note, if the "depths" of the CPT observation are recorded from ground level and not from the start of the sounding, the sounding's reference point could be set at ground level, at the same point as the borehole's. The fact that the borehole's construction was interrupted by the CPT push isn't really significant and any change in hole advancement (like when drilling starts and stops) can be encoded in properties of the borehole object. Option 2: in this case where the borehole eventually extends past the sounding's bored limit and the locations of the CPT results are contained in an observation (or observation collection) within the borehole's "space"m you can create just the borehole sampling feature (from 0 to 40 m depth) and associate the CPT observation to the borehole and there would be no need for a sounding sampling feature. In this case, the locations recorded in the CPT observation would need to be related to the borehole's linear referencing system where in most cases 0 is ground surface, so the first location of a CPT measurement would start at 10 m depth. Either option 1 or 2 is fine, although option 2 is a bit cleaner as it doesn't require instantiating two sampling features. However, if there is some specific sounding property that you would want to encode. like an event that occurs during the push, you would want to go with option 1. If you drilled to 10 m depth and then pushed to 30 m and did not go back and drill, or drilled to a depth less than the limit of the sounding, you would definitely need two sampling features, one for the hole and one for the sounding. As with the pit, both features could be grouped together.

Some investigation types will defy clear categorisation, e.g. pressuremeter, of which there are many variants. Borehole or sounding?

If I understand pressuremeter to involve the insertion of a probe into the ground (for all variants), then the sampling feature attached to the observation would be a Sounding, per the definition I provided in #37. It's important not to confuse the sampling feature with the observation that occurs within it - even where the observation act creates the sampling feature (as with CPT). The sampling feature is the "place" where the observations occur and the "thing" that defines the spatial reference system for the observation locations. We need to do this because we (hardly) ever record an observation in a borehole, pit, or anything else in geographic 3D space. Instead, we identify the location and geometry of the sampling feature (eg the hole or sounding), and then define the observation locations within it in terms of distance (in 1D, 2D or 3D depending on the sampling feature's geometry) from some reference point on the sampling feature.

I think we should just have a generic ground investigation location/activity/thing object, with attributes used to say what the actual hole/test type is. The challenge then is how to deal with 'holes' that change type with depth (which is very common), so we probably need a similarly generic child object.

If you think of a borehole as a narrow, cylindrical "shaft" drilled into the ground, a sounding as a linear feature created by pushing a probe into the ground and a trial pit as a "pit" dug into the ground, each would be similar linear features ("logged" in depth) but with different other properties relevant to their construction. For example, a pit has a width and a length, a borehole has a diameter (or diameters, depending on the depth range), a sounding has none of these, but it's possible for casing to be installed in the hole left from a sounding, record events tied to the push, or rates of advancement that might change with depth so there might be properties for those items within the Sounding object. So you can see that there might be value in having each of these "features" specialized into different objects. OTOH, for the IE project, having a generic SpatialSample feature with standard geometry and linear referencing properties (eg. a linear SpatialSample), with a property that defines its type (eg. borehole, sounding, etc.) and then a non-typed set of properties where you can add pretty much any property that you want (with name-value pairs) for a given instance for exchange purposes, that could work, too, although we'd need to carefully define the controlled terms that would be needed to accommodate the types of properties that could be used in any type of a geotechnical spatial sample in order not to cause confusion and to enable mapping between different encoding standards. This latter approach is akin to what @jjkaelin proposed above.