heightmodels op github en van daaruit inladen?

[leymanan]

ik weet niet meer wat we daar juist over afgesproken hadden. En of we daar eigenlijk al over gesproken hadden? Sorry, maar als ik 't niet op schrijf ... Ik heb enkel een trello daarover "heightmodels op github en laten weten aan Els zdd ze van daar ingeladen kunnen worden met load_height_models"

Was het de bedoeling dat ik daar een aparte repo voor zou opzetten? En dat dan aan jou doorgeven om dat te implementeren in load-height_models?

Er staat me iets bij dat we dat best niet mengden met de forresdat-repo. Klopt dat?

[ElsLommelen]

Ja, inderdaad. Vanaf hier begint de discussie hierover, en als je wat verder leest, zie je waarom het een beetje wringt om dat in forresdat te steken, en dat je kiest voor een gitrepo.

[leymanan]

knoop doorgehakt: ik sla ze centraal op, op onze teamdrive en hou daar ook een archief bij (onder Team_Boseco_BR\PRJ_BR_Gegevensverwerking\Hoogtemodellen)

[ElsLommelen]

En wat sla ik op als versienummer?

[leymanan]

En wat sla ik op als versienummer?

kan dat gewoon de datum van inladen zijn?

[ElsLommelen]

En wat sla ik op als versienummer?

kan dat gewoon de datum van inladen zijn?

Ja, dat kan. Hoe noem ik dat dan in de attributes en metadata, bv. bij een berekende tabel uitgaande van meerdere gegevens waarin dit hoogtemodel gebruikt is? date_height_model? Of eerder zoiets als bij de fieldmapdatabank, met een bestandsnaam en een datum?

En zijn er hier ook regels over wat samen gebruikt mag worden? Ik ga ervan uit dat je 1 tabel met hoogtemodellen gebruikt en er hier dus nooit meerdere versies van die tabel samengevoegd moeten worden, maar zijn er bv. vereisten voor het combineren van de gegevens uit fieldmap en de hoogtemodellen qua versies?

En nog een andere vraag: blijven het excels, of worden het csv's, zoals afgesproken? (Ik kan die link op uw teamdrive niet openen, dus geen idee waar je naar verwijst.)

[leymanan]

En wat sla ik op als versienummer?

kan dat gewoon de datum van inladen zijn?

Ja, dat kan. Hoe noem ik dat dan in de attributes en metadata, bv. bij een berekende tabel uitgaande van meerdere gegevens waarin dit hoogtemodel gebruikt is? date_height_model? Of eerder zoiets als bij de fieldmapdatabank, met een bestandsnaam en een datum?

date_height_model is OK voor mij

En zijn er hier ook regels over wat samen gebruikt mag worden? Ik ga ervan uit dat je 1 tabel met hoogtemodellen gebruikt en er hier dus nooit meerdere versies van die tabel samengevoegd moeten worden, maar zijn er bv. vereisten voor het combineren van de gegevens uit fieldmap en de hoogtemodellen qua versies?

Dat is niet "1 tabel", dat is net het vervelende: er is één excel per bosreservaat, plottype en periode. Dus in totaal zijn er nu 67 excels. Die worden met de functie load_height_models() samengevoegd tot één dataframe in R die vervolgens gebruikt wordt om berekeningen te doen. Ik had geen regels in gedachten over wat samen mag gebruikt worden.

En nog een andere vraag: blijven het excels, of worden het csv's, zoals afgesproken? (Ik kan die link op uw teamdrive niet openen, dus geen idee waar je naar verwijst.)

Het blijven excels

[leymanan]

ter aanvulling bij voorgaande: een mogelijk alternatief is dat ik die 67 xlsx-files opsla in een acces-db, en die acces-db een versienr geef, waarbij de databank steeds een ander versienr krijgt, zodra één van de 67 tabellen verandert. De backups hou ik dan bij in zip-formaat. Bv height_models_20240423.accdb

Nadeel is wel dat ook bij één tabel die wijzigt (één bosreservaat met aangepaste hoogtemodellen), er een volledig nieuwe databank komt, die eigenlijk maar heel weinig verschilt van de voorgaande. Voordeel is dat er een duidelijk versiebeheer is.

Bijkomend nadeel: de functie load_height_models() moet herschreven worden om tabellen in te laden uit een access-db ipv als afzonderlijke excel-files. (En ik moet ook wat extra code schrijven om die excel-files in te laden in een access-db)

[ElsLommelen]

Tja, als je op basis van de datum van inlezen kan reproduceren welke versie van de xlsx-files er op die datum op de teamdrive stond, is het in principe ook reproduceerbaar. (Met googlesheets weet ik dat dit kan, mits wat werk als het om 67 bestanden gaat, maar met xlsx onder googledrive heb ik eigenlijk weinig ervaring en weet ik niet in hoeverre die onder versiebeheer staan en hoe oudere versies opgeroepen kunnen worden.)

En in verband met je voorstel om met een access-db te werken: zou het dan niet handiger zijn om de bestanden gewoon (als csv?) in een gitrepo op te slaan, en te overschrijven als je een nieuwe versie hebt, zoals je eerst voorstelde? Dit lijkt me minder werk (geen code schrijven tenzij je het kopiëren van bestanden naar je lokale versie van git wil automatiseren), en mits een vaste sorteervolgorde van de records in de csv's is het zeer transparant wat tussen verschillende versies van de csv's veranderd is (gemakkelijk op GitHub te zien door een diff te maken). Enfin, ik denk dat je het met een databank nodeloos moeilijk gaat maken terwijl de verschillen tussen versies eigenlijk nog niet echt transparant gaan zijn (tenzij je nog eens extra werk gaat steken in het beschrijven van wat je exact aanpast).

Moest je hulp nodig hebben bij het aanmaken van een gitrepo, mag je het uiteraard altijd laten weten, maar het lijkt me redelijk gemakkelijk, zelfs moest je dat nog niet eerder gedaan hebben:

• op github.com/inbo kiezen voor een 'new' repository, en daar de vraagjes invullen (als je geen publieke repo wil, zal je Bert van IT moeten contacteren, die mogen we zelf niet aanmaken wegens betalend, dus begrijpelijk dat ze het gebruik willen opvolgen) Je kan hier al meteen een readme, gitignore of licentie toevoegen (met simpele klik), of je kan dat achteraf zelf toevoegen (meer werk tenzij je al een bestand hebt om van te vertrekken).
• dan die repo klonen naar een lokaal project in RStudio via File > New Project > Version Control > Git en daar de url plakken die je op de github site via het groene knopje Code krijgt te zien (of moest je github desktop hebben, dan kan dat ook daarmee, maar daar ben ik niet mee vertrouwd)
• en dan een mapje data aanmaken en de bestanden (liefst als csv) toevoegen, en committen (je kan forresdat als inspiratiebron nemen)

[leymanan]

OK, ik zal er een gitrepo voor maken, heb ik al paar keer gedaan ;-) (maar toch bedankt voor korte uitleg!!)

[leymanan]

gitrepo : https://github.com/inbo/forresheights.git

Kan je daarmee verder?

[ElsLommelen]

Ja hoor, het ziet er in elk geval prima uit (ik druk me altijd voorzichtig uit zolang ik de code niet geschreven/aangepast heb ;-) ).

Dus ik gebruik met mijn code telkens de laatste versie van de main, en ik neem de sha van die commit op als versienummer in datapackage.json in forresdat? Of wou je met releases gaan werken ofzo? (Moet uiteraard niet, een gewone sha is ook prima als gewoon elke commit een nieuwe versie is die even belangrijk is als de vorige, en je niet zelf je versies wil nummeren of documenteren ofzo.)

Kleine communicatieve suggestie voor je package: in de readme van het woord 'forrescalc' een link maken naar de documentatie van forrescalc (of de gitrepo zelf).

[leymanan]

Dus ik gebruik met mijn code telkens de laatste versie van de main, en ik neem de sha van die commit op als versienummer in datapackage.json in forresdat? Of wou je met releases gaan werken ofzo? (Moet uiteraard niet, een gewone sha is ook prima als gewoon elke commit een nieuwe versie is die even belangrijk is als de vorige, en je niet zelf je versies wil nummeren of documenteren ofzo.)

sha is goed!

[ElsLommelen]

Ik was dit issue vergeten te vermelden in commit 174fc939, maar load_height_models() laadt intussen ook de data in vanuit forresheights. Dus bij deze is je forresheights volledig in gebruik: gegevens ingeladen, en de sha van de commit komt in de metadata in forresdat.