-
Notifications
You must be signed in to change notification settings - Fork 9
Example Use Case Summaries
This page summarizes the use cases to be demonstrated in the BoreholeIE with a user story
Who : name(organization)
Context : Generic sentence
Requirement towards the IE : Required information (concept), required IT formalism...
Who : Sylvain (BRGM), Martin Nayembil (BGS), John Sharples (BOM)
Context : national obligation for drillers to declare where, how, ... they drilled a Borehole and provide the description of what they observed (log) and associated documents (construction details) In France every type of Borehole (actually every hole deeper than 10 meters) is to be declared even those used in Oil & Gas (embargo periods can apply). Similarly in Australia, any bore drilled for groundwater must be reported.
Requirement towards the IE :
- borehole general details
- drilling details
- purpose/use
- raw log
- site data, i.e. elevations, location, etc
- ... all the information needed to curate Borehole data coming from drillers
Who : Sylvain, Mickaël (BRGM)
Context: raw logs provided by drillers to their client, analyzed by geologist specialists of the area to generate 'validated' logs for the same borehole
Requirement towards the IE :
- a log = an observation
- an observation workflow
Who : Sylvain (BRGM), Martin Nayembil (BGS), John Sharples (BoM), Eric Boisvert (GSC)
Context : National Ground Water Information Network
Requirement towards the IE:
- geo-resource (waterbody, aquifer) monitored (quantity, quality) or exploited (water abstraction
- sensor system
- management zone around the well (to protect water resource)
- pump/aquifer test
- construction details/equipment
Who : Sylvain (BRGM), Martin Nayembil (BGS)
Context : Geothermal probe deployment to assess subsurface heating storage capacity via Ground Thermal Response Testing (TRT). But also construction details specific to geothermal exploitation (ex : geothermal doublets).
Requirements towards the IE :
- 'geothermal log'
- Ground Thermal Response Testing (TRT) details
- Geothermal doublets : coupled borehole
- Geo-ressource available (geothermal field)
Who : Mickaël (BRGM), Jean-François (Energistics), Martin Nayembil (BGS)
Context : boreholes drilled for Geotechnical engineering projects (ex : tunnel, foundations, ...) to aquire knowledge of the subsurface. direct link with Building Information Models (BIM) activities
Requirement towards the IE :
- borehole general details
- drilling details
- detailed geotechnical tests results
- details observation acquired down the hole (ex : borehole televiewer)
Who : Eric (NR-CAN), Mickaël (BRGM), Henning Lorenz (UU)
- ability to position features from any domain along a borehole
- definition of various positioning systems (eg: tropari, absolute, relative, etc.)
- ResqML approach on wellboreframe is an interesting approach
- Use case 6 vocabulary
Who : Eric (NR-CAN), Ollie (GA)
- representation of borehole status (active, inactive, in production, etc.) in time
- representation of changes to borehole (headwork, deepening, etc..)
- Use case 7 vocabulary
Who : Eric (NR-CAN), Sylvain (BRGM), Henning Lorenz (UU)
Context : enhance discoverability of borehole data through the Web. For example, in the context of the EU EPOS research infrastructure, GeoSciML Lite BoreholeView was re-used and extended to provide Borehole summary information in order to facilitate borehole data discovery. This summary information could be considered as a vCard for the Borehole. See : https://external.opengeospatial.org/twiki_public/GeoSciMLswg/SouthamptonGsmlSwgSept2017 -> Borehole_SimpleFeature_UML_model_Grellet.pptx
Requirement towards the IE :
- JSON-LD :representation of that Borehole vCard and associated data. Reusing practices summarized in the recent OGC Environmental Linked Feature Interoperability Experiment (ELFIE) would make a lot of sense
- for the JSON-LD context we will need a reference ontology to point to
Who : Yan Liu (3GS), Josh Lieberman (OGC), Rainer Haener (GFZ)
Context : A new log is generated in a region where a 3D/4D was produced based on pre-existing knowledge of the underground. The new information available should be used to validate/invalidate the model. Borehole measurements are nearly the only way to verify geological or geophysical models derived from indirect investigation methods (for example Magnetotellurics). For this reason, it is essential to establish the means that are suitable to exchange borehole information like lithostratigraphical logs within the various communities without the need to implement the processing each time anew.
Requirement towards the IE :
- how borehole log(s) are linked to 3D/4D underground descriptions
Who : Rainer Haener (GFZ), Yan Liu (3GS), Ollie Raymond (GA)
Context : Various systems already have vocabularies describing boreholes and associated data. Vocabulary should be understood either as data structure (ontology, UML model,...) and/or codeLists/nomenclature/... Establishing a registry that maintains and manages the manifold of terms, concepts and relations between the scientific communities is important
Requirement towards the IE :
- the IT formalism applied should support the use case (ontologies, thesaurus) in order to properly map the semantic umbrella produced by the IE to pre-existing vocabularies (provided those are exposed accordingly...). For example, expose the list of GeoSciML vocabularies that relate to boreholes.
Who : Peter Warren (CSIRO), Mickaël Beaufils (BRGM), Henning Lorenz (UU)
ex Spectrally Scanned Boreholes Context : Mineral boreholes scanned with spectral reflectance logger. Australian National Virtual Core Library project. http://www.auscope.org/nvcl/
Scanning the core in the tray. Result is a downhole log
Requirement towards the IE :
- spectral reflectance logs. Quite dense data
Revised from "Serving shapshot(s) from drill site (uncurated) database for off-site science decision support" Who: Henning Lorenz (UU)
Reason for revision: Managing versions, as it was required by the original formulation of the use case, is a wider problem beyond the borehole standard. In the revised version, time-stamping by the webservice (e.g. WFS) will be sufficient to identify the origin of the data; renewed access to a certain version is not part of the concept.
Context: Decision making support exists in commercial drilling management software and is often focussed on the technical drilling parameters. This use case explores in how far the model (eposb) chosen by the BoreholeIE is suitable for providing that latest (revised from "for near-real time provision of") scientific information from the drill site to the scientific manager (PI, or responsible geologist at ore exploration drillings) in order to provide sufficient information and support for off-site decision making and required control of the latter.
Basic requirements: A drilling (project) that has basic to advanced on-site documentation (core or cutting description, sampling, preliminary downhole logging data, etc.) that is stored in a data base; basic drilling information is stored in a data base; internet connection at the drill site.
Requirement towards the IE:
- Define the on-site data base(s) to be tested (example: ICDP's drilling information system (DIS), => need example for e.g. exploration)
- Mapping of the database to the model chosen by the BoreholeIE (eposb) => see also use cases #6 and #13
- Check whether relevant ontologies and vocabularies can be integrated in a quick and easy way in the initial data collection (avoid classification and translation of data base content to the model) => see also use case #12
- Explore how the information can be digested in a proper way by the end user (starting from, e.g. QGIS App-Schema plugin, and discuss potential specific solutions)
- ? more to be defined
how to time stamp everything and roll-back to a previous version of the instance
Who : Jay Hollingsworth, Jean-François Rainaud
Context : Generic sentence
Requirement towards the IE :