Datacontrole: NA's in Total_xxxx_cover (vegetation)

[leymanan]

Maar ik zie dat bij load_data_vegetation() de bedekkingen van de verschillende lagen soms NA zijn

Als er geen (of heel weinig) bedekking is, moet er "< 1%" geselecteerd worden (of 20) Die NA's zijn soms echt wel effectief vergeten waardes. Ik heb net eens met Peter teruggekoppeld, en dat moet via datacontrole opgevangen worden.

Originally posted by @leymanan in https://github.com/inbo/forrescalc/issues/111#issuecomment-1838399671

[leymanan]

ter info (voor mezelf): ook die '20' betekent eigenlijk dat er niet gekeken is wat de bedekking was (dus ook NA). Bij datacontrole zou dan eerder die '20' verwijderd moeten worden (properder, duidelijke NA)

[ElsLommelen]

Nu ik dit issue tegenkom, heb ik even gecheckt hoe ik dit opgelost heb in check_data_vegetation() (issue #66): ik check telkens:

• is.na(xxx_cover_id) -> geeft foutmelding "missing"
• xxx_cover_id %in% data_totalcover$cover_id -> geeft foutmelding "not in lookuplist"

Dus op basis van bovenstaande zou ik nog moeten toevoegen:

• xxx_cover_id == 20 -> foutmelding?

Al lijkt dit laatste ook wel vreemd: er is iets uit de lijst gekozen, maar toch is dat niet ok. En als er niks ingegeven is, zou het wel ok zijn. Dit wringt een beetje met het principe van een relationele databank, waar liefst net wel afgedwongen wordt dat die id's overeenkomen met die in de lookuptabel en er geen afwijkende waarden kunnen voorkomen. (Bij het inladen via load_data_vegetation() wordt die Value1 = "Niet beschikbaar" trouwens omgezet naar NA, en ook een NA bij de invoer zal hier uiteindelijk als waarde NA geven, dus hiervoor maakt het niet uit welke keuze je maakt in de databank.)

Kan je even aangeven hoe ik het uiteindelijk best zou oplossen? Laat ik het zoals het is (waarbij de 20 geaccepteerd wordt en de NA niet), of pas ik het toch aan? En moet in dat laatste geval de functie load_data_vegetation() aangepast worden? (Misschien beter niet als de databank blijft wat ze is?)

[leymanan]

Dus op basis van bovenstaande zou ik nog moeten toevoegen:

• xxx_cover_id == 20 -> foutmelding?

Al lijkt dit laatste ook wel vreemd: er is iets uit de lijst gekozen, maar toch is dat niet ok. En als er niks ingegeven is, zou het wel ok zijn. Dit wringt een beetje met het principe van een relationele databank, waar liefst net wel afgedwongen wordt dat die id's overeenkomen met die in de lookuptabel en er geen afwijkende waarden kunnen voorkomen. (Bij het inladen via load_data_vegetation() wordt die Value1 = "Niet beschikbaar" trouwens omgezet naar NA, en ook een NA bij de invoer zal hier uiteindelijk als waarde NA geven, dus hiervoor maakt het niet uit welke keuze je maakt in de databank.)

Kan je even aangeven hoe ik het uiteindelijk best zou oplossen? Laat ik het zoals het is (waarbij de 20 geaccepteerd wordt en de NA niet), of pas ik het toch aan? En moet in dat laatste geval de functie load_data_vegetation() aangepast worden? (Misschien beter niet als de databank blijft wat ze is?)

Laten zoals het is.

We gaan dat niet als een fout zien, dat is zo ingevoerd, en betekent dat er niet gekeken is naar de cover. Dat hoort allemaal in het verleden en kunnen ze nu niet meer bijwerken. Ik zal wel aangeven aan Peter dat hij die waarde nu niet meer gebruikt (of toch zeker niet achteraf: is gewoon een NA, maar denk dat Peter daar teklens een '20' van gemaakt heeft bij opkuis data).

Zoals je al aangeeft wordt dit opgevangen in functie load_data_vegetation()

[ElsLommelen]

Ok, dus dit issue mag genegeerd worden (of als opgelost gemarkeerd)?

Ik zal wel aangeven aan Peter dat hij die waarde nu niet meer gebruikt (of toch zeker niet achteraf: is gewoon een NA, maar denk dat Peter daar teklens een '20' van gemaakt heeft bij opkuis data).

Hier misschien toch nog eens over nadenken: databanktechnisch lijkt het me properder dat er overal een waarde staat die overeenkomt met de codekolom (en niet NA; alles invullen is trouwens ook handig want hier kan je in de databank zorgen dat er geen fouten komen door referentiële integriteit af te dwingen). En bovendien wordt dat veld momenteel getest op 'missing' in de checks, dus dit zullen we terug moeten weghalen als je NA als waarde wil toelaten.

[leymanan]

Hier misschien toch nog eens over nadenken: databanktechnisch lijkt het me properder dat er overal een waarde staat die overeenkomt met de codekolom (en niet NA; alles invullen is trouwens ook handig want hier kan je in de databank zorgen dat er geen fouten komen door referentiële integriteit af te dwingen). En bovendien wordt dat veld momenteel getest op 'missing' in de checks, dus dit zullen we terug moeten weghalen als je NA als waarde wil toelaten.

die '20' is een NA, is missing en zou niet mogen voorkomen, net zomin als ik NA wil toelaten. die '20' is dus niet beter dan een NA, enkel heeft Peter op een bepaald moment gezegd "we zijn dat vergeten"

volgens mij is het een utopie om te denken dat we met de datacontrole alle missing values gaan oplossen, er gaan er nog veel blijven. Maar vanaf nu kan dat wel helpen om wat korter op de bal te spelen, en - indien mogelijk - kunnen ze bij een volgend terreinbezoek die ontbrekende waardes nog aanvullen. De ontbrekende waardes '20' die we nu vooral zien, dateren allemaal van voor 2020 ...

[ElsLommelen]

Euh, wat moet het nu uiteindelijk zijn? Dat je uit het verleden ontbrekende waarden hebt die je niet meer kan oplossen, is een realiteit waar je niks meer aan kan veranderen. Om je databank zo uniform mogelijk te houden (wat handiger is voor dataverwerking), kan je voor deze gegevens best een keuze maken om consequent toe te passen: ofwel overal NA, ofwel overal 20 (als teken dat ze gecheckt zijn en niet meer aangepast kunnen worden).

En uiteraard stel je best de datacontrole af op die keuze: als overal 20 ingevoerd wordt, gaat je datacontrole sowieso NA als missing moeten opgeven zodat dit consequent aangepast kan worden naar 20. En daarnaast kan je voor je datacontrole nog kiezen om bv. ook die 20 als fout op te geven, tenzij het record in de tabel met te negeren anomalieën staat (die nog aan te maken is in de databank). Of je kan 20 enkel als fout opgeven vanaf periode 3, of nog een ander regeltje waardoor je die 20 na een eerste check kan negeren ingeval de fout onoplosbaar is.

Dat er onoplosbare fouten in een databank zitten, is onvermijdbaar, maar zoals vorige week besproken: dit los je best op met een tabel in de databank die aangeeft welke onoplosbare anomalieën er zijn, zodat die waar nodig genegeerd kunnen worden bij analyses of foutcontroles.

[ElsLommelen]

cover = 20 mag foutmelding zijn, en NA ook

[ElsLommelen]

Deze was ik na ons overleg wat uit het oog verloren, maar is nu opgelost. Ter herinnering: we hebben toen besproken dat cover_id 20 en NA allebei als fout aangeduid mag worden, en dat je die boodschap voor oude gegevens zou kunnen overrulen door het toe te voegen aan een (nog aan te maken?) tabel in fieldmap die aangeeft wat aberrant maar wel juist is. (Dit moet ik uiteraard ook nog in orde brengen in het script, nadat dit in de databank in orde is. Zie hiervoor o.a. in issue #66, en waarschijnlijk ook je nota's van het overleg.)