search

opengeospatial / Geotech

19 stars 8 forks source link

Geotechnical model #6

Open mbeaufils opened 2 years ago

mbeaufils commented 2 years ago

Proposed members :

Alexis-SERIEYS commented 2 years ago

Reading the definition of the object "Geotechnical Unit", I understood that "Discrete Discontinuity" should be a specific geotechnical unit wich is a surface. I agreed with that.

Do you confirm that "Discrete Discontinuity" is a specifcation of the Geotechnical Unit

neilchadwick-dg commented 2 years ago

This comment could apply to any of the types of model.

First, I think we should have Model as a thing/object above all the model subtypes. Possibly Ground model if you prefer (this is what we do in AGSi, but I know the term ground model in controversial - unfortunately EC7 uses this term in a different way to confuse matters).

The semantics of having a geotechnical model with some of the things listed I am ok with. However, I just wanted to point out how we do things in AGSi (which I think is a good solution, but then I'm biased because I wrote it!)

In AGSi we have the concept of a model object agsiModel which can be of any type. The type is simply defined as an attribute. The terms we recommend users to use are influenced by the work of the predecessor project to this (which you can see here which in turn was influenced by the work of IAEG 25 , which we must consider.

The models are then formed by elements agsiModelElement. The elements will typically be a 'unit' of some type, but they could also be faults, surfaces or anything else. The type of element is defined by an attribute. This is where geotechnical unit, geologal unit are found. AGSi uses the the same OGC/CGI vocabulary that @mbeaufils is suggesting (again, part of the previous work on terminology

The geometry and data (properties and/or parameters) are then defined by further attributes - in this case we embed geometry and data objects as required.

The advantage of our approach is that it is flexible and extensible. We do not have to anticipate every type of unit that may be used.

You can see from this that AGSi is basically collecting and attributing bits of geometry. It does not currently allow the geology (or geotechnics or ...) to be described and linked semantically, e.g. unit 1 conformably overlies unit 2, etc. We have not forgotten about this. We have an idea for something called agsiFeature to address this. Each element would be able to link to a feature, and the features could be linked. However, we have decided to leave this for a future version, because:

Note that the idea of having the geometric and semantic definitions of elements running separately, in parallel, was inspired by OGC, in particular CityGML.

FYI, below is the model part of the AGSi schema. Data, geometry and observation are included below what you see. image

neilchadwick-dg commented 2 years ago

See also my comments on #22 which are relevant to this.

PieGARNIER commented 2 years ago

This is very interesting Neil, thank you very much.

As I understand this, I think the AGS model would also work, but the designation of different models (geological, geotechnical, hydrogeological) has been proposed to ensure no confusion, as well as to save "time & space" since numerous objects will be listed!

As you said also, considering Books A to C, links between models need to be implemented (Various book C design models could refer to only 1 Book A geological model), which may not be possible with the current AGS designation.