search

inbo / dhcurve

An R package for automated modelling of diameter-height relations for trees
https://inbo.github.io/dhcurve
GNU General Public License v3.0
0 stars 0 forks source link

html-rapport van alle modellen? #36

Closed leymanan closed 3 years ago

leymanan commented 3 years ago

ik heb "min_basis" van de minder goede modellen eens opgetrokken, zodat er nu afgeleide modellen van gemaakt worden. Dan bij afgeleid model gaan kijken, maar daar verschijnen enkel deze met meetfouten ... Is het mogelijk om iets te voorzien zodat alle modellen afgedrukt worden? Best statisch. Nu zit de aanmaak van zo een rapport ingebed in de functie "validatie". Al dan niet met de mogelijkheid om een lijst van domein-bms-combinaties aan te bieden als input (om zo ev. enkel een rapport te creëren van de twijfelgevallen)

ElsLommelen commented 3 years ago

Ok, mss wel eerst even verder brainstormen wat je precies wil.

leymanan commented 3 years ago

brainstorm goed idee!

ElsLommelen commented 3 years ago

In verband met die fouten: zelfs als er nog fouten in een model zouden zijn, zouden we kunnen kiezen om in dit rapport alles in het zwart te zetten. Net zoals we er ook voor zouden kunnen kiezen om hier voor de afwijkende curve met maximum in het interval de gecorrigeerde grafiek te tonen die overeenkomt met het eindresultaat dat teruggegeven wordt (dus curve die bij hogere omtrekklassen dit maximum blijft behouden en niet terug daalt). Als dit rapport een iets andere doelstelling heeft dan een validatierapport, lijkt het me logisch dat we keuzes maken in functie van de specifieke doelstellingen. En om verwarring te voorkomen, zou ik zelfs eerder geneigd zijn om het rapport bewust een andere look te geven dan het validatierapport.

Hmmm, anderzijds is je idee om bij de validatie aan te geven als je extra modellen wil toevoegen, ook een goed idee. Om de doelstelling van validatie niet voorbij te schieten en te vermijden dat gebruikers slechte modellen kunnen negeren, zou ik in dit geval wel willen vasthouden aan het feit dat de modellen met fouten sowieso worden opgenomen. Ik weet niet wat je voorkeur heeft: bij de validatie die mogelijkheid toevoegen, of een aparte functie waarbij je voor eender welk model een grafiek kan opvragen (en evt. alle grafieken in 1 rapport doen, dan dan standaard statisch is)? (Bepaal dit best op basis van de workflow die je gebruikt om de modellen te valideren.)

Als je voor een apart rapport kiest: heb je een voorkeur voor de sortering van de modellen? (In het validatierapport zijn ze gesorteerd op de afwijkende metingen, dan boomsoort en dan domein, maar dat eerste lijkt me hier niet relevant.)

leymanan commented 3 years ago

Waar ik een extra rapport voor nodig heb, is tweeërlei: 1) op dit moment vooral ter validatie, want waar ik nu mee sukkel, is om te kunnen beoordelen of een afgeleid model inderdaad beter is dan een basismodel. Omdat op dat moment de afwijkende metingen ofwel goedgekeurd ofwel afgekeurd zijn, worden deze modellen niet meer weergegeven in de validatierapporten. 2) informatief (en ook beetje ter controle): weergave van de modellen die we willen gebruiken in IVANHO (= de expliciet goedgekeurde modellen én de modellen waar geen reden toe was om ze in detail te bekijken).

Maar misschien moeten we daar twee afzonderlijke rapporten voor voorzien.

Sowieso moet er ergens een systeem zijn om afwijkende curves toch af te kloppen als OK. En anderzijds om curves die NIET als afwijkend bestempeld worden (want geen afwijkende vorm), toch te kunnen bekijken en eventueel af te keuren, wegens bv. twee puntenwolken, of indicatie van twee leeftijdsklasses, of ...

Goed idee om dan voor het informatieve rapport voor een andere look te gaan, en om gecorrigeerde grafiek te tonen (die niet terug daalt bij hogere omtreklasses). Hier mag alles in zwart. Sortering voor informatief rapport: eerst op domein en dan op boomsoort.

Een extra validatierapport lijkt me handiger dan de optie toevoegen bij de validatie-functie. Workflow is immers als volgt:

Dit extra validatierapport zou zich moeten baseren op de lijst van afwijkende curves die manueel aangevuld is met ev. extra bossen en een beoordeling (model_ok = T/F). Als model_OK NIET gelijk is aan TRUE of FALSE (dus nog onzeker of het model OK is), dan opnemen in dat extra validatierapport (zie vb in bijlage; zelfde lijst als waar "Uitzonderingen" van vertrekt; in te lezen vanuit dbpath; boomsoorten cfr IVANHO)

Best alle modellen samen in dat extra validatierapport (indien mogelijk). Met vermelding van type model. Sortering eerst op boomsoort en dan op afwijkende metingen domein. Ik loop immers bms na bsms af bij de controles. (? huidig validatierapport: op wat wordt gesorteerd als afwijkende metingen goed/afgekeurd zijn en er enkel slechte curvevorm overblijft? Het lijkt me niet zo logisch zoals het nu is, zou beter eerst op boomsoort sorteren)

Dezelfde lijst (zoals in bijlage) zou ik willen gebruiken voor de aanmaak van het informatieve rapport, om te zorgen dat enkel de goedgekeurde modellen in het informatieve rapport komen (model_ok= TRUE; !!uiteraard samen met deze die niet in de lijst staan, en waar geen reden toe was om ze in detail te bekijken).

Beide rapporten samen moeten dan alle domein-bms-combinaties dekken.

ElsLommelen commented 3 years ago

Euh, ik weet niet hoe je geprobeerd hebt om een bijlage toe te voegen aan een issue van github, maar bij mijn weten kan/werkt dat niet. ;-)

Ok, dus het voorstel is:

Anderzijds heb ik toch nog de bedenking: als er geen fout is (en er toch niks rood gekleurd wordt), waarom dan niet gewoon het informatieve rapport gebruiken om je grafieken te bekijken? Hiermee heb je de vrijheid om alle grafieken op te vragen die je wil, en als je het wat handig aanpakt, kan je hier ook de 2 modellen van dezelfde domein-BMS-combinatie in opvragen. (Het gaat dan wel statisch zijn, maar vermits er geen afwijkende metingen in zitten, is die tooltip niet echt nodig, lijkt mij.)

ElsLommelen commented 3 years ago

Ik heb een functie dhcurvesrapport() toegevoegd, waarmee je op basis van de outputs van outputIVANHO() en initiatie() een rapport met curves kan aanmaken. Welke curves opgenomen worden, wordt bepaald op basis van de input afgeleid uit outputIVANHO(), dus je kan evt. daar filteren. Opgelet! Als bepaalde curves niet goed zijn en je wil vermijden dat deze je totale basismodel beïnvloeden (en daarmee ook de andere curves), moet je ze uit je basisdata halen en alles vanaf de initiatiestap opnieuw doen!

leymanan commented 3 years ago

functie heeft gelopen, maar rapport is leeg, net zoals alle andere html-rapporten ... (ik heb branch "update-code" binnen getrokken (pull) met erna een "build en install")

leymanan commented 3 years ago

O ja: ik had geantwoord op je comment met een mail, en daar een bijlage aan toegevoegd. Dat was een xls met een overzicht van alle curves en een extra veld "model_OK" (TRUE or FALSE). Dat heb ik ondertussen vervangen door de tabel "tblCurvesDomeinBms" in hulpdatabank.accdb, waarbij ik het veld "model_OK" vervangen heb door een "status" cfr afwijkende metingen (niet gecontroleerd, goedgekeurd, te controleren, twijfel)

Deze status kan ik dan in R koppelen aan outputIVANHO, wat me toelaat te filteren op status = twijfel om zo een beperkter rapport te creëren.

leymanan commented 3 years ago

ik heb nu een rapport gecreëerd van alle "twijfelmodellen", maar ik mis daar toch die aanduiding van wat er fout is in het model (in rood). Ik vind die balkjes ook minder duidelijk dan de lijn me t punten zoals in de validatierapporten. En de punten zelf zijn nu een flou (zwak) groen, wat ik niet zo duidelijk vind.

Het rapport hoeft voor mij wel niet interactief te zijn. De afwijkende metingen zijn immers al goed- of afgekeurd op dat moment.

leymanan commented 3 years ago

Voor mij zou het ook handig zijn om toch ook nog het Vlaams model weer te geven, ik vind dat dat toch ook wat houvast biedt. Zeker ook bij de vergelijking tss basismodel en afgeleid model.

Dus layout toch liever wat meer richting het validatierapport ... Op dit moment is bij mij immers het hoofddoel vooral de controle, eerder dan informatief.

Maw liever dat het informatieve rapport meer op een validatierapport lijkt, dan dat mijn rapport om te controleren op een informatief rapport lijkt ;-)

ElsLommelen commented 3 years ago

Vermits je blijkbaar toch eerder op zoek bent naar een soort validatierapport om de curves te controleren (fouten in rood, Vlaams model,...), misschien dan toch beter de piste uitwerken om extra domein-BMS-combinaties op te vragen bij het aanmaken van een validatierapport? Zo'n rapport aanmaken met de info uit outputIVANHO() (of resultaat()) is niet mogelijk, hiervoor is er specifieke info nodig die in de validatiestap berekend wordt (en in latere stappen geen nut meer heeft)...

