-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
invoer soortenlijst op basis van NbnTaxonVersionKey uitdoven of direct stoppen? #232
Comments
Ik gebruik dit niet, maar heb geen zicht op wat anderen doen. |
Bedankt voor je antwoord, @hansvancalster! |
We hebben dit wel gebruikt voor het project om de gunstige abiotische
bereiken te specifiëren door rekening te houden met de aanwezigheid van
sleutelsoorten.
We dachten hiermee tussen de taxonlijsten van de Florabank, Inboveg en de
LSVI-databank iets gemeenschappelijks te hebben gevonden. Maar de
LSVI-databank bleek zowat de enige te zijn die dit veld gebruikt(e) ;-)
Dus het geeft niet om hiermee direct te stoppen. Het vergt maar een heel
kleine inspanning van ons om hiermee in de code rekening te houden (het
project smeult nog).
Op wo 6 nov 2024 om 14:11 schreef Els Lommelen ***@***.***>:
… Bedankt voor je antwoord, @hansvancalster
<https://github.com/hansvancalster>!
Voorlopig heb ik nog van niemand gehoord dat hij/zij het gebruikt (en wel
al enkele reacties van diegenen die het niet gebruiken), dus ik ga er
stilaan van uit dat anderen dit ook niet gebruiken en ik er ook geen moeite
in moet steken om die functionaliteit stilaan uit te doven.
—
Reply to this email directly, view it on GitHub
<#232 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIOMT3CRG6ZBKLJCFSZUWLZ7IIOPAVCNFSM6AAAAABQOTKBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZG4YTKNRYGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
*Jan Wouters*
Onderzoeker
Vlaamse Overheid
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK
Team Milieu en Klimaat
T +32 471 33 93 94
Kantoor & postadres (pakketten): Herman Teirlinckgebouw, Havenlaan 88 bus
73, B-1000 Brussel
*Postadres (brieven):* Koning Albert II-laan 15 bus 186, 1210 Brussel
*Poststukken die naar dit adres worden gestuurd, worden ingescand en
digitaal aan de geadresseerde bezorgd. Poststukken met de vermelding
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de geadresseerde
bezorgd.*
www.inbo.be
////////////////////////////////////////////////////////////
///////////////////////////////
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In het kader van de herziening van de soortenlijsten (o.a. issues #209 en #208) en het gebruik van Gbif-keys, lijkt het beter om de NbnTaxonVersionKey in de toekomst niet meer te gebruiken in het LSVI-package. (Hiermee volgen we de plannen van team databeheer om deze Gbif-keys overal te koppelen in databanken van soorten, maar ook zal het gebruik van de NbnTaxonVersionKey meer en meer problemen gaan geven door het feit dat databank Recorder niet actief onderhouden wordt bij vernieuwde taxonomische inzichten.)
Bij packages is het gebruikelijk om bij het verwijderen van bepaalde functionaliteit een zekere overgangsperiode te voorzien, waarbij een warning gegeven wordt dat dit niet meer lang ondersteund zal blijven, maar de functionaliteit nog wel blijft werken ('deprecated') zodat gebruikers tijd hebben om hun code aan te passen en niet gedwongen worden om dit direct te doen. Dus logischerwijs zou ik dit hier ook doen, maar in dit geval vraag ik me af: is er wel iemand die bij het berekenen van de LSVI de soortenlijsten invoert als NbnTaxonVersionKeys in plaats van als soortnamen? Want als niemand dit ooit gedaan heeft, is het misschien ook niet nodig dat ik in dit geval moeite steek in het tijdelijk onderhouden van deze functionaliteit. Vandaar mijn graag: gebruikt iemand dit? Is het nodig om een overgangsperiode te voorzien waarin deze functionaliteit langzaam uitdooft, of is het ok om hier direct mee te stoppen vanaf de volgende versie van het package?
The text was updated successfully, but these errors were encountered: