datacontrole scriptmatig - MINST DRINGEND

[leymanan]

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]

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

• geen coppice-id
• dood en decaystage 16 kan niet (11 is masterID bij ID 16 NVT - levend)
• dode boom met decay stage 12 in de volgende periode IndShtCop 11 krijgt met decay stage 16: nee dat zou niet mogen kunnen

Ik heb IndShtCop 11 overal hetzelfde behandeld als IndShtCop 10 zodat die records in elk geval nergens tussen de mazen van het net vallen. Ik vind dat laatste geval niet meer direct terug, maar ik zal eerst alle andere items in dit issue oplossen, en daarna de checks nog eens uitvoeren op de volledige databank en alle 'vreemde' fouten bekijken. Moest die dan nog aanwezig zijn, dan komt hij er wel uit.

[ElsLommelen]

• 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

In dat geval is de omschrijving "coordinates" voor aberrant_field misschien niet zo duidelijk?

Dus eventjes samenvatten welke walkers er zijn en hoe die momenteel in de tabellen ingevuld zijn:

• voor layer Trees is er hakhout dat bestaat uit een dood en levend deel, waarvan de velden als volgt ingevuld zijn:

  • plot_id, tree_measure_id en period met telkens 1 id/cijfer
  • aberrant_field = "coordinates"
  • anomaly = "walker in coppice tree"
  • aberrant_value = daar zou de afstand tussen de delen in meter komen (opgenomen als > 50 cm)

• voor layer Trees diff periods (vergelijking tussen opeenvolgende perioden) worden bomen (individueel en hakhout) vergeleken op basis van OldID, waarvan de velden als volgt ingevuld zijn:

  • plot_id met 1 id
  • tree_measure_id en period met telkens 2 id's/cijfers gescheiden door een "_", bv. period 2_1 en tree_measure_id 284_480
  • aberrant_field = "coordinates"
  • anomaly = "walker"
  • aberrant_value = daar zou de afstand tussen de periodes in meter komen (opgenomen als > 20 cm)

• voor layer Trees diff periods (tussen opeenvolgende perioden) is er voor hakhout bijkomend gekoppeld op basis van coppice_id, wat de positie van het dode deel van 1 periode vergelijkt met het levende deel van de volgende periode en omgekeerd, waarvan de velden als volgt ingevuld zijn:

  • plot_id met 1 id
  • tree_measure_id en period met telkens 2 id's/cijfers gescheiden door een "_", bv. period 2_1 en tree_measure_id 284_480
  • aberrant_field = "coordinates"
  • anomaly = "walker coppice_id"
  • aberrant_value = daar zou de afstand tussen de periodes in meter komen (opgenomen als > 50 cm)

• En daarnaast zijn er voor Trees diff periods ook nog de bomen die niet gekoppeld zijn maar wel op dezelfde plaats liggen:

  • plot_id met 1 id
  • tree_measure_id en period met telkens 2 id's/cijfers gescheiden door een "_", bv. period 2_1 en tree_measure_id 284_480
  • aberrant_field = "old_id"
  • anomaly = "on same place but not coupled"
  • aberrant_value = daar staat de oldid van de 2 records (met vaak een NA erbij), gescheiden door een "" (wat op zich wel nuttig lijkt, omdat je die direct kan vergelijken met tree_measure_id's van dit en andere gemelde records) Deze zou ik dus ook opgeven van zodra de afstand minder dan 20 cm is? Momenteel is dat 10 cm, en worden er al een heel deel opgelijst, dus misschien is dat ook genoeg?

Maar mijn belangrijkste vraag bij deze uiteenzetting: zijn de gebruikte termen duidelijk, of heb je betere suggesties? Als we bij aberrant_value de afstand gaan zetten, lijkt "coordinates" voor aberrant_field me minder ideaal, maar ik weet uiteraard niet welke terminologie jullie gebruiken en/of verkiezen. (Voor de meeste andere tests heb ik gewoon de (naar snake_case herleide) veldnamen uit de databank genomen, enkel bij de berekende velden heb ik zelf wat verzonnen.)

[ElsLommelen]

Vraagje over concrete case (al zijn er wel meerdere gelijkaardige cases in de dataset): bij de 3de periode, IDPlots 117, bomen ID 19 en 23 staan 2 levende bomen met dezelfde CoppiceID (5). Wat is hier eigenlijk precies mee fout?

Bij het runnen van mijn script leveren ze volgende foutmeldingen op:

• voor beide bomen bij ind_sht_cop 'incorrect' (waarde 12 zou dus niet juist zijn, een opmerking die kan verschijnen als er geen shoots zijn voor deze boom)
• voor beide bomen bij coppice_id '2 times the same coppice_id' (met waarde 5), eentje waar je nog van gevraagd had om ze in 1 record te zetten, denk ik (dus gaat over het feit dat er 2 levende delen zijn)
• voor de gecombineerde tree_measure_id '19_23' dat het een 'walker in coppice tree' is

Een beetje overkill, want waarschijnlijk gaat het hier over 1 probleem. Maar welke zou(den) best behouden blijven, en welke zijn overbodig? Of heb ik ergens iets verkeerd geïnterpreteerd en zijn de opmerkingen onterecht?

[leymanan]

Maar mijn belangrijkste vraag bij deze uiteenzetting: zijn de gebruikte termen duidelijk, of heb je betere suggesties? Als we bij aberrant_value de afstand gaan zetten, lijkt "coordinates" voor aberrant_field me minder ideaal, maar ik weet uiteraard niet welke terminologie jullie gebruiken en/of verkiezen. (Voor de meeste andere tests heb ik gewoon de (naar snake_case herleide) veldnamen uit de databank genomen, enkel bij de berekende velden heb ik zelf wat verzonnen.)

EDIT DEFINITIEF "coordinates" vond ik inderdaad niet zo duidelijk, sorry, temeer omdat er dan ook nog "location" is (wanneer een boom niet in A3 of A4 voorkomt) Ik dacht eerst om er "walker" van te maken, maar dat staat ook bij anomaly, én is niet echt een "field", maar inderdaad eerder een "anomaly". En dan dacht ik om er gewoon ook "location" van te maken, via het veld anomalyworden de walkers dan onderscheiden van deze die buiten A3/A4 liggen. Maar anderzijds worden deze anomalies wel totaal anders benaderd.

Dus voorstel: aberrant_field "coordinates" vervangen door "location_shift"?

voor het laatste puntje: aberrant_field = "old_id": zeker ok!

[leymanan]

Vraagje over concrete case (al zijn er wel meerdere gelijkaardige cases in de dataset): bij de 3de periode, IDPlots 117, bomen ID 19 en 23 staan 2 levende bomen met dezelfde CoppiceID (5). Wat is hier eigenlijk precies mee fout?

Bij het runnen van mijn script leveren ze volgende foutmeldingen op:

• voor beide bomen bij ind_sht_cop 'incorrect' (waarde 12 zou dus niet juist zijn, een opmerking die kan verschijnen als er geen shoots zijn voor deze boom)
• voor beide bomen bij coppice_id '2 times the same coppice_id' (met waarde 5), eentje waar je nog van gevraagd had om ze in 1 record te zetten, denk ik (dus gaat over het feit dat er 2 levende delen zijn)
• voor de gecombineerde tree_measure_id '19_23' dat het een 'walker in coppice tree' is

Een beetje overkill, want waarschijnlijk gaat het hier over 1 probleem. Maar welke zou(den) best behouden blijven, en welke zijn overbodig? Of heb ik ergens iets verkeerd geïnterpreteerd en zijn de opmerkingen onterecht?

• voor beide bomen bij ind_sht_cop 'incorrect' (waarde 12 zou dus niet juist zijn, een opmerking die kan verschijnen als er geen shoots zijn voor deze boom) Dat vind ik raar, ik zie in mijn project wél een shoot in layer shoots_3eSET. Er wordt toch niet gecheckt of er meer dan één shoot is? Want zelfs met één spil kan een boom een hakhoutstoof zijn, dat wil zeggen dat de andere spillen wellicht nog geen 5 cm dbh bereikt hebben. Maar is alvast een belangrijke melding die zeker behouden moet blijven.

• voor beide bomen bij coppice_id '2 times the same coppice_id' (met waarde 5), eentje waar je nog van gevraagd had om ze in 1 record te zetten, denk ik (dus gaat over het feit dat er 2 levende delen zijn)

• voor de gecombineerde tree_measure_id '19_23' dat het een 'walker in coppice tree' is

Dit is inderdaad eenzelfde probleem, en dan is de eerste melding het duidelijkste, en de tweede dan eigenlijk overbodig (maar ook geen probleem dat de tweede behouden blijft)

[leymanan]

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

teruggekoppeld met Peter, en de twee velden homogeneous(op plotniveau en op vegetatieniveau) mag je negeren, kan zijn dat we dat niet verder meer meenemen, nooit consequent ingevuld en nooit iets mee gedaan.

[ElsLommelen]

• voor beide bomen bij ind_sht_cop 'incorrect' (waarde 12 zou dus niet juist zijn, een opmerking die kan verschijnen als er geen shoots zijn voor deze boom) Dat vind ik raar, ik zie in mijn project wél een shoot in layer shoots_3eSET. Er wordt toch niet gecheckt of er meer dan één shoot is? Want zelfs met één spil kan een boom een hakhoutstoof zijn, dat wil zeggen dat de andere spillen wellicht nog geen 5 cm dbh bereikt hebben.

Ik heb dit even gecheckt, en die opmerking wordt gegeven als nr_of_stems (TreeNumber in database) 1 is terwijl ind_sht_cop 12 is. Er wordt ook gecheckt of nr_of_stems overeenkomt met het aantal shoots. Dus ik neem aan dat minstens een van die tests niet zal moeten gebeuren, als een hakhoutstoof met maar 1 opgemeten shoot correct is. Geeft TreeNumber het totale aantal shoots, of enkel die boven 5 cm? In het eerste geval heeft het geen zin om te checken of TreeNumber overeenkomt met het aantal shoots, is het tweede geval zou niet moeten getest worden of TreeNumber bij hakhout altijd groter is dan 1. (Het omgekeerde, dat individuele bomen maar 1 stam hebben, lijkt me wel relevant om te blijven testen?)

• voor beide bomen bij coppice_id '2 times the same coppice_id' (met waarde 5), eentje waar je nog van gevraagd had om ze in 1 record te zetten, denk ik (dus gaat over het feit dat er 2 levende delen zijn)
• voor de gecombineerde tree_measure_id '19_23' dat het een 'walker in coppice tree' is

Dit is inderdaad eenzelfde probleem, en dan is de eerste melding het duidelijkste, en de tweede dan eigenlijk overbodig (maar ook geen probleem dat de tweede behouden blijft)

Ok, dan ga ik niet moeilijk doen en deze allebei behouden. De tweede opmerking kan voor de oplosser van het probleem ook een gemakkelijke hint zijn dat het misschien niet over dezelfde boom gaat (zeker als die afstand tussen de bomen nog toegevoegd wordt)?

[leymanan]

• voor beide bomen bij ind_sht_cop 'incorrect' (waarde 12 zou dus niet juist zijn, een opmerking die kan verschijnen als er geen shoots zijn voor deze boom) Dat vind ik raar, ik zie in mijn project wél een shoot in layer shoots_3eSET. Er wordt toch niet gecheckt of er meer dan één shoot is? Want zelfs met één spil kan een boom een hakhoutstoof zijn, dat wil zeggen dat de andere spillen wellicht nog geen 5 cm dbh bereikt hebben.

Ik heb dit even gecheckt, en die opmerking wordt gegeven als nr_of_stems (TreeNumber in database) 1 is terwijl ind_sht_cop 12 is. Er wordt ook gecheckt of nr_of_stems overeenkomt met het aantal shoots. Dus ik neem aan dat minstens een van die tests niet zal moeten gebeuren, als een hakhoutstoof met maar 1 opgemeten shoot correct is. Geeft TreeNumber het totale aantal shoots, of enkel die boven 5 cm? In het eerste geval heeft het geen zin om te checken of TreeNumber overeenkomt met het aantal shoots, is het tweede geval zou niet moeten getest worden of TreeNumber bij hakhout altijd groter is dan 1. (Het omgekeerde, dat individuele bomen maar 1 stam hebben, lijkt me wel relevant om te blijven testen?)

TreeNumber geeft enkel die boven 5 cm weer. Dus inderdaad geen zin om het aantal te testen, maar zoals je aangeeft wel relevant om te checken of individuele bomen max. 1 spil hebben.

Wat ik vroeger ook testte was of de link tss layer shootsen layer trees wel in orde was: als ind_sht_cop = 12, dan moet er een gekoppeld record bestaan in layer shoots. En omgekeerd: als er een record in layer shoots zit, zou ind_sht_cop in de layer trees code 12 moeten hebben.

[ElsLommelen]

TreeNumber geeft enkel die boven 5 cm weer. Dus inderdaad geen zin om het aantal te testen, maar zoals je aangeeft wel relevant om te checken of individuele bomen max. 1 spil hebben.

Ok, dan haal ik die test weg.

Wat ik vroeger ook testte was of de link tss layer shootsen layer trees wel in orde was: als ind_sht_cop = 12, dan moet er een gekoppeld record bestaan in layer shoots.

Ok, die test zit ook in check_data_trees() met aberrant_field "link_to_layer_shoot", anomaly "missing" en geen aberrant_value omdat ik geen zinnige waarde kon bedenken.

En omgekeerd: als er een record in layer shoots zit, zou ind_sht_cop in de layer trees code 12 moeten hebben.

Die zit in check_data_shoot(). Zeer concreet checkt die of het record uit data_shoots gekoppeld kan worden aan een record uit data_trees met ind_sht_cop 12. Als dat niet het geval is, krijg je voor aberrant_field "link_to_layer_trees" de anomaly "missing", dus er wordt hier geen onderscheid gemaakt tussen niet aanwezig in trees of wel aanwezig maar geen ind_sht_cop 12.

(In elk geval goed dat je dit even vraagt om zeker te zijn dat we dit niet vergeten zijn. Ik geef hier ook duidelijk aan hoe ik het opgelost heb, zodat je kan reageren als het anders zou moeten.)

[ElsLommelen]

Nog een kleine bedenking i.v.m. het aanduiden van de bomen op dezelfde plaats die niet gekoppeld zijn. De berekening gebeurt nu (na aanpassen) door alle bomen van eenzelfde plot tussen opeenvolgende periodes te koppelen, de onderlinge afstanden te berekenen en de bomen te selecteren die op minder dan 0.2 m van elkaar liggen (en nog niet met elkaar gekoppeld zijn).

• in plots waar bomen opgegeven worden, worden vaak 2 mogelijk te koppelen bomen opgegeven, terwijl de boom op zich al via old_id gekoppeld is aan een andere bomen. In hoeverre is het in dit soort situaties nog nodig om dit aan te geven, en om verschillende koppelmogelijkheden per boom te geven, of reeds gekoppelde bomen nog op te geven?
• ook is deze berekening nogal traag omdat de bomen van eenzelfde plot allemaal onderling gekoppeld moeten worden om de afstand ertussen te kunnen berekenen
• omwille van beide voorgaande redenen vraag ik me af of deze berekening niet beter wat vereenvoudigd zou worden door wat extra voorwaarden op te leggen, bv.
  • enkel bomen voorstellen die nog niet gekoppeld zijn met de vorige periode (dus geen old_id hebben)
  • enkel koppeling tussen bomen voorstellen als ze van dezelfde soort zijn
  • ...

(Ter info: het gaat over 192 gemelde problemen voor de volledige dataset, dus dit is relatief weinig in vergelijking met sommige andere fouten, maar de berekening duurt in vergelijking relatief lang. Dus het voorstel om hierin nog te filteren, is om ervoor te zorgen dat het beperkt blijft tot relevante foutmeldingen, en vooral omdat dit het bijkomend voordeel geeft dat de berekening versnelt als er minder bomen gekoppeld moeten worden waarop de berekening uitgevoerd moet worden.)

[ElsLommelen]

• dode boom met decay stage 12 in de volgende periode IndShtCop 11 krijgt met decay stage 16: nee dat zou niet mogen kunnen

Ok, ik heb dit geval teruggevonden (en er zijn in totaal 9 gevallen in de dataset waarbij decay_stage gaat van 17 naar 16, dus mogelijk zijn die gelijkaardig, mogelijk zijn het ook gewoon fouten waar decay_stage van een levende boom waarde 17 gekregen heeft, want die zitten er nogal wat in):

• het gaat over plot_id 21000, de boom die in de eerste periode id 189 heeft en in de tweede periode id 151
• ind_sht_cop gaat van 12 naar 11
• decay_stage gaat van 17 naar 16: deze overgang wordt als fout aangeduid, maar ook het feit dat de 17 niet kan omdat de boom levend is
• Verontrustend is: als decay_stage van 17 naar 16 aangepast wordt, krijgt deze boom geen fout meer, want op de switch van ind_sht_cop tussen periodes wordt niet getest.

Moet er voor ind_sht_cop iets getest worden tussen periodes? Wat mag, en wat mag niet?

Toevoeging achteraf: ik ben nog bij enkele gevallen uitgekomen waar decay_stage van 16 naar 17 gaat, en minstens bij eentje hiervan gaat de boom van individueel (10) naar hakhout (12). Het gaat over plot_id 51000, en de boom die in de eerste periode id 10222 heeft, en in de 2de periode id 702. Ik weet niet of dit wel kan, qua decay_stage en/of qua ind_sht_cop?

[ElsLommelen]

Vraagje dat ik je misschien al eerder gesteld heb, maar dat ik nergens terugvind: mag decay_stage bij dood hout in opeenvolgende periodes hetzelfde zijn, of niet? (Bij levend hout of hakhout kom ik dat logischerwijs wel tegen, dat decay_stage in opeenvolgende periodes dezelfde waarde heeft (telkens 16 of telkens 17), dus dit mag sowieso niet als fout verschijnen. Maar ik vraag me dus af of het bij dood hout wel als fout moet blijven verschijnen, omdat dit impact heeft op hoe ik de code moet aanpassen.)

[leymanan]

Nog een kleine bedenking i.v.m. het aanduiden van de bomen op dezelfde plaats die niet gekoppeld zijn. De berekening gebeurt nu (na aanpassen) door alle bomen van eenzelfde plot tussen opeenvolgende periodes te koppelen, de onderlinge afstanden te berekenen en de bomen te selecteren die op minder dan 0.2 m van elkaar liggen (en nog niet met elkaar gekoppeld zijn).

• in plots waar bomen opgegeven worden, worden vaak 2 mogelijk te koppelen bomen opgegeven, terwijl de boom op zich al via old_id gekoppeld is aan een andere bomen. In hoeverre is het in dit soort situaties nog nodig om dit aan te geven, en om verschillende koppelmogelijkheden per boom te geven, of reeds gekoppelde bomen nog op te geven?

dat is inderdaad wellicht overkill, als de boom foutief gekoppeld zou zijn, komt dat op een andere plaats naar voor. Reeds gekoppelde bomen moeten dus niet meegenomen worden

• ook is deze berekening nogal traag omdat de bomen van eenzelfde plot allemaal onderling gekoppeld moeten worden om de afstand ertussen te kunnen berekenen

• omwille van beide voorgaande redenen vraag ik me af of deze berekening niet beter wat vereenvoudigd zou worden door wat extra voorwaarden op te leggen, bv.

  • enkel bomen voorstellen die nog niet gekoppeld zijn met de vorige periode (dus geen old_id hebben)

OK, goed idee

• enkel koppeling tussen bomen voorstellen als ze van dezelfde soort zijn

OK, goed idee

• ...

Ik kan niks extra's bedenken

[leymanan]

Vraagje dat ik je misschien al eerder gesteld heb, maar dat ik nergens terugvind: mag decay_stage bij dood hout in opeenvolgende periodes hetzelfde zijn, of niet?

ja dat mag hetzelfde blijven maar zou natuurlijk niet lager mogen worden (bv. niet van 15 naar 13), maar dat zou ik niet mee beginnen nemen in de datacontrole, is beetje overkill.

(Bij levend hout of hakhout kom ik dat logischerwijs wel tegen, dat decay_stage in opeenvolgende periodes dezelfde waarde heeft (telkens 16 of telkens 17), dus dit mag sowieso niet als fout verschijnen. Maar ik vraag me dus af of het bij dood hout wel als fout moet blijven verschijnen, omdat dit impact heeft op hoe ik de code moet aanpassen.)

moet dus niet als fout verschijnen, bedankt ;-)

[ElsLommelen]

Vraagje dat ik je misschien al eerder gesteld heb, maar dat ik nergens terugvind: mag decay_stage bij dood hout in opeenvolgende periodes hetzelfde zijn, of niet?

ja dat mag hetzelfde blijven maar zou natuurlijk niet lager mogen worden (bv. niet van 15 naar 13), maar dat zou ik niet mee beginnen nemen in de datacontrole, is beetje overkill.

Euh, voor alle duidelijkheid: ik controleerde al of het decay stage niet lager mocht worden, en van 15 naar 13 wordt wel degelijk als fout aangegeven, maar hier had ik opgegeven dat hetzelfde blijven ook niet mocht, dus dan pas ik dat gewoon even aan (<=0 naar < 0 of omgekeerd, ik weet niet meer exact hoe ik de regel geformuleerd heb). (Een kleintje om dit soort controles mee te nemen als ik toch de vergelijking van bomen tussen periodes gemaakt heb.)

[ElsLommelen]

Vraagje dat ik je misschien al eerder gesteld heb, maar dat ik nergens terugvind: mag decay_stage bij dood hout in opeenvolgende periodes hetzelfde zijn, of niet?

ja dat mag hetzelfde blijven maar zou natuurlijk niet lager mogen worden (bv. niet van 15 naar 13), maar dat zou ik niet mee beginnen nemen in de datacontrole, is beetje overkill.

Euh, voor alle duidelijkheid: ik controleerde al of het decay stage niet lager mocht worden, en van 15 naar 13 wordt wel degelijk als fout aangegeven, maar hier had ik opgegeven dat hetzelfde blijven ook niet mocht, dus dan pas ik dat gewoon even aan (<=0 naar < 0 of omgekeerd, ik weet niet meer exact hoe ik de regel geformuleerd heb). (Een kleintje om dit soort controles mee te nemen als ik toch de vergelijking van bomen tussen periodes gemaakt heb.)

Ter info: het probleem dat ik hier aankaartte, was blijkbaar geen probleem: in de code zag ik dat bomen die in hetzelfde decay_stage bleven, helemaal niet als fout gemarkeerd werden, TENZIJ ze in dezelfde periode van levend naar dood switchten. Dit laatste geeft wel een fout (wat ook logisch is, in dit geval mag het niet 16 blijven), behalve ingeval van decay_stage 17. Het voorbeeld waarop ik me gebaseerd had om de opmerking te maken, bleek een boom te zijn die decay_stage 16 bleef behouden terwijl hij van levend naar dood ging (dus wel een terechte opmerking in dit geval, lijkt mij). Voor de periode dat deze boom dood was, werd ook de fout aangegeven dat het decay_stage niet juist was (omdat 'tree not alive'). Tja, ik vrees dat het onvermijdelijk is dat er hier of daar weleens een overbodige boodschap verschijnt die niet echt fout is, ik neem aan dat dit geen probleem is? (Beter dit dan een fout die onder de radar blijft, vermoed ik?)

[ElsLommelen]

Nog een kleine bedenking i.v.m. het aanduiden van de bomen op dezelfde plaats die niet gekoppeld zijn. De berekening gebeurt nu (na aanpassen) door alle bomen van eenzelfde plot tussen opeenvolgende periodes te koppelen, de onderlinge afstanden te berekenen en de bomen te selecteren die op minder dan 0.2 m van elkaar liggen (en nog niet met elkaar gekoppeld zijn).

In verband met die niet gekoppelde bomen op dezelfde plaats heb ik de aanpassing gemaakt als afgesproken:

• bomen met old_id niet meer koppelen aan de vorig periode
• enkel koppelen als de soort hetzelfde is

Hiermee gaan we van meer dan 100 meldingen naar 1 melding (en een iets snellere berekening, heb ik de indruk), dus dit geeft jullie ook heelwat minder werk.

[ElsLommelen]

Voor een stand van zaken ben ik eens door het hele issue gescrold, en ik zie nog 2 hangende items:

• de vraag of er voor ind_sht_cop iets moet getest worden tussen periodes, of hier regels zijn of en hoe een boom mag veranderen doorheen de tijd. (Hier en daar zijn er bomen die van 12 naar 11 of van 10 naar 12. Soms komen er die wel uit doordat het decay_stage van 16 naar 17 gaat of omgekeerd, maar ik weet niet of dit altijd zo is?)
• hoe de aberrante waarden die juist zijn, in de fieldmapdatabank opgeslagen worden zodat ze bij verdere controles genegeerd kunnen worden

[leymanan]

• de vraag of er voor ind_sht_cop iets moet getest worden tussen periodes, of hier regels zijn of en hoe een boom mag veranderen doorheen de tijd. (Hier en daar zijn er bomen die van 12 naar 11 of van 10 naar 12. Soms komen er die wel uit doordat het decay_stage van 16 naar 17 gaat of omgekeerd, maar ik weet niet of dit altijd zo is?)

nee, dat hoeft niet: een individuele boom kan keer erop hakhout zijn en omgekeerd

[leymanan]

• hoe de aberrante waarden die juist zijn, in de fieldmapdatabank opgeslagen worden zodat ze bij verdere controles genegeerd kunnen worden

dat is inderdaad een moeilijke Is het geen optie om daar de tabel die aangemaakt wordt bij de datacontrole, en door Peter gebruikt wordt om de data te checken, voor te gebruiken? Als daar een extra veld aan toegevoegd wordt (? veldnaam "control" of "checked" - ik kan niet zo direct een goede naam verzinnen ) waar Peter dan in aanduidt dat het aberrant field correct is, en genegeerd mag worden ("to ignore" of "correct").

Bij een tweede check, kan die file ingelezen worden, en het veld "controle" overgenomen worden. Peter zal dan deze die "te negeren" of "correct" zijn, niet meer moeten bekijken.

[ElsLommelen]

• de vraag of er voor ind_sht_cop iets moet getest worden tussen periodes, of hier regels zijn of en hoe een boom mag veranderen doorheen de tijd. (Hier en daar zijn er bomen die van 12 naar 11 of van 10 naar 12. Soms komen er die wel uit doordat het decay_stage van 16 naar 17 gaat of omgekeerd, maar ik weet niet of dit altijd zo is?)

nee, dat hoeft niet: een individuele boom kan keer erop hakhout zijn en omgekeerd

Dus dan mag het decay_stage ook van 16 naar 17 gaan en omgekeerd? (Dat zou ik dan nog moeten aanpassen, dus belangrijk dat je dit nog even verduidelijkt.)

[ElsLommelen]

• hoe de aberrante waarden die juist zijn, in de fieldmapdatabank opgeslagen worden zodat ze bij verdere controles genegeerd kunnen worden

dat is inderdaad een moeilijke Is het geen optie om daar de tabel die aangemaakt wordt bij de datacontrole, en door Peter gebruikt wordt om de data te checken, voor te gebruiken? Als daar een extra veld aan toegevoegd wordt (? veldnaam "control" of "checked" - ik kan niet zo direct een goede naam verzinnen ) waar Peter dan in aanduidt dat het aberrant field correct is, en genegeerd mag worden ("to ignore" of "correct").

Bij een tweede check, kan die file ingelezen worden, en het veld "controle" overgenomen worden. Peter zal dan deze die "te negeren" of "correct" zijn, niet meer moeten bekijken.

En hoe ga je dat dan doen als je de databank een volgende keer checkt? Die nieuwe tabel eraan plakken? Misschien wil je dan wel overwegen om hier en daar wat te schrappen? Bij eenzelfde boom komen soms meerdere records met fouten tevoorschijn die allen te maken hebben met eenzelfde probleem (bv. als alive_dead fout ingevuld is, krijg je ook een error over decay_stage, en iufro-klassen, en de overgang van de ene periode naar de andere,..), dus Peter wil die waarschijnlijk niet allemaal beoordelen nadat hij al een fout aangepast heeft voor dat record. In elk geval mag hij die niet op "correct" of "to ignore" zetten, want die wil je opnieuw controleren nadat je de aanpassing gedaan hebt. (Eigenlijk zou je alles opnieuw moeten controleren van een boom of ander id waarin je ergens een aanpassing gemaakt hebt.) Dus kans is groot dat dit een zeer lange tabel wordt waar mogelijk ooit meermaals dezelfde error in gaat terechtkomen (en wat als die dan verschillend beoordeeld worden?). Dus bij voorkeur wordt die af en toe weleens nagekeken, of evt. overbodige records geschrapt (waarbij je records met "aangepast" of "correct" of ... waarschijnlijk wel wil behouden). Alternatieve piste is om een tabel te maken met de (wellicht zeer zeldzame) gegevens die echt aberrant maar correct zijn?

[leymanan]

En hoe ga je dat dan doen als je de databank een volgende keer checkt? Die nieuwe tabel eraan plakken?

Niet er onderaan aanplakken, maar eerder de oude tabel (eventueel een selectie ervan, enkel de "correct" records) , met een left_join aan de nieuwe te controleren plakken. Komt dan eigenlijk min of meer overeen met uw alternatieve piste (om een tabel te maken met de (wellicht zeer zeldzame) gegevens die echt aberrant maar correct zijn)

[ElsLommelen]

En hoe ga je dat dan doen als je de databank een volgende keer checkt? Die nieuwe tabel eraan plakken?

Niet er onderaan aanplakken, maar eerder de oude tabel (eventueel een selectie ervan, enkel de "correct" records) , met een left_join aan de nieuwe te controleren plakken. Komt dan eigenlijk min of meer overeen met uw alternatieve piste (om een tabel te maken met de (wellicht zeer zeldzame) gegevens die echt aberrant maar correct zijn)

Euh, ik vermoed dat je iets anders bedoelt dan left join, want met left join ga je een lege tabel als resultaat krijgen als ik er in het script voor zorg dat de "correct" records volgens je tabel niet meer opnieuw als aberrant gemeld worden. Bind_rows() misschien (= wat ik bedoelde met eraan plakken)?

Misschien het handigste als ik je dit eerst eens laat uittesten (evt. samen met Peter) en een tabel aanmaken in de databank, en ik daarna de code toevoeg om de als correct gemarkeerde aberrante waarden te negeren? Dat geeft jullie ook de mogelijkheid om te ervaren hoe vaak er per record meerdere opmerkingen komen als er 1 veld fout ingevuld is, eventuele suggesties te geven bij de gegeven opmerkingen, en te testen wat het gemakkelijkst werkt voor die lijst. En voor mij is het uiteraard ook handiger als ik de code kan ontwikkelen op een databank waar al zo'n tabel in staat, en als jullie het voldoende getest hebben om zeker te zijn dat die tabel gemakkelijk werkt voor jullie. ;-)

[leymanan]

Niet er onderaan aanplakken, maar eerder de oude tabel (eventueel een selectie ervan, enkel de "correct" records) , met een left_join aan de nieuwe te controleren plakken. Komt dan eigenlijk min of meer overeen met uw alternatieve piste (om een tabel te maken met de (wellicht zeer zeldzame) gegevens die echt aberrant maar correct zijn)

Euh, ik vermoed dat je iets anders bedoelt dan left join, want met left join ga je een lege tabel als resultaat krijgen als ik er in het script voor zorg dat de "correct" records volgens je tabel niet meer opnieuw als aberrant gemeld worden. Bind_rows() misschien (= wat ik bedoelde met eraan plakken)?

neenee, ik bedoel toch left_join: die "correcte", aberrante zullen er immers bij de nieuwe controle terug uit komen, en als je dan die tabel met "correcte" eraan plakt, dan weet je dat die "correct" zijn en niet meer gecheckt moeten worden.

Maar wellicht praten we naast elkaar en is 't inderdaad makkelijkste dat ik dat eens uittest samen met Peter ;-)

[ElsLommelen]

neenee, ik bedoel toch left_join: die "correcte", aberrante zullen er immers bij de nieuwe controle terug uit komen, en als je dan die tabel met "correcte" eraan plakt, dan weet je dat die "correct" zijn en niet meer gecheckt moeten worden.

Euh, de bedoeling van een aanduiding in de databank van welke aberrante waarden correct zijn, is toch net om ze bij de volgende controles te kunnen negeren zodat ze niet opnieuw in de lijst komen? (En zodat deze info ook door gebruikers gebruikt kan worden om te weten welke records ze best negeren in hun analyses.)

[leymanan]

neenee, ik bedoel toch left_join: die "correcte", aberrante zullen er immers bij de nieuwe controle terug uit komen, en als je dan die tabel met "correcte" eraan plakt, dan weet je dat die "correct" zijn en niet meer gecheckt moeten worden.

Euh, de bedoeling van een aanduiding in de databank van welke aberrante waarden correct zijn, is toch net om ze bij de volgende controles te kunnen negeren zodat ze niet opnieuw in de lijst komen? (En zodat deze info ook door gebruikers gebruikt kan worden om te weten welke records ze best negeren in hun analyses.)

inderdaad Dus ik zag workflow zo: er is een tabel met correcte aberrante records (van 1ste check), deze wordt ingeladen bij nieuwe datacheck en gekoppeld aan de nieuw ontstane tabel waarbij dan de al correct bevonden records mogen weggelaten worden uit deze nieuwe lijst met aberrante records.

[ElsLommelen]

Dus ik zag workflow zo: er is een tabel met correcte aberrante records (van 1ste check), deze wordt ingeladen bij nieuwe datacheck en gekoppeld aan de nieuw ontstane tabel waarbij dan de al correct bevonden records mogen weggelaten worden uit deze nieuwe lijst met aberrante records.

Vraag hierbij is: is het nodig om die checks volledig opnieuw te doen als je al weet dat die records eigenlijk toch niet gecheckt moeten worden? En dan denk ik vooral aan afwijkende diameters of hoogtes of hun verhouding. Anderzijds, als die info over aberrant in de databank niet bij de records van de bomen zelf bewaard wordt, is het waarschijnlijk meestal geen meerwaarde om die records al voor/bij de datacheck te negeren.

Uit je uitleg kan ik moeilijk afleiden wat precies de bedoeling is: laat ik die records al in mijn functies weg, of ga jij dat achteraf doen? (Vandaar dat we wat naast elkaar aan 't praten waren, denk ik: ik wou weten hoe jij het vanuit je standpunt als gebruiker wou hebben of zou gebruiken, maar ik ben niet zeker dat je het ook op die manier bekeek.)

[leymanan]

Uit je uitleg kan ik moeilijk afleiden wat precies de bedoeling is: laat ik die records al in mijn functies weg, of ga jij dat achteraf doen?

ik dacht dat jij dat al zou kunnen doen maar denk dat we misschien idd eerst iets concreters moeten hebben, is beetje in het ijle praten ;-)