Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use case 1 : The road to the geological model #50

Open
mbeaufils opened this issue Sep 22, 2022 · 4 comments
Open

Use case 1 : The road to the geological model #50

mbeaufils opened this issue Sep 22, 2022 · 4 comments
Labels
Use case Use case description to identify APIs roles

Comments

@mbeaufils
Copy link
Collaborator

mbeaufils commented Sep 22, 2022

This is to explicit the data the geologist / geotechnical engineer will try to find and look at in order to build a comprehension of the geological context of the project.
The idea is to identify which APIs performing which queries on which data can help.
Also please detail (eg. not saying only borehole logs, but stratigraphy, lithology, etc...)

@mbeaufils mbeaufils added the Use case Use case description to identify APIs roles label Sep 23, 2022
@dponti
Copy link
Collaborator

dponti commented Oct 13, 2022

One 3D geologic modeling package I am familiar with is EarthVision, which can be used to construct, visualize and query geologic structure models (with unit volumes, surfaces and faults) as well as the creation and visualization of property models (any property with a numeric value). Book A type data used as input to these models are in ascii fixed-length or delimited ascii format with specific headers From our geotech schema of objects, any API would need to be able to extract the following category of information with these specified properties:

From boreholes/wells:
Well Path data

  • wellid, x, y, z, measured depth for each record.
  • At minimum, each borehole(well) is defined by two records - one for the top of the well and one for the bottom. Complex well paths can be described by any number of records

Well lithology

  • wellid, top measured depth, base measured depth, lithology (name of lith unit)

Well tops

  • wellid, horizon/unit top name, measured depth, dip, dip azimuth

Well log data

  • wellid, measured depth, log value 1, log value 2, etc.
  • This type of file can hold data from wireline logs, or any property identified at a single depth in a well (eg. SPT, CPT data)

Data not tied specifically to a borehole

Scattered data

  • x, y, z1, z2, etc. as basic fields, data organized along a line (eg. borehole or seismic line) can include a wellid or lineid field
  • This type of data is primary input into 2D gridding (surface modeling) calculations., Z fields give the elevation of any property for which you wish to calculate a surface (eg. llth, horizon top, fault surface)

Property data

  • x, y, z, property value
  • This type of data is primary input into 3D gridding

Fault polygon

  • x,y vertices defining a closed polygon. The polygon may have holes
  • defines the location of a non-vertical fault crossing a horizon or the clipping bounds of a gridded fault surface

Vertical faults

  • x, y vertices of a linestring, plus fault number
  • defines boundaries that control gridding extent of a surface

@neilchadwick-dg
Copy link
Collaborator

neilchadwick-dg commented Oct 13, 2022

A few random observations:

  • For successful ground modelling we should start with a conceptual model. This may be very simple: identification of the expected sequence of strata, and a decision made on the 'geological units' to be adopted. Ideally this is input to the GI so that the geological units are identified and coded correctly at the start. If not, there is a reconciliation to do afterwards, which may lead to 'factual' (Book A borehole) units being different to the Book B (model) units. May want to have a think about how to deal with this.

  • Don't forget the ground surface (topography). Provides detail between borehole locations.

  • Should this surface be the existing or a proposed future surface? For a geological model most likely to be 'existing'. However, my suggestion is that we should not care either way. The user should decide what they want to put in their model.

  • For a geological model, most likely that the 'properties' included for a particular model unit would be a summary of the factual data for that unit, e.g. for each measured property (or possibly an EC7 derived property): range, mean/median (if appropriate - sometimes it is not) and number of results.

  • Don't forget that when generating the top surface of a unit from borehole data, the algorithm used will likely need to ensure that only the topmost top surface data is used. This is because a borehole log (i.e. Book A data) may, correctly according to standards, split a geological unit into more than one depth range. In the UK this happens more often than not. It is perhaps more of an issue for the receiving application, or an API design if the API is attempting to process this. It can get complicated if there is a unit with an occurrence of another unit within the first unit (e.g. a lens), or if there is some 'uncoded' core loss within the borehole.

@Didymograptus
Copy link

Simple data requirements:
(the following may all be used to create a model they are not exclusive to one particular model)
The properties of the layers may or may not be required

Models require ground surface data. Which may be the upper geology layer, or combination of upper geology layers.

From raw data:
PointID,inclination,max depth?
Point ID,x,y,z,c of top of geological layers where c = name of the geological layers
x,y,z,c of discontinuities where c = dip and strike

From semi nterpreted/modelled data
2D+ surface shapes of:
geology
discontinuities (fault zones)

From interpreted/modelled data
3D solid shapes of:
geology
discontinuities (fault zones)

@mbeaufils
Copy link
Collaborator Author

mbeaufils commented Oct 19, 2022

A tentative of summary based on current contributions + discussion from the 13/10 meeting:

Identify available SamplingFeatures (boreholes, samples, ...) based on location, based on other criteria

SamplingFeatures description

  • For a borehole, including its shape, ie. the points that constitute the borehole path.

Observations / measurements based on a borehole:

  • Category values (eg. lithology, stratigraphy, ...) : FromDepth/ToDepth or Top
  • Log data : Line or point

Observation / measurements on a point

  • x, y, z, property value. Note: This type of data is primary input into 3D gridding

"DEM like" observation / measurement

  • x, y, z1, z2, etc. as basic fields, data organized along a line (eg. borehole or seismic line) can include a wellid or lineid field. Note: This type of data is primary input into 2D gridding (surface modeling) calculations., Z fields give the elevation of any property for which you wish to calculate a surface (eg. llth, horizon top, fault surface)
  • eg topography

Mapping observation

  • Points, lines or polygons that represents part of shapes of GeologicUnits, Fault, Discontinuities
  • Could also be 3D shapes from existing models

Geological Architecture

  • List of Units + relationship between them (Erod, Onlap)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Use case Use case description to identify APIs roles
Projects
None yet
Development

No branches or pull requests

4 participants