? maximale hoogte uitbreiding

[leymanan]

Els, ik vroeg me af of er een mogelijkheid zou zijn, om - nalv validatie uitbreiding - een maximale hoogte in te geven voor modellen die te steil blijken te zijn?

Bv. in onderstaande grafiek: hoogte maximaal 32 m

Want eigenlijk is er enkel bij de laatste twee omtrekklasses een kleine overschatting. Dat is geen reden om de volledige uitbreiding af te keuren, maar zou iets correcter zijn, mochten we dat kunnen aftoppen. En in sommige gevallen gaat dat nog extremer zijn. En dan is het fijn om niet de volledige uitbreiding te moeten afkeuren.

[ElsLommelen]

Euh, theoretisch kan dit uiteraard allemaal, maar ik heb wel het gevoel dat we over uitzonderingen van uitzonderingen aan het spreken zijn, en we uiteindelijk gewoon lapmiddeltjes aan het zoeken zijn die voor enkele gevallen een oplossing kunnen zijn. Toevallig is dit wel een model waarin de uitbreiding zeer lang is omdat er te weinig metingen van dikke bomen zijn om het model te fitten tot een omtrek van 0.3 m, dus misschien moeten we de uitbreiding beperken tot max x omtrekklassen uitbreiding, maar dan is weer de vraag: hoeveel mag x zijn? Of komt dit probleem vaak voor, en kan je een waarde geven voor x?

Ik denk trouwens dat je met de bestaande tools en/of wat gezond verstand ook zelf tot een oplossing kan komen als dit een alleenstaand geval is:

• de ideale oplossing zou uiteraard zijn om het aantal metingen voor de omtrekklassen tussen 1.45 (?) en 2.3 m wat uit te breiden (en dat moeten waarschijnlijk maar een beperkt aantal metingen zijn), zodat het model gefit zal worden tot een iets hogere omtrekklasse, met hopelijk een iets beter model voor die hogere omtrekklassen (al lijkt het eigenlijk nog niet zo slecht als ik als niet-bosbouwer naar de puntjes kijk)
• je mag uiteraard ook zelf een beslissing nemen om individuele curves toch te kunnen gebruiken tot waar ze ok zijn. Aftoppen in de zin van zelf de hogere waarden aanpassen zou ik niet doen, maar hier zou je bv. kunnen kiezen om het model maar te gaan gebruiken tot een bepaalde omtrekklasse. Bijvoorbeeld:
  • je kan in de uitvoer van validatie.uitgebreid() de waarde van OmtrekMax aanpassen vooraleer je dit invoert in outputIVANHO()
  • je kan voor de hele berekening (dus voor initiatie()) de 2 metingen met hoogste omtrekklassen weglaten, waardoor er vanzelf 5 omtrekklassen wegvallen

Laat gerust weten als ik ervoor moet zorgen dat een uitbreiding maximum x omtrekklassen lang mag zijn, dit lijkt me nog wel een zinvolle aanpassing. Aftoppen tot een bepaalde hoogte lijkt me minder toepasbaar, vooral omdat alle curves anders zijn en je hiervoor maatwerk nodig hebt.

[leymanan]

• je kan in de uitvoer van validatie.uitgebreid() de waarde van OmtrekMax aanpassen vooraleer je dit invoert in outputIVANHO()

dat was iets dat ik nog niet door had, dat dat kon. Daar kan ik al een stuk verder mee! Dan geen behoefte aan extra functionaliteit dat "uitbreiding maximum x omtrekklassen lang mag zijn", want dat kan ik dan zelf bepalen.

[leymanan]

Euh, theoretisch kan dit uiteraard allemaal, maar ik heb wel het gevoel dat we over uitzonderingen van uitzonderingen aan het spreken zijn, en we uiteindelijk gewoon lapmiddeltjes aan het zoeken zijn die voor enkele gevallen een oplossing kunnen zijn.

Het is verre van een alleenstaand geval, is iets dat vrij veel voorkomt. Niet noodzakelijk dat er zover geëxtrapoleerd wordt, maar wel dat ik denk dat aftoppen handig zou zijn ...

Maar het leidt ons inderdaad misschien te ver, en is ook steeds maatwerk zoals je zegt: model per model (van deze met hoge afwijking) een visuele (en dus subjectieve) inschatting van welke hoogte we als maximum willen gebruiken. Dit dan ingeven in mijn hulpdatabank en eventueel gebruiken in de functie outputIVANHO?

Anderzijds moet ik dat sowieso doen voor MaxOmtrek: dat voer ik in de hulpdatabank in (per model) en dan gebruik ik dat om de dataframe Uitbreiding aan te passen, vooraleer ik deze gebruik in de functie outputIVANHO. Dus voor mij zou het niet veel moeite zijn om een extra veld MaxHoogte toe te voegen, en in te vullen. En dat dan toevoegen aan de dataframe Uitbreiding en zo in de functie outputIVANHO.

al lijkt het eigenlijk nog niet zo slecht als ik als niet-bosbouwer naar de puntjes kijk Deze grafiek ziet er inderdaad nog vrij goed uit, was een vb. Er zijn er veel extremere, maar daar kan ik dan wel MaxOmtrekgebruiken om extrapolatie te stoppen. En die echt extreme komen misschien minder vaak voor.

Bv

[ElsLommelen]

Klinkt allemaal te ingewikkeld, en zeker die hoogte vind ik ene gevaarlijke omdat dit zeer domein- en boomsoortafhankelijk is. Zouden we niet gewoon zeggen dat een uitbreiding maximum 10 omtrekklassen lang mag zijn, ofzo? Als ik dan naar het eerste voorbeeld kijk, dan is dat 10 omtrekklassen + de twee omtrekklassen die sowieso nog extra meegenomen worden, en dan kom je ongeveer uit bij vanaf waar het problematisch wordt, vermoed ik. Dat bespaart in elk geval dat je overal arbitrair die grens moet trekken (al kan je het uiteraard wel altijd doen, moest er een model zijn waar die 10 omtrekklassen niet acceptabel zijn). En er is wel iets te zeggen voor het feit dat je die uitbreiding niet eindeloos lang mag maken bij modellen die gefit zijn op basis van metingen die relatief laag eindigen. Als je ervan uitgaat dat een model tot 2.3 m gefit wordt, dan omvat de maximale uitbreiding tot 3 m maar 7 hoogteklassen, dus een uitbreiding van 7 omtrekklassen (+ 2 die er automatisch nog bijkomen) lijkt misschien logischer dan een uitbreiding van 10 omtrekklassen? Enfin, ik laat het aan u om te kiezen bij hoeveel omtrekklassen je de uitbreiding laat eindigen (doe dit best op basis van een aantal curves), maar dit lijkt me wel de beste benadering om dit probleem generiek aan te pakken (en vooral te mijden dat een curve verder doorgetrokken wordt dan acceptabel, want hier is de uitbreiding langer dan het gefitte model, wat ook niet de bedoeling kan zijn).

[leymanan]

Net die uitbreiding met meer dan 10 omtrekklasses is eerder uitzonderlijk, dus daar moet je je tijd niet insteken, dan zet ik er gewoon een MaxOmtrek. Want is ook echt wel domein-bms-afhankelijk.

En als je die max hoogte niet ziet zitten, ook geen probleem, dan laten we het zo.

zeker die hoogte vind ik ene gevaarlijke omdat dit zeer domein- en boomsoortafhankelijk is. Ik zou dat wel per domein-bms invullen, hé? Zo'n beetje als die MaxOmtrek, wanneer ik zie dat de curve beter niet te ver uitgebreid wordt.

[ElsLommelen]

Net die uitbreiding met meer dan 10 omtrekklasses is eerder uitzonderlijk, dus daar moet je je tijd niet insteken, dan zet ik er gewoon een MaxOmtrek. Want is ook echt wel domein-bms-afhankelijk.

Zorgen dat er maar maximum 7 of 10 omtrekklassen meegenomen worden voor de uitbreiding, is een zeer kleine aanpassing in functie initiatie(), en dat lijkt me een relevante 'beveiliging' tegen het te ver uitbreiden van een functie, misschien zelfs relevanter dan het absolute maximum beperken tot 3 m omtrek? Dus geen probleem om dit even te doen.

Max hoogte inbouwen is iets complexer en meer werk (per domein-bms-combinatie; dit kan pas na de berekeningen gebeuren, dus niet samen met MaxOmtrek; extra invoer van de gebruiker vraagt extra validatie en documentatie,...)

[leymanan]

Max hoogte inbouwen is iets complexer en meer werk (per domein-bms-combinatie; dit kan pas na de berekeningen gebeuren, dus niet samen met MaxOmtrek; extra invoer van de gebruiker vraagt extra validatie en documentatie,...)

Ik zou dat inderdaad niet standaardiseren, maar mijn idee was een veld MaxHoogte toe te voegen aan Utbreiding(naast MaxOmtrek) dat initieel NA is, maar kan ingevuld worden indien ik dat nodig acht. In de functie OutputIVANHO, kan dan via de dataframe Uitbreiding, die MaxHoogtemeegegeven worden. Ik moet sowieso MaxOmtrekbijwerken, voor de curves waar de extrapolatie niet helemaal OK is. Dus dan is het in één beweging ook mogelijk om MaxHoogtebij te werken.

Enige minpunt is misschien wel, dat het wat natte vingerwerk is om die MaxHoogtete bepalen. Maar anderzijds is het dat ook een beetje bij die MaxOmtrek(weliswaar op andere manier)

Maar als je dat niet ziet zitten, laat het dan maar zo. Ik ga er niet moeilijk over doen.

[leymanan]

Zorgen dat er maar maximum 7 of 10 omtrekklassen meegenomen worden voor de uitbreiding, is een zeer kleine aanpassing in functie initiatie(), en dat lijkt me een relevante 'beveiliging' tegen het te ver uitbreiden van een functie, misschien zelfs relevanter dan het absolute maximum beperken tot 3 m omtrek? Dus geen probleem om dit even te doen.

