You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lithology – we need to remove descriptions in the documentation that include dual use and add schema elements. Dual use makes it difficult to use/ensure people are transferring data consistently among vendors.
SP
The value that describes the geology (eg. "SM" or
"silty sand"; in the classification system defined in the
classificationSystem property of the associated
LithologySystem. This property should be used in preference
to lithDescription to define lithology for rigid definitions
that adhere to a specific classification system. Either a
classificationCode property or lithDescription property must
be present (or both).
Poorly Graded Sand
lithDescription should be use in conjunction with
classificationCode (eg. well-graded sand for classification
code = SW) to further describe the lithology or for a more
extensive description in lieu of using color, particleSize,
grainSizeDistribution, descriptiveProperties, and
constituents property elements (eg. well-graded sand (SW),
fine-grained, dark grey, massive, dry, hard). If there is no
rigidity of language in the classification system, then
lithDescription can be used instead of classificationCode,
but classificationCode is preferred where
applicable.
Our recommendation is that we have a classificationCode – that is just the “SP” not a text description.
We add a new field called classificationName – this would be something like “Poorly graded sand”
lithDescription would be used for the entire soil description or rock description. From what we have seen around the world, we should always be transmitting the entire description as the person who created the DIGGS file would see on their reports because expecting people to build the description from components is not always feasible. This will facilitate adoption.
More importantly from a data perspective, if we take this approach then whether it is a soil layer, rock layer, or other type of layer we would have a consistent way of reading/writing these layers.
The text was updated successfully, but these errors were encountered:
Lithology – we need to remove descriptions in the documentation that include dual use and add schema elements. Dual use makes it difficult to use/ensure people are transferring data consistently among vendors.
SP
The value that describes the geology (eg. "SM" or
"silty sand"; in the classification system defined in the
classificationSystem property of the associated
LithologySystem. This property should be used in preference
to lithDescription to define lithology for rigid definitions
that adhere to a specific classification system. Either a
classificationCode property or lithDescription property must
be present (or both).
Poorly Graded Sand
lithDescription should be use in conjunction with
classificationCode (eg. well-graded sand for classification
code = SW) to further describe the lithology or for a more
extensive description in lieu of using color, particleSize,
grainSizeDistribution, descriptiveProperties, and
constituents property elements (eg. well-graded sand (SW),
fine-grained, dark grey, massive, dry, hard). If there is no
rigidity of language in the classification system, then
lithDescription can be used instead of classificationCode,
but classificationCode is preferred where
applicable.
Our recommendation is that we have a classificationCode – that is just the “SP” not a text description.
We add a new field called classificationName – this would be something like “Poorly graded sand”
lithDescription would be used for the entire soil description or rock description. From what we have seen around the world, we should always be transmitting the entire description as the person who created the DIGGS file would see on their reports because expecting people to build the description from components is not always feasible. This will facilitate adoption.
More importantly from a data perspective, if we take this approach then whether it is a soil layer, rock layer, or other type of layer we would have a consistent way of reading/writing these layers.
The text was updated successfully, but these errors were encountered: