Use case 3 : The road to the geotechnical model

[mbeaufils]

This is to explicit the data the geotechnical engineer will try to find and look at in order to build a comprehension of the geotechnical context of the project. The idea is to identify which APIs performing which queries on which data can help.

[neilchadwick-dg]

I struggle slightly with the difference between geotechnical model and geotechnical synthesis model. Some of the following may be addressing the latter.

(1) Determine geometry of geotechnical model

Get geometry of geological units in geological model, typically filtered to one unit (but possibly more...). May also be filtered for a particular area/location.

Note : Often a geological unit = geotechnical unit, but not always the case - geological units may be split or combined to form geotechnical units

Also query exploratory hole locations and show these in model view as this can inform uncertainty that the geotechnical model should consider.

Note: there may be more advanced ways of showing and dealing with uncertainty, but these are best left to the application using the data as there are no agreed common methodologies for this.

Geometry of faults etc. - will influence how model is built

Note that whilst the focus may be on one unit as a time, the user will need to remain aware of how the units relate to each other, i.e. no gaps or overlaps in the geotechnical model!

(2) Determine properties and parameters for geotechnical

Get summary of target properties, filtered by unit and area as applicable, e.g. range etc often included in reports. May be additional filters, e.g. 'investigation' (some data may be more reliable than other data).

Get full data for target properties, filtered by unit and area as applicable, Objective is to plot data and assess parameters for design.

[mbeaufils]

Thanks @neilchadwick-dg for this first shot. Clear objectives that I suppose we will all agree on.

My expectations for this issue are more about "what do you look at" to achieve (1) and (2) Does not necessarily have to be exhaustive.

[neilchadwick-dg]

I was starting with a fairly general overview.

On (1), in practice even if we have a 3D model at source, it is usually only practical to work in 2 dimensions at a time. So from the model we would produce sections and maybe contour or spot level plots for, say, the top of a particular unit. The geotechnical model boundaries then get assessed from this (although I'm possibly straying into the synthesis model here).

But is that depth of query best left for the applications only?

For (2), we generally look at data plots (e.g. the SPT plot) assessed parameters from there. Often looking at several plots of related data at the same time. We use our applications to help us filter and sort the data to fit our specific objectives. Some countries use statistical analysis too, but in the UK that is rare! Sometimes we may use data tables (with aggregation) if it is just the summary properties we are after - but even then we would usually plot the data too as this is better for showing up things like outliers.

The main issue here is the data must be delivered with the appropriate metadata so that we can interrogate it properly. That metadata may come from other objects, i.e. the hole data and sample data (e.g. sample type) in addition to the data from the specific test. Thinking about it - that is probably the main thing we need to keep in mind here.

[mbeaufils]

I was starting with a fairly general overview.

Yes sometimes it is good to back to the basics.

Regarding (1), I agree applications are here to help to build the cross sections / appropriate representations. Also I imagine the APIs to be called from the applications.

I am interested to know what enables to decide if we stick to the 1 geol unit = 1 geotech unit or go to a split / group. I guess the answer may rely in looking at some factual data that I would like to see identified...