Inderdaad misschien een extra beveiliging: als je dat ziet zitten, mag je dat doen voor 10 omtrekklasses.

[leymanan]

Inderdaad misschien een extra beveiliging: als je dat ziet zitten, mag je dat doen voor 10 omtrekklasses.

Net eens bekeken, en het gaat maar om 25 curves. Heb de indruk dat ik die toch zal moeten bekijken, om te zien of die niet te ver geëxtrapoleerd worden. Dus voor mij hoef je het toch niet te doen.

[ElsLommelen]

Inderdaad misschien een extra beveiliging: als je dat ziet zitten, mag je dat doen voor 10 omtrekklasses.

Net eens bekeken, en het gaat maar om 25 curves. Heb de indruk dat ik die toch zal moeten bekijken, om te zien of die niet te ver geëxtrapoleerd worden. Dus voor mij hoef je het toch niet te doen.

Euh, hier nog eens op terugkomen: normaal krijg je enkel de 20 slechtste uitbreidingen voorgeschoteld om te valideren, dus een 'redelijk goede' uitbreiding met veel extra omtrekklassen kan in principe door de mazen van het net glippen. (Misschien maak jij nu wel de keuze om ze allemaal te bekijken, maar misschien gaan we er ook best van uit dat dit ooit wel eens door iemand anders gebruikt zal worden? Sowieso is het gemakkelijker om nu eventuele gekende 'achterpoortjes' weg te werken, dan ons over een aantal jaren niet meer bewust te zijn van die achterpoortjes.)

Dus in die zin vind ik die oplossing van 10 omtrekklassen toch iets elegants om even in te bouwen (iets wat vrij weinig werk vraagt, en toch voor wel wat zekerheid zorgt voor de toekomst). Ook vraag ik me af: als we die 10 omtrekklassen uitbreiding hanteren, in hoeverre moet die grens van 3 m dan nog behouden blijven? Je gaat dan wel op 3,3 m + 2 omtrekklassen uitkomen, dus uiteindelijk gaat je model dan wel tot 3,5 m kunnen lopen in extreme gevallen (bv. Zoniën). Maar misschien is dit eerder een teken dat die 10 omtrekklassen toch aan de ruime kant is?

In dit verband toch nog even voor de zekerheid vragen: bedoel je effectief 10 omtrekklassen voor de uitbreiding zelf? Dus dan gaat je eindresultaat 12 omtrekklassen verder lopen: 10 van de uitbreiding (als er gegevens zijn in 10 omtrekklassen), en die 2 extra omtrekklassen die altijd toegevoegd worden bij het 'gebruiken' van het model (en die worden trouwens ook al in de validatierapporten toegevoegd). Dus als je in totaal 10 omtrekklassen meer wil hebben voor het eindresultaat, dan moeten er voor de validatie van de uitbreiding 8 omtrekklassen toegevoegd worden.

Enfin, denk er nog eens even over na wat je het meest ideale scenario lijkt. Met het oog op vereenvoudiging (en flexibiliteit) zou ik ingeval van het invoeren van die 10 omtrekklassen de grens van 3 m laten vallen.

[leymanan]

voor mij dan liefst toch die 10 omtrekklasses uitbreiding en 3m als max behouden. (heb snel eens gekeken en er zijn toch nogal wat metingen boven de 3m, dat gaat weer extra controle van reeds goedgekeurde curves vragen & ik vind het wel proper dat dat op di e3m afgekapt wordt, naar gebruik toe in IVANHO).

[leymanan]

Max hoogte inbouwen is iets complexer en meer werk (per domein-bms-combinatie; dit kan pas na de berekeningen gebeuren, dus niet samen met MaxOmtrek; extra invoer van de gebruiker vraagt extra validatie en documentatie,...)

Ik zou dat inderdaad niet standaardiseren, maar mijn idee was een veld MaxHoogte toe te voegen aan Utbreiding(naast MaxOmtrek) dat initieel NA is, maar kan ingevuld worden indien ik dat nodig acht. In de functie OutputIVANHO, kan dan via de dataframe Uitbreiding, die MaxHoogtemeegegeven worden. Ik moet sowieso MaxOmtrekbijwerken, voor de curves waar de extrapolatie niet helemaal OK is. Dus dan is het in één beweging ook mogelijk om MaxHoogtebij te werken.

Enige minpunt is misschien wel, dat het wat natte vingerwerk is om die MaxHoogtete bepalen. Maar anderzijds is het dat ook een beetje bij die MaxOmtrek(weliswaar op andere manier)

Maar als je dat niet ziet zitten, laat het dan maar zo. Ik ga er niet moeilijk over doen.

je was niet meer van plan zeker om die MaxHoogte nog te implementeren? Gewoon om te weten. Dan pas ik mijn code daaraan aan.

[ElsLommelen]

Nee, als dat voor u niet te lastig is...

[leymanan]

Nee, als dat voor u niet te lastig is...

neenee, geen probleem