| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| database:import-formats [2026/06/17 08:14] – [Transmission des fichiers] jpmilcent | database:import-formats [2026/06/17 08:30] (Version actuelle) – [Évolutions] jpmilcent |
|---|
| * **//meta_archive.ini//** : fichier contenant les métadonnées sur le fournisseur de l'archive et la version du format d'échange utilisée. | * **//meta_archive.ini//** : fichier contenant les métadonnées sur le fournisseur de l'archive et la version du format d'échange utilisée. |
| * **//synthese.csv//** : les données d'observation à intégrer au module Synthèse. Peux être remplacer par un fichier //occtax.csv//. | * **//synthese.csv//** : les données d'observation à intégrer au module Synthèse. Peux être remplacer par un fichier //occtax.csv//. |
| | |
| Les fichiers suivants pourront aussi être fournis sans être obligatoires : | Les fichiers suivants pourront aussi être fournis sans être obligatoires : |
| * //source.csv// : permet de décrire la source des données. Correspond à la table "//gn_synthese.t_sources//". | * //source.csv// : permet de décrire la source des données. Correspond à la table "//gn_synthese.t_sources//". |
| * //organism.csv// : permet de fournir les informations sur les organismes liées aux utilisateurs, jeux de données et cadres d'acquisition. Correspond à la table "//utilisateurs.bib_organismes//". | * //organism.csv// : permet de fournir les informations sur les organismes liées aux utilisateurs, jeux de données et cadres d'acquisition. Correspond à la table "//utilisateurs.bib_organismes//". |
| * //user.csv// : permet de fournir des informations sur les utilisateurs à l'origine des données. Correspond à la table "//utilisateurs.t_roles//". | * //user.csv// : permet de fournir des informations sur les utilisateurs à l'origine des données. Correspond à la table "//utilisateurs.t_roles//". |
| * **//occtax.csv//** : les données d'observation à intégrer au module OccTax. Les données seront automatiquement répercutées dans le module Synthèse via des //triggers// présents dans la base de données. | * //occtax.csv// : les données d'observation à intégrer au module OccTax. Les données seront automatiquement répercutées dans le module Synthèse via des //triggers// présents dans la base de données. |
| * **//validation.csv// : permet de fournir les statuts de validations actuel et passés des observations. Généralement, utilisé en complément du fichier //occtax.csv//. | * //validation.csv// : permet de fournir les statuts de validations actuel et passés des observations. Généralement, utilisé en complément du fichier //occtax.csv//. |
| * //additional_data.csv// : contient la description des champs additionnels présents dans les différents fichiers à importer. uniquement pour la documentation. Non utilisé. | * //meta_additional_data.csv// : contient la description des champs additionnels présents dans les différents fichiers à importer. uniquement pour la documentation. Non utilisé. |
| | |
| ==== Principe de la procédure d'import initial ==== | ==== Principe de la procédure d'import initial ==== |
| * Nous utiliserons plusieurs fichiers textes respectant tous le même format CSV (voir ci-dessous) | * Nous utiliserons plusieurs fichiers textes respectant tous le même format CSV (voir ci-dessous) |
| * Le détail des différents fichiers (user, organism, acquistion_framework, dataset, source, synthese) est présentés ci-dessous | * Le détail des différents fichiers (user, organism, acquistion_framework, dataset, source, synthese) est présentés ci-dessous |
| * Un seul fichier est obligatoire //synthese// mais les autres sont nécessaire pour éviter une saisie manuelle sur GeoNature des métadonnées et sur UsersHub des utilisateurs et organismes. | * Un seul fichier est obligatoire //synthese// (ou //occtax//) mais les autres sont nécessaire pour éviter une saisie manuelle sur GeoNature des métadonnées et sur UsersHub des utilisateurs et organismes. |
| * Dans ces fichiers, nous utiliserons les codes alphanumériques des valeurs pour les champs devant contenir des **identifiant de nomenclatures**. Un script Python se connectant à la base de GeoNature permettra de récupérer l'identifiant numérique spécifique à une instance de base de données. | * Dans ces fichiers, nous utiliserons les codes alphanumériques des valeurs pour les champs devant contenir des **identifiant de nomenclatures**. Un script Python se connectant à la base de GeoNature permettra de récupérer l'identifiant numérique spécifique à une instance de base de données. |
| * Pour les lien avec les **organismes**, **cadres d'acquisition** et **jeux de données**, nous utiliserons un mécanisme différent des nomenclatures. Les liens se feront sur les UUID et un script SQL permettra de récupérer les identifiants spécifiques à chaque instance de base de données. Les champs sur lesquels les liens sont basés peuvent être amené à évoluer dans la base d'origine. Lors d'une mise à jour nous nous appuierons aussi sur les champs "//unique_id//" (UUID) de ces entités (s'ils sont fournis) pour retrouver la correspondance avec un enregistrement en base de données. Il est donc important que les bases de données sources stockent l'UUID des ces entités... | * Pour les lien avec les **organismes**, **cadres d'acquisition** et **jeux de données**, nous utiliserons un mécanisme différent des nomenclatures. Les liens se feront sur les UUID et un script SQL permettra de récupérer les identifiants spécifiques à chaque instance de base de données. Les champs sur lesquels les liens sont basés peuvent être amené à évoluer dans la base d'origine. Lors d'une mise à jour nous nous appuierons aussi sur les champs "//unique_id//" (UUID) de ces entités (s'ils sont fournis) pour retrouver la correspondance avec un enregistrement en base de données. Il est donc important que les bases de données sources stockent l'UUID des ces entités... |
| * avoir un nom au singulier, en minuscules et avec des underscores comme séparateur de mots. | * avoir un nom au singulier, en minuscules et avec des underscores comme séparateur de mots. |
| * avoir l'extension //.csv// | * avoir l'extension //.csv// |
| * avoir un des noms suivant : //synthese.csv//, //source.csv//, //dataset.csv//, //acquisition_framework.csv//, //organism.csv// ou //user.csv// | * avoir un des noms suivant : //synthese.csv//, //source.csv//, //dataset.csv//, //acquisition_framework.csv//, //organism.csv//, //user.csv//, //occtax.csv//, //validation.csv// ou //meta_additional_data.csv//. |
| |
| Le format CSV (en réalité plutôt [[https://fr.wikipedia.org/wiki/Tabulation-separated_values|TSV]]) qu'ils contiendront devra respecter les règles suivantes : | Le format CSV (en réalité plutôt [[https://fr.wikipedia.org/wiki/Tabulation-separated_values|TSV]]) qu'ils contiendront devra respecter les règles suivantes : |
| * si nécessaire utiliser le caractère **guillemet** (") pour préfixer et suffixer une valeur de champ | * si nécessaire utiliser le caractère **guillemet** (") pour préfixer et suffixer une valeur de champ |
| * si nécessaire utiliser **deux guillemets** successifs ("") pour échapper le caractère guillemet dans une valeur de champ préfixé et suffixé par des guillemets. | * si nécessaire utiliser **deux guillemets** successifs ("") pour échapper le caractère guillemet dans une valeur de champ préfixé et suffixé par des guillemets. |
| | * respecter l'ordre des champs décrits dans cette documentation |
| | * si possible fournir les fichiers avec l'ensemble des champs décrits même s'ils doivent contenir des valeurs nulles |
| | |
| Il faut vous assurer d'avoir supprimé, remplacé ou protégé les caractères suivant dans les valeurs des champs : | Il faut vous assurer d'avoir supprimé, remplacé ou protégé les caractères suivant dans les valeurs des champs : |
| * si les champs ne sont pas valables pour toutes les lignes, 1 seule possibilité : | * si les champs ne sont pas valables pour toutes les lignes, 1 seule possibilité : |
| * utiliser le champ //additional_data// dont les valeurs doivent être [[https://www.json.org/json-fr.html|au format JSON]] et [[https://jsonformatter.curiousconcept.com/|être valide]]. Le JSON en question devra correspondre à un objet d'un seul niveau avec attribut et valeur. Ex. : <code json>{"attribut1": "valeur1", "attribut2": "valeur2"}</code> | * utiliser le champ //additional_data// dont les valeurs doivent être [[https://www.json.org/json-fr.html|au format JSON]] et [[https://jsonformatter.curiousconcept.com/|être valide]]. Le JSON en question devra correspondre à un objet d'un seul niveau avec attribut et valeur. Ex. : <code json>{"attribut1": "valeur1", "attribut2": "valeur2"}</code> |
| * si les champs sont valables pour toutes les lignes du fichier d'import, 2 possibilités : | * si les champs sont valables pour toutes les lignes du fichier d'import, <del>2</del> 1 possibilité<del>s</del> : |
| * ajouter des colonnes supplémentaires au fichier | |
| * utiliser le champ //additional_data// (voir ci-dessus) | * utiliser le champ //additional_data// (voir ci-dessus) |
| | * <del>ajouter des colonnes supplémentaires au fichier</del> : non implémenté ! |
| |
| Afin de respecter le standard, il est nécessaire de fournir les méta-données de ces champs additionnel en fournissant le fichier //meta_additional_data.csv// (voir META_ADDITIONAL_DATA). Ce fichier contient la descriptions des champs additionnels. | Afin de respecter le standard, il est nécessaire de fournir les méta-données de ces champs additionnel en fournissant le fichier //meta_additional_data.csv// (voir META_ADDITIONAL_DATA). Ce fichier contient la descriptions des champs additionnels. |
| |
| Pour faciliter l'intégration des données, l'utilisation du champ //additional_data// est conseillée.\\ | Pour permettre l'intégration des données, l'utilisation du champ //additional_data// est nécessaire car la possibilité d'ajouter des colonnes supplémentaires aux fichiers CSV n'est pas implémentée.\\ |
| Les champs additionnels ne seront pas forcément traités pour toutes les ressources. Seuls les champs de la ressource SYNTHESE seront transmis au niveau national. | Les champs additionnels ne seront pas forcément traités pour toutes les ressources. Seuls les champs de la ressource SYNTHESE seront transmis au niveau national. |
| |
| |
| ==== Évolutions ==== | ==== Évolutions ==== |
| | * 2026-06-17 : |
| | * Ajout des statuts des différents fichiers. |
| | * Ajout de complément sur le format des fichiers CSV attendus. |
| | * Mise à jour des textes introductifs. |
| * 2026-04-02 : | * 2026-04-02 : |
| * Utilisation de ''VARCHAR(50)'' pour tous les champs ''code_nomenclature_...'' de SYNTHESE. | * Utilisation de ''VARCHAR(50)'' pour tous les champs ''code_nomenclature_...'' de SYNTHESE. |
| | * 2026-03-13 : |
| | * Ajout du format VALIDATION. Nécessaire pour intégrer un historique des validations à la Synthese ou dans le cadre de l'utilisation du format OCCTAX. |
| * 2025-04-30 : | * 2025-04-30 : |
| * Ajout du format OccTax supporté pour les ajouts uniquement. Non nécessaire pour l'instant dans le cadre des SINP. | * Ajout du format OCCTAX supporté pour les ajouts uniquement. Non nécessaire pour l'instant dans le cadre des SINP. |
| * 2024-10-23 : | * 2024-10-23 : |
| * Nous privilégions maintenant l'utilisation des UUID comme identifiant de lien entre les ressources à la place des codes ou noms. | * Nous privilégions maintenant l'utilisation des UUID comme identifiant de lien entre les ressources à la place des codes ou noms. |
jpmilcent