uitbreiding naar lagere omtrekklasses: hoe?

[leymanan]

Els, hoe heb je dan uiteindelijk de uitbreiding naar de lagere omtrekklasses aangepakt? Ik lees daar dit over in de handleiding: De functie outputIVANHO() geeft hoogteschattingen voor de “bruikbare” omtrekklassen, dus de omtrekklassen binnen het bruikbaar interval of net erbuiten (van 3 omtrekklassen onder tot 2 omtrekklassen boven het bruikbaar interval).

ik lees in de code van hoogteschatting.basis()

filter(
      .data$y >= (100 * .data$Q5k) - 31,
      .data$y <= (100 * .data$Q95k) + 21
    )

Maar ik lees ook op het einde van OutputIVANHO() het volgende filter(.data$Hoogte >= 2.5)

Wellicht heeft dat voor volgend probleem gezorgd (klopt toch, hé?) Bedoeling is toch om de minimumhoogte in te stellen op 2.5m, niet om de omtrekklasses waar de hoogte onder de 2.5m duikt, te verwijderen uit de output?

Wat ik opmerkte: Ik verwachtte dat er steeds 3 omtrekklasses naar beneden extra meegenomen zouden worden, maar als ik mijn oude output vergelijk met de nieuwe output, zie ik dat er bij de basismodellen soms 3 klasses meer zijn, maar soms ook 0, 1 of 2 (terwijl er wel nog ruimte is) En ook dat de uitbreiding soms tot 0.25 gaat, en soms tot 0.15 (terwijl er maar 1 of 2 extra omtrekklasses meegenomen zijn).

Dat kon misschien te maken, hebben met feit dat ik wat metingen afgekeurd heb, maar het gaat wel over veel domein-bms-combinaties (+/- 117 van de 475 basismodellen die een uitbreiding van minder dan 3 klasses hebben tot hoger dan 0.15). 108 daarvan gaan tot 0.25. Dus misschien heb ik toch ergens iets gemist? Wordt er toch ergens een minimum van 0.25 ingesteld, onder bepaalde vwdes?

Uit hoogteschatting.afgeleid() leid ik af dat er daar géén beperking zit op de uitbreiding (behalve uiteraard de grenzen van het Vlaamse model). Daar zie ik dat de uitbreiding maximaal tot 0.25 gaat, nooit tot 0.15. maar soms ook maar tot bv. 0.75, met maar 2 klasses uitbreiding. Van in totaal 653 modellen, zijn er 223 modellen die maar uitbreiden tot 0.35 of 0.55 of ... (dus niet tot 0.25)

Wat betreft de 0.25 bij afgeleide modellen, ik had gevraagd 0.2, dus dat kon 0.15 of 0.25 zijn, dat is OK (tenzij mocht dat héél snel aangepast zijn naar 0.15) zie https://github.com/inbo/dhcurve/pull/67#issuecomment-1181503914

[leymanan]

Wat betreft de 0.25 bij afgeleide modellen, ik had gevraagd 0.2, dus dat kon 0.15 of 0.25 zijn, dat is OK (tenzij mocht dat héél snel aangepast zijn naar 0.15) zie #67 (comment)

laat dat maar zo, heeft te maken met functie Initiatie nTeDun = sum(.data$C13 < 20),

We gaan dat nu niet meer veranderen, is al lang geleden afgesproken. Ook hier weet je nooit welk modellen dan niet meer OK zijn en zo ...

[ElsLommelen]

Euh, hier kunnen verschillende zaken spelen:

1. die uitbreiding naar beneden wordt bepaald door het begin van het bruikbaar interval (Q5k) min 3 omtrekklassen, dus misschien is in een aantal gevallen Q5k hoger dan 0,5 m?
2. ondanks dat er een rapport gemaakt wordt dat metingen onder 0,2 m omtrek weggooit, zie ik nergens in initiatie() staan dat deze metingen effectief weggegooid worden, maar dit was in de vorige versie van dhcurve ook al zo (ik heb in de PR gecheckt, en die code is nergens weggevallen). Dus dit zou ook de variatie kunnen bepalen, laat gerust weten als die filtering wel effectief toegevoegd moet worden, want dat was wel de afspraak.
3. bij de berekeningen zelf (bij hoogteschatting vermoed ik) wordt er sowieso wel voor gezorgd dat de minimale omtrekklasse 0.15 is, dus resultaten voor lagere omtrekklassen zou je niet mogen krijgen

Bedoeling is toch om de minimumhoogte in te stellen op 2.5m, niet om de omtrekklasses waar de hoogte onder de 2.5m duikt, te verwijderen uit de output?

