Tables faune/flore-fonge régionales

Descriptif

Le Cen Centre-Val de Loire est équipé de 2 outils de bases de données naturalistes. Les deux outils stockent leurs données dans notre base régionale postgresql. Tout cela est expliqué dans ce précédent article. Afin de faciliter l’interrogation des données issues des deux outils, nous avons mis en place deux nouvelles tables (des vues matérialisées pour être plus précis) :

• table faune : inventaire.vum_faune
• table flore et la fonge : inventaire.vum_flore_fonge

La structure de la table est basé sur la déclinaison régionale du format SINP "Occurance de taxon". Néanmoins, une partie de ces champs ne présentant pas d’intérêt pour une exploitation interne, ils n’ont pas été conservés.
Par ailleurs, les typologies de listes de valeurs par champ sont réduites et lacunaires par rapport à nos données sources, aussi nous avons fait le choix de ne pas les respecter et d’être plus précis et plus proche en terme d’information de nos données sources.
Nous avons également conservés dans cette table l’accès à toutes les données, y compris celle en attente de validation ou non validées.

Pour information, il existe deux tables (vues matérialisées également) respectant pleinement ce format :

• table faune : inventaire.vum_obs_sinp_faune,
• table flore/fonge : inventaire.vum_obs_sinp_hors_faune

Une vue matérialisée, c’est quoi donc

Une vue est l’équivalent d’une requête enregistrée en base de donnée. Une fois que vous l’avez déclaré, plus besoin de retaper tout le code SQL de la requête, il n’y a plus qu’à la charger.
Néanmoins, une vue relancera le calcul définit par la requête à chaque fois que vous y accéderez. C’est très pratique pour des données qui change énormément sur un pas de temps court. L’inconvénient est que si la requête est longue à répondre, car complexe, vous allez passer beaucoup de temps à attendre le résultat.

Aussi, dans le cas de données dont les modifications ne sont pas fréquentes, et c’est le cas pour nos données naturaliste, une autre notion est fort utile, la vue matérialisée. Le résultat de la requête ne reste pas uniquement en mémoire, mais il est écrit dans une table. On obtient de ce fait les mêmes temps d’accès qu’une table de données. Oui, mais alors, comment être sur que j’ai bien les données à jour ? Et bien le rafraîchissement du contenu de cette vue matérialisée est définit par l’administrateur de la base postgresql.
Au vu de la fréquence de mises à jour de nos observations naturalistes, le choix a été fait de mettre à jour toutes les nuits et tous les midi (12H45).

Pour les plus curieux la documentation complète.

Dictionnaire des champs

L’ensemble des champs composant ces tables sont commentés. Les commentaires seront visibles selon l’outil que vous utiliserez.

statutsource : Provenance de la donnée source Terrain/littérature,
referencebiblio : Référence bibliographique de la source,
identifiantorigine : Identifiant unique de la donnée source de l observation, dans la base de données, indice SER pour SERENA, SIC pour SICEN,
statutobservation : taxon observé ou non observé ou autre,
nomcite : Nom du taxon cité à l origine par l observateur,
nom_verna : Nom vernaculaire, commun,
nom_valide : Nom latin valide du taxon,
cdnom : Code du taxon dans TaxRef ,
cdref : Code du taxon de reference dans TaxRef ,
ordre : ,
famille : ,
group_taxon : Regoupement taxonimique disponible dans Serena,
versiontaxref : Version du referentiel taxonimique utilise,
denombrementmin : nombre minimun d individus du taxon composant l observation,
denombrementmax : nombre maximun d individus du taxon composant l observation,
objetdenombrement : Indique l objet du dénombrement (individu, couple...),
compdenombre : Indication complementaire de denombrement,
determethode : Indique de quelle manière on a pu constater la présence d un sujet d observation,
protocole : Protocole d observation utilise,
phenologie : phenologie du sujet observé,
etatbiolo : Etat biologique de l organisme au moment de l observation (vivant/mort),
sexe : Sexe du sujet observé,
stadedevie : Stade de développement du sujet observé,
statutbiolo : Comportement général de l individu sur le site d observation (migration/hiverbage/stationnement...,
reproduction : Comportement de reproduction observé,
comportbiolo : Comportement precis de l individu sur le site d observation (chasse, fuite, nourissage, chant...),
jourdatedebut : Date du jour de debut d observation,
jourdatefin : Date du jour de fin d observation,
heuredatedebut : Heure et minute auxquelles l observation du taxon a débuté,
heuredatefin : Heure et minute auxquelles l observation du taxon a pris fin,
geometrie : géométrie réelle ou portée (site, site inventaire, commune) de l observation,
natureobjetgeo : Nature de la localisation transmise : precise=reelle (taxon présent sur l ensemble de l objet géographique) ou porteur_geo=site, site inventaire ou commune,
ref_site_serena : code sig du site porteur de l observation dans Serena,
observateurnomorganisme : Organisme(s) de la (ou les) personne(s) ayant réalisé l observation, attention peut ressortir parfois organisme de numerisation a la place,
observateuridentite : Nom de l’ (ou des) observateur(s) ,
statutvalidation : Statut de validation de l observation,
validateurnomorganisme : Organisme de la (ou les) personne(s) ayant réalisé la validation taxonomique,
organismegestionnairedonnee : Nom de l organisme qui détient la donnée source et qui en a la responsabilité

Outils à utiliser pour exploitation

A l’heure actuelle, il n’existe pas d’outil interfacé spécifique à l’exploitation de ces tables. Aussi il va falloir vous munir d’outil capable d’interroger une base postgresql/postgis sous forme de requêtes SQL.

Le premier outil disponible est le plus utilisé pour l’exploitation d’une base postgresql, pgamin (version 3 ou 4, selon vos goûts). Très complet, mais un peu complexe de prise en main. De plus il n’interprétera pas les données géométriques sous forme carto.

Le deuxième outil est Qgis. SIG bureautique, c’est la vision cartographique qui est privilégié. Néanmoins, avec son module "DBmanager", vous pourrez faire toutes les requêtes SQL voulues et même accéder à l’ensemble des informations sur la base et sa structure.

Notion de représentation géographique des observations

La quasi totalité (99,4% au 13/04/18) des observations possèdent une représentation géométrique visible dans un SIG. Cette géométrie est de nature différente.

Forme de géométrie

Tout d’abord en terme de nature de forme, trois possibilités :

• un (ou des) point(s),
• une (ou des) ligne(s),
• une (ou des) surfaces.
  Le champ stockant cette géométrie s’appelle "geométrie". Il contient toutes les formes possibles. Il faudra donc en tenir compte dans l’exploitation. Par exemple dans Qgis, une couche affichée sur la carte ne peut être que d’une seule nature de géométrie. Il vous faudra donc ouvrir 3 couches différentes si vous souhaitez avoir les points, les lignes ou les surfaces.

Précision de la représentation géographique

Le deuxième aspect concerne la précision de cet objet géographique.

• certaines observations ont une représentation précise, au plus près de la réalité du terrain, on parle de "géométrie réelle",
• pour les autres données, notamment celles anciennes ou issues de références littéraires, la localisation est faite par un objet support, une référence à un territoire donnée. Ce territoire peut être une commune, un site Cen, un ensemble de sites Cen, un site d’inventaire. on parle alors de "géométrie portée".
  Un champ indique à l’utilisateur la précision de la géométrie, le champ "natureobjetgeo". A la date du 13/04/18, seulement 18% des observations sont des géométries réelles. La tendance va aller vers une augmentation des données précises du fait de l’évolution des méthodes et des outils.

Implication de l’utilisation des géométries portées :

• un ensemble d’observations peuvent être portés par le même site (ou autre type d’objet). En base, chaque observation va contenir la géométrie complète du site. Donc si on affiche un ensemble d’observations possédant ce même objet géométrique, il va être affiché en superposition sur la carte autant de fois qu’il y a d’observations de même site,
• à l’occasion d’une recherche spatiale (toutes les observations d’un département, ou d’une commune...), il sera plus pertinent d’utiliser la géométrie portée dans son ensemble, et non pas un centroide de la surface par exemple, car vous ne savez pas ou se situe l’observation sur le territoire, vous risquez donc de passer à côté d’espèces concernée par votre secteur de prospection.

Pertinence de la représentation spatiale des observations

Quand le travail se fait à grande échelle (un site ou un site d’inventaire, voir un ensemble), le plus pertinent est d’utiliser la représentation géographique la plus précise. Néanmoins, pour les données portées, c’est plus délicat car on risque le cumul d’objet géographique identique. Le choix de représentation dépendra donc de votre objectif et de la saturation en information.

Astuce : Si vous faites le choix de représenter des polygones par leur centroide, vous pouvez utilisez la fonction ’ST_centroid’ mais aussi la fonction ’ST_PointOnSurface’ qui vous garantit que le point calculé est quelque part sur la surface et ne se retrouvera pas en dehors.

Par contre, à petite échelle (département ou région par exemple), il est clairement pertinent d’utiliser une représentation ponctuelle pour toutes les observations. C’est à cette fin que deux tables (vues matérialisées) ont été ajouté :

• table faune : inventaire.vum_faune_au_point
• table flore et la fonge : inventaire.vum_flore_fonge_au_point
  Le choix de créer deux tables complémentaires plutôt qu’un deuxième champ de géométrie vise à accélérer les temps d’affichage des tables attributaires. Si nous avions fait le choix inverse, le deuxième champ de géométrie se serait chargé dans le SIG en tant que donnée texte, alourdissant énormément la quantité de données à transiter sur internet et donc le temps d’affichage.

Exploitation

Maintenant que vous êtes bien imprégné de l’esprit de la conception de ces tables et de leurs limites d’exploitation, c’est le moment de vous lancer ! Passez à l’article suivant pour du concret et beaucoup de SQL ;)