Organisation des CA et JDD

[aferchal]

Après avoir échangé avec les Pyrénées et lu pas mal de tickets Github à ce sujet je reviens vers vous pour quelques conseils d'organisation et d'emboitements CA / JDD. Lors de la migration d'Obsocc vers GN un CA "Données du Parc national de la Guadeloupe" a été créé avec 2 JDD, l'un qui contient les données obsocc figées et l'autre Occtax qui est actif. Ça me convenait jusqu'à lors. Se pose aujourd'hui la question d'ouvrir Occtax en saisie à d'autres structures (DEAL, ONF, Assos) mais je ne souhaite pas qu'ils voient les données des autres structures dans la synthèse car pour cela nous avons la plateforme SINP régionale karunati (karunati.fr). D'après ce qui ressort de mes échanges avec les Pyrénées et des lectures Github, il n'est actuellement pas possible techniquement de régler des droits de visualisation differents par structure sur un meme JDD à partir du moment ou la structure est indiquée en tant qu'acteur dans les métadonnées. Donc il faut créer un JDD spécifique par structure (ex occtax_DEAL, occtax_ONF) qui s'appuie sur le même module GN (occtax en l'occurrence) et le rattacher à un CA qui soit un peu plus générique que le CA actuel "Données du PNG" ? Ou alors créer un autre CA qui s'appelerait "Données externes" et un JDD par structure selon le meme principe ci-dessus ? J'avoue ne pas voir les conséquences technique que peut engendrer la création de plusieurs CA et JDD et j'ai l'impression avec cette méthode de surcharger inutilement l'appli. Bref, dsl pour Ludovic qui doit lire 2 x mes interrogations mais j'aimerais avoir un retour plus large à ce sujet avant de me lancer

[DonovanMaillard]

Bonjour,

Les cadres et jdd sont bien des boîtes qui servent à ranger les donnees provenant de différents acteurs ou provenant d'un même acteur dans des contextes variables (études, protocoles, projets etc.

En termes de droits cest utile, mais également en termes de transmission ou de requête de données. Si demain la DEAL change d'outils, autant qu'ils puissent récupérer toutes leurs données en récupérant directement leur propre jeu de donnees. Si l'ONF a besoin dun champ additionnels qui ne sert qu'a eux, vous pouvez le définir au niveau de leur jeu de données.

Le cadre d'acquisition est davantage du "rangement d'administrateurs" : a vous de voir si vous faites un cadre ONF, un cadre deal etc ou un seul cadre partenaires. Ca aurait l'avantage que si demain la Deal a besoin de deux jeux de donnees (donnees aléatoires et programme znieff par exemple) ils pourront être rassemblés dans le cadre DEAL.

Ca n'est pas tant une surcharge de l'outil, simplement un moyen de ranger les donnees de manière cohérente avec des metadonnees précises pour détailler les différents lots.

A titre d'exemple nous avons une centaine de jeux de donnees en interne, correspondant à chaque étude que nous réalisons. + 1 jeu de donnees pour chacun de nos partenaires.

[Adrien-Pajot]

Bonjour, Dans le cadre des imports que j'ai réalisés aux Ecrins, on s'est beaucoup demandés comment organiser nos CA et JDD.

Une règle qu'on pense intéressante : un JDD = un organisme ou un groupe d'organismes de production de données.

Pour les CA, on a coupé ça sans trop de règle parce que comme dit @DonovanMaillard c'est plus du rangement admin. Mais pour les CA globalement on fait par grande étude (protocole donné) ou grande localisation (RN XX)

A+

[camillemonchicourt]

Oui en effet, le SINP pousse pour aller vers 1 JDD = 1 organisme, 1 protocole. C'est assez intéressant et utile de découper les JDD par organisme, notamment pour le CRUVED de niveau 2 (les données de mon organisme) et car c'est par le JDD que l'on retrouve le (ou les) organismes d'une occurrence. De notre côté, on a un JDD pour les observations occasionnelles des agents du PNE saisies dans Occtax, et ensuite des JDD différents pour chaque partenaires, que cela soient des données importées ou des données qu'ils saisissent dans Occtax.

Ils sont aussi dans des CA différents pour bien différencier les données PNE et celles des partenaires.

Avec le CRUVED tu peux aussi faire en sorte que la liste des JDD affichés à l'utilisateur dépende de son organisme. Comme ça il ne voit que les JDD dont son organisme est acteur. A noter aussi que depuis la 2.7, il est aussi possible d'avoir des listes de taxons différentes en fonction du JDD (voir aucun JDD), et aussi d'avoir des champs additionnels selon le JDD.

Au GTSI de fin 2020, on avait eu un échange sur le sujet et partagé dans cette présentation l'organisation de différents parcs : https://geonature.fr/documents/2020-11-GTSI-Organisation-Diffusion-Biodiversite.pdf

[cen-cgeier]

Bonjour, Dans le cadre de la définition de métadonnées de mon CEN, nous nous heurtons à une difficulté.. @camillemonchicourt tu évoques que

le SINP pousse pour aller vers 1 JDD = 1 organisme, 1 protocole.

Si je comprends la traduction de ça dans Géonature, 1 protocole = 1 Méthode de collecte Il est possible d'en définir qu'une seule / JDD. Il n'existe pas à ma connaissance d'arguments à faire figurer dans le geonature_config.toml pour permettre une sélection multiple de cet attribut.

Or il arrive que certains protocoles nécessites plusieurs méthodes de collectes (cas de l'indicateur "intégrité des peuplement d'Odonates" où il est demandé des obs visuelles en vol et de la récolte d'exuvies.). Dans les fait, nous pourrions subdiviser ces jeux de données / méthode de collecte, néanmoins ceci alourdi grandement la saisie des données sur le terrain et ça suscite une perte d'information concernant le JDD d'origine, qui doit être reconstitué pour chaque utilisation, export, ...

Qu'en pensez-vous ? Comment faites-vous ? A+

[camillemonchicourt]

Selon moi, il reste à bien clarifier et positionner la notion de protocole et de méthode de collecte (basée sur Campanule) en lien avec les métadonnées.

Je pense qu'il faut travailler sur un triptyque "Occurrences de taxons" / "Métadonnées" / "Méthodes et protocoles" (Campanule) à préciser au niveau des standards du SINP.