html-rapport van alle modellen? #36
Comments
|
Ok, mss wel eerst even verder brainstormen wat je precies wil.
|
|
brainstorm goed idee!
|
|
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.) |
|
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:
- afwijkende metingen checken tot ze allemaal goed- of afgekeurd zijn
- BMS baseren op naamgeving/code IVANHO (verwerkt in main-script; functies
blijven zelfde)
- afwijkende curves checken en ev. overstappen voor bepaalde domeinen van
Vlaams naar afgeleid model, mbv dataframe "uitzonderingen" waar min_basis
opgetrokken wordt
- afgeleid model nogmaals laten lopen
- idealiter een extra rapport waarin de afwijkende curves van het
basismodel nu als afgeleid model te zien zijn, alsook ev. andere
problematische curves. OF nog beter: waar zowel basismodel als afgeleid
model in opgenomen zijn, voor de twijfelgevallen?? (als mogelijk)
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.
|
|
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.) |
|
Ik heb een functie |
|
functie heeft gelopen, maar rapport is leeg, net zoals alle andere html-rapporten ... |
|
O ja: ik had geantwoord op je comment met een mail, en daar een bijlage aan toegevoegd. 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. |
|
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 Het rapport hoeft voor mij wel niet interactief te zijn. De afwijkende metingen zijn immers al goed- of afgekeurd op dat moment. |
|
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. Dus layout toch liever wat meer richting het validatierapport ... Maw liever dat het informatieve rapport meer op een validatierapport lijkt, dan dat mijn rapport om te controleren op een informatief rapport lijkt ;-) |
|
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 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.) |
…validatie.afgeleid() en validatie.lokaal() (issue #36)
|
Ik heb een extra parameter Behoud ik ook het informatieve rapport? Moeten hier evt. nog aanpassingen aan gebeuren? |
|
Ja, misschien inderdaad beter dat er een meer uitgebreid "validatierapport" mogelijk is, waarbij ik niet alleen En daarnaast kan het informatieve rapport zoals het nu voorligt ook behouden blijven, alhoewel ik die balkjes verwarrend 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 ... (?) |
|
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? |
|
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! 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 |
|
Al heel snel een korte verantwoording voor mijn vraag. |
|
"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? Of kan ik de hulpfunctie "validatierapport" zelf aanroepen, en dan zelf de modellen opgeven (SlechtsteModellen) waarvan een grafiek moet gemaakt worden? |
|
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. |
|
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. |
|
" (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. Oeps: ?? ik zie niet hoe ik dat kan doen, hoe haal ik uit "Basismodel" specifieke curves?
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. |
|
Ik zou zeggen: probeer eens of dat praktisch is. |
|
op dit moment staat het aantal bomen al opgenomen in de tabel met curves (in hulpdatabank.accdb). 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. |
|
Misschien toch nog eens resumeren (voor mezelf ook). Huidige werkwijze Naar analogie met AfwijkendeMetingen, pas ik mbv een query in R de status van AfwijkendeCurves aan van "Niet gecontroleerd" naar "Te controleren". 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. In de validatiestap van de afgeleide modellen, maak ik nu gebruik van de uitgebreide validatie-functie, met de dataframe "ExtraCurvesAfgeleid" als extra parameter:
Wat ontbreekt er volgens mij 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)." Een andere optie is om een extra main-script te schrijven om te gebruiken wanneer er nieuwe metingen bijkomen. Uw suggesties Dat leek me een goed idee: na fitten van de modellen, enkel deze die nog niet goedgekeurd zijn "valideren" met de validatiestap. MAAR ik zie niet hoe ik dat kan doen, hoe haal ik uit "Basismodel" specifieke curves? 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. |
|
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... (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.) |
|
OK, is ben akkoord met toevoeging van extra controle obv aantal bomen (+ 5). Inderdaad beter! (puntje (1) is inderdaad goede tip) |
|
Als ik een variabele
Enfin, ik zie bij alle opties voor- en nadelen, dus laat gerust weten wat u het beste/gemakkelijkste/meest logische lijkt. |
|
misschien beste nBomenInterval.
Reden:
- heeft het gewenste effect op 2 van de 3 modellen
- we zullen dan misschien teveel lokale modellen herberekenen, maar alvast
niet te weinig
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
<#36 (comment)>, 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
|
…() en validatie.lokaal() (issue #36)
|
Voila, toegevoegd. Voor (Kan je ook checken of het in de documentatie duidelijk omschreven is?) |
|
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 |
|
Grafieken va ninformatief rapport zijn zo inderdaad beter. Bedankt! |
|
Net functie validate.basis uitgeprobeerd en ik krijg foutmelding: heeft te maken met code lijn 122: assert_that(is.count(GoedgekeurdeAfwijkendeCurves$nBomenTerugTonen)) Ik heb echter het veld "nBomenTerugTonen" aangemaakt als nBomenInterval + 5 Ik heb al geprobeerd om het veld nBomenTerugTonen "as.integer" op te slaan, maar geeft zelfde foutmelding |
|
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. ;-) |
|
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? |
|
In de documentatie van dhcurvesrapport() staat dat ook het Vlaamse model weergegeven wordt. Dat is bij mij niet het geval? |
|
foutmelding: dat is opgelost! |
|
Oeps, foutje in de documentatie (zoals eerder aangehaald, is het Vlaamse model toevoegen niet mogelijk op basis van de uitvoer van |
|
Bedankt! |
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)
The text was updated successfully, but these errors were encountered: