Geotech
Geotech copied to clipboard
opengeospatial
SpatialSample
A physical object or feature on which some observations and/or measurements can be done
Proposed members :
- Borehole #10
- MaterialSample #11
- EnvironmentalMonitoringFacility #17
- Trench / Test pit ? #18
Suggested additions (assuming we go down this type of division, and influenced by the DIGGS post in #18 ):
- Sounding (to include CPT, dynamic probe, dynamic penetrometer, and the like)
- Transect (or similar - possibly consider a wider definition to include more general observations, not just a transect as such)
Also give consideration to a discrete testing location. such as an insitu test like a CBR that is may not be done in a pit (e.g. during construction works). This could be treated as a sounding, but if material sampling and monitoring have their own class (I think I agree on these), then a class for test location is surely justified. Alternatively combine the three into an object class that can represent any of these.
Can we please discuss the name ObservationSupport. I am struggling with this. It is not intuitive. When people in the UK see the support then are immediately thinking about excavation supports, borehole casing etc.
Also possibly add:
- TrenchWall: A wall of a trench or pit dug into the ground and represented by a planar surface.
Is "Sounding" a physical object? or is it just here to "mark the place" where an investigation has been performed?
Can we please discuss the name ObservationSupport.
Yes we can!
Interesting definition provided by DIGGS in #10
A physical object or location through which we observe or measure properties of an investigation target or perform some type of activity
The term DIGGS uses for the definition referenced in #10 is "Sampling Feature". Perhaps this term or something even more clear would be preferable to ObservationSupport?
In DIGGS, sampling feature encompasses all of the types listed here (Borehole, Trial Pit, etc.) except for MaterialSample. Sampling features always carry a location, whereas a Sample (DIGGS simply uses the term Sample as opposed to MaterialSample) represents a different class of object that typically (but not always) is derived from a sampling feature. Samples can also be created from "scratch" (eg. a laboratory standard or material for injection (grout) or can be aggregated from other samples from different locations and therefore observations of that sample have no location relevance.
Observations can be made directly on both sampling features or material samples, so both are ObservationSupport, I suppose but in our view they are different beasts.
Can we please discuss the name ObservationSupport. I am struggling with this. It is not intuitive. When people in the UK see the support then are immediately thinking about excavation supports, borehole casing etc.
I agree completely with neilchadwick-dg.
There is also a question for what purpose this data field is required. Is it simply to link relational db tables? Semantically it is probably not needed. The type of data measurement can be added as a predicate to the data fields. Context can be provide for each predicate (e.g. units, test method).
Following on the really good discussion last week involving the Book A Observations and "ObservationSupport" I've given some thought to how better define the elements on the Miro board, clean up some of the spaghetti, and introduce some ideas on how to address topics that we haven't discussed yet, but will need to - like sampling. Much of this is informed from the DIGGS model but is not rigidly tied to it.
I didn't want to mess with the main board that Mikhail has produced so I created a new one (Observation Support-Ponti), focusing just on Book A. I believe it is automatically shared with the group, but if not, I've attached an image here. Most of the explanation is on the board and I'll be happy to explain further in future posts, on the board or at our weekly calls, depending on when Mikhail decides to move forward further on the Book A topics.
Highlights:
- We work in local reference frames most of the time - at least initially. We define a sample location at some depth in a borehole, we map an outcrop or trench/trial pit exposure using a local grid, etc. The things we construct, like boreholes and trial pit, or the features we exploit, like outcrops, are merely ways of creating ObservedZones and our view of the earth materials are commonly defined and confined by the local reference frame. So, I propose we consider creating an abstract object class that for lack of a better term I'll call an ObservationReferenceFrame, but I'm lousy at naming things so I'm sure a better title can be identified. Essentially these are real or virtual geographic features that define the geometry (location, shape and extent) and the coordinate dimension of a local SRS for ObservedZones. Within this class we can place all the stuff we use to make observations - eg. boreholes, soundings, trial pits, outcrops, etc.
- Consider an object class that deals only with the act of creating a sample (a SamplingActivity) from the properties of the MaterialSample itself. Doing this provides a way of managing the kinds of complex sampling/subsampling/aggregating, etc. that is common in our domain, handling no recovery, and linking of Samples to ObservedZones (eg through the collection activity).
- Consider a Specimen to be derived from a MaterialSample but being tightly bound to a test procedure eg. a Specimen is created as part of a test procedure and only exists in its context.
Looking more closely at the O&M specification, it appears that the concept of an ObservationReferenceFrame appears to be essentially equivalent to O&M's SpatialSample - a geospatial Sample in which properties may vary spatially within its context. Note on p. 95:
Ok, I get it, but I have to admit that the semantics are a little tough to wrap my head around. To think of a borehole or a transect as a Sample I can understand conceptually, I guess, but in our domain I think I'd like to preserve the term "sample" for referring to a MaterialSample, and not use the word "sample" for a geospatial feature.
In any event, if I'm understanding things correctly, it appears that the ORF I proposed and O&M's SpatialSample are essentially equivalent concepts.
I think the model I proposed can fit in well with the O&M structure with some appropriate property extensions/restrictions for our domain.
ORF (the purple things ) = SpatialSample EMF = SpatialSample, as well, with some additional extension properties to manage "observation points" eg. sensors, well screen locations, etc. SamolingActivity = Sampling MaterialSample = MaterialSample Specimen = derivation of MaterialSample with properties to define preparation and pre- and post- testing conditions.
@dponti I think you are on the right track here - certainly the ORF - SamplingActivity - MaterialSample - Specimen - Observation logic looks right (but we need to keep testing it to see if we can break it).
Achieving some commonality with O&M sounds good, albeit not essential. I believe that we should use our own terms rather than borrow from O&M for the sake of it. If we use unfamiliar terms we will just confuse people in our domain (our future 'customers') which would not be helpful for adoption.
Things I'm not quite sure about yet:
- Environmental Monitoring Facility: where does it fit, do we even need it separated out?
- The 1D/2D etc ORF divisions: are these important divisions - how are they used (may be just fine, just can't quite see it yet)
- the best term to use for 'ORF' !
March 31 meeting : decision to adopt the OMS term "SpatialSample" as an alternative to ObservationSupport
@neilchadwick-dg: (sigh) another long post in an attempt to answer your questions
Environmental Monitoring Facility: where does it fit, do we even need it separated out?
IMHO, EMF's are ORF's, albeit ORF's that are located (installed) within another ORF. A well, piezometer tube, vibrating wire piezometer, borehole seismometer, are all EMF's (ORF's because they cover an "observation space" installed within a borehole - another ORF). To get out of the borehole notion a bit, a line of geophones would be an EMF installed within a transect. So EMF's would have the same geometric properties as ORF's (eg. they derive from an abstract ORF) but would additionally be required to reference the host ORF. EMF's would also carry a property that I would, for lack of a better term, call a "response zone" - a location space that is being monitored. A well response zone would be the location of the well screen(s), for an inclinometer, or line of geophones, the sensor locations, for vibrating wire piezometers and borehole seismometers, the response zone would be equivalent to the location of the EMF.
The 1D/2D etc ORF divisions: are these important divisions - how are they used (may be just fine, just can't quite see it yet)
ORFs define the spatial context for observations (and activities) so their geometries are fundamental properties that constrain the reference system for how we describe where observations (or activities) are located within an ORF. You can certainly define a generic ORF with a generic geometry, but once you know what a real ORF looks like, you need to model its shape and to do so you need to populate additional properties that are different depending on the dimensionality of the ORF, so it naturally follows to create distinctive types based on their geometries.
We primarily work with 0D and 1D ORF's with most of the data we collect, 2D ORFs (essentially maps) we tend to capture in GIS or CAD formats and geometries are well defined with GML, but the complexities of observations make XML representations (or some other ASCII representation tricky and we haven't really gotten there yet. But this is the way to go for trial pits and geophysical sections, trench walls, tunnel faces, excavations, etc. if we want to extend beyond the 1+D trial pit construct that AGS has (a trial pit is still 1D?). As far as how they'd be used:
0D ORF's are station locations that we model as a point. 0D ORF's would have to have a reference point (point object), with coordinates in some geographic or local reference system (x,y,z). There's no local coordinate system for a 0D ORF because the only location within it is the point location of the ORF itself, so you could argue that they are really just locations, but we do install things at locations where there may be some value in describing other properties to the ORF beyond it's geometry. So we might want to have these.
1D ORF's are modeled as a linestring. They would contain a reference point (point geometry) that would define some point on the linestring (typically the start). So for a borehole the reference point would commonly be the top of the hole at ground surface, but could be elsewhere, in 3D space (eg, coordinate defined as x1,y1,z1). The 1D ORF would also have a path - a line that defines the shape and extent of the ORF. The path will travel through the reference point (generally will start at it) and its vertices would also be expressed in 3D geographic space (eg x1,y1,z1 x2,y2,z2, etc.). For a vertical borehole the path would be defined by a line with 2 vertices (x1,y1,z1 x1,y1,z2) where z1 is the elevation at the top of the hole (at the reference point) and z2 the elevation at the bottom of the hole. You could also define the length of the path separately (eg. total depth of the hole), but that is informational only as it can be calculated as z1-z2, so the length is completely defined by the line's geometry) and you don't need another property. For an inclined borehole, it's path would be (x1,y1,z1 x2,y2,z2). Here, plunge, bearing and depth properties could be defined, too, but they are redundant and can simply be calculated from the coordinates. Likewise deviated holes would have more than two vertices defining the linestring (eg. x1,y1,z1 x2,y2,z2...xn,yn,zn), etc.). As an aside, a 1D ORF could have more than one path, should a borehole have sidetracks (not common in geotechnics), or if you have some observations referenced at different elevations (more common) like ground surface and rig table.
Finally, we would define the linear reference system LRS for the 1D ORF (borehole) using the constructs provided in GML 3.3 - eg we would define the linear element of the LRS (the path), and the linear referencing method,(eg, chainage,absolute values, and meters for the units for example). Now we can define locations in the borehole in 1D - as distance in meters from the reference point along the hole path. The borehole observations will have point locations with a single coordinate (d1), or an interval with two 1D coordinates (d1 d2) - say for the location of a geologic unit identified in the borehole. In real life in a borehole, we call the point a depth :-), and the interval a depth interval. This may seem a bit convoluted when you're just dealing with a vertical hole, but it's a way to define any linear ORF in 3D space and reference locations within it in 1D - software can then compute absolute locations (in 3D geographic coordinate space) with this information regardless of the linear ORF's shape and extent.
2D ORFs are modeled as a surface. There are several different ways to do this. In DIGGS we define a "planar" ORF, but in reality the surface can be a true plane or a curved or "wiggly" surface. More complex surfaces would require a different approach. Required properties would be a reference point, a reference edge (like the path), an offset vector (that defines the coordinate direction offset from the reference edge and that fixes the surface in space, and a polygon that defines the extent of the ORF (eg. a feature extent that bounds the surface defined by the reference edge and the offset vector). If the reference edge is.a straight line (eg. 2 vertices), then the surface is planar, otherwise it's a curved or wiggly surface that could even close up on itself (eg. a way to represent a tunnel sidewall). You can use GML 3.3's linear referencing to define the offset vector as well as the linear element and then locations on the surface in the LRS are 2D coordinates. As an example, for a trench or trial pit wall, one could collect a sample from the wall at a point, with a coordinate location (r1,v1) where r1 is distance from the reference point along the reference edge, and v1 is distance in the offset vector direction from the reference edge. A fault observed on the trench wall (which is a surface that intersects the wall) would have its location and shape defined by a linestring with coordinates (r1,v1 r2,v2...rn,vn), and you can locate a geologic/geotechnical unit (a solid body) by defining a closed line (polygon) where the top and bottom of the polygon defines the upper and lower horizon of the unit and the edges constrained by the feature extent as this body intersects the wall.
3D (we haven't done this one) would add additional offset vectors to define the "volume space" and locations would be 3D coords defining points, lines, polygons (surfaces) and volumes within the volume space relative to a reference point and in offset vector directions..
Clear as mud?
the best term to use for 'ORF' !
What I've described are what are currently called spatial samples in O&M Edition 2. They used to be called sampling features in O&M version 1. Borrowing heavily from O&M when we were developing this, we called ORF's SamplingFeatures as well. I'm ok with either term although I prefer SamplingFeature rather than SpatialSample because ORF's really are (almost always) features (manmade, natural or virtual) distinct from Sample which we typically associate with a physical sample. Although I understand the confusion in the use of sampling as this also has a specific meaning in geotechnics - eg. collection of a physical sample, rather than "sampling" in a statistical sense.
Another term (besides ORF) might be an observation space, since these features define the "space" that observations can occur in - or maybe ObservationActivitySpace since we do things in such features in addition to observing.
Maybe if we call them purple things it'll catch on? :-)