Open mbeaufils opened 2 years ago
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
Well lithology
Well tops
Well log data
Data not tied specifically to a borehole
Scattered data
Property data
Fault polygon
Vertical faults
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
Observations / measurements based on a borehole:
Observation / measurements on a point
"DEM like" observation / measurement
Mapping observation
Geological Architecture
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...)