Dendro lookups standardization and update

[MattiasSealander]

A number of smaller updates can be made to tbl_dendro_lookup after a discussion with the dendrochronologists at the Lund Uni. dendro lab. These range from updates to the descriptions or name, to field type (e.g. character, boolean), to standardization of misspellings. Should these be treated within the same update or separated based on what form of update they are (name/description etc.)?

Have sent out a request from Lund in regards to description text to be used for tooltips, which matches description in this case. Should wait for that before moving forwards. Will summarize points to consider for variables below.

[MattiasSealander]

Waney edge
Difference between "nära W" and "W?", so these should be left as is but needs some documentation to describe the nuances.

• Nära W - osäkert (nära på, inom några årsringar)
• W? - Inte W men kan vara, viss nyansskillnad

Skapa en ny tabell för beskrivningar av värden? Ontologies? Där textsträngvärden är mappade till beskrivningar. Scope, name, description.

Bark
Not usually entered by expert, but can be asked for when the customer supplies the sample themself. Waney edge is more important.

No. of radii

• Plural of radius is radii, so name update needed
• Will always be numeric, so update field type to this

Kan även vara 'ODEF', låt vara som textsträng och lägg in i ontologi

Sapwood

• Numeric field, but needs a system to register uncertainty. In the case of dendro dates this was solved by adding plus/minus fields but that can be difficult since "Sapwood" is stored together with other lookups. Need to find a good solution.

Keep plus/minus and other uncert and > < etc. as text strings and interpret at render-time

• Count of no. of sapwood rings, but sometimes due to density or other issues it isn't possible to give exact no. Which leads to results such as "33 + 10" where the 10 is an estimate.
• Also needs to handle text with negative ("ej") and "nära" documentation.
  Okej med textfält så länge det är konsekvent, behöver även översättas till engelska

Not dated

• The use of X/Y/Z is code for samples where dating is not possible, however, they may be able to tell that some samples are the same (unknown) age. Those samples within that particular project that are the same age are marked either X/Y/Z etc. to link those together in the report.
• The V is code for Winter season
• numbers (e.g. X+2) thus means that it is same age as X but 2 extra years.
• All notes in this field can be treated as "not dated", but still important that this information is available.
• Possibly make this field boolean (dated/undated) with other info in new field, or possibly added as sample_description?
  Titta på species_association, kan ett liknande system appliceras här?

3 time series

• Change field name to "Earlywood/Latewood measurements"
• Lund explanation: "3 time series innebär att man har mätt upp earlywood för sig och latewood för sig, samt att man mätt hela årsringen och får därmed 3 värden. (Tänk dig en tall där du mäter den ljusa delen av ringer för sig och den mörka för sig). Denna term borde heta "earlywood and latewood measurements" eller något i den stilen."
• Boolean field, either does or does not match criteria

earlywood/latewood

• standardize to only "+ earlywood" or "- latewood"

Pith

• Change field name to "Distance to pith"
• Those samples with "x" should be changed to "odef" (undefined)
• Lund dendro people will look up strange values and report

"Inferred growth year"

• Change name of field to "estimated germination year"

[johanvonboer]

Toppen Mattias, har bara ett fåtal tillägg:

Bark

• Avsaknad av värde här är lika med "Ej B", d.v.s. avsaknad av bark. Detta fylls inte i av dendrokronologerna då det är ovanligt.

No. of radii

• Ett högre antal radier är även en indikator på en högre säkerhet i mätningen. Ingenting som påverkar db men kan vara bra för oss att känna till.

Sapwood

• Har värden som t.ex.: "(46) - Detta är endast ett heltal och bör formateras på det sättet i db. Citat-tecknet och parenteserna är endast en överflödig artifakt som kom som ett resultat av inmatningen.

Övrigt

• Värden som "Ej sp" / "Ej bark" och "ej daterat" bör antagligen översättas till engelska ifall de även fortsättningsvis ska vara fritextfält.
• Värden som ""ca 40", "c 40" och "~40" bör normaliseras till att anges på ett enhetligt/konsekvent sätt.
• 'Större än' och 'Mindre än' värden är angivna som deras respektive html-koder, exempelvis > 3 & < 3, men 'Större eller lika med' och 'Mindre eller lika med' är angivna som '≥ 10' respektive '≤ 5'. Föreslår att > / < förändras till '>' och '<' för att vara konsekvent.

[johanvonboer]

Har ett par punkter, främst gällande dateringar, som vi skulle behöva diskutera vid tillfälle:

1. Gällande "Estimated felling year, lower accuracy" så verkar det som att alla dateringar med ett lower-accuracy-värde även har "not dated"-flaggan satt.
2. När en datering har ett error_plus/minus-värde, relaterar detta då till det äldre eller yngre värdet? Det verkar som att alla dateringar med plus/minus-värden också enbart har värden för dess yngre årtal, vilket gör att det i praktiken inte blir någon fråga om vad som avses, men detta borde ges en bättre struktur. Alltid använda error_plus/minus-referenser istället för younger/older-fält?
3. Det går att specificera en datering som "Ca" genom en länk till tbl_error_uncertainty, men endast 3 dateringar har i dagsläget referenser till Ca. Vad är skillnaden mot younger/older samt error_plus/minus? Behövs konsekvens i hur vilka definitioner som finns och hur de används.
4. Detta är en detalj men alla dateringar har i dagsläget age_type 1, vilket är specificerat som "AD". Borde möjligtvis ändras till CE/BCE?
5. Endast 'komplexa' dateringar, så som Estimated felling year, har age_type och uncertainty-variabler. Icke-komplexa dateringar så som "Inferred growth year ≥" borde också ha age_type (och möjligtvis uncertainty) för att vara konsekvent. Tänk även på Pith som kan ha ett upper/lower spann.
6. Vi har två tabeller som känns väldigt snarlika; tbl_dating_uncertainty och tbl_error_uncertainty, borde dessa vara samma tabell?
7. Pith kan ha värden som "~ 20" och "< 5", borde inte detta istället anges som en rad i error_uncertainty?

[johanvonboer]

Bara en not om att Pith med prefixet " betyder att det handlar om "Measured width", ej antal ringar som i övriga fall.

[roger-mahler]

This CR has been archived.

[johanvonboer]

Change this to a discussion (in github?) @johanvonboer