ElsLommelen
commented
3 years ago Vermits die unieke GUID minder stabiel is dan DOMEIN_ID en BOS_BHI en er rechtstreeks van afgeleid kan worden (?), zou ik ervoor kiezen om die achteraf aan het resultaat te koppelen. Op die manier ben je ook niet verplicht om de hele berekening opnieuw te doen als die GUID nog eens verandert.
Ik ben er zeker van dat je dat zelf ook compact kan programmeren met left_join of inner_join en anti_join (ervan uitgaand dat je die GUID's samen met DOMEIN_ID en BOS_BHI in tabelvorm hebt):
- met left_join: records zonder GUID hebben NA die je kan uitfilteren
- met inner_join en anti_join: het eerste geeft een lijst met de domeinen die gekoppeld kunnen worden, het tweede een lijst met domeinen die niet gekoppeld kunnen worden
Ik heb je hoofdscript even bekeken, en dit lijkt me wel overzichtelijk en goed gedocumenteerd om minder ervaren R-gebruikers mee te laten werken. Als ze het gewoon moeten runnen, of delen ervan, of kleine aanpassingen maken, lijkt me dat wel haalbaar. (Voor iemand zonder enige kennis van R die zelf niks moet aanpassen, verpak je best alles in 1 functie (die aangepast is aan de computer: plaats van db in script enz.) en leer je die persoon om R op te starten en die ene functie te runnen door het commando in te typen ofzo. Als jij de databank beheert, kan je ook het script periodiek zelf runnen (of automatische opdracht instellen) en de resultaten ergens beschikbaar maken + script om deze op te vragen, zoals we met forresdat doen.)
leymanan
de output voor IVANHO moet een extra veld 'BeheerindelingID " bevatten,die een unieke GUID is. Nadeel is dat die minder stabiel is dan de velden DOMEIN_ID en BOS_BHI, en regelmatig verandert (elke keer wanneer er een bestand toegevoegd wordt, of grenzen gewijzigd worden).
Daarom zou het handig zijn om een extra functie in (of buiten) het package te hebben, die toelaat de meest recente versie in te laden, en te koppelen aan de bosdat-metingen. Tegelijkertijd zou er een lijst moeten aangemaakt worden van de domeinen die nu niet meer gekoppeld kunnen worden, omdat de domeinID veranderd is (ter info: tss 2016 en nu is dat voor 10 van de 400 domeinen het geval). Deze moet ik dan GIS-matig gaan opzoeken, en hen een nieuwe domeinID toekennen.
Dit kan ik uiteraard ook zelf programmeren in één van mijn hoofdfuncties, maar wellicht kan jij dat sneller en compacter.
Bovendien moet ik in het achterhoofd houden dat dit package ook bruikbaar moet zijn voor andere mensen van ANB, die nauwer betrokken zijn bij de houtverkopen. Op termijn wordt dit immers naar hen doorgeschoven.