Fiche technique C4.2 — Bancarisation et structuration des données

1Architecture d'une base de données SIG

Structurer les couches par type de géométrie et par thématique, jamais par date de terrain — la structure doit rester lisible après plusieurs campagnes.

Type de couche	Contenu type
Points	Observations ponctuelles (individus, stations de mesure, points d'écoute)
Lignes	Transects, linéaires prospectés, cours d'eau relevés
Polygones	Habitats cartographiés, périmètres d'étude, zones de prospection
Rasters	Fonds de carte, orthophotos, modèles numériques de terrain associés

2Table attributaire type

Champ	Type	Exemple
id_releve	Texte (identifiant unique)	BEAU_20260415_ST_012
date_releve	Date	2026-04-15
observateur	Texte	ST
code_taxref / code_habitat	Texte/numérique	Code TAXREF ou EUNIS
protocole	Texte	IPA, STOC-EPS, IBGN…
precision_m	Numérique	EPE en mètres au moment du relevé
source	Texte	Terrain direct / donnée tierce intégrée
statut_validation	Texte (liste contrôlée)	Brute / vérifiée / validée

3Métadonnées obligatoires

Une couche sans métadonnées perd toute valeur scientifique dès qu'elle change de main — la norme ISO 19115 (simplifiée dans le cadre INSPIRE) fixe le socle minimal.

Titre et résumé de la couche/jeu de données
Système de coordonnées de référence (EPSG)
Date de création et date de dernière mise à jour
Producteur de la donnée (organisme, personne)
Échelle de saisie ou précision de collecte
Protocole ou méthode ayant produit la donnée
Restrictions d'usage ou de diffusion éventuelles

4Formats d'export

Format	Usage recommandé	Limite
Shapefile (.shp)	Standard historique, très large compatibilité SIG	Limite de 10 caractères sur les noms de champs, multi-fichiers
GeoJSON	Échange web, lisible en texte brut, versionnable (git)	Fichiers volumineux moins performants qu'un format binaire
GPX	Export direct depuis GPS de randonnée, points/traces	Peu adapté aux attributs complexes
GeoPackage (.gpkg)	Format moderne recommandé, fichier unique, pas de limite de nommage	Compatibilité plus récente, à vérifier selon les outils du commanditaire

5Traçabilité : de la donnée brute à la donnée validée

Exemple d'arborescence de dossier garantissant qu'aucune donnée brute n'est écrasée par une correction.

projet_expertise/ ├── 01_donnees_brutes/ # exports terrain non modifiés │ ├── terrain_20260415.gpkg │ └── terrain_20260422.gpkg ├── 02_donnees_verifiees/ # après contrôle qualité (fiche 2) │ └── releves_verifies_v1.gpkg ├── 03_donnees_validees/ # base consolidée, prête à l'analyse │ └── base_consolidee_finale.gpkg ├── 04_metadonnees/ │ └── fiche_metadonnees.xml └── 05_journal_modifications/ └── journal.md # traçabilité des corrections apportées

!Erreurs fréquentes à éviter

Modifier directement le fichier de données brutes — toute correction doit produire une nouvelle version tracée, jamais un écrasement silencieux.
Absence de métadonnées rendant la couche inexploitable par un tiers (commanditaire, jury) sans explication orale.
Mélanger systèmes de coordonnées entre couches d'un même projet sans reprojection explicite et documentée.
Utiliser des noms de champs non normalisés d'une campagne à l'autre, rendant l'agrégation temporelle impossible.

Repères réglementaires

La directive européenne INSPIRE encadre l'interopérabilité et le partage des données géographiques environnementales au sein des administrations publiques ; ses spécifications de métadonnées s'appuient sur la norme ISO 19115. Les données naturalistes bancarisées ont vocation à alimenter les bases de référence telles que l'INPN, sous réserve des accords de diffusion du commanditaire.