Minor changes

[ElsLommelen]

PR aangemaakt om te testen of codecov het verschil in coverage detecteert. Deze bevat voorlopig een aantal kleine aanpassingen, maar is nog niet afgewerkt.

[ElsLommelen]

@leymanan @ThierryO Ik ben bezig met dit voorstel in te werken, dus voor afgeleide curves wordt er nu alvast geen rekening meer gehouden met een bruikbaar interval en worden dus alle metingen van bomen met een minimale omtrek van 0.5 m meegenomen om het model te bouwen. Maar bij het inwerken kom ik nog uit bij enkele vragen:

• ik merk dat voor het afleiden van het afgeleide model wel rekening gehouden wordt met het bruikbare interval van het basismodel (Vlaams model) waarvan de curve afgeleid is, ik neem aan dat dit best zo blijft? In dit geval kan ik voor het afgeleide model de meetresultaten van punten buiten dit interval ook niet gebruiken (omdat ik geen rmse kan berekenen). Dus ik neem aan dat ik hier best bij de initiatie-stap al rekening mee houd en deze bomen verwijder? (Voor alle duidelijkheid: het gaat over bomen die in een klein domein voorkomen en dikker zijn dan bomen die voor die boomsoort in grote domeinen opgemeten zijn; bij random gegenereerde gegevens is er af en toe een domein waar 1 of 2 van die bomen tussen zitten op 48 bomen, op 20 bomen meestal geen, en in de praktijk gaat dit waarschijnlijk nog veel minder voorkomen, dus de kans dat je niet aan 10 bomen geraakt omwille van deze regel, lijkt me nihil.)
• ik heb het aantal bomen > 0.5 m in variabele nBomenTotOmtrek05 opgeslagen omdat nBomenOmtrek05 al gebruikt was voor het aantal bomen > 0.5 m binnen het bruikbaar interval (= selectiecriterium voor basismodel en lokaal model), maar mss ga ik die naamgeving beter aanpassen? (bv. nBomenOmtrek05 voor de nieuwe indicator en nBomenIntervalOmtrek05 voor de oorspronkelijke nBomenOmtrek05)
• voorlopig wordt deze nieuwe variabele behalve aan functie initiatie() (toevallig) ook toegevoegd als uitvoer van functies hoogteschatting.xxx() en fit.xxx(), maar ik heb ze nog niet expliciet toegevoegd aan de resultaten en validatierapporten. Is het wenselijk om dit ook te doen? (= vooral vraag voor @leymanan: laat zeker weten wat nuttig is voor u! Ik heb het gevoel dat het wel veel verschillende cijfers worden, dus mss is het ook zinvol om in de validatierapporten niet alle cijfers te vermelden voor alle modellen?)

(@ThierryO Ik heb ook alles weggewerkt behalve die ene dubieuze error... Evt. morgen eens samen te bekijken?)

[ElsLommelen]

Ok, hier even een praktisch voorstel en/of verdere vragen/bedenkingen n.a.v. onze afspraken:

• bij de initiatiestap neem ik in de output ook voor het basismodel alle waarnemingen mee buiten het bruikbaar interval, maar ik vlag ze zodat ze herkenbaar zijn en gemakkelijk verwijderd kunnen worden om bv. het model te fitten. En ik zal hier ook metingen van afgeleide modellen verwijderen die buiten het Vlaamse model zullen vallen (eerste punt van vorige commentaar).
• voor de volgende stap zie ik 2 opties:
  • ik zou deze extra gegevens bij fit.basis() in de output kunnen toevoegen, zodat de variabele Basismodel de volledige dataset bevat, en net zoals Afgeleidmodel een list is van gegevens en model. Voordeel is dan dat de workflow behouden kan worden en dat de extra gegevens in alle stappen gebruikt kunnen worden
  • ik doe dit niet, en dan moet Data.basis telkens als argument toegevoegd worden waar de hoogteschatting ook moet gebeuren op de gegevens buiten het bruikbaar interval
• en daarna is de vraag: nemen we die extra hoogteschatting en de controle ervan ook meteen mee in de validatie (huidige validatie.basis() e.a.), of doen we dit in een aparte validatiestap?
• en ook: wat als we beslissen dat voor een bepaalde curve enkel het bruikbare interval gebruikt mag worden omdat die uitbreiding onbetrouwbaar lijkt? Gaan we dit dan op een of andere manier in Uitzonderingen opnemen dat in de initiatiestap meegegeven wordt, of laten we de gebruiker de dataset na de initiatiestap zelf aanpassen (= wissen van de gevlagde gegevens die buiten het bruikbaar interval vallen)?

En dan mss nog even zeer duidelijk afspreken bij welke modellen die extra gegevens toegevoegd moeten worden:

• ik heb begrepen dat dit sowieso moet gebeuren bij het basismodel, dat input geeft voor het Vlaams model.
• het afgeleid model werkt al niet meer met een bruikbaar interval, dus daar kan het niet
• voor het lokaal model was het niet nodig, dacht ik? Maar kijk dit gerust na, het is waarschijnlijk een kleintje om het principe van het basismodel hier ook toe te passen (en vermits basismodel en lokaal model vaak dezelfde functies gebruiken, kan het mss zelfs gemakkelijker zijn om het voor beiden toe te passen).

En hoe we het statistisch precies gaan aanpakken:

• (ter herhaling) sowieso berekenen we voor de punten binnen het interval de RMSE door cross-validatie op basis van 6 subsets
• een eerste voorstel van gisteren was om ook voor die extra gegevens (buiten bruikbaar interval) een RMSE te berekenen, zodat het model aan de praktijk gecheckt kan worden. Geen idee hoe we dit dan best beoordelen, maar mss is een van volgende voorstellen (zonder berekening van de RMSE van die punten) een optie?
  • checken of er in deze extra omtrekklassen niet buitenproportioneel veel afwijkende metingen zijn (= metingen met afwijking groter dan 2.5 * RMSE, die we dan nemen van het gefitte model)
  • checken of er voor de extra omtrekklassen geen groot onevenwicht is tussen het aantal metingen boven en onder de curve
  • vergelijking maken tussen gemiddelde + stdev van metingen en schatting + RMSE van curve
• een andere suggestie was om te werken via de curvevorm:
  • piste 1: rekening houden met richtingscoëfficiënt op het einde van de curve (mag niet te steil zijn) en ligging van een evt. maximum eerder in de curve (is sowieso berekend, en validatierapport geeft sowieso al aan als dit voorkomt)
  • piste 2: hoogteschattingen geven voor 2 omtrekklassen (kan feitelijk gewoon uit de resultaten voor IVANHO gehaald worden), maar hier is eigenlijk nog niet goed nagedacht over hoe dit best gevalideerd zou worden: uiteindelijk gaat er bij een minder goede curve toch bepaald moeten worden vanaf welk aantal metingen deze terug gevalideerd moet worden...

Euh, misschien hiervoor toch nog eens samenzitten (live of online)?

(In tussentijd ga ik mogelijk nog wat experimenteren met de nieuwe spellingscheck die Thierry aan 't ontwikkelen is: omwille van de combinatie van Nederlands en een beetje Engels is dhcurve een ideale testcase, en het kan (de documentatie van) het package alleen maar verbeteren.)

[leymanan]

• bij de initiatiestap neem ik in de output ook voor het basismodel alle waarnemingen mee buiten het bruikbaar interval, maar ik vlag ze zodat ze herkenbaar zijn en gemakkelijk verwijderd kunnen worden om bv. het model te fitten. En ik zal hier ook metingen van afgeleide modellen verwijderen die buiten het Vlaamse model zullen vallen (eerste punt van vorige commentaar).

OK!

• ik heb het aantal bomen > 0.5 m in variabele nBomenTotOmtrek05 opgeslagen omdat nBomenOmtrek05 al gebruikt was voor het aantal bomen > 0.5 m binnen het bruikbaar interval (= selectiecriterium voor basismodel en lokaal model), maar mss ga ik die naamgeving beter aanpassen? (bv. nBomenOmtrek05 voor de nieuwe indicator en nBomenIntervalOmtrek05 voor de oorspronkelijke nBomenOmtrek05)

OK! Zou inderdaad beter zijn om naam aan te passen (nBomenIntervalOmtrek05 voor de oorspronkelijke nBomenOmtrek05)

• voorlopig wordt deze nieuwe variabele behalve aan functie initiatie() (toevallig) ook toegevoegd als uitvoer van functies hoogteschatting.xxx() en fit.xxx(), maar ik heb ze nog niet expliciet toegevoegd aan de resultaten en validatierapporten. Is het wenselijk om dit ook te doen? (= vooral vraag voor @leymanan: laat zeker weten wat nuttig is voor u! Ik heb het gevoel dat het wel veel verschillende cijfers worden, dus mss is het ook zinvol om in de validatierapporten niet alle cijfers te vermelden voor alle modellen?)

Had het al gezegd, maar hier nog eens: voeg maar toe aan resultaten. Makkelijker weggedaan, dan achteraf moeten koppelen ;-)

• ik merk dat voor het afleiden van het afgeleide model wel rekening gehouden wordt met het bruikbare interval van het basismodel (Vlaams model) waarvan de curve afgeleid is, ik neem aan dat dit best zo blijft? In dit geval kan ik voor het afgeleide model de meetresultaten van punten buiten dit interval ook niet gebruiken (omdat ik geen rmse kan berekenen). Dus ik neem aan dat ik hier best bij de initiatie-stap al rekening mee houd en deze bomen verwijder? (Voor alle duidelijkheid: het gaat over bomen die in een klein domein voorkomen en dikker zijn dan bomen die voor die boomsoort in grote domeinen opgemeten zijn; bij random gegenereerde gegevens is er af en toe een domein waar 1 of 2 van die bomen tussen zitten op 48 bomen, op 20 bomen meestal geen, en in de praktijk gaat dit waarschijnlijk nog veel minder voorkomen, dus de kans dat je niet aan 10 bomen geraakt omwille van deze regel, lijkt me nihil.)

lijkt me OK

voor de volgende stap zie ik 2 opties:

• ik zou deze extra gegevens bij fit.basis() in de output kunnen toevoegen, zodat de variabele Basismodel de volledige dataset bevat, en net zoals Afgeleidmodel een list is van gegevens en model. Voordeel is dan dat de workflow behouden kan worden en dat de extra gegevens in alle stappen gebruikt kunnen worden
• ik doe dit niet, en dan moet Data.basis telkens als argument toegevoegd worden waar de hoogteschatting ook moet gebeuren op de gegevens buiten het bruikbaar interval

Optie 1 lijkt me meest logische.

• en daarna is de vraag: nemen we die extra hoogteschatting en de controle ervan ook meteen mee in de validatie (huidige validatie.basis() e.a.), of doen we dit in een aparte validatiestap?

Voor mij zou het op dit moment makkelijker zijn om dit in een aparte validatiestap te doen. Ik heb de standaard validatie immers al gedaan (bepaalde curves zijn dus al "goedgekeurd"), en dat wil ik niet opnieuw doen. Maar dan kan ik die curves toch nog meenemen bij die extra validatiestap.

• en ook: wat als we beslissen dat voor een bepaalde curve enkel het bruikbare interval gebruikt mag worden omdat die uitbreiding onbetrouwbaar lijkt? Gaan we dit dan op een of andere manier in Uitzonderingen opnemen dat in de initiatiestap meegegeven wordt, of laten we de gebruiker de dataset na de initiatiestap zelf aanpassen (= wissen van de gevlagde gegevens die buiten het bruikbaar interval vallen)?

Lijkt me makkelijker om dat mee te nemen in "Uitzonderingen", want dan is het gedocumenteerd (ik neem dat mee in mijn hulpdatabank waarin alle curves opgesomd staan met oa min_basisen min_afgeleid en status)

En dan mss nog even zeer duidelijk afspreken bij welke modellen die extra gegevens toegevoegd moeten worden:

• ik heb begrepen dat dit sowieso moet gebeuren bij het basismodel, dat input geeft voor het Vlaams model.
• het afgeleid model werkt al niet meer met een bruikbaar interval, dus daar kan het niet
• voor het lokaal model was het niet nodig, dacht ik? Maar kijk dit gerust na, het is waarschijnlijk een kleintje om het principe van het basismodel hier ook toe te passen (en vermits basismodel en lokaal model vaak dezelfde functies gebruiken, kan het mss zelfs gemakkelijker zijn om het voor beiden toe te passen).

Bedoel je met extra gegevens de hoogtemetingen van bomen met omtrek > 2.3m? Bij afgeleid model zitten die daar vanaf nu standaard in toch? Als het Vlaams model ze tenminste bevat. Lokaal model: ik had inderdaad gezegd dat dat niet nodig was, omdat dat minder belangrijke boomsoorten zijn naar houtverkoop toe. Maar als dat niet veel extra moeite is, zou het fijn zijn om die op zelfde manier te behandelen als het basismodel.

En hoe we het statistisch precies gaan aanpakken:

• (ter herhaling) sowieso berekenen we voor de punten binnen het interval de RMSE door cross-validatie op basis van 6 subsets

OK!

een eerste voorstel van gisteren was om ook voor die extra gegevens (buiten bruikbaar interval) een RMSE te berekenen, zodat het model aan de praktijk gecheckt kan worden. Geen idee hoe we dit dan best beoordelen, maar mss is een van volgende voorstellen (zonder berekening van de RMSE van die punten) een optie?

• checken of er in deze extra omtrekklassen niet buitenproportioneel veel afwijkende metingen zijn (= metingen met afwijking groter dan 2.5 * RMSE, die we dan nemen van het gefitte model)
• checken of er voor de extra omtrekklassen geen groot onevenwicht is tussen het aantal metingen boven en onder de curve
• vergelijking maken tussen gemiddelde + stdev van metingen en schatting + RMSE van curve

voor mij hoeft dat niet noodzakelijk een RMSE te zijn, uw andere voorstellen zijn alledrie OK voor mij. Intuïtief heb ik lichte voorkeur voor optie 1 of 3, maar als Thierry of jij denken dat optie 2 meer aangewezen is, is dat ook OK voor mij!

een andere suggestie was om te werken via de curvevorm:

• piste 1: rekening houden met richtingscoëfficiënt op het einde van de curve (mag niet te steil zijn) en ligging van een evt. maximum eerder in de curve (is sowieso berekend, en validatierapport geeft sowieso al aan als dit voorkomt)
• piste 2: hoogteschattingen geven voor 2 omtrekklassen (kan feitelijk gewoon uit de resultaten voor IVANHO gehaald worden), maar hier is eigenlijk nog niet goed nagedacht over hoe dit best gevalideerd zou worden: uiteindelijk gaat er bij een minder goede curve toch bepaald moeten worden vanaf welk aantal metingen deze terug gevalideerd moet worden...

Piste 2 is inderdaad niet uitgeklaard, ik weet het ook niet goed. Is het een optie om piste 1 te combineren met het checken van de individuele metingen (obv proxy voor RMSE, zoals in vorig puntje voorgesteld)?

Euh, misschien hiervoor toch nog eens samenzitten (live of online)?

OK, liefst online, want ik geraak volgende week niet in Brussel. Mag maandag of .....

[ElsLommelen]

• en daarna is de vraag: nemen we die extra hoogteschatting en de controle ervan ook meteen mee in de validatie (huidige validatie.basis() e.a.), of doen we dit in een aparte validatiestap?

Voor mij zou het op dit moment makkelijker zijn om dit in een aparte validatiestap te doen. Ik heb de standaard validatie immers al gedaan (bepaalde curves zijn dus al "goedgekeurd"), en dat wil ik niet opnieuw doen. Maar dan kan ik die curves toch nog meenemen bij die extra validatiestap.

Ah, oei, ik heb hier niet goed op m'n woorden gelet. Ik bedoelde hier of ik naast validatie.basis() e.a. nog een aparte functie moest maken voor die nieuwe validatie, maar nu zie ik dat het vignet binnen validatie.xxx() spreekt over 2 validatiestappen, dus mss bedoel je om hier gewoon een 3de stap aan toe te voegen? In elk geval zouden curves op basis van je input van metingen met vlag 'goedgekeurd' en de dataset 'uitzonderingen' niet meer mogen verschijnen, tenzij ze slecht scoren als het over die extra omtrekklassen gaat. Maar nu ik erover nadenk: die tabel uitzonderingen laat wel toe om te zorgen dat slechte curves niet meer getoond worden tenzij er meer waarnemingen zijn, maar de goedgekeurde curves blijven wel in het rapport staan. Dus ik kan wel extra foutmeldingen toevoegen voor problemen met die extra omtrekklassen, en mss is het ook wel handig om te zorgen dat curves in het validatierapport gesorteerd kunnen worden op een bepaalde foutmelding, maar echt vermijden dat die andere curves terug getoond worden, kan niet, vrees ik.

Anderzijds ga je in de toekomst, als er bv. nieuwe curves bij komen, waarschijnlijk wel liever hebben dat die validatiestappen samen uitgevoerd kunnen worden en je de curves dus maar eenmaal moet bekijken? Dus ik vrees dat het een beetje de bluts met de buil is: ofwel gaan we voor een methode die in de toekomst gemakkelijk werkt, en dan moet je nu in het validatierapport enkel curves bekijken die een foutmelding hebben die gerelateerd is aan die extra omtrekklassen, ofwel gaan we voor een methode die nu goed werkt maar waarbij je later de curves tweemaal moet bekijken. Alternatief is dat ik kijk of we niet eenmaal een rapport kunnen aanmaken waarin die goedgekeurde curves niet verschijnen, maar mss is een sortering per foutmelding voldoende en is deze functionaliteit ook nog handig voor de toekomst?

Mss nog even laten bezinken, maar wat denk jij?

En dan mss nog even zeer duidelijk afspreken bij welke modellen die extra gegevens toegevoegd moeten worden:

• ik heb begrepen dat dit sowieso moet gebeuren bij het basismodel, dat input geeft voor het Vlaams model.
• het afgeleid model werkt al niet meer met een bruikbaar interval, dus daar kan het niet
• voor het lokaal model was het niet nodig, dacht ik? Maar kijk dit gerust na, het is waarschijnlijk een kleintje om het principe van het basismodel hier ook toe te passen (en vermits basismodel en lokaal model vaak dezelfde functies gebruiken, kan het mss zelfs gemakkelijker zijn om het voor beiden toe te passen).

Bedoel je met extra gegevens de hoogtemetingen van bomen met omtrek > 2.3m? Bij afgeleid model zitten die daar vanaf nu standaard in toch? Als het Vlaams model ze tenminste bevat. Lokaal model: ik had inderdaad gezegd dat dat niet nodig was, omdat dat minder belangrijke boomsoorten zijn naar houtverkoop toe. Maar als dat niet veel extra moeite is, zou het fijn zijn om die op zelfde manier te behandelen als het basismodel.

Nee, ik dacht begrepen te hebben dat het ging over de metingen die wegvallen bij het hanteren van het bruikbaar interval, dus dit zijn sowieso metingen < 2.4 m want die worden bij voorbaat al geschrapt (omdat sowieso opgemeten bij verkoop?). Het gaat dus over de omtrekklassen aan het begin en einde van de curve die wegvallen omdat er niet veel metingen van zijn en het risico bestaat dat ze de curve in een verkeerde richting trekken. Op die plaats zouden we dan zien of die curve nog wel ok is. Maar mss heb je minder interesse in het minimum (als het onder 0.5 m ligt)? We hebben bij de strategie eigenlijk ook enkel gesproken over de verlenging naar boven toe.

[ElsLommelen]

@ThierryO zou jij je gedacht ook even kunnen geven hierover?

[leymanan]

Anderzijds ga je in de toekomst, als er bv. nieuwe curves bij komen, waarschijnlijk wel liever hebben dat die validatiestappen samen uitgevoerd kunnen worden en je de curves dus maar eenmaal moet bekijken?

Ja, misschien wel. Als we ergens kunnen sorteren of filteren op foutmelding is dat OK. Maar ik vrees dat er nu wel soms 2 redenen tot controle zullen zijn, daar waar het er tot nu toe steeds maar één kon zijn: holle of bolle curve ... Dus dan moet duidelijk zijn hoe daarmee om te gaan, dat de ene reden de andere niet overschrijft. Zodat ik niet denk dat ik die al gecontroleerd heb, maar dat het eigenlijk nu over een andere fout gaat.

Nee, ik dacht begrepen te hebben dat het ging over de metingen die wegvallen bij het hanteren van het bruikbaar interval, dus dit zijn sowieso metingen < 2.4 m want die worden bij voorbaat al geschrapt (omdat sowieso opgemeten bij verkoop?). Het gaat dus over de omtrekklassen aan het begin en einde van de curve die wegvallen omdat er niet veel metingen van zijn en het risico bestaat dat ze de curve in een verkeerde richting trekken. Op die plaats zouden we dan zien of die curve nog wel ok is. Maar mss heb je minder interesse in het minimum (als het onder 0.5 m ligt)? We hebben bij de strategie eigenlijk ook enkel gesproken over de verlenging naar boven toe.

OK, dus de metingen buiten Q5k-Q95k! Logisch. Wat betreft het minimum (onder de 0.5m): voor mij is het OK om de bestaande curve in die richting te extrapoleren , maar met een minimale hoogte van 2.5m (dus als de hoogteschatting < 2.5 m, de hoogte gelijkstellen aan 2.5 m). Dat had ik ook besproken met Martine en Geert B. en die vonden dat OK. Dat gaat ook over kleine volumes.

Wat betreft verlenging naar boven: die zou toch best tot 3 m omtrek gaan (en niet tot 2.4 m). Blijkbaar wordt inderdaad wel soms opgemeten vanaf 240 cm, maar niet altijd ... Vooral van belang bij eik en beuk (en ev. populier; minder bij naaldhout).

[ThierryO]

• en daarna is de vraag: nemen we die extra hoogteschatting en de controle ervan ook meteen mee in de validatie (huidige validatie.basis() e.a.), of doen we dit in een aparte validatiestap?

Voor mij zou het op dit moment makkelijker zijn om dit in een aparte validatiestap te doen. Ik heb de standaard validatie immers al gedaan (bepaalde curves zijn dus al "goedgekeurd"), en dat wil ik niet opnieuw doen. Maar dan kan ik die curves toch nog meenemen bij die extra validatiestap.

Ik zou dat ook in een aparte stap doen. Op die manier gebruikt je bij de validatie van de curve enkel de data waarop de curve gebaseerd is.

En hoe we het statistisch precies gaan aanpakken:

een eerste voorstel van gisteren was om ook voor die extra gegevens (buiten bruikbaar interval) een RMSE te berekenen, zodat het model aan de praktijk gecheckt kan worden. Geen idee hoe we dit dan best beoordelen, maar mss is een van volgende voorstellen (zonder berekening van de RMSE van die punten) een optie?

• checken of er in deze extra omtrekklassen niet buitenproportioneel veel afwijkende metingen zijn (= metingen met afwijking groter dan 2.5 * RMSE, die we dan nemen van het gefitte model)
• checken of er voor de extra omtrekklassen geen groot onevenwicht is tussen het aantal metingen boven en onder de curve
• vergelijking maken tussen gemiddelde + stdev van metingen en schatting + RMSE van curve

voor mij hoeft dat niet noodzakelijk een RMSE te zijn, uw andere voorstellen zijn alledrie OK voor mij. Intuïtief heb ik lichte voorkeur voor optie 1 of 3, maar als Thierry of jij denken dat optie 2 meer aangewezen is, is dat ook OK voor mij!

RMSE is in dit geval geen goede maat. Door het kwadraten van de fout verlies je informatie over de zin van de fout (positief of negatief). Ik zou kijken naar de mediaan en het maximum van de fouten.

een andere suggestie was om te werken via de curvevorm:

• piste 1: rekening houden met richtingscoëfficiënt op het einde van de curve (mag niet te steil zijn) en ligging van een evt. maximum eerder in de curve (is sowieso berekend, en validatierapport geeft sowieso al aan als dit voorkomt)
• piste 2: hoogteschattingen geven voor 2 omtrekklassen (kan feitelijk gewoon uit de resultaten voor IVANHO gehaald worden), maar hier is eigenlijk nog niet goed nagedacht over hoe dit best gevalideerd zou worden: uiteindelijk gaat er bij een minder goede curve toch bepaald moeten worden vanaf welk aantal metingen deze terug gevalideerd moet worden...

Piste 2 is inderdaad niet uitgeklaard, ik weet het ook niet goed. Is het een optie om piste 1 te combineren met het checken van de individuele metingen (obv proxy voor RMSE, zoals in vorig puntje voorgesteld)?

Ook bij een RC zal je moet bepalen waar de grens ligt. Het verschil in hoogte tussen twee diameterklassen lijkt mij eenvoudiger te interpreteren voor de mensen in het veld.

Ik zou eens in de literatuur kijken bij welke diameter de hoogtegroei van een boom stopt / sterk afvlakt. De hoogtegroei is het eerste wat afvlakt, daarna de diametergroei en tenslotte de waardegroei. Mocht de diameter waarbij de hoogtegroei afvlakt constant zijn dan kunnen we die informatie gebruiken om te extrapoleren. Ik verwacht die diameter hoofdzakelijk boomsoort afhankelijk is. Lichtboomsoorten bereiken hun maximale hoogte immers sneller dan bij schaduwboomsoorten.

Euh, misschien hiervoor toch nog eens samenzitten (live of online)?

OK, liefst online, want ik geraak volgende week niet in Brussel. Mag maandag of .....

Online overleg kan vanaf dinsdag.

[ElsLommelen]

Even op een rijtje zetten wat we afgesproken hebben inclusief vragen/onduidelijkheden:

• we gaan het model voor alle boomsoort-domeincombinaties gebruiken tot 2 klassen buiten het bruikbaar interval (aan beide kanten, met min. van 2,5 m hoogte en omtrek van 20 cm), dit betekent de volgende aanpassingen:
  • de validatierapporten tonen de modellen tot 2 klassen verder
  • functie outputIVANHO() geeft ook deze extra omtrekklassen als output
  • dhcurvesrapport() toont ook 2 extra klassen
  • vraag: wat met afgeleide modellen, waar we sinds recent alle metingen meenemen en dus geen bruikbaar interval meer afkappen (omdat hier de modelvorm toch niet mee bepaald wordt)? Wat we hier nog wel kunnen herzien, is de ondergrens van 0,5 m omtrek.
• voor boomsoort-domeincombinaties waar er veel data zijn buiten het bruikbaar interval van het model:
  • komt er een extra functie die toelaat om het model te valideren ter hoogte van de extra gegevens
  • deze berekent het verschil tussen de metingen en de modelschatting, en hiervan mediaan, min en max
  • ze genereert een validatierapport met in totaal 20 grafieken die 'niet afgekeurd' zijn wat betreft het uitbreiden naar de extra omtrekklassen:
    • in 2 onderdelen: een deel met goedgekeurde gegevens en een deel met nog te valideren gegevens
    • goed- of afkeuren kan door een extra veld in Uitzonderingen aan te vullen met TRUE/FALSE (NA is niet gecontroleerd), voorstel voor naam: uitbreiden_model (tenzij je een kortere naam weet?)
    • idee is om te stoppen als er 20 goedgekeurde en geen te valideren gegevens meer zijn
    • grafieken worden gerangschikt naar maximale absolute mediaan (en hiervan worden dus de 20 slechtste weergegeven)
    • de grafieken zelf tonen de curve, de meetpunten als jitter (met de bijkomende punten die niet gebruikt zijn om het model te fitten, in een andere kleur?), wat algemene info als BMS, domein,... (zeer gelijkaardig aan validatierapport) en de waarden diff_min, diff_mediaan en diff_max
  • vragen:
    • ik dacht toch dat 1 rapport met 2 delen de laatste versie was? Laat gerust weten als er ook functionaliteit moet zijn om een rapport met 'alle goedgekeurde grafieken' te maken (en dan kan evt. het validatierapport bestaan uit enkel de niet goedgekeurde grafieken van de 20 'slechtste' modellen)
    • wat zijn 'veel' extra gegevens? Ik meen iets gehoord te hebben van 10 gegevens, is dat 10 in totaal, of is er een minimum (gemiddelde) per omtrekklasse, of evt. een minimum voor de laatste omtrekklasse met gegevens?
    • wordt deze uitbreiding enkel toegepast voor hogere omtrekklassen, of ook voor lage omtrekklassen?
    • ik neem aan dat deze functie voor zowel basismodel als lokaal model bruikbaar moet zijn? (Ik heb het nog niet in detail bekeken, maar waarschijnlijk gaat dit geen probleem zijn)
  • in outputIVANHO() worden de extra omtrekklassen toegevoegd voor niet afgekeurde uitbreidingen
  • in dhcurvesrapport() worden de extra omtrekklassen en metingen toegevoegd voor niet afgekeurde uitbreidingen
  • in verband met het laatste deel lijkt het mij het beste om de functie initiatie() zodanig aan te passen dat ze voor domeinen met meer dan 50 gegevens (basismodel en lokaal model) ook de extra meetgegevens bij in de output toevoegt als het over voldoende gegevens gaat. Puur qua workflow is het een kleintje om in die functie even te testen hoeveel extra gegevens er zijn en evt. die domeinen (en gegevens) meteen een vlagje mee te geven. Achteraf opnieuw vertrekken van alle gegevens en uitzoeken welke al gebruikt zijn bij het model, gaat veel complexer zijn.

[leymanan]

• we gaan het model voor alle boomsoort-domeincombinaties gebruiken tot 2 klassen buiten het bruikbaar interval (aan beide kanten, met min. van 2,5 m hoogte en omtrek van 20 cm), dit betekent de volgende aanpassingen:

Klopt voor extrapolatie richting zwaardere bomen. Maar ik dacht dat we afgesproken hadden om sowieso naar 20 cm te extrapoleren, met min. van 2.5m hoogte, ongeacht of daar metingen waren. (omdat dat toch maar over kleine volumes gaat). (en inderdaad minimum op 2.5 m instellen). Richting zwaardere bomen inderdaad + 2 omtrekklasses.

• vraag: wat met afgeleide modellen, waar we sinds recent alle metingen meenemen en dus geen bruikbaar interval meer afkappen (omdat hier de modelvorm toch niet mee bepaald wordt)? Wat we hier nog wel kunnen herzien, is de ondergrens van 0,5 m omtrek.

Ja, dat zou goed zijn; extrapolatie naar 20 cm (zelfs als die omtrekken niet opgemeten zijn), met een minimum van 2.5 m?

voor boomsoort-domeincombinaties waar er veel data zijn buiten het bruikbaar interval van het model:

• komt er een extra functie die toelaat om het model te valideren ter hoogte van de extra gegevens
• deze berekent het verschil tussen de metingen en de modelschatting, en hiervan mediaan, min en max

• ze genereert een validatierapport met in totaal 20 grafieken die 'niet afgekeurd' zijn wat betreft het uitbreiden naar de extra omtrekklassen:

  • in 2 onderdelen: een deel met goedgekeurde gegevens en een deel met nog te valideren gegevens
  • goed- of afkeuren kan door een extra veld in Uitzonderingen aan te vullen met TRUE/FALSE (NA is niet gecontroleerd), voorstel voor naam: uitbreiden_model (tenzij je een kortere naam weet?)

naam is OK!

vragen:

• ik dacht toch dat 1 rapport met 2 delen de laatste versie was? Laat gerust weten als er ook functionaliteit moet zijn om een rapport met 'alle goedgekeurde grafieken' te maken (en dan kan evt. het validatierapport bestaan uit enkel de niet goedgekeurde grafieken van de 20 'slechtste' modellen)

voor mij lijkt die laatste optie misschien het makkelijkste: 2 rapporten: één met alle goedgekeurde grafieken en daarnaast het validatierapport met enkel de niet goedgekeurde grafieken van de 20 'slechtste' modellen. En dan laat ik die lopen tot ik 20 goede modellen heb.

• wat zijn 'veel' extra gegevens? Ik meen iets gehoord te hebben van 10 gegevens, is dat 10 in totaal, of is er een minimum (gemiddelde) per omtrekklasse, of evt. een minimum voor de laatste omtrekklasse met gegevens?

Ik dacht 10 metingen in totaal, maar als die sterkt verspreid zijn lijkt me dat ook niet OK. Anderzijds is het enkel om het model te valideren. Dus als dat model slecht is voor die extra metingen, komt dat wel naar boven obv die 10 extra metingen. DUS: 10 metingen in totaal.

• wordt deze uitbreiding enkel toegepast voor hogere omtrekklassen, of ook voor lage omtrekklassen? Enkel voor hogere omtrekklassen, voor lagere zouden we sowieso tot 20 cm gaan. Niet erg dat model daar wat minder goed is. Daar hoeft geen controle.

• ik neem aan dat deze functie voor zowel basismodel als lokaal model bruikbaar moet zijn? (Ik heb het nog niet in detail bekeken, maar waarschijnlijk gaat dit geen probleem zijn) Als dat kan wel, maar minder prioritair, want dat zijn minder voorkomende boomsoorten. Dus als dat veel extra tijd kost, mag je dat zo laten.

• in verband met het laatste deel lijkt het mij het beste om de functie initiatie() zodanig aan te passen dat ze voor domeinen met meer dan 50 gegevens (basismodel en lokaal model) ook de extra meetgegevens bij in de output toevoegt als het over voldoende gegevens gaat. Puur qua workflow is het een kleintje om in die functie even te testen hoeveel extra gegevens er zijn en evt. die domeinen (en gegevens) meteen een vlagje mee te geven. Achteraf opnieuw vertrekken van alle gegevens en uitzoeken welke al gebruikt zijn bij het model, gaat veel complexer zijn.

OK, lijkt me logisch!

[ElsLommelen]

Maar ik dacht dat we afgesproken hadden om sowieso naar 20 cm te extrapoleren, met min. van 2.5m hoogte, ongeacht of daar metingen waren. (omdat dat toch maar over kleine volumes gaat). (en inderdaad minimum op 2.5 m instellen).

Euh, was dat ook niet tot max. 2 klassen verder dan de metingen? Ik heb tijdens het overleg genoteerd: extrapolatie tot 2 klassen buiten het bruikbaar interval (zowel groter als kleiner, met min. op 2,5 m hoogte en omtrek 20), en hoogte tot 2 klassen boven model, dus ik interpreteer dat als: 2 klassen verder, maar minimum tot 20 cm en 2.5 m. Sowieso is de helling van de curve hier een stuk steiler dan aan de bovenkant van de curve, en ook hier krijg je meestal nog een afbuiging van de curve, dus hier ga je mogelijk wel een heel grote afwijking krijgen als die curve niet echt goed ligt en lage omtrekklassen ontbreken. (De fit gebeurt op basis van de gemeten bomen, en die bepalen door hun (toevallige) onderlinge ligging feitelijk ook of het model verderop al dan niet steil gaat afbuigen, en in welke richting.) Het zijn maar kleintjes, maar vele kleine bomen maken ook een groot volume, en in een uitzonderlijk geval van een domein waar enkel bomen met omtrek groter dan 1 m opgemeten zijn, zou die verlenging tot 20 cm weleens een zeer grote fout kunnen geven (kan o.a. ook deels beïnvloed worden door het domeinmodel): de curve kan theoretisch variëren van bijna horizontaal tot afbuigen naar bijna verticaal of u-vormig eindigen... Het gevolg is een zeer onbetrouwbare inschatting voor kleine bomen, en dat kan weleens grote gevolgen hebben voor een lot met dunning van de kleine bomen uit een bos.

In hoeveel gevallen ga je voor basismodellen of lokale modellen niet tot die 20 cm geraken? Ik vermoed dat dit eerder beperkt is. En anderzijds vrees ik dat voor die modelllen met enkel metingen van dikke bomen (waarbij er mss ook maar metingen voor een beperkt aantal omtrekklassen zijn) het risico op een serieuze afwijking te groot is om ze te ver te gaan verlengen. Vergeet ook niet: op deze extrapolatie wordt geen enkele controle meer uitgevoerd: je hebt je modellen al gecontroleerd en goedgekeurd, dus we gaat hier gewoon die grafiek verder tekenen zonder te checken of die vorm nog wel in orde is bij verlenging.

Misschien is het niet echt een probleem om naar onderen toe met 3 omtrekklassen te verlengen i.p.v. 2, zodat je bij metingen vanaf omtrekklasse 0,5 m sowieso aan 0,2 m geraakt, maar onafhankelijk van de ondergrens van de metingen elk model verlengen tot 0,2 m lijkt me eerlijk gezegd geen goed idee omwille van de (wellicht beperkte) modellen waarbij enkel dikke bomen gemeten zijn. Ik zou hier dus sowieso een vast aantal omtrekklassen vastleggen waarmee de curve verlengd mag worden.

• vraag: wat met afgeleide modellen, waar we sinds recent alle metingen meenemen en dus geen bruikbaar interval meer afkappen (omdat hier de modelvorm toch niet mee bepaald wordt)? Wat we hier nog wel kunnen herzien, is de ondergrens van 0,5 m omtrek.

Ja, dat zou goed zijn; extrapolatie naar 20 cm (zelfs als die omtrekken niet opgemeten zijn), met een minimum van 2.5 m?

Sowieso blijven we hier afhankelijk van de breedte van het Vlaams model, dus in dit geval zal het zijn: metingen + 2 omtrekklassen (of hetgeen hierboven afgesproken wordt), maar het model kan niet verder gaan dan het Vlaams model (dat bepaald wordt door de breedte van de basismodellen van die soort). Hier zou ik in dit geval wel aanraden om deze modellen bij een hoge RMSE zeer kritisch te bekijken (of helling een beetje acceptabel ligt t.o.v. puntenwolk met metingen).

voor mij lijkt die laatste optie misschien het makkelijkste: 2 rapporten: één met alle goedgekeurde grafieken en daarnaast het validatierapport met enkel de niet goedgekeurde grafieken van de 20 'slechtste' modellen. En dan laat ik die lopen tot ik 20 goede modellen heb.

Euh, ik vrees dat je ze zal moeten laten lopen tot je geen slechtste modellen meer hebt die niet goedgekeurd zijn. (Het zou kunnen dat je ooit eens 20 modellen goedgekeurd hebt, maar dat er een nieuw model opduikt met voldoende metingen, dat slechter scoort, en dat ga je volgens de regels ook nog moeten bekijken, want hiervan weet je niet of het goed is.) Maar ok om er 2 rapporten van te maken.

• wordt deze uitbreiding enkel toegepast voor hogere omtrekklassen, of ook voor lage omtrekklassen? Enkel voor hogere omtrekklassen, voor lagere zouden we sowieso tot 20 cm gaan. Niet erg dat model daar wat minder goed is. Daar hoeft geen controle.

Te herbekijken na uitklaren hierboven.

[leymanan]

Misschien is het niet echt een probleem om naar onderen toe met 3 omtrekklassen te verlengen i.p.v. 2, zodat je bij metingen vanaf omtrekklasse 0,5 m sowieso aan 0,2 m geraakt, maar onafhankelijk van de ondergrens van de metingen elk model verlengen tot 0,2 m lijkt me eerlijk gezegd geen goed idee omwille van de (wellicht beperkte) modellen waarbij enkel dikke bomen gemeten zijn. Ik zou hier dus sowieso een vast aantal omtrekklassen vastleggen waarmee de curve verlengd mag worden.

OK! goed idee! (3 omtrekklasses naar beneden toe)

• vraag: wat met afgeleide modellen, waar we sinds recent alle metingen meenemen en dus geen bruikbaar interval meer afkappen (omdat hier de modelvorm toch niet mee bepaald wordt)? Wat we hier nog wel kunnen herzien, is de ondergrens van 0,5 m omtrek.

Ja, dat zou goed zijn; extrapolatie naar 20 cm (zelfs als die omtrekken niet opgemeten zijn), met een minimum van 2.5 m?

Sowieso blijven we hier afhankelijk van de breedte van het Vlaams model, dus in dit geval zal het zijn: metingen + 2 omtrekklassen (of hetgeen hierboven afgesproken wordt), maar het model kan niet verder gaan dan het Vlaams model (dat bepaald wordt door de breedte van de basismodellen van die soort). Hier zou ik in dit geval wel aanraden om deze modellen bij een hoge RMSE zeer kritisch te bekijken (of helling een beetje acceptabel ligt t.o.v. puntenwolk met metingen).

OK, is goed! We volgen breedte van het Vlaams model (metingen + 2 of + 3 omtrekklasses)

voor mij lijkt die laatste optie misschien het makkelijkste: 2 rapporten: één met alle goedgekeurde grafieken en daarnaast het validatierapport met enkel de niet goedgekeurde grafieken van de 20 'slechtste' modellen. En dan laat ik die lopen tot ik 20 goede modellen heb.

Euh, ik vrees dat je ze zal moeten laten lopen tot je geen slechtste modellen meer hebt die niet goedgekeurd zijn. (Het zou kunnen dat je ooit eens 20 modellen goedgekeurd hebt, maar dat er een nieuw model opduikt met voldoende metingen, dat slechter scoort, en dat ga je volgens de regels ook nog moeten bekijken, want hiervan weet je niet of het goed is.) Maar ok om er 2 rapporten van te maken.

Ja, dat is ook goed (tot geen slechtste modellen meer)!

[ElsLommelen]

OK, is goed! We volgen breedte van het Vlaams model (metingen + 2 of + 3 omtrekklasses)

Euh, ik bedoelde metingen afgeleid model + 2 of +3 omtrekklasses, maar dit maximaal tot aan de breedte van het Vlaams model. Dat Vlaams model kan wel een goed generiek model zijn, maar je wil het wel voor dat specifieke model fitten op basis van de metingen van het model. Zoals tijdens het overleg uitgelegd: dit Vlaams model kan afhankelijk van de beschikbare metingen in andere domeinen ofwel sterk neigen naar een typisch model voor de leemstreek, ofwel typisch voor de Kempen (met mogelijk een iets minder steile curve?), of een combinatie van beiden dat bij lage omtrekklassen meer bepaald wordt door Kempense bomen en bij hoge omtrekklassen door bomen van Zoniën? Je afgeleid model wijkt hier qua karakteristieken misschien sterk van af qua hellingsgraad, dus daarom wil je het ook voor het afgeleide model niet te ver uitbreiden buiten de range van de metingen zelf. Inderdaad, dit zal de bruikbare range mogelijk wat beperken, maar hier blijft het advies: extra metingen zijn nodig om een goed model te hebben.

[leymanan]

OK, is goed! We volgen breedte van het Vlaams model (metingen + 2 of + 3 omtrekklasses)

Euh, ik bedoelde metingen afgeleid model + 2 of +3 omtrekklasses, maar dit maximaal tot aan de breedte van het Vlaams model. Dat Vlaams model kan wel een goed generiek model zijn, maar je wil het wel voor dat specifieke model fitten op basis van de metingen van het model. Zoals tijdens het overleg uitgelegd: dit Vlaams model kan afhankelijk van de beschikbare metingen in andere domeinen ofwel sterk neigen naar een typisch model voor de leemstreek, ofwel typisch voor de Kempen (met mogelijk een iets minder steile curve?), of een combinatie van beiden dat bij lage omtrekklassen meer bepaald wordt door Kempense bomen en bij hoge omtrekklassen door bomen van Zoniën? Je afgeleid model wijkt hier qua karakteristieken misschien sterk van af qua hellingsgraad, dus daarom wil je het ook voor het afgeleide model niet te ver uitbreiden buiten de range van de metingen zelf. Inderdaad, dit zal de bruikbare range mogelijk wat beperken, maar hier blijft het advies: extra metingen zijn nodig om een goed model te hebben.

ook OK!

[ElsLommelen]

@leymanan Nog 2 vraagjes zodat ik verder kan tijdens je verlof:

• heb je een suggestie voor een naam voor de functie die de validatie doet voor de curves met extra metingen in hogere omtrekklassen?
• nu we uitgeklaard hebben dat er automatisch max. 3 lagere omtrekklassen toegevoegd worden: is er ook nood aan het toevoegen van gelijkaardige validaties voor lagere omtrekklassen? (Jij hebt een veel beter zicht op de curves, zelf heb ik eigenlijk geen idee of er veel domeinen met relatief veel metingen zijn waar die lage omtrekklassen beperkt opgemeten zijn zodat ze bij de kwantielen afgekapt worden.) Indien ja: is het alles of niks (dus valideren voor hogere en lagere omtrekklassen tegelijk), of wil je apart kunnen valideren voor enerzijds hogere en anderzijds lagere omtrekklassen? (Deze vraag geldt uiteraard enkel voor de domeinen waar er zowel bij hogere als bij lagere omtrekklassen nog minstens 10 extra metingen zijn.)

[leymanan]

• heb je een suggestie voor een naam voor de functie die de validatie doet voor de curves met extra metingen in hogere omtrekklassen?

Ev. validatie_uitbreiding? naar analogie met uitbreiden_model(variabele) Dacht ook even aan validatie_extrapolatie, maar misschien is validatie_uitbreiding beter.

• nu we uitgeklaard hebben dat er automatisch max. 3 lagere omtrekklassen toegevoegd worden: is er ook nood aan het toevoegen van gelijkaardige validaties voor lagere omtrekklassen? (Jij hebt een veel beter zicht op de curves, zelf heb ik eigenlijk geen idee of er veel domeinen met relatief veel metingen zijn waar die lage omtrekklassen beperkt opgemeten zijn zodat ze bij de kwantielen afgekapt worden.) Indien ja: is het alles of niks (dus valideren voor hogere en lagere omtrekklassen tegelijk), of wil je apart kunnen valideren voor enerzijds hogere en anderzijds lagere omtrekklassen? (Deze vraag geldt uiteraard enkel voor de domeinen waar er zowel bij hogere als bij lagere omtrekklassen nog minstens 10 extra metingen zijn.)

Ik zou daar geen tijd in steken, is niet zo belangrijk, dus NEE, geen nood aan validatie voor lagere omtrekklasses ;-) Bedankt!

[ElsLommelen]

Nu ik bezig ben aan die extra functie validatie.uitbreiding(), heb ik er toch nog enkele vragen over. Dus idee van deze functie is om bij curves met meer dan 10 metingen met omtrek hoger dan deze in het bruikbaar interval, een validatie uit te voeren om de curve naar boven te kunnen uitbreiden. Een validatierapport zou toelaten om de gegevens zelf te valideren, en de 20 slechtste curves te valideren.

Mijn vragen hierbij:

• tot waar wordt de curve uitgebreid? Is dat tot de omtrekklasse waarin de laatste meting valt, of 2 omtrekklassen verder dan die laatste meting (naar analogie met de grens die nu geldt voor de gefitte curves op basis van de metingen binnen het bruikbaar interval)?
• en enkele bedenkingen i.v.m. de validatie van metingen (best allemaal lezen voor je reageert):
  • worden in dit validatierapport bij een eerste keer ook alle curves met niet gevalideerde afwijkende metingen getoond, gelijkaardig aan de 'gewone' validatierapporten, maar dan voor de metingen die boven het bruikbaar interval vallen? (Dan ga je behalve je 20 slechtste grafieken ook heel veel grafieken hebben met 1 of enkele afwijkende metingen.)
  • zijn die afwijkende metingen ook hier de metingen met een RMSE boven 2,5 (waarbij de RMSE berekend is op basis van metingen binnen bruikbaar interval)? In hoeverre moeten er ook extra metingen meegenomen worden bij bv. de curves met hoogste DiffMax of DiffMin of RMSE (naar analogie met toevoegen van 10 hoogste RMSE bij domeinen met hoge RMSE)?
  • op zich bestaat die validatie van deze metingen uit dezelfde stappen als de andere validatierapporten (hoogteschatting doen, rmse berekenen, afwijkingen selecteren), maar dan toegepast op die extra gegevens die toegevoegd worden. Dus dit betekent een herhaling van diezelfde berekeningen in de nieuwe functie, en voor u in de toekomst ook opnieuw een validatie voor enkele extra afwijkende metingen (nu ontkom je er sowieso niet aan, vrees ik). En ik vraag me af: zou het niet zinvol zijn om die extra metingen voor de validatie gewoon mee te nemen bij validatie.basis() en validatie.lokaal()? Ik schat de kans vrij groot dat je in dit geval geen of amper extra metingen moet valideren voor die hogere omtrekklassen (omdat het een kleine proportie van de metingen is), en dan hoeven we ons ook niet de vraag te stellen hoe we afwijkende metingen aanduiden. Voor de toekomst lijkt me dat gemakkelijker (dan bekijk je bij validatie.uitbreiding() enkel de 20 slechtste uitbreidingen), maar anderzijds ga je dan nu wel weer die andere validatiestappen opnieuw moeten doen.

[ElsLommelen]

@leymanan , ik heb ook nog een vraag i.v.m. dit onderdeel dat ik uit het voorstel van hierboven geplukt heb:

• goed- of afkeuren kan door een extra veld in Uitzonderingen aan te vullen met TRUE/FALSE (NA is niet gecontroleerd), voorstel voor naam: uitbreiden_model (tenzij je een kortere naam weet?)

In tegenstelling tot de andere uitzonderingen (min_basis en min_afgeleid), waar het afkeuren aangeduid wordt door een aantal op te geven vanaf wanneer opnieuw gecontroleerd moet worden, ga je bij uitbreiden_model door TRUE/FALSE een definitief oordeel toevoegen, dat niet automatisch herzien wordt zodra er een bepaald aantal extra metingen bijgekomen is. Ik weet niet of dit hier nodig zou zijn?

Het gaat hier sowieso over basismodellen en lokale modellen, die gebaseerd zijn op een groter aantal metingen, dus ik vermoed dat de curve op zich niet zo heel snel ingrijpend gaat veranderen (tenzij bij proportioneel veel extra gegevens). En als ze ingrijpend veranderen, dan ga je dat waarschijnlijk wel in validatierapporten zien aan het opduiken van minstens enkele nieuwe afwijkende metingen (bv. oude metingen die je nooit eerder hebt moeten controleren, maar nu wel moet valideren omwille van het feit dat ze verder van de nieuwe curve af liggen). Maar met de huidige methode ga je dus geen signaal krijgen als door die wijziging van de curve de DiffMediaan vergroot, of andere specifiek aan de validatie.uitbreiding() gerelateerde kenmerken veranderen. Is dit nodig voor u? En zo ja, welke numerieke waarde zouden we kunnen gebruiken? Het totaal aantal metingen, of het aantal metingen buiten het bruikbaar interval, of enkel de metingen binnen het bruikbaar interval, zoals bij min_basis en min_afgeleid, dus diegenen die de curvevorm bepalen? (Concreet zou je dan bij afgekeurde uitbreidingen een aantal aanduiden vanaf wanneer de uitbreiding opnieuw gevalideerd moet worden.)

Zo'n numerieke waarde laat wel toe om aan te geven tot wanneer we gegevens mogen negeren (wanneer FALSE van het eerdere voorstel toepassen), maar niet welke gegevens niet getoond worden wegens goedgekeurd (TRUE versus NA). Hiervoor zouden we het principe van de GoedgekeurdeAfwijkendeCurves van validatie.basis() en validatie.lokaal() ook kunnen toepassen bij validatie.uitbreiding().

En nog een andere (ongerelateerde) vraag: hoe bereken ik de diff bij een curve die terug daalt? Modelmatig daalt ze terug, maar voor het eindresultaat vervangen we die dalende curve door de maximale waarde van de curve. Bereken ik de diff op basis van het (dalende) model, of op basis van het eindresultaat (met maximale waarde)?

(En bekijk je ook nog even de vragen die ik gisteren toevoegde?)

[leymanan]

Nu ik bezig ben aan die extra functie validatie.uitbreiding(), heb ik er toch nog enkele vragen over. Dus idee van deze functie is om bij curves met meer dan 10 metingen met omtrek hoger dan deze in het bruikbaar interval, een validatie uit te voeren om de curve naar boven te kunnen uitbreiden. Een validatierapport zou toelaten om de gegevens zelf te valideren, en de 20 slechtste curves te valideren.

Mijn vragen hierbij:

• tot waar wordt de curve uitgebreid? Is dat tot de omtrekklasse waarin de laatste meting valt, of 2 omtrekklassen verder dan die laatste meting (naar analogie met de grens die nu geldt voor de gefitte curves op basis van de metingen binnen het bruikbaar interval)?

twee klasses verder dan die laatste meting

[leymanan]

En nog een andere (ongerelateerde) vraag: hoe bereken ik de diff bij een curve die terug daalt? Modelmatig daalt ze terug, maar voor het eindresultaat vervangen we die dalende curve door de maximale waarde van de curve. Bereken ik de diff op basis van het (dalende) model, of op basis van het eindresultaat (met maximale waarde)?

op basis van het eindresultaat (met maximale waarde)

[leymanan]

In tegenstelling tot de andere uitzonderingen (min_basis en min_afgeleid), waar het afkeuren aangeduid wordt door een aantal op te geven vanaf wanneer opnieuw gecontroleerd moet worden, ga je bij uitbreiden_model door TRUE/FALSE een definitief oordeel toevoegen, dat niet automatisch herzien wordt zodra er een bepaald aantal extra metingen bijgekomen is. Ik weet niet of dit hier nodig zou zijn?

Dat is volgens mij niet nodig, maakt alles weer complexer. Er gaan sowieso niet continu nieuwe gegevens binnenkomen, dus dan lijkt het me niet zo moeilijk om in de handleiding te vermelden dat er bij extra gegevens steeds moet gekeken worden of model niet verder uitgebreid kan worden. Of in de code opnemen dat als er meer bomen opgemeten werden dan de vorige keer, én uitbreiden_model was FALSE, dan nog eens checken? Ik kan dat ook opnemen in mijn code, die alle stappen doorloopt ....

[leymanan]

en enkele bedenkingen i.v.m. de validatie van metingen (best allemaal lezen voor je reageert):

• worden in dit validatierapport bij een eerste keer ook alle curves met niet gevalideerde afwijkende metingen getoond, gelijkaardig aan de 'gewone' validatierapporten, maar dan voor de metingen die boven het bruikbaar interval vallen? (Dan ga je behalve je 20 slechtste grafieken ook heel veel grafieken hebben met 1 of enkele afwijkende metingen.)

Nee dat hoeft volgens mij niet. Die metingen worden immers niet gebruikt om de curves op te stellen, enkel om te checken of de uitbreiding van de curve OK is. Dat klopt toch, he?

• zijn die afwijkende metingen ook hier de metingen met een RMSE boven 2,5 (waarbij de RMSE berekend is op basis van metingen binnen bruikbaar interval)?

Afwijkende metingen: zou ik niet extra aanduiden (zie vraag hierboven)

In hoeverre moeten er ook extra metingen meegenomen worden bij bv. de curves met hoogste DiffMax of DiffMin of RMSE (naar analogie met toevoegen van 10 hoogste RMSE bij domeinen met hoge RMSE)?

dat gedeelte van de vraag snap ik niet, sorry.

• op zich bestaat die validatie van deze metingen uit dezelfde stappen als de andere validatierapporten (hoogteschatting doen, rmse berekenen, afwijkingen selecteren), maar dan toegepast op die extra gegevens die toegevoegd worden. Dus dit betekent een herhaling van diezelfde berekeningen in de nieuwe functie, en voor u in de toekomst ook opnieuw een validatie voor enkele extra afwijkende metingen (nu ontkom je er sowieso niet aan, vrees ik). En ik vraag me af: zou het niet zinvol zijn om die extra metingen voor de validatie gewoon mee te nemen bij validatie.basis() en validatie.lokaal()? Ik schat de kans vrij groot dat je in dit geval geen of amper extra metingen moet valideren voor die hogere omtrekklassen (omdat het een kleine proportie van de metingen is), en dan hoeven we ons ook niet de vraag te stellen hoe we afwijkende metingen aanduiden. Voor de toekomst lijkt me dat gemakkelijker (dan bekijk je bij validatie.uitbreiding() enkel de 20 slechtste uitbreidingen), maar anderzijds ga je dan nu wel weer die andere validatiestappen opnieuw moeten doen.

Ik dacht dat de extra validatierapporten enkel gingen kijken - obv metingen buiten bruikbaar interval - of de uitbreiding OK was, en niet zouden focussen op individuele metingen? Mocht ik bij zo een controle natuurlijk zien dat er een meting niet OK is, kan ik de statusvan die meting toch steeds veranderen naar afgekeurd? Daarom lijkt het me toch makkelijker om die twee rapporten uit elkaar te houden, niet? Of mis ik iets?

Misschien moeten we donderdag eens kort een google meet houden? Om alles duidelijk te krijgen? Of wanneer zou dat passen voor jou?

[ElsLommelen]

Bij deze heb ik de meest dringende functionaliteit ingewerkt:

• alle curves worden onder het bruikbare interval van de gegevens uitgebreid met 3 omtrekklassen, en boven het bruikbaar interval met 2 omtrekklassen, dus dit betekent gewoon dat het gebouwde model toegepast wordt op die 3 + 2 extra omtrekklassen (dit gebeurt automatisch als je de nieuwe versie runt, er zijn geen argumenten die dit regelen)
• voor domein-boomsoortcombinaties met meer dan 10 metingen boven het bruikbaar interval (grens aanpasbaar bij Uitzonderingen$min_uitbreiden_model in functie initiatie()), kan het bruikbare interval naar boven toe verder uitgebreid worden door:
  • validatie.uitbreiding() te runnen en de uitbreiding voor de 20 slechtste modellen te beoordelen in het gegenereerde validatierapport (blauw gekleurde deel: valt de curve door de puntenwolk?). Dit functioneert gelijkaardig aan andere validatierapporten: bij slechte curve Uitzonderingen$min_uitbreiden_model in initiatie() optrekken en de verschillende stappen opnieuw runnen zodat je slechte curve verdwenen is.
  • de (uiteindelijke) output van validatie.uitbreiding() toevoegen als argument Uitbreiding in outputIVANHO()

Ik heb wel enkele vragen, maar die ga je best kunnen oplossen door het allemaal te testen in de praktijk, vermoed ik:

• validatie.uitbreiding() verwacht als input de gegevens voor 1 modeltype (Basis of Lokaal), terwijl je bij outputIVANHO() meerdere modeltypen (Basis, Afgeleid en Lokaal) samen kan invoeren en het resultaat in 1 tabel krijgen. Als je dit laatste wil doen voor meerdere modeltypen samen, dan ga je wel voor je argument Uitbreiding de resultaten van meerdere runs van validatie.uitbreiding() moeten samenplakken. outputIVANHO() apart runnen voor Basismodellen en Afgeleide modellen enerzijds, en Lokale modellen anderzijds, is uiteraard ook een optie. (Als je de gegevens per boomsoort verwerkt, zit je eigenlijk altijd in die situatie.) Hier is mijn vraag: kan je hiermee verder, of zou het beter zijn dat je bij validatie.uitbreiding() basismodellen en lokale modellen naast elkaar kan invoeren? Dit laatste heeft uiteraard wel het gevolg dat de invoer ingewikkelder wordt (nu heb je 1 model en 1 dataset, en wat andere argumenten, dan worden het 2 modellen en 2 datasets en dezelfde argumenten).
• Wat met het dhcurvesrapport()? Ik heb hier nog niks aan aangepast, wat als gevolg heeft dat het gewoon de ingevoerde gegevens uitvoert: voeg je de extra gegevens toe, dan worden die mee weergegeven, en als je ze vooraf uitfiltert met filter(VoorModelFit), dan worden enkel de ingevoerde gegevens meegegeven. Gemakkelijk en flexibel. Of zou je hierin graag extra opties zien, zoals een optie om de gegevens van de uitbreiding in een andere kleur weer te geven?

Wat nog moet gebeuren (en waar ik de komende dagen verder aan werk):

• de documentatie nalezen en updaten. De helpfuncties van de functies zelf heb ik wel al bijgewerkt tijdens het herwerken van de code, dus hier vind je alle info over het gebruik en de extra argumenten van de functie (al kan ik uiteraard wel iets over het hoofd gezien hebben), dus hiermee kan je normaal gezien verder om de functies alvast te testen. Het vignet moet nog wel aangepast worden aan de nieuwe situatie, en ik lees voor de zekerheid alles nog eens na (wat niet wil zeggen dat je onduidelijkheden mag melden).
• de validatie van de gegevens van de uitbreiding (dus outliers aanduiden). Deze zouden toegevoegd worden aan validatie.basis() en validatie.lokaal(), maar ik had begrepen dat dit minder prioritair was. Sowieso ga je in het validatierapport van de uitbreiding de punten DiffMin en DiffMax kunnen bekijken voor de validatie. Of misschien is dit wel helemaal voldoende? Want eigenlijk kan je bij twijfel ook gemakkelijk controleren of de absolute waarde van deze waarden groter is dan 2.5 keer de rmse.
• zorgen dat het package technisch volledig in orde is en ik automatisch signalen krijg als dat in de toekomst niet meer zo is (bv. door aanpassingen in packages waar het van afhangt, zo heb ik enkele dagen geleden gemerkt dat sommige functies heelwat warnings gooien als iemand de nieuwste versie van dplyr (tidyverse) al zou geïnstalleerd hebben). Ik heb het package omwille van de meertaligheid ooit gebruikt om een spellingscheck te testen, en als dit nog werkt (i.e. het me geen extra tijd kost), wou ik het ook toevoegen, dat kan alleen maar handig zijn als we ooit teksten gaan herschrijven.

Maar in tussentijd kan je dus gerust de huidige versie van deze branch testen, codematig zou alles in orde moeten zijn.

[ElsLommelen]

@leymanan Nog een vraagje om eens over na te denken: in de vorige versie van het package was voor het afgeleide model bewust gekozen om het model te fitten en de rmse te berekenen op basis van het bruikbaar interval (zie hier). Hoe ga ik hier best mee om na je vraag om het volledige interval in beschouwing te nemen? Als ik voor het fitten en de foutenmarge alle punten gebruik, dan ligt de curve beter voor het hele interval van de punten (dus globaal genomen, inclusief dunne en dikke bomen), maar dan is de curve mogelijk een iets minder goede benadering op het vroeger vooropgestelde bruikbare interval (dus bomen tussen 0.5 en 2.3 m diameter). Dus eigenlijk hangt de plaats waar je curve een goede benadering is, in de huidige versie af van de omtrekklassen waarin er (veel) metingen zijn. Is dit ok? Of zou je hier op een of andere manier toch invloed op willen hebben? (Sowieso kan je altijd vooraf metingen weggooien, moest je bv. voor een bepaalde boomsoort-domeincombinatie veel metingen hebben van lage omtrekklassen, met een ongewild gevolg omdat de curve vooral fit op de lage omtrekklassen. Waarschijnlijk ga je meestal wel vooral metingen hebben van de omtrekklassen waarin je interesse hebt, waardoor het vanzelf goed komt, vermoed ik?)

[leymanan]

Nog een vraagje om eens over na te denken: in de vorige versie van het package was voor het afgeleide model bewust gekozen om het model te fitten en de rmse te berekenen op basis van het bruikbaar interval (zie hier). Hoe ga ik hier best mee om na je vraag om het volledige interval in beschouwing te nemen?

Ik zou die nog steeds niet meenemen. Ik dacht dat eigenlijk dat de curves op dezelfde manier gingen opgesteld worden als ervoor (weliswaar met max 3m ipv 2.4 m), en dat de metingen buiten het initiële bruikbare interval gebruikt zouden worden om te kijken of een extrapolatie OK was.

Het klopt toch dat voor alle modellen nog steeds enkel met Q5-Q95 gewerkt wordt om het model op te stellen, maar dat er geëxtrapoleerd wordt buiten dit interval? Of heb ik dat misbegrepen? Hierna wat je hiervoor noteerde:

• alle curves worden onder het bruikbare interval van de gegevens uitgebreid met 3 omtrekklassen, en boven het bruikbaar interval met 2 omtrekklassen, dus dit betekent gewoon dat het gebouwde model toegepast wordt op die 3 + 2 extra omtrekklassen (dit gebeurt automatisch als je de nieuwe versie runt, er zijn geen argumenten die dit regelen)

Dus eigenlijk hangt de plaats waar je curve een goede benadering is, in de huidige versie af van de omtrekklassen waarin er (veel) metingen zijn. Is dit ok?

Eigenlijk niet echt. Ik vind dat beetje gevaarlijk. Ik heb de afgeleide curves gecontroleerd obv RMSE, en de slechtste afgekeurd. Maar als we nu die dunne er allemaal bij nemen, weet ik niet wat effect gaat zijn, en moet ik controle opnieuw doen. In handleiding staat ook dat het beter is die niet mee te nemen "Bij het meenemen van lagere omtrekklassen bepalen deze metingen mee de ligging van de curve, met een (mogelijk) minder goede benadering in het gekozen interval tot gevolg". Terwijl dat het bij lokaal en basismodel net wel nodig was "Omdat we voor het basismodel en lokaal model gemerkt hebben dat het meenemen van de metingen van de lagere omtrekklassen vaak een betere curvevorm geeft bij de gekozen wiskundige functie, hebben we ervoor gekozen om deze lagere omtrekklassen mee te nemen voor het berekenen van het model"

Ter info: er zijn 1015 afgeleide curves, daarvan heb ik er 330 gecontroleerd (wegens hoge RMSE of weinig afzonderlijke hoogtes gemeten) en 135 afgekeurd/194 goedgekeurd. Ik ben bang dat als we anders gaan werken, ik die controle weer helemaal opnieuw moet doen. (Ik dacht dat ik enkel controle zou moeten doen van de curves waar er een signaal is dat de extrapolatie mogelijks foutief is)

Sowieso kan je altijd vooraf metingen weggooien, moest je bv. voor een bepaalde boomsoort-domeincombinatie veel metingen hebben van lage omtrekklassen, met een ongewild gevolg omdat de curve vooral fit op de lage omtrekklassen.

Dat kan, maar is wel omslachtig en beetje teveel at random naar mijn gevoel: eerst controle doen, dan - als niet OK - hoeveel metingen moet ik weggooien, welke, ... Dan terug curve maken, terug controleren, ...

[ElsLommelen]

Ik zou die nog steeds niet meenemen. Ik dacht dat eigenlijk dat de curves op dezelfde manier gingen opgesteld worden als ervoor (weliswaar met max 3m ipv 2.4 m), en dat de metingen buiten het initiële bruikbare interval gebruikt zouden worden om te kijken of een extrapolatie OK was.

Het klopt toch dat voor alle modellen nog steeds enkel met Q5-Q95 gewerkt wordt om het model op te stellen, maar dat er geëxtrapoleerd wordt buiten dit interval? Of heb ik dat misbegrepen?

Nee, dat bruikbaar interval wordt enkel nog gehanteerd voor het basismodel en het lokaal model (en daar wordt geëxtrapoleerd zoals je beschrijft). Omdat het afgeleid model enkel een verschuiving is van het basismodel en de curvevorm hier niet beïnvloed wordt door de randpunten, is beslist om hier alle punten mee te nemen (zie deze discussie). Het weglaten van randpunten heeft hier dus geen zin, het vermindert enkel maar het aantal punten dat we kunnen gebruiken om het model naar de juiste hoogte te schuiven. Ik lees hier wel dat afgesproken is om enkel de punten boven 0.5 m mee te nemen (dat had ik bij het stellen van mijn vraag over het hoofd gezien, alweer een hele tijd geleden dat ik dat ingebouwd heb), dus dat lost wel al een groot deel van mijn vraag/bezorgdheid op: de scope gaat sowieso boven 0.5 m zijn.

En aan de bovengrens is het (voorlopig) zo dat bij het afgeleide model voor de validatie enkel omtrekklassen meegenomen worden die ook in het Vlaams model zitten, dus dat is ten hoogste de grens van 2,4 m + 2 omtrekklassen = 2,6 m. Dus als ik het zo bekijk, zit die scope nog wel ok, zowel aan de onder- als aan de bovengrens. Een bug in de huidige situatie is dat bij een gevalideerde uitbreiding van het basismodel die uitbreiding wel zal meegenomen worden bij de berekening van de omtrekklassen voor outputIVANHO() (dus het wordt niet gevalideerd, maar komt wel in het eindresultaat).

Maar er is dus nog niks ingebouwd om die uitbreiding van het basismodel naar boven toe te valideren. Gezien het feit dat dit model afwijkt van de andere in de zin dat het een verschuiving is van een curve (en dus grotendeels een toepassing van het bestaand basismodel), is ook de vraag wat de beste manier is om dit model te valideren. Ik zie 2 opties:

