datacontrole scriptmatig - MINST DRINGEND

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

ElsLommelen commented 3 years ago

zie ook #1

ElsLommelen commented 10 months ago

Op basis van bovenstaande info en de aanzet voor functie check_data_trees() die eerder gemaakt is, stel ik voor de foutcontrole (dit en verwante issues) het volgende voor:

ik vul check_data_trees() verder aan en geef die als output een tabel met de afwijkende records met de velden IDPlots, tree_measure_id (ID van tabel Trees), aberrant_field (Engelse variant op 'afwijkendveld' uit voorstel die aangeeft in welke kolom(men) de fout zit) en anomaly (Engelse variant op 'afwijking' die aangeeft wat mis is: te hoog, te laag,...)
ik maak gelijkaardige functies check_data_shoots(), check_data_deadwood(), ... (een functie per te controleren tabel)
evt. maak ik achteraf ook een overkoepeldende functie check_data_fmdb() die alle functies aanroept en het eindresultaat in 1 tabel samenzet met extra veld layer dat naar de FM-tabel verwijst (Trees, Shoots, Deadwood,...), laat maar weten of je dit een voordeel vindt. (Waarschijnlijk moet je de tabel toch terug opsplitsen om in FM te kunnen toevoegen, tenzij je werkt met for (table in unique(checkresults$layer)), maar dan ga je toch nog wel wat sukkelen met de tabelspecifieke ID's.)

Idee is dat deze gegevens op basis van de id's gemakkelijk toegevoegd kunnen worden in hiervoor voorziene kolommen in de FM-databank.

Alvast enkele klein vraagjes in verband hiermee:

vertaal ik de mogelijkheden voor 'anomaly' ook naar het Engels (vermits het package in het Engels is, en de kolomnamen in fieldmap)? In hoeverre overweeg je om een codetabel in fieldmap toe te voegen met deze categorieën (al is het misschien toch ook niet zo'n goed idee als ik de id's hard codeer in het script i.p.v. de omschrijvingen)?
wat als eenzelfde record meerdere ongerelateerde fouten heeft in meerdere kolommen? Bv. de diameter is veel te dik, de hoogte ontbreekt, en het decaystage staat niet in de lookuplijst? Is het dan aberrant_field = dbh_mm/height_m/decaystage en anomaly = te hoog/ontbrekend/niet in lookuplijst? (Uiteraard is dit een fictief voorbeeld dat in de praktijk niet gaat voorkomen, maar het gaat me vooral over het principe: plak ik gewoon alles na mekaar in dezelfde volgorde?)
ik neem aan dat de functies de gegevens niet moeten rapporteren met controlestatus waarvan de string 'goed' of 'gemodelleerd' bevat? En misschien ook niet bij 'gecorrigeerd', of moet dit de controle toch nog opnieuw passeren? (Dit kan ik uiteraard pas implementeren nadat het veld controlestatus (of een Engelse veldnaam met dezelfde betekenis) toegevoegd is in fieldmap.)

ElsLommelen commented 10 months ago

voor de zekerheid nog een extra vraagje: bij trees$species staat in de nota's enkel aangegeven dat gecontroleerd moet worden of dit veld al dan niet ontbreekt. Moet dit ook gecontroleerd worden op juistheid (of het in de tabel met de boomsoorten voorkomt)? Of is dit overbodig omdat het onmogelijk is om foute waarden via fieldmap in te vullen?

leymanan commented 10 months ago

voor de zekerheid nog een extra vraagje: bij trees$species staat in de nota's enkel aangegeven dat gecontroleerd moet worden of dit veld al dan niet ontbreekt. Moet dit ook gecontroleerd worden op juistheid (of het in de tabel met de boomsoorten voorkomt)? Of is dit overbodig omdat het onmogelijk is om foute waarden via fieldmap in te vullen?

het is onmogelijk om foute waarden in te vullen (werkt via een lookuplijst)

leymanan commented 10 months ago

wat als eenzelfde record meerdere ongerelateerde fouten heeft in meerdere kolommen? Bv. de diameter is veel te dik, de hoogte ontbreekt, en het decaystage staat niet in de lookuplijst? Is het dan aberrant_field = dbh_mm/height_m/decaystage en anomaly = te hoog/ontbrekend/niet in lookuplijst? (Uiteraard is dit een fictief voorbeeld dat in de praktijk niet gaat voorkomen, maar het gaat me vooral over het principe: plak ik gewoon alles na mekaar in dezelfde volgorde?)

ja, lijkt me beste om alles na elkaar te plakken (drie afzonderlijke records)

leymanan commented 10 months ago

vertaal ik de mogelijkheden voor 'anomaly' ook naar het Engels (vermits het package in het Engels is, en de kolomnamen in fieldmap)?

Dat mag van mij in het Engels.

In hoeverre overweeg je om een codetabel in fieldmap toe te voegen met deze categorieën (al is het misschien toch ook niet zo'n goed idee als ik de id's hard codeer in het script i.p.v. de omschrijvingen)?

Eigenlijk niet, het script lijkt me vlotter leesbaar als we omschrijvingen gebruiken, eerder dan codes/id's. Bovendien vind ik codetabellen vooral nuttig voor data-invoer in Fieldmap, en dat is hier niet het geval.

ElsLommelen commented 10 months ago

nog een vraagje: in het document eerste aanzet staat bij de te checken ontbrekende waarden van trees bij height tussen haakjes '(indien snag)', weet jij wat dit zou kunnen betekenen? Op basis van de data heb ik wel gemerkt dat die hoogte leeg kan zijn bij hakhoutstoven (wat mogelijk nieuw is t.o.v. toen we de regels opstelden, want toen nam ik de berekende waarden nog uit fieldmap), dus ik heb hier alvast de voorwaarde toegevoegd dat dit alleen gecheckt moet worden als IndShtCop 10 is. Maar bij snag weet ik niet goed waarom er misschien geen hoogte ingevuld zou zijn.

ElsLommelen commented 10 months ago

In hoeverre overweeg je om een codetabel in fieldmap toe te voegen met deze categorieën (al is het misschien toch ook niet zo'n goed idee als ik de id's hard codeer in het script i.p.v. de omschrijvingen)?

Eigenlijk niet, het script lijkt me vlotter leesbaar als we omschrijvingen gebruiken, eerder dan codes/id's. Bovendien vind ik codetabellen vooral nuttig voor data-invoer in Fieldmap, en dat is hier niet het geval.

Ok, in dat geval: vertaal ik die omschrijvingen ook naar het Engels?

leymanan commented 10 months ago

ik vul check_data_trees() verder aan en geef die als output een tabel met de afwijkende records met de velden IDPlots, tree_measure_id (ID van tabel Trees), aberrant_field (Engelse variant op 'afwijkendveld' uit voorstel die aangeeft in welke kolom(men) de fout zit) en anomaly (Engelse variant op 'afwijking' die aangeeft wat mis is: te hoog, te laag,...)

ik maak gelijkaardige functies check_data_shoots(), check_data_deadwood(), ... (een functie per te controleren tabel)

OK!

evt. maak ik achteraf ook een overkoepelende functie check_data_fmdb() die alle functies aanroept en het eindresultaat in 1 tabel samen zet met extra veld layer dat naar de FM-tabel verwijst (Trees, Shoots, Deadwood,...), laat maar weten of je dit een voordeel vindt.

Ik vind dat wel een goed idee. Ik dacht om eventueel te werken zoals we bij de VBI ook werken: alle tabellen "incorrect_trees", "incorrect_deadwood", ... samenvoegen tot één grote tabel "tbl_anomalies". Maar die dan niet via de standaard fieldmap software benaderen, maar als een afzonderlijke tabel bewaren, hetzij in een afzonderlijke access-db ("validation.accdb"), hetzij in de fieldmap-databank als aparte tabel.

Ik kan die tabel/db dan aan Peter bezorgen, en hij kan dan ofwel (1) in de tabel aanpassingen doen (in twee nieuwe velden corrected_field, corrected_value) en dan met een updatequery de gecorrigeerde velden in fieldmap aanpassen, ofwel (2) direct in fieldmap de aanpassingen doen (nog met Peter te bespreken).

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

leymanan commented 10 months ago

bij de VBI kijken we bij de datacontrole ook naar de twee opeenvolgende opnames: we linken de bomen obv hun old_id en kijken naar status, soort, diameter en hoogte. Op basis daarvan definiëren we shifters (van soort veranderd), zombies (van dood naar levend), outlier_height en outlier_diameter (grote wijziging in hoogte of diameter), walklers (andere XY-coordinaten)

Maar dat kan misschien in een afzonderlijke functie (als uitbreiding - indien je daar nog tijd voor vindt), eventueel de 23ste te bespreken?

leymanan commented 10 months ago

Ok, in dat geval: vertaal ik die omschrijvingen ook naar het Engels?

stonden die nu niet al in het Engels in het script ? (voor mij eigenlijk om 't even Engels of Nederlands ;)- )

leymanan commented 10 months ago

nog een vraagje: in het document eerste aanzet staat bij de te checken ontbrekende waarden van trees bij height tussen haakjes '(indien snag)', weet jij wat dit zou kunnen betekenen? Op basis van de data heb ik wel gemerkt dat die hoogte leeg kan zijn bij hakhoutstoven (wat mogelijk nieuw is t.o.v. toen we de regels opstelden, want toen nam ik de berekende waarden nog uit fieldmap), dus ik heb hier alvast de voorwaarde toegevoegd dat dit alleen gecheckt moet worden als IndShtCop 10 is. Maar bij snag weet ik niet goed waarom er misschien geen hoogte ingevuld zou zijn.

Is eigenlijk zo dat enkel bij snags (afgebroken bomen/top uitgebroken) de hoogte MOET ingevuld staan. Bij de intacte bomen kan de hoogte uit de curves gehaald worden.
Dus de controle op lege velden "Height_m" moet enkel gebeuren bij de bomen met veld intact_snag = 10

ElsLommelen commented 10 months ago

bij de VBI kijken we bij de datacontrole ook naar de twee opeenvolgende opnames: we linken de bomen obv hun old_id en kijken naar status, soort, diameter en hoogte. Op basis daarvan definiëren we shifters (van soort veranderd), zombies (van dood naar levend), outlier_height en outlier_diameter (grote wijziging in hoogte of diameter), walklers (andere XY-coordinaten)

Maar dat kan misschien in een afzonderlijke functie (als uitbreiding - indien je daar nog tijd voor vindt), eventueel de 23ste te bespreken?

In het document met de aanzet staat dit onderaan ook vermeld, en ik zie in het document van Peter ook hier en daar regeltjes i.v.m. OldID verschijnen, dus ik was er sowieso al van uitgegaan dat dit moest. ;-) OldID wordt in functie check_data_trees() binnengehaald, maar inderdaad misschien niet slecht om er een aparte functie voor te maken om check_data_trees() niet te lang te maken. Dankzij ons eerder denkwerk gaat die regeltjes toevoegen eigenlijk vrij vlot (trees is al bijna klaar), ik verwacht het op 2 à 3 dagen te kunnen afronden, dus zeker geen probleem om die OldID nog even toe te voegen. Op basis van je omschrijving klinkt het niet al te moeilijk, enkel nog weten wat een grote wijziging is, maar dat vind ik wel in de VBI-code, neem ik aan? (Als Toon hier ook van op de hoogte is, kan ik hem hier morgen evt. wel even over aanspreken, dan hoeft het zelfs niet tot de 23ste te blijven liggen.) Sowieso: ik zal finaal beide bovenstaande documenten grondig nakijken om te zien of ik alles ingewerkt hebt, maar het zal best zijn dat jij (en Peter?) alles ook nog nakijkt op volledigheid.

ElsLommelen commented 10 months ago

nog eentje: in hoeverre is het nodig om ingeval van TreeNumber > 1 te checken of het over een hakhoutstoof gaat, en omgekeerd? Vermits dit niet in de documenten staat, ga ik ervan uit dat dit niet getest moet worden (dat het in fieldmap niet anders ingevoerd kan worden), maar ik vraag het toch maar even om zeker te zijn.

ElsLommelen commented 10 months ago

In de praktijk merk ik dat DecayStage bij levende bomen soms ontbreekt (bij CA). Op zich is het logisch dat daar overal 16 moet staan. Moeten die als fout opgegeven worden, of niet?
Ook hebben de IUFRO-klassen nogal eens waarde 0 bij periode 0 of 1, terwijl dat volgens de documenten geen toegelaten waarde is (die ook niet in de codetabel staat), misschien werden die toen nog niet opgenomen? Wat doe ik hiermee, moet hiervoor een uitzonderingsregel komen?

ElsLommelen commented 10 months ago

in de codetabellen en het document van Peter zie ik voor stoven voor DecayStage waarde 17 en voor de IUFRO-klassen waarde 50, maar dit staat niet in het document van de 'eerste aanzet'. Ik neem aan dat ik deze ook meeneem in de checks? Hoe zit dit dan precies? Wat bij een levende stoof, mag deze zowel DecayStage 16 als 17 hebben? Kunnen dode bomen ook stoven zijn? Mag een dode stoof zowel IUFRO-klasse 40 als 50 hebben, of moet er dan consequent voor 40 of voor 50 gegaan worden?

ElsLommelen commented 10 months ago

En mijn laatste vraag i.v.m. trees:

moet ik iets met trees$remark doen?

ElsLommelen commented 10 months ago

Eerste vraagjes voor de controle van Shoots:

bij Trees moet er naar de verhouding D/H gekeken worden, maar bij Shoots staat dit nergens in onze voorbereiding (die wel gemaakt is vooraleer we beslist hebben om de volumes in het package te berekenen). Moet deze controle ook gebeuren voor de shoots, en gelden dezelfde limieten als bij trees?
idem voor min en max diameter en max hoogte: voeg ik die controles ook toe voor shoots?
en moeten andere velden ook gecheckt worden voor onmogelijke waarden? Bv. DecayStage, IUFRO-klasses?
Wat DecayStage betreft: ik neem aan dat dat verschillend kan zijn voor verschillende spillen van eenzelfde boom, of moet dit ook getest worden? Of andere tests waarbij spillen gegroepeerd moeten worden op boomniveau?

ElsLommelen commented 10 months ago

Vragen voor de controle van Deadwood:

moet er bij DecayStage ook gecheckt worden voor onmogelijke waarden (stond niet in nota's)? En kan hier ook een levende boom met DecayStage 16 voorkomen? (Dus moet dan ook gecheckt worden of het liggend hout levend is als DecayStage 16 is, en dood bij een ander DecayStage?
volgens nota's kan IntactFragment enkel bij plottype 30 (=CA), en dan staat er (BE-kartering) tussen haakjes. Betekent dit dat het bij CA en bij BE kan?

leymanan commented 10 months ago

Op basis van je omschrijving klinkt het niet al te moeilijk, enkel nog weten wat een grote wijziging is, maar dat vind ik wel in de VBI-code, neem ik aan?

Inderdaad, ik kan je de code ook doormailen, mocht je willen.. 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).

Voor dode is controle moeilijker: kan "gekrompen" zijn, maar ook nog tijdje verder gegroeid zijn vóór het afsterven ...

nog eentje: in hoeverre is het nodig om ingeval van TreeNumber > 1 te checken of het over een hakhoutstoof gaat, en omgekeerd? Vermits dit niet in de documenten staat, ga ik ervan uit dat dit niet getest moet worden (dat het in fieldmap niet anders ingevoerd kan worden), maar ik vraag het toch maar even om zeker te zijn.

Normaal gezien zit er in Fieldmap een "on-change-scripts" dat elke keer er een extra spil toegevoegd wordt, het veld TreeNumber bijwerkt. Bijkomend kunnen er in data collector enkel spillen toegevoegd worden als er aangegeven werd dat het om hakhout gaat.

In theorie zouden we TreeNumber kunnen vergelijken met een zelf berekend "aantal spillen". Of gewoon enkel bekijken of TreeNumber > 1 overeenstemt met het al dan niet hakhoutstoof zijn. Want ik denk dat er wel iets kan mislopen als men eerst aangeeft dat het hakhout is, en er daarna op terugkomt ...

Dus voer toch maar in. Bedankt!

leymanan commented 10 months ago

In de praktijk merk ik dat DecayStage bij levende bomen soms ontbreekt (bij CA). Op zich is het logisch dat daar overal 16 moet staan. Moeten die als fout opgegeven worden, of niet?

Nee, dat is niet nodig, die "16" is ingevoerd om lege velden te vermijden, maar hoeft niet retro-actief aangevuld te worden

Ook hebben de IUFRO-klassen nogal eens waarde 0 bij periode 0 of 1, terwijl dat volgens de documenten geen toegelaten waarde is (die ook niet in de codetabel staat), misschien werden die toen nog niet opgenomen? Wat doe ik hiermee, moet hiervoor een uitzonderingsregel komen?

Volgens mij komen die overeen met een NA, maar voor 't zekerste toch eens gevraagd aan Peter (is OK, mail 10/1/2024). Maar eigenlijk zou Peter dat met een query in de moederdb (retro-actief) moeten aanpassen, en die dan allemaal effectief NA maken. Dus er hoeft geen uitzonderingsregel te komen.

leymanan commented 10 months ago

in de codetabellen en het document van Peter zie ik voor stoven voor DecayStage waarde 17 en voor de IUFRO-klassen waarde 50, maar dit staat niet in het document van de 'eerste aanzet'. Ik neem aan dat ik deze ook meeneem in de checks? Hoe zit dit dan precies?

Klopt, ik denk dat dat maar recenter toegevoegd is, om de verwarring van lege velden te vermijden: indien een stoof, dan wordt er op niveau van de boom/stoof (layer trees) géén info verzameld over decaystage en iufroklasses, dat wordt op het spilniveau (layer shoots) aangevuld.

Wat bij een levende stoof, mag deze zowel DecayStage 16 als 17 hebben?
Enkel 16 (lookuplist in Fieldmap wekt met master-lookuplist, als levend dan is enkel 16 mogelijk) MAAR ik zag dat er nu wel vaak 17 staat, volgens mij heeft Peter dat retro-actief aangevuld mbv een access-query Dat zal moeten gecorrigeerd worden door ons.

Kunnen dode bomen ook stoven zijn?
Ja

Mag een dode stoof zowel IUFRO-klasse 40 als 50 hebben, of moet er dan consequent voor 40 of voor 50 gegaan worden? Consequent voor 40 (lookuplist in Fieldmap werkt met master-lookuplist, als dood dan is enkel 40 mogelijk)

leymanan commented 10 months ago

En mijn laatste vraag i.v.m. trees:

moet ik iets met trees$remark doen?

nee

EDIT: nu ik je vraag mbt deadwood beantwoord, bedenk ik dat je misschien zou kunnen checken of alle trees met CommonRemark = 150 (liggend) effectief levend zijn (anders moeten ze bij deadwood layer)

leymanan commented 10 months ago

Eerste vraagjes voor de controle van Shoots:

bij Trees moet er naar de verhouding D/H gekeken worden, maar bij Shoots staat dit nergens in onze voorbereiding (die wel gemaakt is vooraleer we beslist hebben om de volumes in het package te berekenen). Moet deze controle ook gebeuren voor de shoots, en gelden dezelfde limieten als bij trees?

ja, dat mag (hoewel we voorrang geven aan individuele bomen om hoogtes te meten, maar soms is er geen alternatief)

idem voor min en max diameter en max hoogte: voeg ik die controles ook toe voor shoots?

ja, dat mag

en moeten andere velden ook gecheckt worden voor onmogelijke waarden? Bv. DecayStage, IUFRO-klasses?

Dat mag volgens zelfde stramien zijn als bij trees layer, maar NVT-stoof (decaystage 17 of iufroklasse 50) zou hier niet mogen.

Wat DecayStage betreft: ik neem aan dat dat verschillend kan zijn voor verschillende spillen van eenzelfde boom, of moet dit ook getest worden?

Decaystage kan inderdaad anders zijn voor de verschillende spillen van een stoof, dat is geen probleem

Of andere tests waarbij spillen gegroepeerd moeten worden op boomniveau?

Nee

ElsLommelen commented 10 months ago

nog eentje: in hoeverre is het nodig om ingeval van TreeNumber > 1 te checken of het over een hakhoutstoof gaat, en omgekeerd? Vermits dit niet in de documenten staat, ga ik ervan uit dat dit niet getest moet worden (dat het in fieldmap niet anders ingevoerd kan worden), maar ik vraag het toch maar even om zeker te zijn.

Normaal gezien zit er in Fieldmap een "on-change-scripts" dat elke keer er een extra spil toegevoegd wordt, het veld TreeNumber bijwerkt. Bijkomend kunnen er in data collector enkel spillen toegevoegd worden als er aangegeven werd dat het om hakhout gaat.

In theorie zouden we TreeNumber kunnen vergelijken met een zelf berekend "aantal spillen". Of gewoon enkel bekijken of TreeNumber > 1 overeenstemt met het al dan niet hakhoutstoof zijn. Want ik denk dat er wel iets kan mislopen als men eerst aangeeft dat het hakhout is, en er daarna op terugkomt ...

Dus voer toch maar in. Bedankt!

In verband hiermee volgende checks toegevoegd:

controle of TreeNumber/nr_of_stems overeenkomt met het aantal Shoots -> geeft aberrant_field = "tree_number" en anomaly = "incorrect"
controle of afhankelijk van TreeNumber de juiste IndShtCop gekozen is -> geeft aberrant_field = "ind_sht_cop" en anomaly = "incorrect"

Laat maar weten als je de anomaly anders wil omschrijven dan "incorrect", in ons voorbereidend lijstje vond ik niks passend dus heb ik (voorlopig) zelf iets verzonnen

leymanan commented 10 months ago

Vragen voor de controle van Deadwood:

moet er bij DecayStage ook gecheckt worden voor onmogelijke waarden (stond niet in nota's)?

En kan hier ook een levende boom met DecayStage 16 voorkomen? (Dus moet dan ook gecheckt worden of het liggend hout levend is als DecayStage 16 is, en dood bij een ander DecayStage?

Normaal worden alle levende bomen bij de staande (layer trees) gestopt, met commonremark = 150 (liggend) Deadwood is specifiek voor het dode liggende hout. Er moet enkel gecontroleerd worden of er een levende bij de liggende dode bomen zit, dus op AliveDead: moet 12 zijn. Klinkt inderdaad onzinnig dat dit mogelijk is, maar mochten er nieuwe terreinmedewerkers zijn, dan is het wel een goed signaal om te geven dat er levende liggende genoteerd werden.

volgens nota's kan IntactFragment enkel bij plottype 30 (=CA), en dan staat er (BE-kartering) tussen haakjes. Betekent dit dat het bij CA en bij BE kan?

Inderdaad, sorry voor verwarring, niet duidelijk. Dus mogelijk bij plottype 30 én 40

ElsLommelen commented 10 months ago

DecayStage 17 en IUFRO-klasse 50 toegevoegd (en de nodige checks aangepast en toegevoegd).

ElsLommelen commented 10 months ago

Wat DecayStage betreft: ik neem aan dat dat verschillend kan zijn voor verschillende spillen van eenzelfde boom, of moet dit ook getest worden?

Decaystage kan inderdaad anders zijn voor de verschillende spillen van een stoof, dat is geen probleem

Euh, hoe zit dat dan met AliveDead? Dit zie ik in de databank enkel in tabel Tree staan, niet in tabel Shoots. Betekent dit dat voor een levende boom alle Shoots levend zijn en DecayStage_shoots dus 16 (of NA) moet zijn voor alle shoots? En dat bovenstaande reactie dus enkel bij dode bomen geldt? Of kunnen levende bomen ook dode spillen hebben, en is het zinloos om bij levende bomen te checken dat decaystage altijd 16 of NA is?

leymanan commented 10 months ago

Wat DecayStage betreft: ik neem aan dat dat verschillend kan zijn voor verschillende spillen van eenzelfde boom, of moet dit ook getest worden?

Decaystage kan inderdaad anders zijn voor de verschillende spillen van een stoof, dat is geen probleem

Euh, hoe zit dat dan met AliveDead? Dit zie ik in de databank enkel in tabel Tree staan, niet in tabel Shoots. Betekent dit dat voor een levende boom alle Shoots levend zijn en DecayStage_shoots dus 16 (of NA) moet zijn voor alle shoots? En dat bovenstaande reactie dus enkel bij dode bomen geldt? Of kunnen levende bomen ook dode spillen hebben, en is het zinloos om bij levende bomen te checken dat decaystage altijd 16 of NA is?

een "tree" is altijd volledig levend of dood. Als er een hakhoutstoof is met levende en dode spillen wordt die als twee afzonderlijke "trees" geïnventariseerd/ingevoerd, een levende tree/stoof en een dode. Is inherent aan fieldmap.

ElsLommelen commented 10 months ago

een "tree" is altijd volledig levend of dood. Als er een hakhoutstoof is met levende en dode spillen wordt die als twee afzonderlijke "trees" geïnventariseerd/ingevoerd, een levende tree/stoof en een dode. Is inherent aan fieldmap.

Ok, dus ik check het decaystage met de alive/dead van het Tree-niveau?

ElsLommelen commented 10 months ago

Vragen voor de controle van Deadwood:

moet er bij DecayStage ook gecheckt worden voor onmogelijke waarden (stond niet in nota's)?

En kan hier ook een levende boom met DecayStage 16 voorkomen? (Dus moet dan ook gecheckt worden of het liggend hout levend is als DecayStage 16 is, en dood bij een ander DecayStage?

Normaal worden alle levende bomen bij de staande (layer trees) gestopt, met commonremark = 150 (liggend) Deadwood is specifiek voor het dode liggende hout. Er moet enkel gecontroleerd worden of er een levende bij de liggende dode bomen zit, dus op AliveDead: moet 12 zijn. Klinkt inderdaad onzinnig dat dit mogelijk is, maar mochten er nieuwe terreinmedewerkers zijn, dan is het wel een goed signaal om te geven dat er levende liggende genoteerd werden.

Betekent het feit dat bij deadwood geen levende bomen toegevoegd worden, dat DecayStage 16 hier niet kan/mag voorkomen? Moet hier ook op getest worden, of niet? (Intussen wel al test toegevoegd dat deadwood niet levend mag zijn.)

leymanan commented 10 months ago

Vragen voor de controle van Deadwood:

moet er bij DecayStage ook gecheckt worden voor onmogelijke waarden (stond niet in nota's)?

En kan hier ook een levende boom met DecayStage 16 voorkomen? (Dus moet dan ook gecheckt worden of het liggend hout levend is als DecayStage 16 is, en dood bij een ander DecayStage?

Normaal worden alle levende bomen bij de staande (layer trees) gestopt, met commonremark = 150 (liggend) Deadwood is specifiek voor het dode liggende hout. Er moet enkel gecontroleerd worden of er een levende bij de liggende dode bomen zit, dus op AliveDead: moet 12 zijn. Klinkt inderdaad onzinnig dat dit mogelijk is, maar mochten er nieuwe terreinmedewerkers zijn, dan is het wel een goed signaal om te geven dat er levende liggende genoteerd werden.

Betekent het feit dat bij deadwood geen levende bomen toegevoegd worden, dat DecayStage 16 hier niet kan/mag voorkomen? Moet hier ook op getest worden, of niet? (Intussen wel al test toegevoegd dat deadwood niet levend mag zijn.)

ja, dat mag

ElsLommelen commented 9 months ago

Ik ben ervan uitgegaan dat decay_stage_shoots ook NA mag zijn bij levende bomen, net zoals bij trees. (Dus bij levende bomen is 16 en NA toegelaten, bij dode bomen enkel 10 t.e.m. 15.) Klopt dit?

ElsLommelen commented 9 months ago

Vraagje i.v.m. checks voor regspecies: in de datacontrole van Peter lees ik iets over rubbing damage. Moet dit gecheckt worden vanaf periode 2? Bij een eerste test zie ik in periode 2 nog veel 'missing', en ook op basis van de tekst leid ik af dat dit niet per definitie opgenomen is op het veld (maar dat NA op 0 wordt gezet als er ergens schade genoteerd is). Dus misschien ook niet handig als ik vanaf periode 2 test op NA-waardes en voor elk van die records 'missing' geef? Zou het handig zijn als ik 'missing' aangeef bij NA van zodra er eentje van de plot niet NA is ofzo? Of hoeft die test niet?

ElsLommelen commented 9 months ago

Vraagje i.v.m. checks voor vegetation: bij het document OpbouwDatacontroleEersteAanzet staat als voorwaarden voor onmogelijke waarden Total_xxx_cover < 100 en TotalSoildisturbanceGame < 100, maar hier staan telkens waarden van 1 tot 14 of 20 verwijzend naar tabel qtotalCover. Ik neem dus aan dat hier getest moet worden of de ingegeven waarden voorkomen in veld ID van de codetabel qtotalCover? (En ik neem ook aan dat aan qtotalCover nooit bedekkingen > 100 % toegevoegd zullen worden?)

leymanan commented 9 months ago

Ik ben ervan uitgegaan dat decay_stage_shoots ook NA mag zijn bij levende bomen, net zoals bij trees. (Dus bij levende bomen is 16 en NA toegelaten, bij dode bomen enkel 10 t.e.m. 15.) Klopt dit?

ja, dat klopt

leymanan commented 9 months ago

Vraagje i.v.m. checks voor regspecies: in de datacontrole van Peter lees ik iets over rubbing damage. Moet dit gecheckt worden vanaf periode 2? Bij een eerste test zie ik in periode 2 nog veel 'missing', en ook op basis van de tekst leid ik af dat dit niet per definitie opgenomen is op het veld (maar dat NA op 0 wordt gezet als er ergens schade genoteerd is). Dus misschien ook niet handig als ik vanaf periode 2 test op NA-waardes en voor elk van die records 'missing' geef? Zou het handig zijn als ik 'missing' aangeef bij NA van zodra er eentje van de plot niet NA is ofzo? Of hoeft die test niet?

net zoals er in tabel plotinfo (obv layer plotdetails) een veld survey_deadw is, bestaat er ook het veld game_impact_reg (en game_impact_veg) om aan te geven of de "game impact" (zijnde browsing of rubbing) genoteerd werd. Op basis daarvan zou beslist moeten worden of iets een NA of een nulwaarde is. Maar zit dat niet al verwerkt incalculate_regeneration()?

Wat wel een idee zou zijn: als game_impact_reg = TRUE, én er is ergens een nulwaarde én een andere waarde ingevuld (in die plot), dan toch de NA's als missing aanduiden

leymanan commented 9 months ago

Vraagje i.v.m. checks voor vegetation: bij het document OpbouwDatacontroleEersteAanzet staat als voorwaarden voor onmogelijke waarden Total_xxx_cover < 100 en TotalSoildisturbanceGame < 100, maar hier staan telkens waarden van 1 tot 14 of 20 verwijzend naar tabel qtotalCover. Ik neem dus aan dat hier getest moet worden of de ingegeven waarden voorkomen in veld ID van de codetabel qtotalCover? (En ik neem ook aan dat aan qtotalCover nooit bedekkingen > 100 % toegevoegd zullen worden?)

klopt!

ElsLommelen commented 9 months ago

(Ah ja, ter info: ik zet duimpjes bij uw posts op het moment dat ze in orde zijn in de code, om voor mezelf het overzicht wat te kunnen bewaren en niet altijd alle commentaren in het hele issue te moeten herlezen. De checks i.v.m. de vergelijking tussen jaren ga ik pas na de andere checks schrijven, dus die hebben voorlopig nog geen duimpje, maar dat heeft dus enkel als betekenis dat er voorlopig nog geen code voor is, het heeft niks te maken met niet ok zijn ofzo. ;-) )

ElsLommelen commented 9 months ago

Maar zit dat niet al verwerkt incalculate_regeneration()?

Ja, inderdaad, in load_data_regeneration() zit zoiets, maar dat is bedoeld om berekeningen te maken met de aanwezige gegevens, terwijl check_data_regspecies() als doel heeft om de FM-databank op te kuisen (of aan te geven wat nog opgekuist moet worden). Dus de vraag is eigenlijk vooral op welk niveau je dit wil oplossen. Als je de FM-databank nog voor andere zaken gebruikt (niet via forrescalc) of deelt met personen die dit soort zaken niet weten, dan kan het nuttig/nodig zijn dat dit in de databank opgekuist wordt, en dan is het handig als die check ook in check_data_regspecies() zit om Peter erop te wijzen dat dat nog in orde gebracht moet worden. Als je niet van plan bent om de FM-databank op te kuisen wat dit item betreft, dan is een check in check_data_regspecies() eerder vervelend dan nuttig (en overbodig). load_data_regeneration() vangt dit euvel sowieso op, dus als je de databank enkel via deze functie bevraaagt, is er sowieso geen probleem.

Wat wel een idee zou zijn: als game_impact_reg = TRUE, én er is ergens een nulwaarde én een andere waarde ingevuld (in die plot), dan toch de NA's als missing aanduiden

Ok, laat maar weten of dit nuttig is, als je bovenstaande in het achterhoofd houdt. Sowieso begrijp ik dat dit hetgeen is wat aangepast is in de databank, dus dan lijkt het wel zinvol om het zo te doen.

leymanan commented 9 months ago

Wat wel een idee zou zijn: als game_impact_reg = TRUE, én er is ergens een nulwaarde én een andere waarde ingevuld (in die plot), dan toch de NA's als missing aanduiden

Ok, laat maar weten of dit nuttig is, als je bovenstaande in het achterhoofd houdt. Sowieso begrijp ik dat dit hetgeen is wat aangepast is in de databank, dus dan lijkt het wel zinvol om het zo te doen.

dat lijkt me wel nuttig, maar inderdaad niet alle NA's gaan opkuisen, enkel waar er verwarring kan zijn of het een 0 of echte NA is

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? 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

Bij deze zijn alle functies voor controles van de gegevens per periode in orde, vermoed ik. De volgende stap is om check-functie(s) te maken die gegevens van dezelfde bomen over de periodes heen checkt.

ElsLommelen commented 9 months ago

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(),...

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.

zou het dan niet beter zijn om die outliers per soort te bekijken? Op deze manier krijg je populieren als outliers terwijl ze dat niet zijn, maar betekent dit niet dat bij andere, minder snel groeiende soorten, de afwijkende waarden niet als outliers getoond worden omdat ze minder afwijken dan een doorsnee populier?

ElsLommelen commented 9 months ago

Edit: intussen zag ik in bovenstaande conversatie dat ook voor de verschilAfstand de berekening gebeurt op basis van de outliers, dus onderstaande vraag mag je negeren.

Nog een vraag i.v.m. die opeenvolgende periodes: vanaf welk verschil in X of Y is een boom een walker? Ik zie hier en daar verschillen tot 2,5 cm, dus ik neem aan dat dit gewoon nog onder meetonnauwkeurigheid valt, of niet? Maar waar ligt de grens dan ongeveer? Op 10 cm ofzo? Of is dat te veel, is het de bedoeling dat die coördinaten op exact dezelfde waarde gezet worden?

leymanan commented 9 months ago

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)

leymanan 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.

zou het dan niet beter zijn om die outliers per soort te bekijken? Op deze manier krijg je populieren als outliers terwijl ze dat niet zijn, maar betekent dit niet dat bij andere, minder snel groeiende soorten, de afwijkende waarden niet als outliers getoond worden omdat ze minder afwijken dan een doorsnee populier?

Zou inderdaad beter zijn, maar misschien ook rekening houden met feit dat sommige soorten te weinig voorkomen (die dan ev. samen nemen)? Of eventueel enkel populier als heel snel groeiende soort apart nemen?

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.

zou het dan niet beter zijn om die outliers per soort te bekijken? Op deze manier krijg je populieren als outliers terwijl ze dat niet zijn, maar betekent dit niet dat bij andere, minder snel groeiende soorten, de afwijkende waarden niet als outliers getoond worden omdat ze minder afwijken dan een doorsnee populier?

Zou inderdaad beter zijn, maar misschien ook rekening houden met feit dat sommige soorten te weinig voorkomen (die dan ev. samen nemen)? Of eventueel enkel populier als heel snel groeiende soort apart nemen?

Juist ja, aan weinig voorkomende soorten had ik niet gedacht. Hier gaat een niet extreem grote afwijking inderdaad niet altijd als outlier aangegeven worden. Anderzijds, als je enkel populier apart gaat nemen, gaan je iets sneller groeiende soorten dan niet de snelstgroeiende outliers van de zeer traag groeiende soorten maskeren, of omgekeerd (heel traag groeiende soorten die de extreem traag groeiende bomen van de normaal eerder snelgroeiende soorten maskeren)? Oftewel: bij die weinig voorkomende soorten loop je bij beide opties het risico dat afwijkingen minder snel als oulier naar boven komen (maar echte extremen komen er wel uit), terwijl je bij de veel voorkomende soorten in het eerste geval een beter resultaat zal hebben (omdat het specifiek op maat is van de groeisnelheid van de soort in kwestie). Tja, en bomen samennemen volgens groeisnelheid, vraagt dan weer een (eenmalige) lastige manuele handeling om ze te combineren (en wat onderhoud bij nieuwe boomsoorten?)... Eventueel beiden uitrekenen (outliers per soort en outliers voor alle soorten behalve populier) en alle outliers weergeven als afwijking? 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).

leymanan 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

ElsLommelen commented 9 months ago

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?

inbo / forrescalc

datacontrole scriptmatig - MINST DRINGEND #66