Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lithology Object - Enhancements/Corrections #36

Open
sdeaton75 opened this issue Nov 4, 2022 · 0 comments
Open

Lithology Object - Enhancements/Corrections #36

sdeaton75 opened this issue Nov 4, 2022 · 0 comments

Comments

@sdeaton75
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant