search

inbo / forrescalc

Calculation of aggregated values on dendrometry, regeneration and vegetation of forests, starting from individual tree measures from Fieldmap
https://inbo.github.io/forrescalc/
GNU General Public License v3.0
0 stars 0 forks source link

datacontrole scriptmatig - MINST DRINGEND #66

Open leymanan opened 3 years ago

leymanan commented 3 years ago

Als er tijd is, datacontrole in scripts gieten. Zie folder op gdrive: ....\PRJ_BOSECO_ALGEMEEN\PRJ_BR_VisualisatieResultaten\Datacontrole

Eventueel in eerste instantie als output een simpele lijst van "fouten" (plot_id, periode, tree_id, ...) : overzicht van wat we checken in "PROCEDURE_DATACONTROLE_PeterVdK_vs2.doc" (https://docs.google.com/document/d/1etpJoinb-gsY79oye7naN7MlKQac3szK?rtpof=true&authuser=anja.leyman%40inbo.be&usp=drive_fs) Daarna echt systeem opzetten: zie "OpbouwDatacontroleEersteAanzet.gdoc" (https://docs.google.com/open?id=12NbFRsMzmA8Q5f_iJvWTlgUglRBDYd2RVRLVF5z2TBQ&authuser=anja.leyman%40inbo.be&usp=drive_fs), daar heben we vroeger al eens over gebrainstormd

leymanan commented 9 months ago

ok

Op ma 12 feb. 2024 14:06 schreef Els Lommelen @.***>:

In verband met die opeenvolgende periodes heb ik alvast enkele vragen:

  • hoe noem ik de functie die dit checkt? check_tree_evolution(), check_tree_growth(), check_tree_growth_anomal(), check_tree_oldid(),...

ik vind check_tree_evolution() wel goed! (3de vond ik ok goed (anomal), maar is meer dan groei)

Ik zie net dat de tabel trees heet en we in de naamgeving van de functies ook altijd trees gebruiken en niet tree. Dus ik stel voor om er check_trees_evolution() van te maken?

— Reply to this email directly, view it on GitHub https://github.com/inbo/forrescalc/issues/66#issuecomment-1938645611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKXN5AOAPCIMUQPFI5EEGDYTIHTTAVCNFSM4YUYPRQ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTHA3DINJWGEYQ . You are receiving this because you authored the thread.Message ID: @.***>

ElsLommelen commented 9 months ago

Ik ga gemakkelijkheidshalve voor die verschillen tussen periodes bij elke boom gewoon de soort hangen die het eerste in de tabel voorkomt, wat bij shifters meestal zal betekenen dat de soort van periode 1 gebruikt wordt. Ik hoop dat dit ok is?

Sowieso zal voor elke check een beetje gelden dat bij een combinatie van fouten voor eenzelfde record, er mogelijk overbodige fouten tussen staan. Of omgekeerd, dat bepaalde fouten nog niet verschijnen zolang een andere fout niet opgelost is. Ik denk dan bv. aan bomen die verkeerdelijk als dood of levend aangeduid staan (en die daardoor mogelijk het verkeerde decay stage ofzo hebben), of ook aan het geval hierboven waarbij een diameterverschil al dan niet afwijkend kan zijn afhankelijk van de soort. Dus jij en Peter zullen sowieso iteratief die scripts moeten blijven runnen tot alles opgelost is, dat is volgens mij niet te vermijden. (Uiteraard kan je wel bepaalde records in de databank markeren als 'gecontroleerd maar afwijkend op xxx' om te vermijden dat ze telkens in de lijst verschijnen terwijl ze gecontroleerd zijn. Nog te bespreken op welk veld het script zich kan baseren om gecheckte gegevens niet opnieuw te controleren.)

leymanan commented 9 months ago

Ik ga gemakkelijkheidshalve voor die verschillen tussen periodes bij elke boom gewoon de soort hangen die het eerste in de tabel voorkomt, wat bij shifters meestal zal betekenen dat de soort van periode 1 gebruikt wordt. Ik hoop dat dit ok is?

Als soort verandert tss twee periodes, is de soort van de tweede periode meestal de meest correcte. In Fieldmap verschijnt immers een melding als de soort wijzigt tss twee periodes, dus de terreinploegen hebben er dan wel over nagedacht. Ik dacht ook dat de soort van periode 1 dan met terugwerkende kracht automatisch aangepast wordt , maar vrees dat we daar niet op kunnen rekenen, zeker niet bij de oudere opnames.

leymanan commented 9 months ago

Sowieso zal voor elke check een beetje gelden dat bij een combinatie van fouten voor eenzelfde record, er mogelijk overbodige fouten tussen staan. Of omgekeerd, dat bepaalde fouten nog niet verschijnen zolang een andere fout niet opgelost is. Ik denk dan bv. aan bomen die verkeerdelijk als dood of levend aangeduid staan (en die daardoor mogelijk het verkeerde decay stage ofzo hebben), of ook aan het geval hierboven waarbij een diameterverschil al dan niet afwijkend kan zijn afhankelijk van de soort. Dus jij en Peter zullen sowieso iteratief die scripts moeten blijven runnen tot alles opgelost is, dat is volgens mij niet te vermijden. (Uiteraard kan je wel bepaalde records in de databank markeren als 'gecontroleerd maar afwijkend op xxx' om te vermijden dat ze telkens in de lijst verschijnen terwijl ze gecontroleerd zijn. Nog te bespreken op welk veld het script zich kan baseren om gecheckte gegevens niet opnieuw te controleren.)

ok!

ElsLommelen commented 9 months ago

Ik ga gemakkelijkheidshalve voor die verschillen tussen periodes bij elke boom gewoon de soort hangen die het eerste in de tabel voorkomt, wat bij shifters meestal zal betekenen dat de soort van periode 1 gebruikt wordt. Ik hoop dat dit ok is?

Als soort verandert tss twee periodes, is de soort van de tweede periode meestal de meest correcte. In Fieldmap verschijnt immers een melding als de soort wijzigt tss twee periodes, dus de terreinploegen hebben er dan wel over nagedacht. Ik dacht ook dat de soort van periode 1 dan met terugwerkende kracht automatisch aangepast wordt , maar vrees dat we daar niet op kunnen rekenen, zeker niet bij de oudere opnames.

Achteraf gezien een kleintje om de laatste periode te nemen, dus ik heb het aangepast.

ElsLommelen commented 9 months ago

Ruwweg komt her erop neer dat de verschillen (verschilPerimeter, verschilHoogte, verschilAfstand) berekend worden, en op basis daarvan gekeken wat daarin de outliers zijn obv boxplot(). Zo hoor ik van Leen dat bv. bij verschilPerimeter vaak Populier zit, omdat die sneller groeit dan de meeste andere soorten.

Voor omtrek en hoogte wordt enkel gekeken naar levende, individuele bomen (geen hakhout: dat is niet één op één gekoppeld).

In verband met dat laatste: ik veronderstel dat de meetresultaten van hakhout niet in tabel Trees zitten, en dat het dus ok is dat ik het verschil in omtrek en hoogte bekijk voor alle levende bomen in trees? Of is het om een of andere reden toch nodig om enkel de individuele bomen eruit te filteren?

ElsLommelen commented 9 months ago

Of we zouden ook kunnen beslissen om vanaf een bepaald aantal bomen enkel de specifieke outliers van de soort weer te geven (wat een voordeel kan zijn voor gemiddeld snelgroeiende bomen zoals wilg, of gemiddeld traaggroeiende bomen, die een grote kans hebben om bij de ouliers voor alle soorten terecht te komen zonder dat het afwijkende bomen zijn voor die soort).

dat lijkt me wel een goed idee! want ook niet zo eenvoudig om snel en traaggroeiend te onderscheiden, er zijn altijd randgevallen

Euh, en vanaf hoeveel bomen zou ik dan enkel de specifieke outliers van de soort moeten weergeven? Voorlopig heb ik het zo opgelost dat ik altijd beiden weergeef, dus zowel de outliers op soortniveau als de outliers van alle soorten behalve populier. Ik heb wel andere omschrijvingen gegeven, zodat je ze kan onderscheiden:

Eventueel kan je het voorlopig zo laten en op basis hiervan testen waar onterechte outliers verschijnen, en op een later moment aangeven vanaf hoeveel individuen voor een soort de outliers voor het totaal niet meer weergegeven moeten worden?

ElsLommelen commented 9 months ago

Nog een vraag laatste vraag voor dit onderdeel (vermoed ik): in de procedure van de datacontrole van Peter staat ook een check waarbij bomen met eenzelfde XY en zonder verwijzing naar elkaar via OldID gekoppeld worden. Dit heb ik nog niet in het script toegevoegd. Is dit nodig/nuttig? Ik ga ervan uit dat ik dit enkel moet testen voor bomen die in dezelfde plot staan? Zoek ik enkel in opeenvolgende perioden, of ook bv. tussen periode 1 en 3, of tussen 0 en 2 of 0 en 3?

ElsLommelen commented 9 months ago

Ik heb intussen ook de overkoepelende functie check_data_fmdb() toegevoegd die alle checks na elkaar uitvoert en de resultaten samenvoegt. In verband met uw eerdere suggestie hierover, heb ik toch wel een opmerking.

In dat kader zou het goed zijn dat er in de output-tabel volgende lege velden toegevoegd worden:

  • corrected_field: character (bv. DBH_mm of Species of ...)
  • corrected_value: number (bv. 95 of 2 of ...)
  • checked: logical (TRUE or FALSE): om aan te geven of de anomalie gecheckt is, zodat die bij een volgende datacontrole niet terug opgevist wordt

Deze gegevens ga je (ook) in de databank zelf (of elders) moeten opslaan, vrees ik. Als deze functie(s) opnieuw gerund worden, zal het script opnieuw de gegevens uit de databank opladen en zich daarop baseren om te bepalen wat opnieuw gecheckt moet worden. Zoals eerder aangegeven, kan ik hierbij een extra kolom inladen en de records waarin hier 'gecontroleerd maar afwijkend in xxx' of iets dergelijks staan, negeren voor een welbepaalde kolom of test. Gegevens die aangepast zijn ('corrected' zoals je hierboven voorstelt), zullen dan wel opnieuw gecheckt worden of ze na aanpassen wel in orde zijn. Zoals eerder aangegeven: het kan zijn dat er na het oplossen van 1 probleem nieuwe problemen opduiken (bv. pas als je een missing value aangevuld hebt, zal deze op juistheid gecheckt worden), dus het is wel belangrijk dat aangepaste records opnieuw gecheckt worden tot er geen enkele fout meer gemeld wordt. En het is voor gebruikers van je databank sowieso ook belangrijk dat die afwijkende gegevens gemarkeerd zijn.

Het scenario wat jij voorstelt, begrijp ik eigenlijk niet zo goed: je vraagt om lege kolommen toe te voegen, maar ik neem aan dat je die zelf ook kan toevoegen op het moment dat je die wil aanvullen. Dan heb je een tabel die aangeeft wat nagekeken moet worden, en waarin je aangeeft dat iets gecheckt is, maar ik snap niet goed hoe ik dan moet zorgen dat de datacontrole niet opnieuw gedaan wordt. Want bij een volgende datacontrole is die tabel waarschijnlijk hopeloos verouderd (bv. old_id aangepast, gegevens aangepast waardoor je evt. andere outliers krijgt voor de walkers of de diameterverandering, koppeling tussen Trees en Shoots in orde gemaakt, soort bij shifter aangepast,...), en het gaat quasi onmogelijk zijn om die tabel scriptmatig terug met je databanktabel te koppelen (waar misschien ook om andere redenen in tussentijd nog aanpassingen in gemaakt zijn). En zoals in de vorige paragraaf aangegeven: het is niet omdat je in 1 record 1 fout aangepast (checked = TRUE), dat er geen andere fouten op de radar kunnen komen. Daarom dat opgeloste fouten beter opnieuw gecontroleerd zouden worden, enkel 'echte afwijkingen' die juist waren, wil je negeren bij de checks.

Voor alle duidelijkheid: ik kan me voorstellen dat het voor het oplossen van de fouten wel nuttig is om met de outputtabel van de functie te werken (aanduiden welke records je nagekeken hebt,...), maar ik denk dat je voor het 'negeren van anomalieën bij volgende datacontroles' best een zo beperkt mogelijk lijstje maakt met hetgeen echt afwijkt en dit liefst in of zo dicht mogelijk bij de databank bewaart, want dit maakt in se deel uit van je data (net zoals de gegevens in plotdetails over het al dan niet uitvoeren van dendrometrische gegevens of vegetatiegegevens deel uitmaken van je data). Gebruikers van je data willen voor sommige analyses die anomalieën eruit filteren, en voor andere analyses niet, dus ik zou echt aanraden om na te denken over iets wat de anomalieën dichtbij je data markeert. (Gemakkelijkste lijkt me in de tabel zelf, dan is er nooit twijfel over waar de anomalie zich voordoet.)

Enfin, om over na te denken...

leymanan commented 9 months ago

Voor omtrek en hoogte wordt enkel gekeken naar levende, individuele bomen (geen hakhout: dat is niet één op één gekoppeld).

In verband met dat laatste: ik veronderstel dat de meetresultaten van hakhout niet in tabel Trees zitten, en dat het dus ok is dat ik het verschil in omtrek en hoogte bekijk voor alle levende bomen in trees? Of is het om een of andere reden toch nodig om enkel de individuele bomen eruit te filteren?

Hakhout zit wel in tabel trees, niet de individuele stammen, maar wel de stoof in zijn geheel. Dus toch nodig om individuele bomen eruit te filteren: qIndShootCop = 10

leymanan commented 9 months ago

Nog een vraag laatste vraag voor dit onderdeel (vermoed ik): in de procedure van de datacontrole van Peter staat ook een check waarbij bomen met eenzelfde XY en zonder verwijzing naar elkaar via OldID gekoppeld worden. Dit heb ik nog niet in het script toegevoegd. Is dit nodig/nuttig? Ik ga ervan uit dat ik dit enkel moet testen voor bomen die in dezelfde plot staan? Zoek ik enkel in opeenvolgende perioden, of ook bv. tussen periode 1 en 3, of tussen 0 en 2 of 0 en 3?

Ja, dat zou nuttig zijn. Inderdaad enkel in dezelfde plot en in opeenvolgende periodes.

Sowieso ook het omgekeerde checken: NIET dezelfde XY (meer dan 0.5m verschil bv., kan te weinig zijn, maar misschien daarmee starten), maar WEL dezelfde OldID

leymanan commented 9 months ago

Ik heb intussen ook de overkoepelende functie check_data_fmdb() toegevoegd die alle checks na elkaar uitvoert en de resultaten samenvoegt. In verband met uw eerdere suggestie hierover, heb ik toch wel een opmerking.

misschien moeten we hier eens online over praten, dan kan ik eens tonen hoe vbi opgebouwd is en kunnen we wat brainstormen. Past ev. do-NM 22/2 in NM? En ik vraag eens aan peter hoe hij dat ziet, of het mogelijk is om aan elke tabel een extra veld "anomaly" toe te voegen. Dat zou dan een txt-veld moeten zijn met vermelding welke anomaly goedgekeurd is. Wat met meerdere anomalieën? Dat zou ev. "multiple" kunnen zijn.

ElsLommelen commented 9 months ago

Nog een vraag laatste vraag voor dit onderdeel (vermoed ik): in de procedure van de datacontrole van Peter staat ook een check waarbij bomen met eenzelfde XY en zonder verwijzing naar elkaar via OldID gekoppeld worden. Dit heb ik nog niet in het script toegevoegd. Is dit nodig/nuttig? Ik ga ervan uit dat ik dit enkel moet testen voor bomen die in dezelfde plot staan? Zoek ik enkel in opeenvolgende perioden, of ook bv. tussen periode 1 en 3, of tussen 0 en 2 of 0 en 3?

Ja, dat zou nuttig zijn. Inderdaad enkel in dezelfde plot en in opeenvolgende periodes.

Sowieso ook het omgekeerde checken: NIET dezelfde XY (meer dan 0.5m verschil bv., kan te weinig zijn, maar misschien daarmee starten), maar WEL dezelfde OldID

Ja hoor, dat laatste heb ik wel gecheckt, maar daar dacht ik op basis van je eerdere uitleg begrepen te hebben dat ik alle outliers van het verschil in afstand moest geven (zie hier en [hier](https://github.com/inbo/forrescalc/issues/66#:~:text=mocht%20je%20willen..-,Ruwweg%20komt%20her%20erop%20neer%20dat%20de%20verschillen%20(verschilPerimeter%2C%20verschilHoogte%2C%20verschilAfstand)%20berekend%20worden%2C%20en%20op%20basis%20daarvan%20gekeken%20wat%20daarin%20de%20outliers%20zijn%20obv%20boxplot().,-Zo%20hoor%20ik)). Ik heb geen idee hoeveel outliers dat geeft als het verschil meestal 0 is. Laat ik het voorlopig zo en test je het eerst even uit, of kan/wil je er een exact getal op plakken?

leymanan commented 9 months ago

Sowieso ook het omgekeerde checken: NIET dezelfde XY (meer dan 0.5m verschil bv., kan te weinig zijn, maar misschien daarmee starten), maar WEL dezelfde OldID

Ja hoor, dat laatste heb ik wel gecheckt, maar daar dacht ik op basis van je eerdere uitleg begrepen te hebben dat ik alle outliers van het verschil in afstand moest geven (zie hier en [hier](https://github.com/inbo/forrescalc/issues/66#:~:text=mocht%20je%20willen..-,Ruwweg%20komt%20her%20erop%20neer%20dat%20de%20verschillen%20(verschilPerimeter%2C%20verschilHoogte%2C%20verschilAfstand)%20berekend%20worden%2C%20en%20op%20basis%20daarvan%20gekeken%20wat%20daarin%20de%20outliers%20zijn%20obv%20boxplot().,-Zo%20hoor%20ik)). Ik heb geen idee hoeveel outliers dat geeft als het verschil meestal 0 is. Laat ik het voorlopig zo en test je het eerst even uit, of kan/wil je er een exact getal op plakken?

ik test eerst wel eens uit! bedankt!

ElsLommelen commented 9 months ago

Wat met meerdere anomalieën? Dat zou ev. "multiple" kunnen zijn.

Als het haalbaar is, zou ik hier eerder kiezen voor een opsomming van de anomalieën, bv. gescheiden door een komma, wat als voordeel heeft dat er codematig gemakkelijk te filteren is op die anomalieën (bv. alle metingen met welbepaalde anomalie wegdoen en de rest behouden), en dat je bij 2 anomalieën nog altijd weet wat er mis is met de data (en je ze voor iets anders evt. wel nog kan gebruiken, testen op juistheid,...). Om over na te denken tegen ons overleg.

ElsLommelen commented 9 months ago

Hier heb ik nog een vraag van hierboven opgevist waarop ik nog geen reactie gehad heb. Bekijk je die nog even? (Ik heb trouwens alle opgeloste commentaren dichtgeklapt, enkel die i.v.m. de anomalieën en een paar kleine bemerkingen zonder vraag waar niet op gereageerd is, heb ik open gelaten.)

In het document "OpbouwDatacontroleEersteAanzet.gdoc" staat bij PlotDetails om te checken voor ontbrekende waarden ook Date_Veg, Date_reg, Fieldteam_Reg en Fieldteam_Veg, maar ik die dat niet in de tabel PlotDetails. Ik vermoed dat dit wijst op de velden Date en Fieldteam in de tabellen Vegetation en Regeneration? En dat die dus ook best aan de functie met checks van die respectievelijke functies toegevoegd worden?

Ik ga er ook van uit dat rA1 tot rA4 enkel ingevuld moeten worden bij een CP, en LengthCoreArea_m2 en WidthCoreArea_m2 enkel bij een CA?

ElsLommelen commented 9 months ago

Nog een laatste vraagje, en dan denk ik dat we met dit issue klaar zijn (na ons overleg): in het document met de procedure van de datacontrole van Peter staat dat het leggen van de linken tussen de 1ste en de 2de set voor coppice beter gaat via CoppiceID dan via OldID. Maar wat betekent dit precies, en moet ik in dit verband nog extra tests toevoegen, en zo ja, wat juist?

Wat ik dus al heb, is dat ik test dat CoppiceID ingevuld is ingeval van IndShtCop != 10, en dat het niet ingevuld is ingeval van IndShtCop == 10 (in functie check_data_trees()). In check_trees_evolution() test ik ook de verschillen tussen opeenvolgende periodes (zombies, shifters,...), maar dit is altijd op basis van OldID, en voor diameter en height check ik die enkel voor individuele bomen.

Mijn vraag is dus: moet er voor hakhout nog iets extra gebeuren op basis van CoppiceID? Bv. testen van verschil in diameter of height? (Ik dacht dat je eerder al aangegeven had dat dat bij hakhout niet kon, omdat die stammen niet individueel gekoppeld kunnen worden.) Of testen van dood-levend (zombies),... via CoppiceID i.p.v. OldID? Of het testen van de XY op basis van CoppiceID i.p.v. OldID? (Je mag de vraag uiteraard donderdag ook live beantwoorden.)

leymanan commented 9 months ago

In het document "OpbouwDatacontroleEersteAanzet.gdoc" staat bij PlotDetails om te checken voor ontbrekende waarden ook Date_Veg, Date_reg, Fieldteam_Reg en Fieldteam_Veg, maar ik die dat niet in de tabel PlotDetails. Ik vermoed dat dit wijst op de velden Date en Fieldteam in de tabellen Vegetation en Regeneration?

Inderdaad

En dat die dus ook best aan de functie met checks van die respectievelijke functies toegevoegd worden?

Dat zou fijn zijn

leymanan commented 9 months ago

Ik ga er ook van uit dat rA1 tot rA4 enkel ingevuld moeten worden bij een CP, en LengthCoreArea_m2 en WidthCoreArea_m2 enkel bij een CA?

inderdaad

ElsLommelen commented 9 months ago

In het document "OpbouwDatacontroleEersteAanzet.gdoc" staat bij PlotDetails om te checken voor ontbrekende waarden ook Date_Veg, Date_reg, Fieldteam_Reg en Fieldteam_Veg, maar ik die dat niet in de tabel PlotDetails. Ik vermoed dat dit wijst op de velden Date en Fieldteam in de tabellen Vegetation en Regeneration?

Inderdaad

En dat die dus ook best aan de functie met checks van die respectievelijke functies toegevoegd worden?

Dat zou fijn zijn

Is in orde. Blijkbaar had ik dat al toegevoegd in commits dc39ae7 en 48a351f (waarschijnlijk met het idee dat ze terug verwijderen gemakkelijker is dan achteraf opnieuw uitzoeken wat er moest gebeuren ;-) ), en het vooral gevraagd om zekerheid te hebben dat dit wel juist en relevant was.

ElsLommelen commented 9 months ago

Ik ga er ook van uit dat rA1 tot rA4 enkel ingevuld moeten worden bij een CP, en LengthCoreArea_m2 en WidthCoreArea_m2 enkel bij een CA?

inderdaad

Ok, dan heb ik dat ook juist gedaan. Bedankt!

leymanan commented 8 months ago

Nog een laatste vraagje, en dan denk ik dat we met dit issue klaar zijn (na ons overleg): in het document met de procedure van de datacontrole van Peter staat dat het leggen van de linken tussen de 1ste en de 2de set voor coppice beter gaat via CoppiceID dan via OldID. Maar wat betekent dit precies, en moet ik in dit verband nog extra tests toevoegen, en zo ja, wat juist?

Hier wat info (uit één van mijn scripts)

The way we handle coppice wood is determined by the software we use in the field (FieldMap from Ifer). We look at coppice as if it was one tree (one record), with mean diameter of all shoots (representing a mean basal area) saved as the tree diameter, and an extra variable "TreeNumber" indicating how many shoots the coppice counts. Details on the shoots (exact diameter, decaystage, intact/snag of every shoot) are stored in a seperate table. Only the trees are linked between censuses, not the individual shoots. As a "tree" can only be dead or alive - not both - the living and the dead part of the coppice have a different tree_measure_id. Also, as coordinates have to be unique for each "tree", we have to use a minimal shift of the coordinates between the dead and the living part of one coppice tree (when they are both present at the same time).

For a correct link between coppice (both the living and the dead part), we use coppice-id to create a unique tree-id. Important to know is that XY may differ slightly between the living and dead shoots of the same coppice.

I'd suggest I give you a list of all stems (= individual trees + seperate shoots of coppice wood). Shoots of the same coppice will then have the same (non-unique) tree-id.

Trees_calc bevat een unieke tree_id per boom (die constant blijft doorheen de tijd), verschillend van de tree_measure_id uit fieldmap, die wel varieert doorheen de tijd..

Deze tree_id wordt in het package aangemaakt obv old_id.

OPGEPAST Bij hakhout kan/kon dit soms tot gemiste linken leiden. (zie ook "TreeMortalityData_DetailHakhout.Rmd")

Hakhoutstoven worden opgesplitst in een levend en dood deel, en elk deel wordt dan als een afzonderlijke boom beschouwd (een boom kan immers niet én levend én dood tegelijk zijn)

OldID wordt standaard toegekend aan het levende deel van de hakhoutstoof. Het dode deel wordt gelinkt via CoppiceID. Indien er enkel een dood deel is (en geen levend deel), dan wordt daar OldID aan toegekend.

Dat wil zeggen dat een koppeling via oldid enkel een probleem geeft wanneer er in één van de twee periodes zowel een levend als een dood deel voorkomt. In de andere gevallen is de koppeling die gebeurt via OldID correct.

OPLOSSING Daarom wordt de tree_id voor hakhout dat in één van de twee periodes uit zowel een levend als een dood deel bestaat, bepaald obv coppice_id.

Voor de 11 verwerkte CP's + KV Muizenbos is die koppeling gecheckt en OK bevonden.

Dit houdt in dat tree_id niet meer uniek is (zelfde tree-id voor een levende en een dode "boom" (stoof)) Dat geeft dan weer problemen wanneer we er een "wijde" tabel van willen maken.

Daarom wordt er een _a of _b toegevoegd, afh. of het om levend of dood deel van een hakhoutstoof gaat. Indien we toch één ID per hakhout willen, ongeacht levend/dood, dan kunnen we makkelijk de _a en _b verwijderen (= tree_id_non_unique).

leymanan commented 8 months ago

Wat ik dus al heb, is dat ik test dat CoppiceID ingevuld is ingeval van IndShtCop != 10, en dat het niet ingevuld is ingeval van IndShtCop == 10 (in functie check_data_trees()). In check_trees_evolution() test ik ook de verschillen tussen opeenvolgende periodes (zombies, shifters,...), maar dit is altijd op basis van OldID, en voor diameter en height check ik die enkel voor individuele bomen.

is al zeker ok

Mijn vraag is dus: moet er voor hakhout nog iets extra gebeuren op basis van CoppiceID? Bv. testen van verschil in diameter of height? (Ik dacht dat je eerder al aangegeven had dat dat bij hakhout niet kon, omdat die stammen niet individueel gekoppeld kunnen worden.) Of testen van dood-levend (zombies),... via CoppiceID i.p.v. OldID? Of het testen van de XY op basis van CoppiceID i.p.v. OldID? (Je mag de vraag uiteraard donderdag ook live beantwoorden.)

ElsLommelen commented 8 months ago

OPLOSSING Daarom wordt de tree_id voor hakhout dat in één van de twee periodes uit zowel een levend als een dood deel bestaat, bepaald obv coppice_id.

Voor de 11 verwerkte CP's + KV Muizenbos is die koppeling gecheckt en OK bevonden.

Dit houdt in dat tree_id niet meer uniek is (zelfde tree-id voor een levende en een dode "boom" (stoof)) Dat geeft dan weer problemen wanneer we er een "wijde" tabel van willen maken.

Daarom wordt er een _a of _b toegevoegd, afh. of het om levend of dood deel van een hakhoutstoof gaat. Indien we toch één ID per hakhout willen, ongeacht levend/dood, dan kunnen we makkelijk de _a en _b verwijderen (= tree_id_non_unique).

In hoeverre is het wenselijk dat ik in de functie create_unique_tree_id() zorg dat deze _a en _b ook toegevoegd worden? (Dit is dus een functie die door gebruikers gebruikt kan worden voor dataverwerking.) Alternatief is dat ik enkel zorg dat deze bomen bij de checks niet ten onrechte als fout toegevoegd worden aan de lijst anomalieën.

leymanan commented 8 months ago

OPLOSSING Daarom wordt de tree_id voor hakhout dat in één van de twee periodes uit zowel een levend als een dood deel bestaat, bepaald obv coppice_id. Voor de 11 verwerkte CP's + KV Muizenbos is die koppeling gecheckt en OK bevonden. Dit houdt in dat tree_id niet meer uniek is (zelfde tree-id voor een levende en een dode "boom" (stoof)) Dat geeft dan weer problemen wanneer we er een "wijde" tabel van willen maken. Daarom wordt er een _a of _b toegevoegd, afh. of het om levend of dood deel van een hakhoutstoof gaat. Indien we toch één ID per hakhout willen, ongeacht levend/dood, dan kunnen we makkelijk de _a en _b verwijderen (= tree_id_non_unique).

In hoeverre is het wenselijk dat ik in de functie create_unique_tree_id() zorg dat deze _a en _b ook toegevoegd worden? (Dit is dus een functie die door gebruikers gebruikt kan worden voor dataverwerking.) Alternatief is dat ik enkel zorg dat deze bomen bij de checks niet ten onrechte als fout toegevoegd worden aan de lijst anomalieën.

Dat zou natuurlijk wel handig zijn, als je daar nog tijd voor hebt. Dan bezorg ik je het script waarmee ik tot nu toe de id's van hakhout aanmaakte.

Maar 't is ook OK als je enkel zorgt dat deze niet bij de anomalieën terecht komen.

ElsLommelen commented 8 months ago

OPLOSSING Daarom wordt de tree_id voor hakhout dat in één van de twee periodes uit zowel een levend als een dood deel bestaat, bepaald obv coppice_id. Voor de 11 verwerkte CP's + KV Muizenbos is die koppeling gecheckt en OK bevonden. Dit houdt in dat tree_id niet meer uniek is (zelfde tree-id voor een levende en een dode "boom" (stoof)) Dat geeft dan weer problemen wanneer we er een "wijde" tabel van willen maken. Daarom wordt er een _a of _b toegevoegd, afh. of het om levend of dood deel van een hakhoutstoof gaat. Indien we toch één ID per hakhout willen, ongeacht levend/dood, dan kunnen we makkelijk de _a en _b verwijderen (= tree_id_non_unique).

In hoeverre is het wenselijk dat ik in de functie create_unique_tree_id() zorg dat deze _a en _b ook toegevoegd worden? (Dit is dus een functie die door gebruikers gebruikt kan worden voor dataverwerking.) Alternatief is dat ik enkel zorg dat deze bomen bij de checks niet ten onrechte als fout toegevoegd worden aan de lijst anomalieën.

Dat zou natuurlijk wel handig zijn, als je daar nog tijd voor hebt. Dan bezorg ik je het script waarmee ik tot nu toe de id's van hakhout aanmaakte.

Maar 't is ook OK als je enkel zorgt dat deze niet bij de anomalieën terecht komen.

Opgelost in commit 9436979f

ElsLommelen commented 8 months ago

In eerste instantie had ik de nummering van tree_id bij hakhout in create_unique_tree_id() fout gedaan omdat ik er verkeerdelijk van uitging dat die hetzelfde tree_id zou krijgen. Nu heb ik het anders aangepakt:

Ah, oei, terwijl ik dit schrijf, bedenk ik: als de boom op 2 opeenvolgende periodes een dood en levend deel heeft, gaat het mislopen. Dus ik ga er nog voor moeten zorgen dat tree_id dan gewoon via old_id van de vorige periode overgenomen wordt, en dat er geen extra _a of _b achter komt.

ElsLommelen commented 8 months ago

Bij deze zou dat in orde moeten zijn. Nu bij de checks nog testen of hier alles in orde is voor hakhout.

ElsLommelen commented 8 months ago

(uit eerdere commentaar over coppice_id)

  • walkers: dat is wel iets dat ik check: zelfde coppice-id, dan moeten de X en Y toch dicht bij elkaar liggen. Kan wel 30 cm schelen, maar toch niet meer normaal gezien
  • shifters: ook te checken: zelfde coppice-id, dan zelfde soort; ev. ook binnen eenzelfde periode te checken (levend en dood deel van zelfde stoof moet zelfde soort zijn)

Ik zal deze items sowieso testen in check_trees_evolution(), dat de verschillen tussen periodes checkt. En automatisch gaat daaruit ook naar voren komen als het dode en levende deel van eenzelfde boom verschillend zijn. Is het nodig om ditzelfde daarnaast ook nog eens te testen in functie check_data_trees() (dat problemen in tabel trees per periode checkt) voor verschillen in XY of soort tussen het levende en dode deel van een zelfde boom? Of ga je sowieso altijd alle checks runnen (evt. met check_data_fmdb()) en is het voldoende als die fout er bij een van de checks uitkomt?

leymanan commented 8 months ago

(uit eerdere commentaar over coppice_id)

  • walkers: dat is wel iets dat ik check: zelfde coppice-id, dan moeten de X en Y toch dicht bij elkaar liggen. Kan wel 30 cm schelen, maar toch niet meer normaal gezien
  • shifters: ook te checken: zelfde coppice-id, dan zelfde soort; ev. ook binnen eenzelfde periode te checken (levend en dood deel van zelfde stoof moet zelfde soort zijn)

Ik zal deze items sowieso testen in check_trees_evolution(), dat de verschillen tussen periodes checkt. En automatisch gaat daaruit ook naar voren komen als het dode en levende deel van eenzelfde boom verschillend zijn. Is het nodig om ditzelfde daarnaast ook nog eens te testen in functie check_data_trees() (dat problemen in tabel trees per periode checkt) voor verschillen in XY of soort tussen het levende en dode deel van een zelfde boom? Of ga je sowieso altijd alle checks runnen (evt. met check_data_fmdb()) en is het voldoende als die fout er bij een van de checks uitkomt?

Hangt af van hoeveel extra werk dat zou zijn: soms zijn er éénmalige opnames en dan zal ik niet standaard check_trees_evolution() runnen. Maar anderzijds, als zowel check_trees_evolution() als check_data_trees() in één functie samen zitten (check_data_fmdb()) , dan moet ik er gewoon aan denken om - zelfs al is er maar data van één periode - beide checks uit te voeren. En dan hoef jij niks extra's te programmeren.

ElsLommelen commented 8 months ago

Intussen heb ik gemerkt dat ik op het moment walkers en shifters in check_trees_evolution() sowieso al check zodra ze hetzelfde tree_id hebben (dus als er achtervoegsel _a of _b is, worden ze als ander tree_id beschouwd). Dus de 2 mogelijke checks om in te bouwen, zijn:

Dat laatste heeft wel als voordeel dat je je checks systematisch kan uitvoeren en er bv. eerst voor kan zorgen dat je data per periode in orde zijn (waarbij je normaal enkel fouten tegenkomt in de nieuw toegevoegde), voor je de functie uitvoert die de verschillen tussen de periodes weergeeft. Want als je bv. bij een boom een fout gemaakt hebt i.v.m. decay stage of alive/dead ofzo, dan krijg je onvermijdelijk bij check_data_evolution() nog eens dezelfde fouten omdat die in strijd zijn met eerdere gegevens van die boom. En als je de fouten op die lijst systematisch gaat proberen wegwerken, ga je achteraan vaak bij problemen uitkomen die al opgelost zijn.

Dus ik zal misschien toch maar best beide checks inbouwen, ik neem aan dat dit toch handiger werkt voor jullie? En zoveel werk is zo'n extra testje niet. (Elk testje is uiteraard weer een beetje extra werk, maar als het nuttig is, is die tijd snel terug verdiend.) (Ik heb ook geen idee over hoeveel fouten dat gaat: als je bij een eerste run tientallen fouten per functie krijgt, lijkt het me wel overzichtelijker om de checks-functies eerst allemaal afzonderlijk te runnen en per functie zoveel mogelijk op te lossen, en finaal check_data_fmdb() om te zien of alles in orde is. En als je maar 10 fouten in totaal krijgt voor een bepaalde periode, dan werkt het weer het vlotste als jullie direct check_data_fmdb() runnen.)

ElsLommelen commented 8 months ago

Voila, ik denk dat hiermee alles van dit issue opgelost is. In check_tree_evolution() heb ik bijkomend getest of niet met old_id gelink hakhout in opeenvolgende periodes geen shifters of walkers zijn, dus in de praktijk is dat tussen het dode deel van de stoof in de periode dat de stoof deels dood is en de volledige stoof in de periode dat de stoof nog volledig levend is. In check_data_trees() test ik of de levende en dode delen van dezelfde boom bij elkaar staan (geen walker) en van dezelfde soort zijn (geen shifter). En walkers op basis van old_id testte ik eerder al. Ik denk dat ik hiermee alles afgedekt heb?

Wel nog enkele kleine opmerkingen:

ElsLommelen commented 8 months ago

Nog een vraagje i.v.m. die checks: verwijst de kolom Coverage van tabel Herblayer naar qtotalCover of naar qCoverHerbs? Ik gebruik in mijn checks voorlopig de eerste, maar op basis van een fout die bij de checks naar boven komt, vraag ik me af of het niet de tweede zou moeten zijn.

ElsLommelen commented 8 months ago

(Nog een probleempje met hakhout opgemerkt en opgelost: een hakhoutstoof (ind_sht_cop 12) werd als fout aangeduid als die maar 1 stam had, maar hier werd geen rekening gehouden met het feit dat een hakhoutstoof kan bestaan uit een levende en een dode 'tree' met verschillende id. Opgelost in commit d9ef053)

ElsLommelen commented 8 months ago

En nog een vraag i.v.m. de check voor de verhouding diameter/hoogte: moet ik hier een waarde opgeven bij de output-tabel die de afwijkingen weergeeft? En zo ja, welke? De verhouding dbh/hoogte, of plak ik dbh en hoogte samen in een cel?

ElsLommelen commented 8 months ago
  • bij deze twee nieuwe tests heb ik voor de walker de afstand van 30 cm als grens gehanteerd (die je eerder al eens voorgesteld hebt), en bij de 'gewone' test van walkers via old_id duid ik de outliers aan op basis van de afstand. Wegens het beperkt aantal records lijkt het me voor die tests met de hakhoutstoven sowieso beter om een vaste waarde te nemen en niet te hopen dat die outliers een betrouwbaar resultaat geven. Houd ik het voor de gewone test van de walkers wel op outliers, of heb je hier ook liever een vaste grens?

In verband hiermee ook de volgende opmerking: bij wijze van test heb ik de check eens gerund op de hele fieldmapdatabank, en dat geeft redelijk wat walkers. Ik heb eens eentje nagerekend van een plot met zeer veel walkers (plot_id 200), en daar bleek de boom in opeenvolgende perioden minder dan 1 cm (0.0098 m) uit elkaar te staan. Oftewel: als je heel veel nullen hebt, gaat mogelijk alles wat niet exact 0 is, als outlier gezien worden. Dus als je niet te veel bomen als walkers wil gemarkeerd hebben, lijkt een vaste waarde me beter dan de outliers van de functie boxplot.

Trouwens, met die grens van 30 cm worden dode en levende delen van hakhoutstoven nog wel redelijk vaak als walker aangeduid, dus misschien wil je die waarde iets hoger nemen? Anderzijds heb ik de indruk dat voor een individuele boom de verschillen zelden aan 30 cm zullen geraken. Dus om eens over na te denken of op de dataset uit te testen welke waardes je hier wil.

ElsLommelen commented 8 months ago

Vraag i.v.m. layer Vegetation: homogeneous_id is nogal vaak "missing", is het de bedoeling om dat zoals browse_index en game_damage_number enkel als "missing" aan te geven het minstens eenmaal per plot ingevuld is? Ik zie dit nergens in de procedure van Peter vermeld, en in ons voorbereidend document staat het gewoon vermeld als te checken.

En is er eigenlijk een verschil tussen de homogeneous_id in Vegetation en die in Plots?

ElsLommelen commented 8 months ago

bij check_trees_evolution() geef ik alle bomen op minder dan 10 cm van elkaar die niet gekoppeld zijn, op als "on same place but not coupled". Ik merk dat hier waarschijnlijk ook wel wat fouten zitten in de zin dat dicht bij elkaar gelegen bomen ook opgegeven worden (in totaal zijn er een 90-tal meldingen voor de hele databank). Anderzijds ga je ook eventueel terecht gemelde fouten niet meer krijgen als die limiet nog smaller wordt dan 10 cm. Ik neem dus aan dat het ok is om die grens te behouden ondanks de onterechte meldingen? (Als dit als aberrant maar ok gemeld wordt in de databank en het script hieraan aangepast wordt, kunnen die na een eerste check door jullie altijd genegeerd worden.)

ElsLommelen commented 8 months ago

Wat is die IndShtCop = 11? En vooral, hoe behandel ik die?

(vooral: zijn er checks die ik hierop niet moet uitvoeren of net wel?)

leymanan commented 8 months ago

En nog een vraag i.v.m. de check voor de verhouding diameter/hoogte: moet ik hier een waarde opgeven bij de output-tabel die de afwijkingen weergeeft? En zo ja, welke? De verhouding dbh/hoogte, of plak ik dbh en hoogte samen in een cel?

misschien best dbh en hoogte samen in één cel

ElsLommelen commented 8 months ago

En nog een vraag i.v.m. de check voor de verhouding diameter/hoogte: moet ik hier een waarde opgeven bij de output-tabel die de afwijkingen weergeeft? En zo ja, welke? De verhouding dbh/hoogte, of plak ik dbh en hoogte samen in een cel?

misschien best dbh en hoogte samen in één cel

Doe ik dat dan gescheiden door een /? Fictief voorbeeld: 30 / 50, waarbij 30 de dbh in mm is, en 50 de hoogte in m. (Het mogelijk verwarrende is dat in de berekening ook een pi zit, maar vermits die functie waarschijnlijk enkel door insiders gebruikt wordt, is dat misschien geen probleem?)

leymanan commented 8 months ago

Doe ik dat dan gescheiden door een /? Fictief voorbeeld: 30 / 50, waarbij 30 de dbh in mm is, en 50 de hoogte in m. (Het mogelijk verwarrende is dat in de berekening ook een pi zit, maar vermits die functie waarschijnlijk enkel door insiders gebruikt wordt, is dat misschien geen probleem?)

Als ik het zo zie staan, is het misschien toch beter om de verhouding weer te geven: bv. 1.9 bij een dbh_mm = 300 en height_m = 50. Ik veronderstel immers dat in de tabel dbh_mm en height_m ook opgenomen zijn?

Functie wordt inderdaad enkel door insiders gebruikt, dus pi is geen probleem.

leymanan commented 8 months ago

Wat is die IndShtCop = 11? En vooral, hoe behandel ik die?

  • moet die een coppice_id hebben, of mag die geen coppice_id hebben?
  • kan het dat die dood is en decay stage 11 heeft?
  • kan het dat een dode boom met decay stage 12 in de volgende periode IndShtCop 11 krijgt met decay stage 11?
  • ...

(vooral: zijn er checks die ik hierop niet moet uitvoeren of net wel?)

Dat is wanneer er aan een zwaardere boom een dunnere spil uitschiet. Dat is dan geen individuele boom, maar ook geen hakhout, want geen twee evenwaardige spillen (b. dbh 40 cm en dbh 5 cm) Dat onderscheid was vooral vroeger van belang omdat we met de beperkingen van fieldmap zaten. Deze mogen op zelfde manier behandeld worden als individuele bomen, dus

leymanan commented 8 months ago

Vraag i.v.m. layer Vegetation: homogeneous_id is nogal vaak "missing", is het de bedoeling om dat zoals browse_index en game_damage_number enkel als "missing" aan te geven het minstens eenmaal per plot ingevuld is? Ik zie dit nergens in de procedure van Peter vermeld, en in ons voorbereidend document staat het gewoon vermeld als te checken.

En is er eigenlijk een verschil tussen de homogeneous_id in Vegetation en die in Plots?

Verschil: het ene is op plotniveau (met inbegrip van bomen), het andere gaat enkel over de kruidlaag.

Maar die op plotniveau is blijkbaar maar in een kwart van de plots ingevuld, en bovendien bijna altijd homogeen. Die op veg-niveau is al wat meer ingevuld, maar ook bijna 1/3de NIET ingevuld. Ook meestal homogeen. Ik heb net aan Peter gevraagd wat we daarmee doen, mogelijks is dat een veld dat niet meer opgenomen gaat worden. Ik laat dus nog iets weten. Het is zeker niet de bedoeling om dat als browse-index te behandelen, ik denk echt dat dat vaak vergeten is ...: dus ene plot wel en andere niet ingevuld binnen eenzelfde reservaat

leymanan commented 8 months ago

Nog een vraagje i.v.m. die checks: verwijst de kolom Coverage van tabel Herblayer naar qtotalCover of naar qCoverHerbs? Ik gebruik in mijn checks voorlopig de eerste, maar op basis van een fout die bij de checks naar boven komt, vraag ik me af of het niet de tweede zou moeten zijn.

inderdaad naar qCoverHerbs (de tweede)

ElsLommelen commented 8 months ago

Doe ik dat dan gescheiden door een /? Fictief voorbeeld: 30 / 50, waarbij 30 de dbh in mm is, en 50 de hoogte in m. (Het mogelijk verwarrende is dat in de berekening ook een pi zit, maar vermits die functie waarschijnlijk enkel door insiders gebruikt wordt, is dat misschien geen probleem?)

Als ik het zo zie staan, is het misschien toch beter om de verhouding weer te geven: bv. 1.9 bij een dbh_mm = 300 en height_m = 50. Ik veronderstel immers dat in de tabel dbh_mm en height_m ook opgenomen zijn?

Euh, nee, de tabel geeft enkel de afwijkende waarde van het veld waar het om gaat. Een voorbeeldje:

image

Als aberrant_field ratio_dbh_height is, staat er momenteel NA bij aberrant_value, maar dat zou ik dan vervangen door 1.9?

Dit is de output van check_data_trees(), voor de output van check_data_fmdb() staat er nog een extra kolom layer die in dit geval waarde Trees zou hebben. En dan staan er ook nog een hele serie extra id's bij, zoals subplot_id, vegetation_id,...

Laat zeker weten als je suggesties hebt voor verbetering, want ik zie niet goed hoe ik evt. alle velden van alle tabellen zou kunnen toevoegen zonder er een zeer brede en onoverzichtelijke tabel van te maken. Met de id's kan je gemakkelijk naar de originele tabel uit de databank, of deze gericht koppelen met de gewenste originele tabel, lijkt mij. Maar een output geven met alle mogelijke waarden uit al die tabellen in mekaar, lijkt me voor een gebruiker niet meer werkbaar (te veel info om nog te kunnen hanteren). Zeker als die met de vergelijking tussen periodes voor een aantal records nog eens dubbele gegevens per cel bevat.

Enfin, laat maar weten wat voor jullie handig zou zijn, want uiteraard is het ook mogelijk om bij de functies per layer iets meer info te geven dan de generieke tabel (waar ik echt niet verder zou gaan dan nu, met die id's is die tabel al breder dan een scherm, of misschien kunnen daar id's geschrapt worden wegens overbodig?). Best eerst alle output eens even bekijken, gemakkelijkst hiervoor is om het script example_dataset onder data-raw eens te runnen (om het testdatabankje te maken), en daarna kan je alle voorbeelden gewoon runnen.

leymanan commented 8 months ago

Voila, ik denk dat hiermee alles van dit issue opgelost is. In check_tree_evolution() heb ik bijkomend getest of niet met old_id gelink hakhout in opeenvolgende periodes geen shifters of walkers zijn, dus in de praktijk is dat tussen het dode deel van de stoof in de periode dat de stoof deels dood is en de volledige stoof in de periode dat de stoof nog volledig levend is. In check_data_trees() test ik of de levende en dode delen van dezelfde boom bij elkaar staan (geen walker) en van dezelfde soort zijn (geen shifter). En walkers op basis van old_id testte ik eerder al. Ik denk dat ik hiermee alles afgedekt heb?

Wel nog enkele kleine opmerkingen:

  • bij deze twee nieuwe tests heb ik voor de walker de afstand van 30 cm als grens gehanteerd (die je eerder al eens voorgesteld hebt), en bij de 'gewone' test van walkers via old_id duid ik de outliers aan op basis van de afstand. Wegens het beperkt aantal records lijkt het me voor die tests met de hakhoutstoven sowieso beter om een vaste waarde te nemen en niet te hopen dat die outliers een betrouwbaar resultaat geven. Houd ik het voor de gewone test van de walkers wel op outliers, of heb je hier ook liever een vaste grens?

dat mag obv outliers (mocht ik testen en dat geven er teveel of net te weinig, dan laat ik t nog weten)

  • bij meerdere checks waarbij de coördinaten gebruikt zijn, wist ik niet goed welke waarde ik moest toevoegen als 'aberrant_value', dus deze kolom is voorlopig niet ingevuld bij deze checks (o.a. of locatie binnen of buiten A3 ligt, bij checks van walkers,...). Welke waarde zou ik hier evt. kunnen invullen? (Ik zou x_m en y_m aan elkaar kunnen plakken in 1 veld, of ingeval van een walker zou ik de afstand tussen beiden kunnen weergeven, maar belangrijkste is uiteraard dat een eventuele waarde nuttig is voor jullie)

walker: afstand tss beide lijkt me wel nuttig al dan niet in A3/A4: ev. enkel "not in A3" of "not in A4"

  • de shifters en walkers van 1 boom in check_data_trees() staan nu verspreid over 2 records (het record met het dode deel en het record met het levende deel). Is dit ok, of zet ik ze beter samen? (Met vermelding van beide tree_measure_id's e.d., uiteraard)

Als dat lukt, is samen misschien wel 't beste

leymanan commented 8 months ago
  • bij deze twee nieuwe tests heb ik voor de walker de afstand van 30 cm als grens gehanteerd (die je eerder al eens voorgesteld hebt), en bij de 'gewone' test van walkers via old_id duid ik de outliers aan op basis van de afstand. Wegens het beperkt aantal records lijkt het me voor die tests met de hakhoutstoven sowieso beter om een vaste waarde te nemen en niet te hopen dat die outliers een betrouwbaar resultaat geven. Houd ik het voor de gewone test van de walkers wel op outliers, of heb je hier ook liever een vaste grens?

In verband hiermee ook de volgende opmerking: bij wijze van test heb ik de check eens gerund op de hele fieldmapdatabank, en dat geeft redelijk wat walkers. Ik heb eens eentje nagerekend van een plot met zeer veel walkers (plot_id 200), en daar bleek de boom in opeenvolgende perioden minder dan 1 cm (0.0098 m) uit elkaar te staan. Oftewel: als je heel veel nullen hebt, gaat mogelijk alles wat niet exact 0 is, als outlier gezien worden. Dus als je niet te veel bomen als walkers wil gemarkeerd hebben, lijkt een vaste waarde me beter dan de outliers van de functie boxplot.

Trouwens, met die grens van 30 cm worden dode en levende delen van hakhoutstoven nog wel redelijk vaak als walker aangeduid, dus misschien wil je die waarde iets hoger nemen? Anderzijds heb ik de indruk dat voor een individuele boom de verschillen zelden aan 30 cm zullen geraken. Dus om eens over na te denken of op de dataset uit te testen welke waardes je hier wil.

Ja, doe dan maar direct een vaste grens, die bij hakhout wat groter mag zijn dan bij individuele bomen (die je over de tijd heen vergelijkt). Bij hakhout mag dat 50 cm zijn (tss leven en dood deel), en bij individuele bomen doorheen de tijd dan eerder 20 cm.

leymanan commented 8 months ago

Als aberrant_field ratio_dbh_height is, staat er momenteel NA bij aberrant_value, maar dat zou ik dan vervangen door 1.9?

ja, doe dat maar. Zal inderdaad beste zijn om de tabel zo beknopt mogelijk te houden, en dan moet er maar verder gelinkt worden naar de eigenlijke dbh en hoogte

ElsLommelen commented 8 months ago
  • de shifters en walkers van 1 boom in check_data_trees() staan nu verspreid over 2 records (het record met het dode deel en het record met het levende deel). Is dit ok, of zet ik ze beter samen? (Met vermelding van beide tree_measure_id's e.d., uiteraard)

Als dat lukt, is samen misschien wel 't beste

Euh, wat het beste is, hangt vooral af van wat voor jullie het handigst is. Als ik ze samenvoeg door in tree_measureid de id's van de 2 bomen gescheiden door een '' weer te geven, is het voor jullie als gebruikers iets lastiger om dat bv. achteraf te koppelen met andere tabellen (want je moet eerst die id's terug uitsplitsen). Anderzijds is het waarschijnlijk wel overzichtelijker om het samen te zetten als Peter manueel met die lijst aan de slag gaat. Voor mij is dat samenvoegen een kleintje, dus laat maar weten wat jullie voorkeur is.