circular plots versus core areas

[leymanan]

een bedenking: mbv create_statistics kunnen we een gemiddeld volume berekenen voor een bepaald bosreservaat. Input daarvoor zijn idealiter de cirkelplots, daar zullen we geen kernvlakte bij betrekken. Idem dito als we meer algemene uitspraken willen doen over onbeheerde bossen (bv. gemiddeld aantal soorten in een onbeheerd bos, per bodemtype). Ook hier bestaat de input enkel uit cirkelplots.

Kernvlaktes worden helemaal anders benaderd: daar wordt gekeken wat ruimtelijke spreiding is van de verjonging, de vegetatie, .... in relatie tot bv. aanwezige boomsoorten, bodemtoestand, .... (ik moet toegeven, dat we daar nog niet zover in staan, in de échte verwerking van de kernvlaktes, blijft tot op dit moment meer exemplarisch).

We gaan ook nooit statistieken berekenen op CP's en CA's samen.

Eigenlijk is de functie create_statistics vooral bedoeld voor de cirkelplots en niet voor de kernvlaktes. Dus misschien is het een idee om plottype als extra inputvariabele toe te voegen, met plottype = 20 (CP) als default?

Wat denk je?

[ElsLommelen]

Euh, qua workflow lijkt het me minder logisch dat een gebruiker alle gegevens zou inladen, evt. een eerste verwerking doen en dan bij de analyse ineens beslissen om ze toch niet allemaal te gebruiken. De meeste functies van het package hebben de mogelijkheid om functies te filteren op plottype, en het filteren van gegevens met dplyr is niet zo moeilijk, dus het lijkt me wat overbodig.

Ander tegenargument: voor de functie create_statistics() kiest de gebruiker nu volledig zelf welke gegevens hij invoert (dit moeten zelfs niet eens bosreservaten zijn), enige voorwaarde is dat de dataframe de velden 'year' en 'period' bevat (waarop gegroepeerd wordt). Ik heb het gevoel dat je door plottype = 20 toe te voegen, de flexibiliteit van die functie voor de gebruiker inperkt: hij wordt niet alleen verplicht om een variabele plottype in z'n data te hebben, maar hij kan ook maar 1 plottype per keer analyseren (wat ingeval van de bosreservaten logisch is, maar voor andere databanken misschien niet?).

Naar aanleiding van je vraag en mijn eerste alinea maakte ik me wel de bedenking dat het mss wel interessant zou zijn om die optie van plottype wel in read_git toe te voegen. Dan kan deze selectie voor plottype telkens gemaakt worden bij het inladen van gegevens: bij de load-functies voor de ruwe Fieldmap-gegevens en bij read_git voor de geaggregeerde forresdat-gegevens. Anderzijds heb je in dat geval ook wel het nadeel dat read_git() databankspecifiek wordt... Eventueel op te lossen door een wrapper read_forresdat() te maken die specifieke functionaliteit heeft voor de bosreservaten?

Tot daar mijn extra bedenkingen om over na te denken. ;-)

[leymanan]

ja, moet inderdaad niet in create_statistics opgenomen worden.

Voor mezelf vind ik dat ook totaal overbodig, maar ik probeer me een beetje in te denken hoe Kris gaat werken. Die zal over alle cirkelplots heen iets willen weten, en zal dan uit git (of access) de reeds berekende data halen (waar CP en KV samen in zitten) ...

Ik heb het toch goed op dat het de bedoeling is dat alles wat berekend wordt met de functies calculate_dendro/reg/veg in git opgeslagen wordt? Resultaten van create statistics niet, en "ruwe" data (results van load_data) ook niet. Dat klopt toch, hé?

Je voorstel om plottype toe te voegen in read_git lijkt me goed idee. Dat deze dan databankspecifiek wordt, daar heb ik minder problemen mee. Sowieso is het ganse package toch vrij databank specifiek, niet? Maar read_forresdat is even goede oplossing voor mij!

Op di 12 mei 2020 om 16:19 schreef ElsLommelen notifications@github.com:

Euh, qua workflow lijkt het me minder logisch dat een gebruiker alle gegevens zou inladen, evt. een eerste verwerking doen en dan bij de analyse ineens beslissen om ze toch niet allemaal te gebruiken. De meeste functies van het package hebben de mogelijkheid om functies te filteren op plottype, en het filteren van gegevens met dplyr is niet zo moeilijk, dus het lijkt me wat overbodig.

Ander tegenargument: voor de functie create_statistics() kiest de gebruiker nu volledig zelf welke gegevens hij invoert (dit moeten zelfs niet eens bosreservaten zijn), enige voorwaarde is dat de dataframe de velden 'year' en 'period' bevat (waarop gegroepeerd wordt). Ik heb het gevoel dat je door plottype = 20 toe te voegen, de flexibiliteit van die functie voor de gebruiker inperkt: hij wordt niet alleen verplicht om een variabele plottype in z'n data te hebben, maar hij kan ook maar 1 plottype per keer analyseren (wat ingeval van de bosreservaten logisch is, maar voor andere databanken misschien niet?).

Naar aanleiding van je vraag en mijn eerste alinea maakte ik me wel de bedenking dat het mss wel interessant zou zijn om die optie van plottype wel in read_git toe te voegen. Dan kan deze selectie voor plottype telkens gemaakt worden bij het inladen van gegevens: bij de load-functies voor de ruwe Fieldmap-gegevens en bij read_git voor de geaggregeerde forresdat-gegevens. Anderzijds heb je in dat geval ook wel het nadeel dat read_git() databankspecifiek wordt... Eventueel op te lossen door een wrapper read_forresdat() te maken die specifieke functionaliteit heeft voor de bosreservaten?

Tot daar mijn extra bedenkingen om over na te denken. ;-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/inbo/forrescalc/issues/20#issuecomment-627375673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKXN5HE2WK4WA4NXA4Y5FDRRFLIRANCNFSM4M62PRWQ .

--

Anja Leyman

Expert Cel Beheerplanning en Monitoring

---

Ik werk tijdelijk deeltijds (maandag, dinsdag en donderdag).

Mails die mij op een andere dag bereiken, komen in de wachtrij. Sorry hiervoor.

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

Vlaamse overheid

AGENTSCHAP NATUUR & BOS

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

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

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

[ElsLommelen]

ja, inderdaad, klopt zoals je het zegt: alles van die calculate-functies komt in git, evt. m.u.v. de _diff-functies.

Inderdaad, het hele package is vrij databankspecifiek, maar de functie create_statistics zou evt. misbruikt kunnen worden voor andere doeleinden. ;-)

Ok, ik bekijk morgen om dat plottype toe te voegen in read_git.

[ElsLommelen]

Ervan uitgaande dat dit idee nog altijd gewenst is: geef ik aan het nieuwe argument plottype voor read_forresdat() standaard een waarde mee, of niet? Moet er evt. ook een optie zijn om beiden op te vragen? (In dit geval zou ik dit als standaardwaarde meegeven, in het andere geval zou ik enkel een default opgeven als je verwacht dat een van de types veel vaker gebruikt gaat worden.)

[leymanan]

standaard cirkelplots indien mogelijk

[ElsLommelen]

Misschien eerst issue #75 oplossen, of toch minstens voor de benaming van plottype... Is er eigenlijk al een knoop doorgehakt over de benamingen? Gebruik ik Value2 uit qPlotType, of afkortingen? We hebben dit vrij uitgebreid bediscussieerd in #74 (best de argumenten nog eens bekijken), maar de beslissing is uitgesteld. Evt. kan ik voorlopig de code te ontwikkelen op basis van Value2 uit qPlotType. Als er uiteindelijk beslist wordt om toch afkortingen te gebruiken en als deze in FM gezet worden, dan moet in de code enkel in de queries qPlotType.Value2 vervangen worden door qPlotType.Value3.

[leymanan]

Nog klein vraagje: als we géén afkortingen gebruiken, maar factors (en plottype voluit ), moeten we deze in de code dan steeds ook voluit typen? Of kunnen we daar ook met de codes van de factors werken? En zo ja, kunnen deze codes dan op 20 en 30 geplaatst worden?

Indien niet, dan zou ik toch gaan voor afkortingen, die ik dan inderdaad in qValue3 zal plaatsen. Deze dan misschien ook gebruiken als argument in de functies? Value2 dan vervangen door Value3

check_input(plottype, database, "qPlotType", "Value2")

[leymanan]

Value3 NAV CP CA POLYG VEG BIO OTHER

[leymanan]

Package wel enkel ontworpen voor CP en CA, dus ik weet niet of we dan de andere afkortingen mee moeten nemen? (in de veronderstelling dat we er ene factor van zouden maken)

[ElsLommelen]

Nog klein vraagje: als we géén afkortingen gebruiken, maar factors (en plottype voluit ), moeten we deze in de code dan steeds ook voluit typen? Of kunnen we daar ook met de codes van de factors werken? En zo ja, kunnen deze codes dan op 20 en 30 geplaatst worden?

