Description de l’architecture

Au Cen Centre-Val de Loire, nous n’avons pas 1 outil base naturaliste. Nous avons un ensemble d’outil renseignant 1 base de données. A partir de cette base, on multiplie les exploitations en fonction des besoins.

La structure en image :

Voyons maintenant le détail.

La base SI_CENTRE

Toutes les données du Conservatoire à composante directe ou indirecte géographique sont stockées dans une base PostgreSQL à cartouche spatiale PostGIS.

La base est constituée de plusieurs grands ensembles appelés "schémas", représentés par des cylindres gris dans la figure ci-dessus. Le cylindre bleu correspond lui à l’ensemble de la base SI_CENTRE. Les schémas décrits ici sont :

  • spatial : il contient un certain nombre de tables spatiales (équivalent de couches au sens SIG), à savoir entre autres :
    • les limites administratives,
    • les sites d’inventaire et de protections,
    • les sites conservatoire,
    • la BD Parcellaire.
  • serenabase (et serenarefe) : toutes les tables pour l’application Serena. Le schema serenarefe contient la partie référentiel taxonomique et les protections associées,
  • saisie et md : constituent les schémas de la base SICEN,
  • inventaire : vise à stocker les informations valides des inventaires du Cen, par exemple la table des habitats des sites.

Données issues de Serena

Données avec coordonnées réelles
Si lors de la saisie d’une observation on indique des coordonnées ponctuelles, soit en saisie manuelle, soit avec le module carto de Serena, le seul travail de la base sera de transcrire ces coordonnées en objet point au sens Postgis du terme. Il deviendra alors interrogeable à partir d’un logiciel SIG ou pour des requêtes spatiales sur la base.

Données avec localisation relative à un objet support
Si l’observation n’a pas de coordonnées X,Y (ponctuelle), on va utiliser dans Serena la notion de site. C’est ce dernier qui va "porter" l’information géographique.
La gestion des objets géographiques autre que point dans Serena posant un certain nombre de contraintes et de limites, nous avons fait le choix assez tôt de ne pas stocker cette information géographique dans Serena, mais dans des couches SIG puis, avec la montée en puissance de postgis, dans des tables spatiales. Les objets supports de localisation retenus sont de trois nature :

  • un site conservatoire : sa géométrie est présente dans la table "spatial.sites" et sa mise à jour est prise en charge par le responsable SIG,
  • une commune : la table des communes directement issue de la BD parcellaire est "spatial.bdp_commune", son actualisation est prise en charge par le responsable SIG,
  • un site d’inventaire : un tel site porte potentiellement une série d’observation. Il peut s’agir d’un transect, d’un quadrat, d’un sous-secteur d’un site. Sa géométrie et sa dimension est déterminée en fonction des besoins par le chargé scientifique. Plusieurs sites d’inventaires peuvent se chevaucher. Qu’il soit linéaire, polygonal voir ponctuel, Il est stocké dans la table "spatial.sites_inventaire" . A chaque objet créé, un identifiant doit être généré selon la procédure décrite ici.

Comment fait-on pour renseigner cette géographie dans Serena du coup ?

  • on vérifie que l’objet géographique existe dans la table spatiale correspondante (site, commune, site d’inventaire), au besoin on le créé (site d’inventaire uniquement, sinon demander au responsable SIG),
  • on créé le site (si besoin) dans Serena en indiquant bien l’identifiant unique (code site, code INSEE, code site d’inventaire) dans le champ "Références SIG",
  • on saisie l’observation en lui affectant le site,
  • le reste se passe directement dans la base postgresql. Un programme automatique va chercher la géométrie de l’objet source et l’affecter à l’observation dans les tables de Serena. Dans le cas d’une géométrie polygonale ou linéraire, il va affecter cette géométrie mais également le centroide de l’objet en tant qu’objet ponctuel dans le champ adaptée. Ceci permet des requêtes de consultation beaucoup plus rapide et adaptées à la restitution à petite échelle.

Données de la base SICEN

La base SICEN est alimenté par deux sources :

  • l’application WEB, accessible avec Firefox,
  • l’application mobile geoODKCollect (sous Android) avec le formulaire SICEN approprié. A noter que ce formulaire exploite des données de référence (taxref, liste observateurs, etudes, protocoles, statut de reproduction) qui ne sont pas actualisées automatiquement mais nécessite des mises à jour manuelles régulières.

Dans les deux cas, les données sont directement enregistrées en base dans un format directement exploitable dans l’ensemble des applications, y compris sur l’aspect géographique.

Référentiel taxonomique et statuts d’espèces

Les deux bases utilisent comme référence TAXREF. Néanmoins :

  • à cette date (20/04/18), les deux bases sont sur taxref 11,
  • la mise à jour de Taxref est réalisée :
    • par le développeur de Serena pour cette application,
    • par le responsable SIG du Cen pour SICEN,
  • en base, le référentiel est stocké dans deux schémas différents (non indiqué sur la figure accompagnant cet article) :
    • INPN : pour SICEN,
    • serenarefe : pour serena
  • Serena a modifié la structure de la table fournie par le MNHN là ou SICEN l’exploite tel quelle,
  • Serena enrichirait la synonymie du référentiel (à vérifier).

Au niveau des statuts de protection, rien n’est présent dans SICEN, mais les statuts de protection sont dispos sur le référentiel taxref. Parallèlement Serena :

  • propose les statuts de protections,
  • permet la création de pseudo-champs qui ont servi à saisir les informations suivantes au Cen :
    • les taxon en liste rouge régionale,
    • les espèces patrimoniales,
    • les espèces invasives.

Le stockage de ces différents éléments dans la base Serena n’étant pas vraiment adapté à l’écriture aisée de requête, encore moins à utiliser ces informations avec les données de la base SICEN, le Cen a enrichi Serena de plusieurs tables, dans le schéma "serenarefe", pour pouvoir les exploiter soit avec les données de la base Serena, soit avec les données de la base SICEN :

  • protection : liste des protections internationales, nationales et locales issue de Serena,
  • sp_protege : liste des taxons protégés et de la nature de leur protection,
  • sp_list_rouge_cvl : liste des taxons classés en liste rouge régionale,
  • sp_pat_cvl : liste des taxons patrimoniaux,
  • sp_invasives_cvl : liste des espèces invasives en région Centre

Dans ces quatre dernières tables, deux champs permettent de faire des requêtes sur les données des deux bases :

  • taxon_id : à utiliser pour les données Serena uniquement,
  • cdnom : utilisable sur les deux bases.

Convergence des sources -> table Observations

Des tables communes regroupent les informations issues des deux bases.
Elles sont au nombre de 4 :

  • tables faune : inventaire.vum_faune, avec les géométries précises,
  • tables faune : inventaire.vum_faune_au_pt, avec les centroïdes des géométries,
  • table flore/fonge : inventaire.vum_flore_fonge, avec les géométries précises,
  • tables flore/fonge : inventaire.vum_flore_fonge_au_pt, avec les centroïdes des géométries.

Voir cet article pour plus de détails.

Exploitation des données

Pour faciliter la consultation des données en dehors des applications respectives, donc soit dans le SIG, soit dans un requêteur SQL (pgadmin, DB manager sous Qgis), un certains nombres de requêtes pré-enregistrées, appelées "vues" dans le vocabulaire postgresql sont disponibles :

  • saisie.vu_obs_sicen_detail : observations de SICEN, avec un champ pour les 3 formes géométriques (point/ligne/surface),
  • serenabase.vum_obs_serena_detail : observations de Serena, sans géométrie, donc à consulter uniquement sous forme tabulaire,
  • serenabase.vum_obs_serena_detail_pt : observations de Serena avec géométrie ponctuelle,
  • serenabase.vum_obs_serena_detail_pline : observations de Serena avec géométrie lineaire,
  • serenabase.vum_obs_serena_detail_pgone : observations de Serena avec géométrie surfacique,

EDIT 20/04/18 : Depuis la mise en place des vues communes, ces dernières présentent beaucoup moins d’intérêt.

Pour les vues de Serena il faut savoir que :

  • les géométries sont réelles ou portées, le champ source_geom en précise la nature,
  • du fait du volume de données, ces vues sont physiquement enregistrées en base et rafraîchie selon une modalité encore en cours de réflexion (à chaque modification d’observation ou bien par un processus régulier planifié).

Les statuts des taxons peuvent être utilisés par l’écriture de requête traité dans cet article.

L’alimentation de l’INPN se fait par un export spécifique au format SINP. Le format d’export respecte la déclinaison régionale de l’occurence de taxon définie dans le cadre de l’animation régionale du SINP.

Pour l’interrogation des données, le développement en interne d’une interface web de requêtes multicritères est envisagé.