Dit is de enige manier waarop die hoogte op een verantwoorde manier kan verwijderd worden, vrees ik. Als je bij voorbaat alle metingen met hoogte onder 2,5 m zou verwijderen, maar andere metingen van dezelfde omtrekklasse zou behouden, dan krijg je een vertekend resultaat doordat je een deel van de metingen van die omtrekklasse negeert (en dat net in de laagste omtrekklasse, dus die omtrekklasse die het meest invloed heeft op de vorm van de curve). Een alternatief zou kunnen zijn om alle metingen bij voorbaat weg te gooien van de omtrekklasse waarin er een meting met hoogte lager dan 2,5 m zit, maar zonder eerst te valideren is dit toch een risico: wat bv. als het een typfout was en het eigenlijk om een boom van 25 m ging? Dan gooi je een volledige omtrekklasse ergens in het midden van je curve weg. Dus de beste optie is in elk geval om die boom gewoon mee te nemen tijdens de validatiestappen, en daar op basis van de concrete situatie (afwijkende meting of niet) te bepalen wat ermee moet gebeuren. Enfin, ik weet niet meer precies hoe het destijds geformuleerd is toen we de methode uitdachten (het is sowieso ter sprake gekomen, herinner ik me), maar in elk geval zorgt het verwijderen van enkel die hoogtes voor een vertekening van je resultaat.

En voor afwijkende gegevens: daar worden alle metingen onder 0,5 m weggegooid, dus daar gaat de uitbreiding inderdaad nooit verder gaan dan 0,25 m, maar net zoals bij de andere modellen is dit afhankelijk van de minimale omtrekklasse waarvoor er metingen zijn (en ook van het Vlaams model, maar ik verwacht dat dit meestal niet de beperkende factor is).

[ElsLommelen]

laat dat maar zo, heeft te maken met functie Initiatie nTeDun = sum(.data$C13 < 20),

We gaan dat nu niet meer veranderen, is al lang geleden afgesproken. Ook hier weet je nooit welk modellen dan niet meer OK zijn en zo ...

Nee, dit is enkel om dat rapport te maken, door een vergetelheid worden die kleine omtrekklassen blijkbaar toch niet weggegooid. Maar een kleintje om dat toch even aan te passen, dat lost waarschijnlijk ook deels het probleem op van die 2,5 m, en zorgt misschien ook voor minder variatie in de minimale omtrekklasse?

[ElsLommelen]

2. ondanks dat er een rapport gemaakt wordt dat metingen onder 0,2 m omtrek weggooit, zie ik nergens in initiatie() staan dat deze metingen effectief weggegooid worden, maar dit was in de vorige versie van dhcurve ook al zo (ik heb in de PR gecheckt, en die code is nergens weggevallen). Dus dit zou ook de variatie kunnen bepalen, laat gerust weten als die filtering wel effectief toegevoegd moet worden, want dat was wel de afspraak.

Oeps, sorry, hier heb ik iets over het hoofd gezien: Q5k kan minimum 0,25 zijn, dus dat komt op hetzelfde neer dat de metingen minimum 0,2 m omtrek moeten hebben...

[leymanan]

1. die uitbreiding naar beneden wordt bepaald door het begin van het bruikbaar interval (Q5k) min 3 omtrekklassen, dus misschien is in een aantal gevallen Q5k hoger dan 0,5 m?

jaja, dat is logisch, dat bedoel ik niet!

[leymanan]

Bedoeling is toch om de minimumhoogte in te stellen op 2.5m, niet om de omtrekklasses waar de hoogte onder de 2.5m duikt, te verwijderen uit de output?

Dit is de enige manier waarop die hoogte op een verantwoorde manier kan verwijderd worden, vrees ik. Als je bij voorbaat alle metingen met hoogte onder 2,5 m zou verwijderen, maar andere metingen van dezelfde omtrekklasse zou behouden, dan krijg je een vertekend resultaat doordat je een deel van de metingen van die omtrekklasse negeert (en dat net in de laagste omtrekklasse, dus die omtrekklasse die het meest invloed heeft op de vorm van de curve)

Denk dat je me verkeerd begrijpt. Ik zeg niet dat hoogtes verwijderd worden of moeten verwijderd worden. Ik zeg dat bij outputIVANHO de omtrekklasses met een voorspelde hoogte < 2.5m verwijderd worden in de output. En dat ik dacht dat we - net zoals we de hoogte niet terug laten stijgen bij holle curves - we als minimale hoogte 2.5m gingen nemen.

[leymanan]

2. ondanks dat er een rapport gemaakt wordt dat metingen onder 0,2 m omtrek weggooit, zie ik nergens in initiatie() staan dat deze metingen effectief weggegooid worden, maar dit was in de vorige versie van dhcurve ook al zo (ik heb in de PR gecheckt, en die code is nergens weggevallen). Dus dit zou ook de variatie kunnen bepalen, laat gerust weten als die filtering wel effectief toegevoegd moet worden, want dat was wel de afspraak.

Oeps, sorry, hier heb ik iets over het hoofd gezien: Q5k kan minimum 0,25 zijn, dus dat komt op hetzelfde neer dat de metingen minimum 0,2 m omtrek moeten hebben...

Ik lees daar ook dat Q95k maximaal 2.35 is? Moet dat niet aangepast worden naar 3? Of wordt Q5k en Q95k niet enkel nog gebruikt om RMSE te berekenen?

[ElsLommelen]

Denk dat je me verkeerd begrijpt. Ik zeg niet dat hoogtes verwijderd worden of moeten verwijderd worden. Ik zeg dat bij outputIVANHO de omtrekklasses met een voorspelde hoogte < 2.5m verwijderd worden in de output. En dat ik dacht dat we - net zoals we de hoogte niet terug laten stijgen bij holle curves - we als minimale hoogte 2.5m gingen nemen.

Ah, nee, dat had ik issue #73 inderdaad verkeerd begrepen, ik dacht dat je net zoals je bij bolle curves het maximum wou doortrekken, hier het minimum wou doortrekken i.p.v. terug stijgen bij die lage omtrekklassen. Ik check hier niet of dit minimum onder die 2.5 m komt. Dus bij een minimum onder 2,5 m moet ik in dit geval overal 2,5 m van maken?

[ElsLommelen]

Ik lees daar ook dat Q95k maximaal 2.35 is? Moet dat niet aangepast worden naar 3? Of wordt Q5k en Q95k niet enkel nog gebruikt om RMSE te berekenen?

Q95k is de bovengrens van het bruikbaar interval, wat gebruikt wordt voor de modelfit, en dat blijft gewoon gelimiteerd tot 2,35. Die 3 m gaat enkel over de metingen die we gebruiken voor de validatie van het model ter hoogte van de uitbreiding, niet om de modelfit zelf te doen. Aan die modelfit zelf verandert er niks, daarvoor gebruiken we nog steeds enkel de metingen van het bruikbare interval (waarvan Q95k de bovengrens is). Dus ja, die begrenzing klopt zoals ze daar staat.

[leymanan]

Ah, nee, dat had ik issue #73 inderdaad verkeerd begrepen, ik dacht dat je net zoals je bij bolle curves het maximum wou doortrekken, hier het minimum wou doortrekken i.p.v. terug stijgen bij die lage omtrekklassen. Ik check hier niet of dit minimum onder die 2.5 m komt. Dus bij een minimum onder 2,5 m moet ik in dit geval overal 2,5 m van maken?

Issue https://github.com/inbo/dhcurve/issues/73 heb je niet verkeerd begrepen, hoor, dat is OK. Maar daarnaast - bij niet holle curves - kan bv. bij 0.25m de hoogte gemodelleerd worden als 1.2m . En dat zou dan minimaal 2.5m mogen zijn.

[ElsLommelen]

Dus ik vervang inoutputIVANHO() alle gemodelleerde omtrekklassen met als resultaat een hoogte onder 2,5 m door een hoogte van 2,5 m in plaats van ze weg te laten?

[leymanan]

Dus ik vervang inoutputIVANHO() alle gemodelleerde omtrekklassen met als resultaat een hoogte onder 2,5 m door een hoogte van 2,5 m in plaats van ze weg te laten?

inderdaad

[ElsLommelen]

Ok, ingewerkt, maar wel nog een vraag: kan je me een verklaring geven die ik in de handleiding kan toevoegen ter verantwoording hiervan? Voor iemand die dit package zou willen gebruiken voor andere redenen, lijkt me dit ongewenst gedrag (dat een geschatte waarde vervangen wordt door iets anders, tenminste als je de schatting zelf zou willen is dit een nadeel).

[leymanan]

Was begonnen met tekstje op te stellen, maar dan nog eens gekeken naar over hoeveel modellen het gaat die niet tot 0.25 geëxtrapoleerd worden, en eigenlijk is dat verwaarloosbaar (en vooral populier ...) Initieel keek ik tot omtrekklasse 0.15, maar nu ik weet dat de afgeleide modellen ook maar maximum tot 0.25 gaan, heeft het weinig zin om kunstmatig de basismodellen tot die 0.15 te extrapoleren, als dat bij de afgeleide modellen sowieso niet gebeurt.

Dus je zou dat toch mogen houden zoals het eerst was (omtrekklasses met hoogte < 2.5 m verwijderen uit de output) Sorry!! Zou nu een emoji van aapje met handen voor zijn gezicht willen toevoegen.

En anders was het iets geweest in de trant van "Om de praktische bruikbaarheid te verhogen, werd op uitdrukkelijke vraag van de gebruikers een minimale hoogte van 2.5 m ingesteld. Dus eerder dan de omtrekklasses met een te lage hoogteschatting (<2.5 m) te verwijderen, werd standaard een hoogte van 2.5m toegekend aan die omtrekklasses."

[ElsLommelen]

Ok, geen probleem, dan pas ik het terug aan (maar ik ga misschien toch wel even iets in de documentatie laten hangen over die geschrapte records). ;-)