opengeospatial
Use case 1 : The road to the geological model
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...)
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
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.
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)
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)