dponti
commented
1 year ago The current definition of lithologyClassificationType is as follows: "Describes the classification system(s) used to define the lithology classification codes (eg. USCS) used within this system". Couple things of note 1) this property is of type gml:CodeType, so is intended to come from a controlled list of terms. So the terms Soil, Rock, ODOT Classification System, or any other term could be used, as long as the codespace points to an authority or a dictionary that defines the term; 2) lithologyClassificationType has a multiplicity of 1..* - so situations where an organization may combine standard classifications within a single "description system", those can be listed here. So if the combined system uses USCS for soil classification and AGI for rock and perhaps another classification for anthropogenic materials (eg. asphalt), they can all be presented.
Bottom line is that this property is somewhat open-ended, especially as single classification codes are also permitted (n fact required) with pointers to authorities for individual LithologyObservation objects. There would be value in defining a constrained set of "standard" values for this property, as well as perhaps doing the same for common lith classification codes. This is up to the community to help define. Happy to develop those dictionaries with you.
Finally, if there's a situation where an organization defines a soil in both USCS and AASHTO systems, then there each should be defined in separate LithologySystem's, since each LithologyObservation can only have one lith code
We need to define the controlled value list for LithologyClassificationType. These could be something like:
Soil, Rock, Other
It could also be something like: USCS, USDA, AASHTO, BSI, AS1726, etc.
The challenge with something like the latter approach is most organizations don't have a specific system that it is strictly based upon. You also have potential scenarios where you want to have both USCS Classifications and AASHTO Classification for the same material which also routinely happens. Also, we are already specifying a codespace for the classificationCode so I am not convinced that having something like the latter approach is necessary.