Ter info: ik heb voor het informatieve rapport bewust de lijn van de 'curve' weggelaten, omdat die verkeerdelijk de indruk geeft dat het over een continu model zou gaan. Ik zou van die balkjes ook punten kunnen maken als dit duidelijker is, maar dan is het moeilijk om een duidelijk onderscheid te maken tussen de punten van het model en de metingen (vandaar ook de groene kleur voor de metingen-jitter). Een andere vorm misschien (driehoek, vierkant, ruit,...)? Ik was hier uitgegaan van het idee dat dit voor goedgekeurde curves was, waarbij een juiste interpretatie belangrijk is. Moest je ideeën hebben om deze duidelijker te maken voor dit doel, laat zeker weten. (Ook bv. de metingen: ik heb een poging gedaan om deze niet te storend te maken in de grafiek, maar wel zichtbaar, door bv. de sterkte te laten afhangen van het aantal metingen, maar blijkbaar toch niet zo geslaagd.)

(Daarnaast zal ik er dus voor zorgen dat je extra curves kan toevoegen in het validatiemodel, zodat je de modellen op die manier kan controleren.)

ElsLommelen commented 3 years ago

Ik heb een extra parameter ExtraCurvesRapport toegevoegd aan validatie.basis(), validatie.afgeleid() en validatie.lokaal() waarin je extra domein-BMS-combinaties kan opgeven om in de validatierapporten te tonen. Voldoet dit?

Behoud ik ook het informatieve rapport? Moeten hier evt. nog aanpassingen aan gebeuren?

leymanan commented 3 years ago

Ja, misschien inderdaad beter dat er een meer uitgebreid "validatierapport" mogelijk is, waarbij ik niet alleen (1) bepaalde afgeleide modellen kan toevoegen (bv. door min_basis > 50; zonder duidelijke fout, maar mogelijks met twee puntenwolken), maar ook (2) de modellen die ik reeds goedgekeurd heb (status "goedgekeurd" NIET meer weergeef

En daarnaast kan het informatieve rapport zoals het nu voorligt ook behouden blijven, alhoewel ik die balkjes verwarrend vind. Vierkantjes of driehoeken zouden een alternatief kunnen zijn, als je een lijn te misleidend vind.

Wat betreft de sterkte van de punten af laten hangen van het aantal metingen: dat ziet er inderdaad op een of andere manier toch minder geslaagd uit dan je zou denken. Ik zou ze dan toch gewoon weergeven, maar misschien in een niet al te opvallende kleur ... (?)

leymanan commented 3 years ago

ik heb validatie.afgeleid laten lopen met die extracurves en dat is OK!

Maar zou er ook een mogelijkheid bestaan om een optie toe te voegen zodat ik bij de basiscurves en de lokale curves enkel deze curves te zien krijg die nog niet goedgekeurd zijn? Of naar analogie van de parameter ExtraCurvesRapport, een parameter GeenCurvesRapport met lijst van deze die ik NIET wil zien (omdat ze goedgekeurd zijn? Dat zou echt wel handig zijn ...

ElsLommelen commented 3 years ago

Ik vind dit een beetje een lastige situatie: op het moment wil je die goedgekeurde curves niet meer zien, maar zodra er gegevens toegevoegd worden aan de databank, wil je uiteraard dat die curves weer wel getoond worden als ze afwijkend zijn (de afwijking kan groter zijn, waardoor je ze mss toch wel beter zou afkeuren, al is ze hopelijk minder groot). En je wil niet manueel gaan checken welke van je goedgekeurde curves nieuwe gegevens hebben... En vooral: als je het negeren van bepaalde curves in een script verwerkt hebt, ga je gewoon vergeten om het negeren van die curves terug 'af' te zetten met het risico dat het validatierapport niet meer doet waar het eigenlijk voor gemaakt is: de gebruiker duiden op potentiële probleemgevallen.

Anderzijds vraag ik me af voor alles anders dan het basismodel: als je de analyse al gedaan hebt en de curves voor jezelf goedgekeurd hebt, waarom zou je dan de validatiestap opnieuw uitvoeren voor die domein-BMS-combinatie zolang er geen aanpassingen in de databank zijn? De analyse (en vooral het aanmaken van het rapport) duurt wel eventjes, dus van zodra ik de rapporten nog voor enkele specifieke BMS of BMS-domein-combinaties nodig zou hebben, zou ik de functie enkel runnen voor die specifieke combinaties (en niet voor de hele databank). M.a.w. waarom filter je de goedgekeurde domein-BMS-combinaties niet uit vooraleer je de analyse begint? Hierbij uiteraard wel opletten dat je voor het basismodel wel alle domeinen van een bepaalde BMS in je analyse moet houden! Je zou dan de validatie stap voor stap kunnen uitvoeren op specifieke delen van de databank (per BMS?) tot alles goedgekeurd of afgekeurd is. (Je kan trouwens ook in de tussenstappen, bv. de gefitte modellen, de gewenste modellen uitselecteren om de volgende stap, in dit geval de validatiestap, uit te voeren.) En daarna kan je finaal nog eens het volledige script runnen (op de goedgekeurde gegevens en/of gebruik makend van de uitzonderingen bij initiatie), waarbij je de validatiestappen kan overslaan. (Dit kan uiteraard enkel als je alles netjes bijhoudt in tabellen, zoals jij dat doet, zodat je zeker bent dat er geen curves ontsnappen aan de validatie.)

Enfin, ik heb het gevoel dat de aanpassing zoals je ze voorstelt de hele bedoeling van de validatierapporten ondermijnt, dus ik zou ze niet als dusdanig willen implementeren. Een optie zou zijn dat je bij de modellen het huidige aantal bomen in de databank opgeeft om ervoor te kunnen zorgen dat de curve na het toevoegen van een extra boom opnieuw getoond wordt als hij nog steeds afwijkt (iets als de uitzonderingen bij initiatie()), maar dat is extra rompslomp die mij niet echt praktisch lijkt. (Een interessant maar onrealistisch idee zou kunnen zijn dat het package op basis van je goedkeuringen leert wat je acceptabel vindt, maar dat gaat dus te ver...) Voorlopig heb ik niet echt een beter idee, dus ik zou het even willen laten rusten tot me iets te binnen schiet. Als we er tegen het overleg met Thierry geen oplossing voor hebben, dit mss ook met hem erbij bediscussiëren?

leymanan commented 3 years ago

Al heel snel een korte verantwoording voor mijn vraag. Het klinkt inderdaad onlogisch om op een bepaald moment de afwijkende curves nniet meer te willen zien. Maar ik vind het wel handig dat je kan afvinken wat reeds goedgekeurd is. Als ook de goedgekeurde curves er steeds tussen blijven staan, dan maakt dat de controle lastiger.

leymanan commented 3 years ago

"M.a.w. waarom filter je de goedgekeurde domein-BMS-combinaties niet uit vooraleer je de analyse begint? Hierbij uiteraard wel opletten dat je voor het basismodel wel alle domeinen van een bepaalde BMS in je analyse moet houden!"

dat uitfilteren zou goed idee lijken, maar zoals je zegt: om basismodel op te stellen heb je alle andere domeinen ook nodig, dus eigenlijk lukt dat niet echt ...

Je bedoelt toch na de initiatiestap? Maar je hebt alles nodig om Vlaams model en de ervan afgeleide modellen (basis en afgeleid) te maken. Dus zou al na de fit-stap moeten zijn. Maar bij de validatiestap is de input het model, ik zie niet in hoe ik daar nog kan filteren? => validatie.basis(Basismodel, TypeRapport = "Dynamisch")

Of kan ik de hulpfunctie "validatierapport" zelf aanroepen, en dan zelf de modellen opgeven (SlechtsteModellen) waarvan een grafiek moet gemaakt worden? Misschien is dat nog het makkelijkste??

leymanan commented 3 years ago

je zegt "op het moment wil je die goedgekeurde curves niet meer zien, maar zodra er gegevens toegevoegd worden aan de databank, wil je uiteraard dat die curves weer wel getoond worden als ze afwijkend zijn (de afwijking kan groter zijn, waardoor je ze mss toch wel beter zou afkeuren, al is ze hopelijk minder groot)."

Dat is inderdaad een aandachtspunt. Maar sowieso moet ik daar een oplossing voor hebben: ik zet in mijn databank dat die bepaalde curve goedgekeurd is. Als ik dan initiatie laat lopen, ga ik niet meer kijken naar die "goedgekeurde" curve (maakt niet uit of ze nu wel of niet in het validatierapport zit). Ik zal sowieso een script moeten aanmaken dat ervoor zorgt dat voor alle curves waar nieuwe gegevens bijkomen, de status terug naar "te controleren" gezet wordt

leymanan commented 3 years ago

je zegt : "En vooral: als je het negeren van bepaalde curves in een script verwerkt hebt, ga je gewoon vergeten om het negeren van die curves terug 'af' te zetten met het risico dat het validatierapport niet meer doet waar het eigenlijk voor gemaakt is: de gebruiker duiden op potentiële probleemgevallen."

Ik zou niet werken met negeren, maar eerder met een lijst die ik doorgeef van modellen die NIET opgenomen moeten wordenn. Vergelijkbaar met lijst van modellen die WEL moeten opgenomen worden. Als dat kan tenminste.

leymanan commented 3 years ago

" (Je kan trouwens ook in de tussenstappen, bv. de gefitte modellen, de gewenste modellen uitselecteren om de volgende stap, in dit geval de validatiestap, uit te voeren.)"

Misschien dat dat een optie is: ik heb dan de modellen gefit, en dan ga ik degene die nog niet goedgekeurd zijn "valideren" met de validatiestap. En dan schrijf ik inderdaad wat extra code, dat kan, komt beetje op zelfde neer: ofwel neem jij dat mee in de functie, ofwel schrijf ik er een extra stukje code voor.

Oeps: ?? ik zie niet hoe ik dat kan doen, hoe haal ik uit "Basismodel" specifieke curves? AfwijkendeMetingen <- validatie.basis(Basismodel, TypeRapport = "Dynamisch")

summary(Basismodel) BMS Model.Length Model.Class Model.Mode Length:13 18 lme list
Class :character 18 lme list
Mode :character 18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list
18 lme list

Zijn er manieren om de resultaten van de initiatie en fit-stappen op et slaan, zodat ik - als ik erna de code open - die stappen niet opnieuw moet runnen. Want duurt inderdaad vrij lang. Ik gebruikte daar vroeger save.image() voor denk ik

ElsLommelen commented 3 years ago

Ik zou zeggen: probeer eens of dat praktisch is. En anders gaan we best nog eens goed nadenken over de dataflow en hoe we evt. 'goedkeuring van curves' hierin verder kunnen uitbreiden. Voor afgekeurde curves bestaat er een optie om die als uitzondering op te geven, maar het zou ook wel logisch zijn dat je op een of andere manier ook goedgekeurde (afwijkende) curves zou kunnen opgeven als 'in orde zolang er geen nieuwe metingen bij komen'. Dat betekent wel dat je een aantal bomen zal moeten opgeven vanaf wanneer de curve terug getoond moet worden bij de validatie. Dit dus als veiligheid om te zorgen dat de grafiek terug getoond wordt zodra er (meerdere) metingen bij komen (we gaan dat moeten bekijken, mss moet die nog niet terug bekeken worden bij 1 extra meting, wel bij 5 ofzo, analoog aan de uitzonderingen bij intiatie()). Praktisch zou je het dan als volgt kunnen doen: in je databank een lijst maken (of je bestaande lijst aanpassen) zodat je voor de afwijkende curves bij zowel de goedgekeurde als de afgekeurde curves een aantal bomen hebt staan. Van deze lijst geef je de afgekeurde curves mee bij uitzonderingen van initiatie() (en hier duidt het aantal bomen aan vanaf wanneer er terug van model geswitcht moet worden), en de goedgekeurde curves geef je mee bij de nog aan te maken functionaliteit (mss best bij validatie.xxx() mee te geven?) (en hier duidt het aantal bomen aan vanaf wanneer de validatiecurve terug getoond moet worden). En van zodra die curves terug in je validatierapport verschijnen, is het tijd om je tabelletje in de databank aan te passen: goedgekeurd/afgekeurd herbekijken en het aantal bomen wat optrekken, of mss kan het (aantal bomen) wel verdwijnen uit je lijstje (als er enkel nog afwijkende metingen zijn, geen afwijkende curve meer)? (Evt. zou je af en toe, bv. om de 10 jaar, het lijstje nog eens kunnen bijwerken op basis van het aantal bomen in het domein, want mogelijk gaan sommige curves in orde zijn zodra ze terug in het validatierapport zouden moeten terechtkomen, en dus nooit getoond worden. In principe is het geen probleem dat die lijstjes behouden blijven, maar wellicht wat minder overzichtelijk voor u.) Om eens over na te denken. ;-)

leymanan commented 3 years ago

op dit moment staat het aantal bomen al opgenomen in de tabel met curves (in hulpdatabank.accdb). Dat is een vrij volledige tabel met alle domein-bms-combinaties, modeltype, nBomen, RMSE, reden_controle, status, opmerking, min_basis, min_afgeleid, en ook een unieke ID. Ze werd aangemaakt obv de eerste run van het script, maar zal dus aangevuld worden wanneer er extra metingen bijkomen

Ik gebruik die tabel al om de dataframe Uitzonderingen aan te maken, en ook om in de functie validatie.afgeleid extra afgeleide curves op te geven. Maar ik kan daar natuurlijk nog verder in gaan.

leymanan commented 3 years ago

Misschien toch nog eens resumeren (voor mezelf ook).

Huidige werkwijze Ik werk nu dus met een volledige tabel van domein-bms-combinaties (opgeslagen als "tblCurvesDomeinBms" in de hulpdatabank), met volgende info: modeltype, nBomen, RMSE, reden_controle, status, opmerking, min_basis, min_afgeleid, en ook een unieke ID. Ze werd aangemaakt obv de eerste run van het script, maar zal dus aangevuld worden wanneer er extra metingen bijkomen

Naar analogie met AfwijkendeMetingen, pas ik mbv een query in R de status van AfwijkendeCurves aan van "Niet gecontroleerd" naar "Te controleren". Deze curves bekijk ik vervolgens in de validatierapporten. Ik geef in het veld status aan of ze goedgekeurd zijn, afgekeurd of nog een twijfelgeval. Als ik van een basismodel naar een afgeleid model wil overstappen, pas ik min_basis aan, en zet ik de status terug naar "Niet gecontroleerd".

In een tweede run, start ik met het aanmaken van de file "Uitzonderingen": mbv een query in R bevraag ik de tabel en selecteer ik de domein-bms-combinaties waar min_basis > 50. Ik laat opnieuw alles lopen, initiatiestap, fit en validatie van de 3 mogelijke modellen.

In de validatiestap van de afgeleide modellen, maak ik nu gebruik van de uitgebreide validatie-functie, met de dataframe "ExtraCurvesAfgeleid" als extra parameter:

ExtraCurvesAfgeleid <- curves_db %>% filter(min_basis >= 50) t <- validatie.afgeleid(Basismodel, Afgeleidmodel, ExtraCurvesRapport = ExtraCurvesAfgeleid ) Zo worden de afgeleide curves (die nooit als AfwijkendeCurve gedetecteerd worden) toch in het validatierapport weergegeven.

Wat ontbreekt er volgens mij Ik heb in de eerste stap reeds heel wat modellen goedgekeurd (ook sommige afgekeurd en bij sommige aangegeven om er een afgeleid model van te maken). Het zou voor mij makkelijker zijn om op een of ander manier in deze 2de stap niet opnieuw alle goedgekeurde modellen in de validatierapporten te zien. Een lijst van deze goedgekeurde modellen is makkelijk aan te maken, naar analogie met de aanmaak van de tabel "Uitzonderingen" (zit immers allemaal in de hulpdatabank).

Dat strookt wellicht met het voorstel uit jouw vorige comment "... en de goedgekeurde curves geef je mee bij de nog aan te maken functionaliteit (mss best bij validatie.xxx() mee te geven?)" : is inderdaad zo een aanvulling die ik graag zou hebben :-)

Jij stelt dan verder voor ".... (en hier duidt het aantal bomen aan vanaf wanneer de validatiecurve terug getoond moet worden)." Ik veronderstel dat je dan bedoeld: als status = goedgekeurd én aantal bomen <> aantal bomen in tabel uit hulpdatabank, dan TOCH weergeven.

Een andere optie is om een extra main-script te schrijven om te gebruiken wanneer er nieuwe metingen bijkomen. Dat script kan dan de tabel "tblCurvesDomeinBms" in de hulpdatabank bijwerken: zodra er nieuwe metingen zijn van een bepaalde domein-bms-combinatie, de status terug naar "Niet gecontroleerd" zetten.

Uw suggesties (1) " (Je kan trouwens ook in de tussenstappen, bv. de gefitte modellen, de gewenste modellen uitselecteren om de volgende stap, in dit geval de validatiestap, uit te voeren.)"

Dat leek me een goed idee: na fitten van de modellen, enkel deze die nog niet goedgekeurd zijn "valideren" met de validatiestap. Met dan wat extra code errond, dacht dat dat beetje op zelfde neerkwam: ofwel neem jij dat mee in de functie, ofwel schrijf ik er een extra stukje code voor...

MAAR ik zie niet hoe ik dat kan doen, hoe haal ik uit "Basismodel" specifieke curves? AfwijkendeMetingen <- validatie.basis(Basismodel, TypeRapport = "Dynamisch")

Dus voor mij toch liever een extra parameter in de validatie-functies die toelaat om de goedgekeurde curves te specifiëren.

(2) "Dat betekent wel dat je een aantal bomen zal moeten opgeven vanaf wanneer de curve terug getoond moet worden bij de validatie. Dit dus als veiligheid om te zorgen dat de grafiek terug getoond wordt zodra er (meerdere) metingen bij komen (we gaan dat moeten bekijken, mss moet die nog niet terug bekeken worden bij 1 extra meting, wel bij 5 ofzo, analoog aan de uitzonderingen bij intiatie())."

Ik zou dat eerder verwerken in een extra main-script dat gebruikt moet worden wanneer er nieuwe metingen bijkomen. Zie hierboven (Dat script moet dan de tabel "tblCurvesDomeinBms" in de hulpdatabank bijwerken: zodra er nieuwe metingen zijn van een bepaalde domein-bms-combinatie, de status terug naar "Niet gecontroleerd" zetten).

ElsLommelen commented 3 years ago

Eventjes inpikken op het deeltje 'Uw suggesties', op basis daarvan kan ik min of meer alles behandelen waar ik op wil reageren:

(1) Voor het basismodel kan je idd enkel op boomsoort filteren omdat je hier een model per BMS hebt, voor de andere modellen kan het wel per curve. Dus ja, dat is een oplossing om modellen stap voor stap te controleren, maar je kan niet nauwkeuriger gaan dan het niveau van 1 model... Het filteren doe je trouwens zo: Basismodel %>% filter(BMS == "Beuk") Bij het lokaal model is het gelijkaardig (maar hier kan je ook filteren op DOMEIN_ID), voor het afgeleid model ga je in de dataframes van de list moeten filteren.

(2) Idee van het opgeven van het aantal bomen (dat inderdaad aangeeft vanaf hoeveel bomen de curve terug getoond moet worden, dus analoog aan de min_basis bij uitzonderingen zou je hier de regel van huidig aantal + 5 kunnen hanteren) is dat je dat extra main-script kan vermijden: je kan jezelfde main-script met uitzonderingen en goedgekeurde metingen blijven gebruiken, en als er een 'kritisch aantal bomen' (bv. 5 in bovenstaande suggestie) bijgekomen is bij een bepaalde domein-BMS-combinatie, krijg je vanzelf terug die nieuwe curve in het validatierapport (als deze nog steeds afwijkend is). Zolang je dit volledig zelf blijft opvolgen, is dat mss overbodig, maar als dit (zoals je aangaf) doorgegeven wordt aan anderen, lijkt het me handiger dat ze altijd een en hetzelfde script kunnen runnen en zeker niet vergeten om die curves indien nodig opnieuw controleren. (En ook: als anderen het package onafhankelijk van uw script gaan gebruiken, is het goed om in de aangeboden opties zeker te vermijden dat curves niet meer gevalideerd gaan worden omdat ze eenmalig als goedgekeurd aangeduid zijn.) Enfin, het is dus bedoeld als beveiliging tegen onvoorzichtig gebruik van deze optie, en het maakt je extra main-script inderdaad overbodig.

Dus, ik stel voor dat ik die extra optie voor de validatiefuncties inwerk? (Puntje (1) hierboven is geen volledige oplossing voor je probleem, maar ik heb dit informatief even toegevoegd zodat je waar gewenst je validatie stap voor stap kan uitvoeren (bv. per BMS) zonder al te veel impact op je gehele workflow.)

leymanan commented 3 years ago

OK, is ben akkoord met toevoeging van extra controle obv aantal bomen (+ 5). Inderdaad beter!

(puntje (1) is inderdaad goede tip)

ElsLommelen commented 3 years ago

Als ik een variabele nBomenTerugTonen toevoeg om het aantal bomen toe te voegen vanaf wanneer de curve terug getoond moet worden, op welke variabele baseer ik deze dan best, nBomen, nBomenInterval of nBomenOmtrek05?

Enfin, ik zie bij alle opties voor- en nadelen, dus laat gerust weten wat u het beste/gemakkelijkste/meest logische lijkt.

leymanan commented 3 years ago

misschien beste nBomenInterval. Reden:

Op ma 7 dec. 2020 om 15:06 schreef ElsLommelen notifications@github.com:

Als ik een variabele nBomenTerugTonen toevoeg om het aantal bomen toe te voegen vanaf wanneer de curve terug getoond moet worden, op welke variabele baseer ik deze dan best, nBomen, nBomenInterval of nBomenOmtrek05?

  • nBomen klinkt het gemakkelijkst omdat een gebruiker dit gemakkelijk uit z'n databank kan afleiden (en het staat in je tabel), maar nadeel is dat het opmeten van extra 'te dikke' bomen geen enkele invloed heeft op die grafiekvorm, dus bij extra bomen ga je niet noodzakelijk een verandering zien (al ga je uiteraard meestal wel bomen binnen het relevante interval opmeten)
  • nBomenInterval en nBomenOmtrek05 geven wel beter aan als er extra relevante gegevens toegevoegd zijn, maar bij het basismodel en lokaal model verandert het model al zodra nBomenInterval toeneemt, en bij het lokaal model pas als nBomenOmtrek05 toeneemt... Vermits er 3 validatiefuncties zijn, is het wel mogelijk om twee functies te baseren op nBomenInterval en de derde op nBomenOmtrek05, maar vanuit gebruikersperspectie lijkt me dat onwenselijk.

Enfin, ik zie bij alle opties voor- en nadelen, dus laat gerust weten wat u het beste/gemakkelijkste/meest logische lijkt.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/inbo/dhcurve/issues/36#issuecomment-739938989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKXN5AK3WUPTXGUGSM72OTSTTON7ANCNFSM4SBN6VPA .

--

Anja Leyman

Expert Cel Beheerplanning en Monitoring

Ik werk tijdelijk niet op woensdag- en vrijdagnamiddag.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Vlaamse overheid

AGENTSCHAP NATUUR & BOS

Standplaats Instituut voor Natuur- en Bosonderzoek (INBO) Gaverstraat 4, 9500 Geraardsbergen T: 054 436 182 M: 0495 14 90 60 E-mail: anja.leyman@vlaanderen.be anja.leyman@lne.vlaanderen.be

www.natuurenbos.be http://www.natuurenbos.be/

De inhoud van dit bericht en eventuele bijlage(n) verbinden het Agentschap voor Natuur en Bos niet, zolang niet bevestigd door een geldig ondertekend document

ElsLommelen commented 3 years ago

Voila, toegevoegd. Voor validatie.afgeleid() zijn er geen afwijkende curves, dus hier heeft die parameter geen zin (bedacht ik na het toevoegen van de vorige post hierboven).

(Kan je ook checken of het in de documentatie duidelijk omschreven is?)

ElsLommelen commented 3 years ago

Ik heb ook de grafieken van het informatief rapport aangepast: ik heb de horizontale strepen vervangen door ruiten, en de punten van de metingen zwart gemaakt. Ik heb wel alpha voorlopig behouden, want met zwart op zwart zouden de ruiten onzichtbaar zijn. Check je even of dit beter is? En moest je graag graag wat testen om een goede kleurbalans te vinden: je kan de grafieklayout aanpassen in dhcurve.Rmd.

leymanan commented 3 years ago

Grafieken va ninformatief rapport zijn zo inderdaad beter. Bedankt! Misschien speel ik later nog eens met kleuren, maar is voorlopig meer dan goed genoeg. Zeker als informatief rapport, curvevorm checken doe ik dan in de validatierapporten.

leymanan commented 3 years ago

Net functie validate.basis uitgeprobeerd en ik krijg foutmelding: Error: GoedgekeurdeAfwijkendeCurves$nBomenTerugTonen is not a count (a single positive integer)

heeft te maken met code lijn 122: assert_that(is.count(GoedgekeurdeAfwijkendeCurves$nBomenTerugTonen))

Ik heb echter het veld "nBomenTerugTonen" aangemaakt als nBomenInterval + 5 Het is alvast een numeriek veld: 'data.frame': 9 obs. of 3 variables: $ DOMEIN_ID : chr "DomLIM09173" "DomLIM09471" "DomLIM09504" "DomVBR09235" ... $ BMS : chr "Cors. Den" "Cors. Den" "Cors. Den" "Populier" ... $ nBomenTerugTonen: num 163 2316 179 246 94 ...

Ik heb al geprobeerd om het veld nBomenTerugTonen "as.integer" op te slaan, maar geeft zelfde foutmelding

ElsLommelen commented 3 years ago

Normaal zou de foutmelding hiermee weg moeten zijn, kan je even testen?

Ik raad uiteraard wel aan dat je die nBomenInterval + 5 als waarde in je databank opslaat, zodat die niet mee verandert als er nieuwe bomen opgemeten zijn. ;-)

ElsLommelen commented 3 years ago

Ik heb ook nog even een wit randje toegevoegd rond de ruiten in het informatief rapport. Dit is amper zichtbaar in de meeste curves, maar in die enkele curves waar er veel punten van metingen onder de ruit staat (bv. Zoniën), is hierdoor de ruit wel zichtbaar op de donkere achtergrond van punten. Verder laat ik het aan u over om evt. nog aanpassingen te maken in die layout (of aan te geven als er nog aanpassingen moeten komen).

Ik neem aan dat dit issue hiermee afgerond kan worden?

leymanan commented 3 years ago

In de documentatie van dhcurvesrapport() staat dat ook het Vlaamse model weergegeven wordt. Dat is bij mij niet het geval? En als ik naar de scripts ga kijken (dhcurve.Rmd) zie ik dat ook niet aangegeven. Dat wit lijntje zie ik dan weer wel (zowel in Rmd-script als op de grafiek)

leymanan commented 3 years ago

foutmelding: dat is opgelost! (ik heb wel niet gecontroleerd of de curve verschijnt als nBomenInterval groter wordt dan nBomenTerugTonen, maar dat ik veronderstel dat dat geen probleem zal zijn.) Bedankt!

ElsLommelen commented 3 years ago

Oeps, foutje in de documentatie (zoals eerder aangehaald, is het Vlaamse model toevoegen niet mogelijk op basis van de uitvoer van outputIVANHO()). En ik merkte bij het updaten hiervan ook dat de RMSE-waarde niet weergegeven werd in het rapport... Bij deze is dat dus ook opgelost.

leymanan commented 3 years ago

Bedankt!