Chaque donnée intégrée à la base de données de l'atlas doit être examinée (validée / invalidée). Afin de faciliter le travail de validation, les fonctions présentées ici, permettent de passer chaque donnée saisie au crible des connaissances actuelles sur l'espèce, issues de la base de données.
Chaque taxon a tout d'abord été « caractérisé » selon les connaissances actuelles mobilisables dans la base de données (données validées).
Pour chaque espèce ont donc été calculées les références suivantes :
Cette démonstration s'arrête au moment de l'envoi des données collectées au serveur, et de la démonstration de l'intégration automatique et instantanée des données à SiCen.
Comment intégrer les données de l'INPN relatives à la protection de staxon et créer une matrice mentionnant pour chaque taxon (en ligne) les statuts dont il fait l'objet (en colonne).
Le support des données matricielles (raster) est une « nouveauté » de PostGIS 2.
A chaque pixel de la grille est associée une valeur (altitude, température, densité de population, type d'occupation du sol, perméabilité...). Cette valeur est stockée dans une bande.
PostGIS permet d'associer plusieurs bandes à un raster. On peut par exemple disposer d'un raster de températures mensuelles moyennes qui contient une bande par mois de l'année.
Dans le cadre d'un projet de collecte de données en ligne, nous souhaitions mettre en place depuis longtemps un système d'envoi de mail qui prévient à intervalle régulier les contributeurs, que leurs données ont été examinnée par un "expert" et qu'elles posent question.
L'idée générale était de mettre en place un trigger qui se déclenche aprés chaque modification du statut de validation d'une observation mais cela peut générer beaucoup de messages en cas de "validation" par lot.
Une vue sollicitée à intervalle régulier par une tâche cron sera donc plus appropriée.
Voici la présentation réalisée lors de notre Conférence Technique et Thématique "Géomatique" du dernier congrès des CENs qui s'est tenu à Thionville du 1er au 5 octobre 2014.
Pour diverses raisons, on se souci de moins en moins de la taille des fichiers que nous produisons (diaporama de plus de 100 Mo, rapports d'un poids similaire).
Cependant, si ce comportement se généralise au sein de l'équipe, la capacité de stockage de notre serveur de fichiers et sa sauvegarde sont rapidement malmenées.
Afin surveiller un peu cela, et pour pouvoir "harceler" un peu les collègues concernés, nous avons mis en place un petit script shell qui utilise les commandes find, ls et awk
Dans une application de collecte de données en ligne, nous utilisons une fonction qui génère, à partir de la liste des identifiants d'observateurs, la listes de leurs noms et prénoms. Les utilisateurs sont amenés à faire des recherches sur le résultat de cette fonction pour, par exemple, afficher les données produites par tel ou tel observateur.
La requête ci-dessous met environ 20 secondes à renvoyer un résultat :
L'outil de saisie des données naturaliste est enfin motorisé par les dernières version de PostgreSQL (9.2) et de Postgis (2.0).
Nous allons utiliser les trigger de PostgreSQL et la capacité de PostGIS 2 à gérer les données raster pour renseigner automatiquement l'altitude des données ponctuelles renseignées dans l'interface.
Voici comment arriver à un résultat qu'on recherche souvent avec QGis. Je dispose d'un maillage de mon territoire (maille régulière ou non) et d'une couche d'observation. J'aimerai savoir pour chaque maille, le nombre d'observation qu'elle contient.
L'exemple qui suit est inspiré de cet article : http://datagistips.blogspot.fr/2012/04/le-carroyage-avec-qgis-et-le-plugin.html
Les données naturalistes que nous collectons sont consolidées dans le SIG à traveur une interface web de saisie.
Une table de la base de données (saisie.suivi_saisie_observation) recence toutes les opérations d'insertion, de modification ou de suppression de ces donénes.
Nous allons interroger cette table pour calculer la somme mensuelle des données saisie via l'interface ainsi que la somme cumulée depuis sa mise en place en aout 2010.
Comment lister les tyopes enum utilisé dans ma base de données, dans quel schéma sont-ils définis et qsuelles sont les valeurs de leurs différenst éléments ?
En voulant mettre à jour des données d'altitude d'une distribution de points, nous avons rencontré une erreur :
La requête suivante :
UPDATE export.tous_point_espece_selon_format_esri SET pente_mnt = ST_VALUE(rast, geometrie, true)
FROM raster.pente_mnt30
WHERE code_insee LIKE '30%' AND st_intersects(geometrie, rast)
Les demandes de données sont fréquentes et il est intéressant d'une part, de se faciliter la vie, et d'autre part de garder une trace de ces exports afin de valoriser le travail réalisé par les naturalistes et de les tenir informés de l'utilisation qui est faite de leurs données.
Nous venons d'installer postgis 2.0 sur la base de développement de l'atlas des papillons de jour et des libellules du Languedoc-Roussillon.
Cette fonctionalité des plus intéressantes nous intéresse particulièrement pour caractériser l'écologie des espèces et décrire leurs préférences écologiques.
Le site sig.cenlr.org est devenue difficilement navigable.
Initialement utilisé comme un bloc-note ou un registre de notre travail géomaticien au sein du CEN L-R, le wiki mis en place en 2008 s'est étoffé, a beaucoup grossi. Ce nouveau site s'appelle si.cenlr.org, pour garder l'ancien site accessible et pour mieux correspondre au contenu qui ne concerne pas que la partie géographique du SI.
Le nouveau protocole national et la charte régionale du SINP ont été discutés, partagés et adoptés en concertation au printemps 2013.