1. net zoals voor het basismodel en het lokaal model de uitbreiding valideren op basis van metingen in hogere omtrekklassen. Voordeel is dat dit eenvormig is met de rest, en dat je je bestaand model toepast, maar gezien het feit dat deze domeinen per definitie weinig metingen hebben (< 50 boven een omtrek van 0,5 m), vraag ik me af of je wel ooit aan 10 metingen zal geraken met omtrekklasse hoger dan 2,4 m. Dus kans dat je op die manier een afgeleid model zal kunnen uitbreiden, lijkt me zeer klein.
2. de functies fit.afgeleid() en validatie.afgeleid() lichtjes aanpassen zodat ze alle metingen met omtrekklassen tot 2,8 m meegenomen worden, dus dan wordt het model gebouwd (= verschoven) op basis van alle beschikbare metingen met omtrek tot 2,8 m, en met uitbreiding van 2 omtrekklassen kom je aan een toepassing van het model tot 3 m ingeval er metingen tot 2,8 m aanwezig zijn. Dit betekent dan wel weer dat die scope breder is voor die enkele gevallen waar je metingen van dikke bomen hebt (maar vermits de curve naar boven toe vlakker is dan naar beneden, is dit misschien minder een probleem?). De scope is dan in elk geval even breed als de uiteindelijke curve (op die 3 en 2 omtrekklassen na die er bij de toepassing van het model aan geplakt worden).

Ter info: er zijn 1015 afgeleide curves, daarvan heb ik er 330 gecontroleerd (wegens hoge RMSE of weinig afzonderlijke hoogtes gemeten) en 135 afgekeurd/194 goedgekeurd. Ik ben bang dat als we anders gaan werken, ik die controle weer helemaal opnieuw moet doen. (Ik dacht dat ik enkel controle zou moeten doen van de curves waar er een signaal is dat de extrapolatie mogelijks foutief is)

Oeps, dat zijn er redelijk wat die afgekeurd zijn. Misschien eventjes proberen te bedenken wat dit zou geven als we een van bovenstaande opties zouden inbouwen?

1. Sowieso wijkt de huidige methode al lichtjes af van je eerder gebruikte methode omwille van die randpunten, maar ik zou ervan uitgaan dat het aantal randpunten dat in het bruikbaar interval weggevallen is, eerder beperkt is en dus een beperkte invloed zal hebben op het resultaat voor de gecontroleerde curves. De enkele afgekeurde curves die echt veel weggevallen randpunten hadden, komen hopelijk nu boven het min_afgeleid_model dat je ingesteld hebt, waardoor enkel deze opnieuw ter controle opduiken in validatie.afgeleid(). Voor validatie.uitbreiding() krijg je de 20 slechtste gevallen voorgeschoteld, en in het slechtste geval ga je die afkeuren en dit enkele keren moeten herhalen, maar zoals hierboven aangegeven: ik vraag me af of er veel van die afgeleide modellen zijn waarbij een uitbreiding mogelijk is (> 10 metingen van die 50 die boven 2,4 m liggen...), dus voor de meest curves zal je waarschijnlijk niet kunnen uitbreiden.
2. Iets lastiger om in te schatten wat hier gebeurt. Sowieso gaan modellen terug in je validatierapport opduiken als:
   • er veel extra metingen zijn in de hoge omtrekklassen (of randpunten), waardoor je boven je min_afgeleid_model komt, of
   • er extra afwijkende metingen zijn, omdat de curve veel verschoven is of omdat er bij de hoge omtrekklassen afwijkende metingen zijn

Dus in beide gevallen krijg je (hopelijk) enkel de grote veranderingen terug voorgeschoteld in validatie.afgeleid(), zoals het zou moeten (als je curves na enkele jaren en enkele extra metingen opnieuw bekijkt). Afgekeurde curves blijven afgekeurd, tenzij er veel extra metingen zijn die nu ineens wel meetellen.

Met een beetje pech krijg je wel heelwat (eerder goedgekeurde) grafieken te zien waarin 1 of enkele afwijkende metingen bij gekomen zijn, maar die staan idealiter achteraan in het rapport, dus als je de grote problemen vooraan opgelost hebt, wil je misschien gewoon het model opnieuw fitten en eens door dat rapport scrollen om te zien of het inderdaad enkel om een beperkt aantal afwijkende metingen per model gaat? Ik weet eigenlijk ook niet hoe dat bij je vorige validatie was? Als dat toen geen probleem was, zal het dat nu ook niet zijn.

Sowieso kan je altijd vooraf metingen weggooien, moest je bv. voor een bepaalde boomsoort-domeincombinatie veel metingen hebben van lage omtrekklassen, met een ongewild gevolg omdat de curve vooral fit op de lage omtrekklassen.

Dat kan, maar is wel omslachtig en beetje teveel at random naar mijn gevoel: eerst controle doen, dan - als niet OK - hoeveel metingen moet ik weggooien, welke, ... Dan terug curve maken, terug controleren, ...

Ja, inderdaad, 100 % gelijk. Maar ik had dus over het hoofd gezien dat we de omtrekklassen onder 0,5 m niet meenemen, dus probleem gaat veel minder groot zijn dan ik aangaf: met 0,5 m als minimum zitten we eigenlijk op de originele scope, voor de hogere omtrekklassen is het dus nog uit te klaren.

[leymanan]

Maar er is dus nog niks ingebouwd om die uitbreiding van het basismodel naar boven toe te valideren. Gezien het feit dat dit model afwijkt van de andere in de zin dat het een verschuiving is van een curve (en dus grotendeels een toepassing van het bestaand basismodel), is ook de vraag wat de beste manier is om dit model te valideren. Ik zie 2 opties:

1. net zoals voor het basismodel en het lokaal model de uitbreiding valideren op basis van metingen ......

? je bedoelt hier toch afgeleid model, niet?

[leymanan]

Maar er is dus nog niks ingebouwd om die uitbreiding van het basismodel naar boven toe te valideren. Gezien het feit dat dit model afwijkt van de andere in de zin dat het een verschuiving is van een curve (en dus grotendeels een toepassing van het bestaand basismodel), is ook de vraag wat de beste manier is om dit model te valideren. Ik zie 2 opties: 1. .... 2. de functies fit.afgeleid() en validatie.afgeleid() lichtjes aanpassen zodat ze alle metingen met omtrekklassen tot 2,8 m meegenomen worden, dus dan wordt het model gebouwd (= verschoven) op basis van alle beschikbare metingen met omtrek tot 2,8 m, en met uitbreiding van 2 omtrekklassen kom je aan een toepassing van het model tot 3 m ingeval er metingen tot 2,8 m aanwezig zijn. Dit betekent dan wel weer dat die scope breder is voor die enkele gevallen waar je metingen van dikke bomen hebt (maar vermits de curve naar boven toe vlakker is dan naar beneden, is dit misschien minder een probleem?). De scope is dan in elk geval even breed als de uiteindelijke curve (op die 3 en 2 omtrekklassen na die er bij de toepassing van het model aan geplakt worden).

voorkeur voor optie 2

[ElsLommelen]

Maar er is dus nog niks ingebouwd om die uitbreiding van het basismodel naar boven toe te valideren. Gezien het feit dat dit model afwijkt van de andere in de zin dat het een verschuiving is van een curve (en dus grotendeels een toepassing van het bestaand basismodel), is ook de vraag wat de beste manier is om dit model te valideren. Ik zie 2 opties:

1. net zoals voor het basismodel en het lokaal model de uitbreiding valideren op basis van metingen ......

? je bedoelt hier toch afgeleid model, niet?

Ja, inderdaad, foutje in deze uitleg...

[ElsLommelen]

Maar er is dus nog niks ingebouwd om die uitbreiding van het basismodel naar boven toe te valideren. Gezien het feit dat dit model afwijkt van de andere in de zin dat het een verschuiving is van een curve (en dus grotendeels een toepassing van het bestaand basismodel), is ook de vraag wat de beste manier is om dit model te valideren. Ik zie 2 opties:

1. ....
2. de functies fit.afgeleid() en validatie.afgeleid() lichtjes aanpassen zodat ze alle metingen met omtrekklassen tot 2,8 m meegenomen worden, dus dan wordt het model gebouwd (= verschoven) op basis van alle beschikbare metingen met omtrek tot 2,8 m, en met uitbreiding van 2 omtrekklassen kom je aan een toepassing van het model tot 3 m ingeval er metingen tot 2,8 m aanwezig zijn. Dit betekent dan wel weer dat die scope breder is voor die enkele gevallen waar je metingen van dikke bomen hebt (maar vermits de curve naar boven toe vlakker is dan naar beneden, is dit misschien minder een probleem?). De scope is dan in elk geval even breed als de uiteindelijke curve (op die 3 en 2 omtrekklassen na die er bij de toepassing van het model aan geplakt worden).

voorkeur voor optie 2

Ok, da's voor mij ook het minste werk.

[leymanan]

2. Iets lastiger om in te schatten wat hier gebeurt. Sowieso gaan modellen terug in je validatierapport opduiken als:

• er veel extra metingen zijn in de hoge omtrekklassen (of randpunten), waardoor je boven je min_afgeleid_model komt, of
• er extra afwijkende metingen zijn, omdat de curve veel verschoven is of omdat er bij de hoge omtrekklassen afwijkende metingen zijn

Op zich is dat niet zo erg, maar we moeten erop letten dat er geen domein-bms-combinaties zijn die dan bij géén van beide opgepikt worden (niet bij afgeleid model, want boven min_afgeleid_model, en niet bij basismodel omdat daar misschien andere aantallen bekeken worden?)

[ElsLommelen]

2. Iets lastiger om in te schatten wat hier gebeurt. Sowieso gaan modellen terug in je validatierapport opduiken als:
   • er veel extra metingen zijn in de hoge omtrekklassen (of randpunten), waardoor je boven je min_afgeleid_model komt, of
   • er extra afwijkende metingen zijn, omdat de curve veel verschoven is of omdat er bij de hoge omtrekklassen afwijkende metingen zijn

Op zich is dat niet zo erg, maar we moeten erop letten dat er geen domein-bms-combinaties zijn die dan bij géén van beide opgepikt worden (niet bij afgeleid model, want boven min_afgeleid_model, en niet bij basismodel omdat daar misschien andere aantallen bekeken worden?)

Codematig kan dit niet gebeuren, want bij initiatie() worden voor het afgeleid model alle domein-bms-combinaties meegenomen

• waarvan de bms in de metingen voor het basismodel voorkomt en de domein-bms-combinatie niet (m.a.w. de niet-basismodellen komen sowieso bij afgeleid terecht)
• tenzij het aantal bomen (met omtrek > 0,5) kleiner is dan 10 (= minimumwaarde voor afgeleid model) of dan min_afgeleidmodel (dus de domeinen die we tijdelijk negeren omdat het model slecht is)

Dus ja, bij basismodel worden andere aantallen bekeken (het bruikbaar interval), maar de eigenlijke definitie en werkwijze is dat alles wat niet in het basismodel zit (om welke reden dan ook: te weinig metingen, afgekeurd model,...), voor het afgeleid model in aanmerking komt, tenzij het daar niet aan de minimumeisen voldoet. Dus iets dat tussen de twee zit, zal niet uit de boot vallen (tenzij je als gebruiker na de initiatie-stap gaat prutsen met de datasets of niet alle gegevens van een bms meeneemt in eenzelfde analyse, achterpoortjes bij oneigenlijk gebruik zijn er uiteraard altijd ;-) ).