Ja, dat was inderdaad het idee, al merk ik nu dat een factor bij afwezigheid van tussenliggende waarden de achterliggende codes omzet naar 1 en 2. Maar ik zal even checken of er geen andere methode is om dit te realiseren (die compatibel is met git2rdata, anders hebben we er nog niks aan).

Package wel enkel ontworpen voor CP en CA, dus ik weet niet of we dan de andere afkortingen mee moeten nemen? (in de veronderstelling dat we er ene factor van zouden maken)

Evt. kan ik enkel de afkortingen meenemen die aanwezig zijn in de dataset in kwestie. (Veiliger dan expliciet enkel CP en CA meenemen, tenzij je bij toevoegen van nieuwe plottypes in FM sowieso wil dat ze niet meegenomen worden...)

[ElsLommelen]

Ik heb alvast een oplossing gevonden die voldoet om tekst als een label aan de waarden te hangen (of omgekeerd), nl. het package labelled.

library(labelled)
testlabel <- labelled(c(30, 20, 30), c("CA" = 20, "CP" = 30))
testlabel == 30
#> [1]  TRUE FALSE  TRUE
to_character(testlabel) == "CA"
#> [1] FALSE  TRUE FALSE

^{Created on 2021-07-28 by the reprex package (v2.0.0)}

Morgen nog testen wat git2rdata ermee doet, in het slechtste geval moeten we zelf zorgen dat we het op een deftige manier opslaan en terug bovenhalen.

[leymanan]

Evt. kan ik enkel de afkortingen meenemen die aanwezig zijn in de dataset in kwestie. (Veiliger dan expliciet enkel CP en CA meenemen, tenzij je bij toevoegen van nieuwe plottypes in FM sowieso wil dat ze niet meegenomen worden...)

Ja, dat lijkt me beste

[leymanan]

Misschien is het gewoon het simpelste en makkelijkste om voor CP en CA te gaan, en dat voluit geschrevene vergeten ...

[ElsLommelen]

Dat is het gemakkelijkste voor diegenen die vertrouwd zijn met de afkortingen, maar het verplicht anderen wel om in de documentatie te gaan opzoeken waar het over gaat (tenzij het in jullie studiegebied courant gebruikte afkortingen zijn die iedereen kent). Al ga je door standaard enkel cirkelplots te geven, er wel voor zorgen dat ze jullie belangrijkste dataset krijgen, waardoor ze pas in de documentatie moeten duiken als ze iets anders willen. En met read_forresdat() in gedachten als functie waarmee ze de data ophalen, kan de vermelding van de volledige naam in de help van de functie voldoende zijn.

Dus dan doe ik die CP/CA als labels, of is het in dat geval niet nodig om de id's te bewaren?

[leymanan]

geen courant gebruikte afkortingen denk ik. Als we met CP en CA werken, dan is die 20 en 30 niet nodig. Was meer om te vermijden dat ik telkens circular plot en core area voluit moet typen ;-)

Dus CP/CA , 20/30 moet niet bijgehouden worden

[ElsLommelen]

standaard cirkelplots indien mogelijk

Dit is mogelijk als join_plotinfo = TRUE (wat standaard is in read_forresdat()), in het andere geval is er geen kolom plotinfo aanwezig in de opgehaalde dataset.

[leymanan]

geen kolom plotinfo aanwezig in de opgehaalde dataset.

geen kolom plottypebedoel je toch?

[ElsLommelen]

Ja, inderdaad, plottype. Is het ok als dat enkel kan bij join_plotinfo = TRUE, en dat ik in het andere geval bv. een warning geef dat het plottype niet uitgesorteerd is? Of zorg ik er toch liefst voor dat het altijd kan? (Op 't eerste zicht zie ik 2 mogelijkheden: ofwel toch die kolom plotinfo joinen om de info i.v.m. plottype eruit te halen, of meer ingrijpend: plottype toevoegen aan alle tabellen van forresdat. Uiteraard zou ik in dit geval voor de eerste mogelijkheid gaan. En op zich is dat niet zoveel extra werk, dus laat gerust weten als je graag hebt dat ik dit zo oplos. Grootste nadeel is dat de functie bij zeer grote scripts trager zou kunnen zijn: je moet een tweede dataset binnenhalen, en de join doen. En waarschijnlijk gaat het vooral om die reden zijn dat een gebruiker voor join_plotinfo = FALSE gaat kiezen: om niet te lang moeten wachten bij een zeer grote dataset. Dus door die dataset dan alsnog te koppelen omwille van de plotinfo, gaan we de gebruiker die mogelijkheid ontnemen. Dus het mss best bij die warning houden?)