opengeospatial / boreholeie Goto Github PK

EPOS conceptual model uses INSPIRE monitory facility .
One-off measurements also fall under INSPIRE def of monitoring facility.

Only adaptation needed on the conceptual model to allow having a TRT signature class is to provide a way to dynamically add parameters to the Env. Monitoring Facility (like: SamplingFeature type of parameter)

From webconf 25: rename bhml:boreholeEventCollectionMember into bhml:collectionMember otherwise it’s really a mouthful !

A raw driller's log is something completely different than a geologist's log. The driller's log is not a basis that can be analysed by a geologist and validated. The content of the driller's log will be governed by the drilling circumstances and perceived rock properties that are important for drilling or by the background of the job. Examples of the former would be "unconsolidated", "sandstone", "hard rock", of the later "ore", "country rock".
If you want a geologist's log, then you'd better have one on site or sample cuttings/drill core for a proper off-site geological description.

From webconf 24 : No need anymore to have it in the model since we deleted the relation between TrajectoryDistance and TrajectoryReferent (see #39 )
Our main target is Borehole people not only 19148 specialist
Collapse TrajectoryDistance within TrajectoryPosition but still having in its definition a reference to “adaptation of ISO 19148 LR_DistanceExpression” (current TrajectoryDistance def)

Monitoring Facility can pertain to monitoring Networks (ex : groundwater monitoring network)

This would not change much our instance documents (just forces a mandatory sampledFeature).
I know there is a SF_SamplingCurve too, but it's not strickly a curve here (it's a bit of 19148 machinery). This gives us the hability to have this borehole as a target of a relatedSamplingFeature and link to other sampling features and obs.

As discussed in teleconf, we need to add header info to bhml:Borehole to hold borehole specific information (owner, drilling method, date, etc..).

we exclude metadata, because it might have a mixed semantic (such a linking to metadata about the dataset itself (who created the record, who is maintaining the dataset) as opposed to borehole header.

property should be "anyType" (at the conceptual model, modeled as "Process" class of O&M)

need to include in XSD and EAP

National data bank managers still receive papers.
Link at least from Borehole to documentation.

Documentation type exemple

• drilling declaration form
• driller report
• pictures : collar, surrouding environment (to help find it again)

This documentation can have a legal value (ex : declaration form)

Working on this with Mickaël using 'COSC_specimen.yaml' as a basis, it seems we should point to TrajectoryReferent and not TrajectoryDistance. Indeed pointing to TrajectoryDistance, we declare distanceAlong once and from it traversing to TrajectoryReferent then TrajectoryPosition we, again have to express distanceAlong (this is not in the current version of the yaml file).

In 19148 the class 'AtLocation' contains a 'atPosition' attribute.
We mimicked that pattern for the FromToLocation class (which contains fromPosition/toPosition attributes) but not here.

Should be fixed before the ER -> also implies instances update.

from Webconf 25
Not all Borehole related standards are ISO191xx compliant (gml:AbstractFeature) and 'Feature' has a specific meaning in that context

• 'locatedFeature’ -> ‘locatedEntity’ / ‘locatedElement’ / ‘locatedObject’ / ‘locatedThing’ / ‘locatedProperty’ / ‘locatedMember’ ?
  -> rename it into ‘locatedMember’ for consistency with bhml:collectionMember and the approach in GML "gml:member" (see I.2.7 in GML 3.2.1)
• 'locatedMember' type changed from ‘GFI_Feature’ -> ‘Any’ to streamline connexion to other standards (non GML)

In the EPOS model the intention was to reuse and extend the model from GWML2 to take into account requirement from other domains (ex : geotechnics, geothermy, ...).

However, in GWML2 spec the construction part is only introduced at the logical model level (see: http://docs.opengeospatial.org/is/16-032r2/16-032r2.html#22).

The job needs to be done

Required by 5/ Borehole for geotechnical investigation.

Consequence : there was a relatedObservation initially linked to GeologyLog.
Proposition to rename this relation to a specific type of Observation (logs) into relatedLog

From Leuven physical meeting
Change type for at and from/to to allow ‘measure’ and ‘boreholeEvent’ (union) -> remove FromToEvent class (but reuse part of the def of FromToEvent)

Important link that cannot only rely on geospatial process (geometry VS admin layers) : geometry 'errors' and not using the 'right' version of an admin layer can lead to biases.
Such errors can have important impacts on the legal side (reponsible party, ...)

add

• associatedFrom -> date
• associatedTo -> date
• associatedBy -> responsibleParty

Currently it’s almost raw EPOS conceptual model but most of the IE discussion is about 'core'. + also not being intrusive into pre-existing communities standards.
There may be a need to keep some classes from EPOS conceptual model where no community standard exist (at least just some classes as placeholders and not too much attributes detailing them).
Anyhow all this would ultimately be taken on board a SWG down the road for finalisation

A quick issue to remember considering ISO 19148 for Borehole IE
ISO 19148:2012 - Geographic information -- Linear referencing

Note : HY_Feature SWG did that exercise already and ended up using another (simpler) mechanism.
Both approaches should be considered

The quality of the association between a Borehole and a GeoresourceFeature (ex : Aquifer, ...) needs to be qualified.

Many discussions around this in many use cases and standardisation group (esp in GWML2)

One expression of need not to forget

• shapes/logs still remain are relative : first vertex is 0,0,0 and other vertices are dx,dy,dz – dz
• with referenceElevation
• but instead of attaching the referenceElevation to the well, attach it to the logs instead because
  • this could evolve throughout the life of the well/borehole
  • and because various work domains don't always reuse the same referenceElevation
• within referenceElevation have
  • a/ the Z of the ground (with SRS) and precising what type of ground it is ('Natural', 'after being reworked before putting a concrete pad', ...)
  • b/ the height of the 'benchmark' ('repère' in French) above the Z of the ground
    There is a need to differentiate both because over decades one or the other (or both) can change -> easier when stored separately
  • who/when this was measured

In both cases there is a need for location: TrajectoryPosition

Need to set this up

From EPOS discussions : Was created to support cases were an observation result is encoded in highly optimized binary file formats. This case often pertaining to geotechnical/geophysical logs (but not only) leads to huge files which encoding are widespread accross their community

Discussed in TelCo 15 : could be removed from the conceptual model. Mostly physical level discussion

Ex : Mining code, water law ...
We are not speaking about licence here (like exploitation licence)

Question : is this a new UseCase: 'my borehole-my legal obligation' ? => providing key parameters of the Borehole (depth, location, purpose...) identifying which legal constraints must be fulfilled

Everything ‘feature’
Appart from BoreholeReferencingMethod (DataType)
BoreholeEventLocation -> Abstract

Need to add properties to DrillingCampaign

see https://github.com/opengeospatial/boreholeie/wiki/(Use-Case-Vocabulary)-national-borehole-databank#conceptfeature-drilling-campaign

Idea : an equivalent exercise was carried out for Inspire, under the term EnvironmentalMonitoringActivity because the scope was environmental monitoring campaign (see https://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/index.htm?goto=2:3:6:1:1:7980 )

Good presentation here

https://dl.ppdm.org/dl/109

Need to formalise 'elevation', 'height' and 'depth'

In Australia we run up against issues of multiple identification numbers/names for a single bore hole. For example, a state agency will assign a name and an ID ((i.e. name=Burke flats 1, ID=1234). If this bore is incorporated into the national data set it is assigned another ID to ensure uniqueness across all states.

This can be compounded again when state level agencies merge/split or change data management technologies. In the past this has lead to renaming of bores to accommodate these changes, hence some bores have "historical IDs" as well as (multiple) current identifiers.

Multiple pipes in a single bore hole can also impact IDs.

the namespace of the new schema in GitHub (https://github.com/opengeospatial/boreholeie/blob/master/schemas/BhML-Core.xsd ) is now

https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas

Is this the namespace we should use for examples (or should we care ?)

Is anything further required to include them ?

UC13 Analysis on core & result positionning down the hole

A description of the positioning system for the measurements on the core is missing. Without it, the UC task "result positioning down the hole" will not be possible to achieve.

It might be worth to compare a solution for result positioning on the core that itself is positioned down the hole with one that directly converts core positions to "down the hole" positions.
Core measurements are not downhole logs, and the question is at what stage it is most meaningful to do the depth conversion. If core measurements are kept on the core and only converted to "down the hole" positions when it is necessary, then they will follow along the core in case the core is repositioned along the borehole, e.g. through the comparison of downhole logs with geophysical core logs (which also requires data on the core, and not converted to "down the hole" depth).

Comment triggered by ISO19148 figure 27 on LR_Referent.
This would allow to know all the Referent(s) of a 'Borehole' as often sub-domain do not always use the same one (ex : Groundwater level, construction element, Log) and would also be useful in case of branching 'Borehole'

Maybe I do not understand correctly what is meant in the UC 6 examples, but according to the descriptions it appears to me that an item (feature/non-feature) should be taken from the hosted model and wrapped into the borehole model/"form" with positioning assigned, risking to loose context.

Is it necessary to wrap (parts of) the hosted model into a borehole form (c.f. "Examples") in order to refer to it as a feature that has a position along/is intersected by a borehole? Or is it sufficient to refer to such a feature (whatever its representation/model) externally, preferably by an unique identifier?

Example:
"borehole" (with geometry) intersects "feature defined by UID" (with geometery); positioning is implicit and can be figured out by the client as long as the hosted model is an OGC standard or equivalent.

"borehole" (with geometry) intersects "feature defined by UID" (without geometery) at depth XXXX (or: with top depth YYYY and bottom depth ZZZZ); positioning is explicit

Both examples would fulfill all three UC requirements without wrapping anything. Minimum interference with the hosted model grants maximum flexibility (as long as the hosted model is well defined and valid).

Third UC example "Exposing data that is not following OGC standard (non feature model, or maybe even under an encoding not supported by OGC)." might be problematic. If it is possible to refer to a problematic "non-feature"/"non OGC" item that is positioned along the borehole by some kind of identifier, then this approach would leave the problem where it is (i.e. with the hosted model) instead of wrapping the problem into the borehole content. However, if the only option is to wrap the item of the hosted model into the borehole content, then the question is how context can be preserved. (And if it makes sense at all to do it).

Re-reading UC 13, I'm not sure it's only an O&M on Sample discussion.
"Scanning the core in the tray. Result is a downhole log"
-> could we consider conceptually that the 'downhole log' part can be 'reconstructed' from the observations on the various cores (Sample) related to that Borehole ?

Use Case 11 : introduces those notions.

It was discussed in TelCo 15 that those are out of scope as they are more a reuse of standardized description of Borehole Logs -> out of scope for BhML
However, Geological Structure is in as this refers to Features observed in Borehole Log.

In geothermal exploitation, some borehole construction elements are plugged to surface ones (pumps, heating extraction and distribution system, ...). Need to draw a line.

To us of scope for this IE

Issue to keep track that there is a constellation of possible terms (Borehole/well& friends) for our 'HoleInTheGround' class (term we won't keep in the ER)

So far the biggest overlap is ‘Borehole’

Which definition could contain

• Common part :”Well, Borehole are seen as synonymous”
• A: A Borehole is a hole that is drilled from an origin (top/start) to a terminating point (bottom/end) (PPDM slightly adapted)
• B: A Borehole is the generalized term for any narrow shaft drilled in the ground (INSPIRE def slightly adapted).

For now the model define a borehole can have [0, 1] trajectory.

In real life, a borehole always have a trajectory, but because it has not been recorded, 3D geometry may not be available (yet a device could get it ad hoc if the hole still exists).

I suggest to define borehole have 1 trajectory. Trajectory being conceptual, with or without known geometry.

Eric Boivert & François Letourneau : Nr-Can : done
@Others : please ask here

I added a note in "Future Work" that some of the naming should be reviewed in future work, but should we consider renaming BoreholeEvent into something that is more common to people.

We also decided to stop changing stuff, so I only made this issue because it was suggested to do so in the report comments.

I am not confident what is meant by "Platform" in EPOS model. Can someone please add notes to the EPOS model? @sgrellet ?

For now:
BoreholeEvent is defined as a single observation (one result associated to a depth, or depth interval).
BoreholeEventCollection is defined as several single observation attached to the same BoreholeLRS, but without being necessary attached to the same property > pros and cons for me.

Proposition: Introducing a "BoreholeEventStream or BoreholeEventSerie" concept for logs / diagraphy = for BoreholeEvents that can (shall) be grouped. It would be a subtype of BoreholeEventCollection.

working on the conversion to RESQML we would need slight adjustments

• swe:identifierhttp://resource.geosciml.org/classifier/cgi/contacttype/0012</swe:identifier>
  should point to http://resource.geosciml.org/classifier/cgi/contacttype/faulted_contact (which derefferences)
• ideally would be good to have next to the swe:identifier / swe:label (the prefLabel in CGI Geoscience vocab). for example : swe:labelfaulted contactswe:label

Vocabulary entry:
"True vertical depth (TVD) (fr: Profondeur verticale réelle)
True elevation of a point along the borehole trajectory with reference to a datum"

a) Depth is not elevation
b) Vertical depth is "vertical" and not along the borehole trajectory, i.e. vertical depth (without "true"!): "Depth below surface (of a point on the borehole trajectory)."

If "true" means the reference to a datum, then the question is what the datum is. With a local datum (e.g. with the collar as reference) there wouldn't be a difference between "true vertical depth" and "vertical depth". If it is an external datum (e.g. RH2000 - Swedish example, EPSG:5613, https://epsg.io/5613) then we are in terminology-hell. Can the bottom of a borehole have a positive "depth"? "Height", "Elevation", "Depth" ...
It's actually only necessary for a 3D-representation. Else, the location of (e.g.) the collar will be specified in a 3D (or 2D+1D) coordinate system and everything else is below it ("implicit" local datum/reference system => "borehole origin").

Borehole class one figure 1 and figure 2 are different -

Now that we have the BoreholeEventCollection related to the TrajectoryReferent, is there really a need to allow redefining the referent for each TrajectoryDistance ?
The referent being defined at the collection level, is simplifies the model.
Are we missing a Use Case ?

For now, there is a connection between BoreholeEventCollection and TrajectoryReferent.

This means that we can define the point that is used as the origin for the distanceexpression.
Yet, two BoreholeEventCollections having the same TrajectoryReferent + same distanceexpression may not be similar. There may be for example conventions in which depth are measured with positive values, and in some with negative values.

I propose to have a concept that would be a joint of :

• Borehole trajectory,
• TrajectoryReferent,
• LinearReferencingMethod.

This is basically the definition of Coordinate Referencing System (CRS).

BoreholeCRS would have an Id.
BoreholeEventCollection would then be linked to BoreholeCRS, and not TrajectoryReferent.