extra argument om de locatie van output te specifiëren in de validatierapporten #45
Comments
|
ik gebruik Rmd-scripts om het package te gebruiken, en ik moet nogal wat kunstgrepen (extra code) uitvoeren om zowel bij knitr als bij aflopen van de chuncks dezelfde output-locatie (wd) te verkrijgen. |
|
Goed idee om dat toe te voegen, het kan inderdaad handig zijn om die locaties te kunnen specifiëren. Als ik je een tip mag geven in verband met die Rmd's: er bestaan tegenwoordig packages om dit soort euvels op te lossen, bv. rprojroot of here. Ze laten toe om een 'oorsprong' (bv. root van gitrepo, project of package) op te zoeken, of zelf een oorsprong voor je relatieve paths te definiëren. Bv. met rprojroot kan je de root van je git-repo opzoeken met |
|
"here" gebruik ik al regelmatig, en in dit geval
ook knitr::opts_knit$set(root.dir =
"C:/5DHcurves/02_aanmaak_dhcurves_ANB/output/").
Output is sowieso een andere locatie dan mijn wd, dus "here" and
find_root zijn daarom niet wat ik nodig heb.
Zoals gezegd: ik trek mijn plan er wel mee, maar leek me toch handig ;-)
Op ma 18 jan. 2021 om 15:51 schreef ElsLommelen <notifications@github.com>:
… Goed idee om dat toe te voegen, het kan inderdaad handig zijn om die
locaties te kunnen specifiëren.
Als ik je een tip mag geven in verband met die Rmd's: er bestaan
tegenwoordig packages om dit soort euvels op te lossen, bv. rprojroot
<https://rprojroot.r-lib.org/> of here <https://here.r-lib.org/>. Ze
laten toe om een 'oorsprong' (bv. root van gitrepo, project of package) op
te zoeken, of zelf een oorsprong voor je relatieve paths te definiëren.
Bv. met rprojroot kan je de root van je git-repo opzoeken met find_root(criterion
= is_git_root), en zo kan je bv. in het begin van je Rmd je WD aanpassen
naar de root van je git-repo (of een subfolder ervan). Er zijn trouwens ook
functies als find_root_file() die toelaten toe om specifieke files op te
halen die bv. een andere oorsprong nodig hebben dan je WD. Dus tal van
mogelijkheden om je paths zodanig te definiëren dat ze hetzelfde blijven
bij gebruik van knitr en runnen van de chunks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#45 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGKXN5DYP6PKBE3L22EA7E3S2RDIZANCNFSM4WHKMFLA>
.
--
*Anja Leyman *
Expert Cel Beheerplanning en Monitoring
--------------------
*Ik werk tijdelijk niet op woensdag- en vrijdagnamiddag.*
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Vlaamse overheid
AGENTSCHAP *NATUUR & BOS*
Standplaats Instituut voor Natuur- en Bosonderzoek (INBO)
Gaverstraat 4, 9500 Geraardsbergen
T: 054 436 182 M: 0495 14 90 60
E-mail: *anja.leyman@vlaanderen.be <anja.leyman@lne.vlaanderen.be>*
*www.natuurenbos.be <http://www.natuurenbos.be/>*
---
De inhoud van dit bericht en eventuele bijlage(n) verbinden het Agentschap
voor Natuur en Bos niet, zolang niet bevestigd door een geldig ondertekend
document
|
|
Ik ga het sowieso nog toevoegen, hoor, maar omdat je aangaf dat je ermee zat te sukkelen, leek het me wel zinvol om wat tips te geven om het op een handige manier te organiseren. Want met here zou je niet meer het probleem mogen hebben dat knitr een andere wd gebruikt dan bij het runnen van chunks, dacht ik. Je zou trouwens ook kunnen overwegen om de wd te zetten waar je output moet komen (of een hoofdfolder ergens hierboven, evt. een gemeenschappelijke hoofdfolder met je code, want ik veronderstel dat je bij Bestandsnaam wel een subfolder kan meegeven). Enfin, het zijn maar ideetjes om het je gemakkelijker te maken. |
|
ja, ik heb wd al gezet waar output moet komen, als ik knit is dat OK. Maar
bij het gewoon aflopen van de chunks, onthoudt hij dat niet altijd.
En probleem van here is dat ik dat niet kan gebruiken in de functies die in
het package zitten.
Dus als ik bij de functies een locatie kan meegeven, is het opgelost ;-)
Op ma 18 jan. 2021 om 17:35 schreef ElsLommelen <notifications@github.com>:
… Ik ga het sowieso nog toevoegen, hoor, maar omdat je aangaf dat je ermee
zat te sukkelen, leek het me wel zinvol om wat tips te geven om het op een
handige manier te organiseren. Want met here zou je niet meer het probleem
mogen hebben dat knitr een andere wd gebruikt dan bij het runnen van
chunks, dacht ik.
Je zou trouwens ook kunnen overwegen om de wd te zetten waar je output
moet komen (of een hoofdfolder ergens hierboven, evt. een
gemeenschappelijke hoofdfolder met je code, want ik veronderstel dat je bij
Bestandsnaam wel een subfolder kan meegeven). Enfin, het zijn maar ideetjes
om het je gemakkelijker te maken.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#45 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGKXN5GOELJP5G36GMKJZQLS2RPOVANCNFSM4WHKMFLA>
.
--
*Anja Leyman *
Expert Cel Beheerplanning en Monitoring
--------------------
*Ik werk tijdelijk niet op woensdag- en vrijdagnamiddag.*
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Vlaamse overheid
AGENTSCHAP *NATUUR & BOS*
Standplaats Instituut voor Natuur- en Bosonderzoek (INBO)
Gaverstraat 4, 9500 Geraardsbergen
T: 054 436 182 M: 0495 14 90 60
E-mail: *anja.leyman@vlaanderen.be <anja.leyman@lne.vlaanderen.be>*
*www.natuurenbos.be <http://www.natuurenbos.be/>*
---
De inhoud van dit bericht en eventuele bijlage(n) verbinden het Agentschap
voor Natuur en Bos niet, zolang niet bevestigd door een geldig ondertekend
document
|
is het mogelijk om een extra argument toe te voegen aan de functies validate.xxx, dat toelaat de outputlocatie zelf in te stellen?
Nu wordt gebruik gemaakt van "PathWD = getwd()" in de sub-functie "validatierapport", maar in de functies validate.afgeleid, en ... komt dat argument niet meer terug.
Misschien kan dat herhaald worden? Zodat ik ofwel gebruik maak van de default (= getwd) of zelf een locatie intyp waar ik graag de output (= het validatierapport) zie verschijnen?
The text was updated successfully, but these errors were encountered: