-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Following #373, where @phytoclast recommended providing SI conversions for some data elements. This is a good idea--but probably is more involved than we want soilDB to be in terms of how the raw data are being returned.
In general I think it is against our current ethos to be automatically changing things like this, but there are some instances where we do fix things (e.g. filling missing lowest horizon bottom depth, replacing NULL rock fragments with 0) that are clear-cut. I think for now I would prefer to stick to the data model and suggest folks propose a change to alternate units in the database. Now is the time to get stuff like this changed before we get too far with new Vegetation Plot standards, and while we have an forthcoming data model update...
Automatic conversion gets tricky... see questions below:
-
Should soilDB provide support for unit conversion where the NASIS metadata indicate data should be stored in English units?
-
If the user can opt in to the conversion it may be OK, but can we provide enough options that suit all user needs?
-
An example is Vegetation Transect
transectlengthis stored in units of feet, not meters. Should we provide an alternative derived column for the converted columns? i.e.transectlengthandtransectlength_m -
Which functions would need to handle unit conversion?
-
Which columns use non-SI units? And what units are used?
-
How to handle rounding when converting to SI units? Should decimal places be retained or rounded to whole numbers? Rounding to whole numbers in e.g. feet to meters results in some loss of "information", but may not be meaningful loss in most applications. E.g. 10 points on a 100 ft transect would all result in unique values in meters. 100 points on a 100 foot transect would result in non-uniqueness