[ElsLommelen]

Nog een vraagje: voorlopig staat er eigenlijk nergens een bovengrens meer, behalve de grens van 2,8 m die ik hierboven suggereerde voor het afgeleide model. Voor het basismodel en lokaal model is er wel die grens van 2,4 waarbij het fitten van het model stopt, maar voor de uitbreiding heb ik nergens een bovengrens vastgelegd.

Uiteraard wil ik je gerust de vrijheid geven om die grens zelf te bepalen, maar een bijkomende reden om bij initiatie() toch een bovengrens vast te leggen waarboven er een alarm afgaat (= het rapport met verwijderde gegevens en het effectief verwijderen van de metingen uit de dataset), is dat problematische metingen zoals metingen in verkeerde eenheden, niet meegenomen worden in de analyses. Oftewel: je wil in je validatierapport niet ineens een grafiek zien verschijnen met een boom van 200 m omtrek, want dat betekent dat je opnieuw moet beginnen. ;-)

Dus concreet:

• is er een bovengrens te bepalen waarboven de gegevens bij initiatie() weggegooid mogen worden en sowieso niet meer gebruikt gaan worden om een uitbreiding te berekenen (vooral relevant voor basismodel en lokaal model)? Sowieso gaat je eindresultaat nog 2 klassen verder gaan als de hoogste meting. Dus als je 2,8 m neemt, krijg je een resultaat tot 3,0 m, en als je 3,0 m kiest, ga je een resultaat tot 3,2 m krijgen (klassemidden ligt telkens 0,05 m lager).
• is het ok om voor het afgeleid model alles boven 2,8 m al in de initiatiestap weg te gooien (dus model wordt berekend tot 2,8 m en toegepast tot 3 m)? Of toch liever een andere waarde?

[leymanan]

• is er een bovengrens te bepalen waarboven de gegevens bij initiatie() weggegooid mogen worden en sowieso niet meer gebruikt gaan worden om een uitbreiding te berekenen (vooral relevant voor basismodel en lokaal model)? Sowieso gaat je eindresultaat nog 2 klassen verder gaan als de hoogste meting. Dus als je 2,8 m neemt, krijg je een resultaat tot 3,0 m, en als je 3,0 m kiest, ga je een resultaat tot 3,2 m krijgen (klassemidden ligt telkens 0,05 m lager).

Neem maar 3 m

• is het ok om voor het afgeleid model alles boven 2,8 m al in de initiatiestap weg te gooien (dus model wordt berekend tot 2,8 m en toegepast tot 3 m)? Of toch liever een andere waarde?

Is OK, 2.8 m voor afgeleid model!

[ElsLommelen]

@leymanan De documentatie is intussen ook in orde, en ik zie niet meer direct inhoudelijke issues die nog opgelost moeten worden, dus wat mij betreft, zou alles voor u in orde moeten zijn om te reviewen. Bekijk je hierbij evt. ook nog even de vragen die ik hier gesteld heb? Het gaat vooral over wat al dan niet handig is voor u, dus geef gerust aan als de huidige situatie hier nog verbeterd moet worden.

(Zelf ga ik ondertussen nog even naar de machinerie kijken, en evt. wat details zoals de automatische publicatie op Zenodo en spellingscontrole. Die falende testen zijn trouwens een technisch issue i.v.m. die testomgeving: de check op zich werkt wel, maar niet online in een Linux-omgeving, of toch niet zolang m'n poging tot oplossing ervoor niet in de main zit.)

[leymanan]

@leymanan De documentatie is intussen ook in orde, en ik zie niet meer direct inhoudelijke issues die nog opgelost moeten worden, dus wat mij betreft, zou alles voor u in orde moeten zijn om te reviewen. Bekijk je hierbij evt. ook nog even de vragen die ik hier gesteld heb? Het gaat vooral over wat al dan niet handig is voor u, dus geef gerust aan als de huidige situatie hier nog verbeterd moet worden.

(Zelf ga ik ondertussen nog even naar de machinerie kijken, en evt. wat details zoals de automatische publicatie op Zenodo en spellingscontrole. Die falende testen zijn trouwens een technisch issue i.v.m. die testomgeving: de check op zich werkt wel, maar niet online in een Linux-omgeving, of toch niet zolang m'n poging tot oplossing ervoor niet in de main zit.)

OK, bedankt! Ben nu ook even met iets anders bezig geweest, maar vanaf maandag ben ik er een weekje voltijds mee bezig (hoop ik).

[leymanan]

Ik lees hier wel dat afgesproken is om enkel de punten boven 0.5 m mee te nemen (dat had ik bij het stellen van mijn vraag over het hoofd gezien, alweer een hele tijd geleden dat ik dat ingebouwd heb), dus dat lost wel al een groot deel van mijn vraag/bezorgdheid op: de scope gaat sowieso boven 0.5 m zijn.

Els, is dat al geïmplementeerd? Want als ik nu de afgeleide functies fit, zie ik bv. bij Aerdshouw - beuk: daar zijn wel alle metingen < 0.5 m mee genomen om een curve te fitten (maar 8 metingen met dbh > 0.5m) Heb net gepulld en opnieuw package gebuild ...

[leymanan]

Kan je eventueel ook de functie validatie.uitbreidingmee opnemen in Hoofdscript.Rmd?

[ElsLommelen]

Kan je eventueel ook de functie validatie.uitbreidingmee opnemen in Hoofdscript.Rmd?

Euh, die heb ik daar toch in opgenomen? Ben jij met de laatste versie van deze branch bezig?

[leymanan]

• validatie.uitbreiding() verwacht als input de gegevens voor 1 modeltype (Basis of Lokaal), terwijl je bij outputIVANHO() meerdere modeltypen (Basis, Afgeleid en Lokaal) samen kan invoeren en het resultaat in 1 tabel krijgen. Als je dit laatste wil doen voor meerdere modeltypen samen, dan ga je wel voor je argument Uitbreiding de resultaten van meerdere runs van validatie.uitbreiding() moeten samenplakken. outputIVANHO() apart runnen voor Basismodellen en Afgeleide modellen enerzijds, en Lokale modellen anderzijds, is uiteraard ook een optie. (Als je de gegevens per boomsoort verwerkt, zit je eigenlijk altijd in die situatie.) Hier is mijn vraag: kan je hiermee verder, of zou het beter zijn dat je bij validatie.uitbreiding() basismodellen en lokale modellen naast elkaar kan invoeren? Dit laatste heeft uiteraard wel het gevolg dat de invoer ingewikkelder wordt (nu heb je 1 model en 1 dataset, en wat andere argumenten, dan worden het 2 modellen en 2 datasets en dezelfde argumenten).

Het is goed zoals het nu is, afzonderlijk voor basismodel en lokaalmodel. Enige dat eventueel handig zou zijn, is dat de naam van de output (nu Validatie_Uitbreiding.html) het gechekte model zou bevatten: dus Validatie_Uitbreiding_Lokaalmodel.html en Validatie_Uitbreiding_basismodel.html. Maar is een detailke! Dat kan ik zelf ook manueel doen!! Dus enkel implementeren wanneer dat echt maar max 5 à 10 minuutjes werk vraagt!!

[leymanan]

• Wat met het dhcurvesrapport()? Ik heb hier nog niks aan aangepast, wat als gevolg heeft dat het gewoon de ingevoerde gegevens uitvoert: voeg je de extra gegevens toe, dan worden die mee weergegeven, en als je ze vooraf uitfiltert met filter(VoorModelFit), dan worden enkel de ingevoerde gegevens meegegeven. Gemakkelijk en flexibel. Of zou je hierin graag extra opties zien, zoals een optie om de gegevens van de uitbreiding in een andere kleur weer te geven?

Mocht dat niet veel extra werk zijn, zou dat wel heel handig zijn, die optie om gegevens van de uitbreiding in een andere kleur te zien. Op dit moment kan ik aan niks anders denken. Is inderdaad een straight forward functie ;-)

[leymanan]

deze morgen toch gepulled en gebuild

[ElsLommelen]

Enige dat eventueel handig zou zijn, is dat de naam van de output (nu Validatie_Uitbreiding.html) het gechekte model zou bevatten: dus Validatie_Uitbreiding_Lokaalmodel.html en Validatie_Uitbreiding_basismodel.html.

Zou in orde moeten zijn nu.

[ElsLommelen]

• Wat met het dhcurvesrapport()? Ik heb hier nog niks aan aangepast, wat als gevolg heeft dat het gewoon de ingevoerde gegevens uitvoert: voeg je de extra gegevens toe, dan worden die mee weergegeven, en als je ze vooraf uitfiltert met filter(VoorModelFit), dan worden enkel de ingevoerde gegevens meegegeven. Gemakkelijk en flexibel. Of zou je hierin graag extra opties zien, zoals een optie om de gegevens van de uitbreiding in een andere kleur weer te geven?

Mocht dat niet veel extra werk zijn, zou dat wel heel handig zijn, die optie om gegevens van de uitbreiding in een andere kleur te zien.

Voila, dat is ingebouwd, je moet wel expliciet aangeven als je die uitbreiding in een andere kleur wil (en het zijn enkel de gebruikte metingen). Laat maar weten of het ok is zoals ik het ingebouwd heb.

[ElsLommelen]

Ok, bij deze is het wat mij betreft afgerond, dus laat maar weten als alles goedgekeurd is en de nieuwe versie gepubliceerd mag worden.

[leymanan]

OK, bedankt! Ik hoop er eind volgende week ook mee klaar te zijn (met de controles van de uitbreidingen). Ik zal dan ook nog eens de documentatie doornemen. Ik hou je op de hoogte!

[ElsLommelen]

Ter info: ik heb bij enkele andere functies dezelfde truc toegepast als bij GoedgekeurdeUitbreidingen in validatie.uitbreiding() om te vermijden dat daar gelijkaardige problemen als beschreven in issue #76 zouden kunnen optreden. Dit zou geen invloed mogen hebben op je code, maar dus best toch even de nieuwste versie installeren vooraleer je verder test (of dit na afsluiten of voor opstarten even doen).

[ElsLommelen]

Bedankt om dit nog eens allemaal na te lezen! En ja hoor, die 'approve' had je mogen aanvinken, dat is enkel om aan te geven dat je akkoord bent dat het gemerged wordt (en je doet hiermee geen merge). Hier heb ik dat niet als vereiste opgegeven, maar in sommige packages is het nodig dat er zo een 'approval' is (of meerdere, bv. 2) vooraleer de branch gemerged kan worden (net zoals ik het hier zo ingesteld heb dat alle testen moeten slagen voor ik kan mergen).

Dus de 3 opties zijn als volgt:

• approval: je geeft expliciet toestemming om te mergen (dit doe je dus als alles voor u in orde is, maar kan je dus ook al doen als je nog enkele kleine suggesties gegeven hebt die te nemen of te laten zijn)
• comment: gewoon een commentaar, zonder gevolgen (kan je doen als je nog niet helemaal akkoord bent maar ook niet te ampetant wil doen of het aan anderen wil laten om evt. een approval te geven)
• 'request changes': da's inderdaad ene harde, want dan ga jij achteraf expliciet nog een 'approval' moeten geven vooraleer er gemerged kan worden, zelfs al hebben meerdere andere personen al een approval gegeven. Dus hiermee kan je echt een merge tegenhouden (misschien wel enkel als een approval als voorwaarde gesteld is voor een merge?).

Enfin, ik wacht nog even af tot de testen gepasseerd zijn, en dan wordt versie 0.2 officieel gepubliceerd. :-)