Les données collectées à l'aide des formulaires ODK Collect sont identifiées par un uuid que nous récupérons dans notre base de données métier.
L'idée consiste à récupérer cet identifiant quand il existe, sinon a en générer un.
Dans notre base de données, cet uuid généré par odk est stocké dans le champ id_waypoint de la donnée, sous forme de texte, formaté comme ceci : uuid:d9efd9ee-0b21-40a9-8606-901a8766106a
Donc quand cet uuid existe, on le garde comme id_permanent, sinon on en génère 1.

La base de connaissance "Stauts des espèces" de l'INPN est disponible ici : https://inpn.mnhn.fr/telechargement/referentielEspece/bdc-statuts-especes

Le daporama et les données sont ici

1er test de l'extension Time Manager de QGIS pour montrer la progression de notre connaissance du territoire.

En rouge les données d'espèces animales en vert les données d'espèces végétales.

A reproduire avec nos données de maîtrise foncière et d'usage, et à l'échelle du Réseau des CEN !

Et voilà pour la gestion (maîtrise foncière et d'usage) : Les propriétés en rouge et les "conventions" en vert

Intégrer des données externes à notre propre base de données peut se révéler fastidieux. pour faciliter la chose, nous allons créer une table qui décrit pour chaque table de données à intégrer, la liste des champs à y ajouter pour pouvoir ensuite les intégrer à sicen. Nous décrirons dans cette table comment le champ "sicen" doit être généré à partir des colonnes de la table à intégrer.

PostGIS 2.4 propose des fonction de fenêtre très pratiques pour les calculs d'aire d'occupation de taxon, utilisés dans la définition des listes rouges

Deux fonctions sont disponibles, ST_ClusterDBSCAN et ST_ClusterKMeans :

Une collègue a réalisé une symbologie catégorisée en utilisant un code couleur contenu dans un champ de la table.

Le souci est que QGIS ne sait pas encore faire les légendes qui vont bien pour cette sylmbologie, et, s'il affiche correctement ls données sur la carte, il conserve dans la légende les couleurs aléatoires.

La seule solution que j'ai trouvé consiste à créer un fichier de style et à la modifier à l'aide d'un éditeur de texte qui comprend les expressions régulières (jedit our moi mais aussi notepad++ ou d'autres).

Un collègue bien embarrassé nous a posé la question suivante : comment sélectionner tous les points d'une couche A qui se trouvent à moins de 4km d'une autoroute.

Le postulat de départ est que nous travaillons sur des fichiers shp (donc on oublie tout de suite la requête sql et l'opérateur st_dwithin() )

Nous avons tous répondu "tu crées un tampon de 4km de rayon autour de l'autoroute puis tu fais une recherche par localisation de tous les objets de la couche de points qui intersectent le tampon créé".

Je partage ici un trés gros travail réalisé par les collègues géomaticiens du CEN Picardie (Jérôme Boutet, Marie Héraude, et Gratien Testud) qui ont actualisé le document "Aide-mémoire SIG et Quantum GIS Lisboa 1.8", réalisé en 2013 par Guillaume Doucet du CEN Bourgogne.

Consolidation par région des geojson générés par cquest dans une table postgis (lambert 93)

-> https://github.com/cquest/photos-aeriennes-ign/tree/master/data/pva
-> http://georezo.net/forum/viewtopic.php?pid=279360#p279360

Les dumps contiennent une table PostGIS ayant la structure suivante :

Suite aux discussions des journées utilisateurs de QGIS des 10 et 11 décembre. J'ai testé l'utilisation d'une table atributaire comme couche de couverture. Et ça fonctionne !

Je ne sais pas si c'était le cas sur les versions précédentes mais ça fonctionne sur la 2.12. Ma table ne contient que deux colonnes cd_ref et lb_nom.

On utilisera les règles de symbologie pour n'afficher que les données correspondant au cd_ref courant :

 "cd_ref"  = attribute(@atlas_feature ,'cd_ref')

QGIS rocks !

Les Cen sont de gros utilisateurs de logiciels libres, notamment dans leurs SIG avec Qgis et PostgreSQL/PostGIS.

Ces outils nous facilite grandement la gestion et l'exploitation de nos données pour l'exercice de nos missions de conservation des especes naturels.

Cette première initiative du réseau est donc un premier, "petit" mais juste, retour vers la communauté.

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 :

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).

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.