Le mois d’août se prête au tâches de fond. La semaine dernière nous avons réalisé la migration de notre instance PostgreSQL/PostGIS de la version 13 à la version 17.
L’occasion de passer d’un service « dockerisé » sur un hôte à l’OS proche de la fin de vie à un service s’exécutant sur un OS tout frais sur une machine plus costaude.
L’occasion aussi d’installer quelques extensions que nous attendions impatiemment.
L’extension pg_cron pour faciliter la mise en œuvre de tâches cron par l’équipe, mais surtout pl-python pour plus d’interactions avec notre serveur ODK Central grâce aux fonctions pl-pyodk. De quoi partager des référentiels d’objets entre nos applications métier (web, lizmap et QGIS) et nos applications mobiles (ODK Collect) et entre nos bases de données transversales et « projet ». Nous avons aussi installé le connecter ogr-fdw permettant d’inerragir depuis nos bases de données avec divers sources de données géo (services web, fichiers…)
Les grandes étapes :
Création du nouveau serveur
installation et mise à jour de l’OS
configuration du pare-feu
création et montage des volumes (un pour les données de PostgreSQL, un provisoire pour accueillir les dumps de l’ancien serveur
Installation de PostgreSQL et des paquets utiles aux extensions
Paramétrage et Tuning de l’instance PostgreSQL avec pg_tune
Isolement de l’ancien serveur
Arrêt des connexions sur l’ancienne instance (pg_hba.conf restrictif)
Arrêt de l’ensemble des tâches cron
Sauvegarde des rôles et des bases de données
26 bases de données sont servies par notre instance, la plus ancienne date de 2006 et elle est le point d’entrée de nos données métier dans le SI.
Restauration sur le nouvel hôte (une à une)
On commence par les rôles puis on restaure chacune des bases en redirigeant les messages d’erreur vers un fichier de log consulté en fin de processus
Mise en ligne du nouveau serveur
récupération de l’adresse IP de l’ancienne instance, de manière à ne pas casser les nombreuses paramétrages d’outils connectés à ce serveur
Test de connexion
Ouverture des accès (restauration du fichier pg_hba.conf)
Correction des erreurs rencontrées
Ces erreurs non bloquantes étaient toutes des erreurs rencontrées lors du peuplement des vues matérialisées. Certaines de ces vues utilisent des serveurs de données externe (FDW vers d’autres bases de l’instance) dont le port à changer avec la migration de l’instance. La modification du port des serveurs externes a permis de résoudre l’ensemble des erreurs.
Relance des tâches cron.
Ces tâches cron interrogent régulièrement des serveurs distants, PostgreSQL ou autres (ODK Central) pour collecter ou publier des données.
Bilan
Migration sans encombre et sans impact sur le travail de l’équipe. L’opération a débuté à 18h, une bonne pizza et une bonne playlist plus tard et le nouveau serveur et les services associés étaient fonctionnels le lendemain matin à 5h30.
Cette nouvelle architecture, non « dockerisée » permettra une montée de version plus aisée avec l’outil pg_upgrade.
I was invited to participate in the ODK 2025 summit, which focused on agriculture.
Thanks a lot to the ODK team and to the Bill & Melinda Gates Foundation for making this moment possible ! It’s always a privilege and a great pleasure to chat with the team and the community during these work sessions!
The team asked me to give a short presentation on our use of ODK over the last 10 years. Designing forms, sharing work…
You’ll find the summit report here, including a link to the obove slides.
This year I celebrate 10 years using ODK. From our first form to the 50 we use now, our way to design forms has evolved a lot as ODK did. This talk is a good occasion to draw a kind of big picture of this story
Who am I
Our team grew up as ODK and it has had some consequences on user needs discussions and form design. In the same time, ODK added great functionnalities, and we had to modernize some parts, without breaking old and proven dataflows. We started to copy/paste question blocks from our form « library » to create new ones.
This was the team in 2015. Easy to discuss together, one form designer (me). A simple directory was sufficient to manage the form library. Nathalie joined me to design forms and we introcuced a « changes » tab in our xlsforms. Each change was documented. Data analysis and mapping was mainly done within PostGIS (SQL based reports) with simple dblink/FDW access to Aggregate’s database
10 years later, it’s not the same game. 160 colleagues + ~ 20 trainees Discussing user needs has become more complicated and we dedicated a forum category to ODK forms. Since march of this year, we moved some of our forms directories to a git repo as we are now 5 colleagues who potentially design forms. Data analysis is stilll done within PostGIS. We use ODATA API and pyODK, both integrated into PG functions to create a kind of database replica to connect dashboards and mapping tools on.
Our first form was a kinf of field notebook to naturalist obervations : animals, plants, mushrooms, habitats, described on points, lines or polygons
It was sometimes too much complicated for users who simply wanted to map for example plant points. So in order to make it lighter and more efficient, we “hacked” the phone number question to encode the user’s preferences. For example, relevant question for plants (ex.) are only shown if the phone number contains number 5
Today, to achieve the same, we can use a block of question at form start. Those settings do persist between versions through #last-saved values. At the begining of the form, the user can ask to modifiy its preferences. When ODK team develops a new widget that can enhance user experience, we can introduce it in forms in a progressive way by adding one new question using this widget and calculate the non null value between the former and the new question, with no impact on the dataflow Here an example, in the foreground, with two questions to « select » a grid cell on a map (geopint + GIS vs. select from map)
This illustrates our most complicated form, adapted to 13 farm habitats evaluated according to 3 criteria / 33 indicators. Cristiano (our roman colleague) stands with a wine grower, in front of an hedge. This project, mainly funded by the European commission aims to enhance the ecological potential of farms. ODK is used for this ecological part of the diagnosis. It has been duplicated on a lizmap server to help users to modify / complete their data (geo) after submission. A good way to appriciate how easy it is to build forms with xlsform !
All the forms include some reusable parts : to identify the user, to set user’s preferences, to plot a point, to select from map from a geojson…
Building a new form make me think about a kid playing with bricks, like my nepheu on this picture.
The xlsform template help us a lot to normalize our forms and makes it really easy to reuse, adapat and share. We can now all use and adapt the same bricks ! This can help a lot of potential users to onboard !
Don’t hesitate to share your own forms and bricks with the community ! Over the forum or everywhere else ! Like we try to do with biodiversityforms.org, wich is a simple git based website. We need some more time to well document the forms but at least they are publicly shared. And for people lookink for a more academic way to share their forms as protocoles, a website like https://protocols.io is a great solution : Inventaires et suivis floristiques par maille
Thanks you so much for making this meeting possible Thanks you so much for the discussions, the coffee, the smiles ! And let’s play ODK together !
L’OREME a choisi de parler d’ODK à l’occasion de son vingtième « apéro technique ».
J’y étais invité pour présenter la solution. Pierre Balzergue (G-EAU), Amélie Fargevieille (CEFE), et Bruno Bonté (G-EAU) ont quant à eux présenté 3 cas d’utilisation très différents (suivi d’impact des inondations, suivi de piézomètres en Algérie, suivie nichoir de mésanges charbonnières et mésanges bleues).
Voilà un mois que j’ai eu la chance de participer au sommet ODK organisé à Londres grâce au soutien de la Fondation Bill & Melinda Gates.
J’étais très excité, impressionné et je dois l’avouer un petit peu stressé à l’idée de rencontrer d’autres utilisateurs assidus de la solution, ainsi que l’équipe de développement.
Excité car voila 8 ans que j’utilise la solution au CEN Occitanie, 6 ans que je suis actif au sein de la communauté ODK , que je m’y implique bénévolement (traduction, forum, réunion du TAB), et que j’y côtoie et apprécie de nombreuses personnes. J’allais pouvoir les rencontrer « en vrai », discuter avec elles, échanger.
Impressionné pour les mêmes raisons et aussi par les structures représentées et les échelles auxquelles elles utilisent ODK dans tant de domaines différents.
Un peu stressé enfin car le sommet se tenait en anglais… que je lis et écris sans trop de difficulté mais écouter et parler ne sont pas lire et écrire. Ma pratique orale de l’anglais se limite au réunions mensuelles du TAB et aux séries en VO…
Merci donc à Aurelio et Tino pour l’immersion progressive le soir de notre arrivée 😉
Merci à toutes et tous pour votre indulgence, votre bonne humeur et nos échanges.
Merci à Hélène L. et Hélène M. pour les discussions off en français… Vous avez sauvé de la surchauffe une partie de mes neurones 🙂
Merci à Gareth, Florian et Andrew pour vos retours d’expériences sur la [vege|mar]mite
Merci bien sûr à l’équipe de nous avoir concocté un tel programme.
Les discussions furent à l’image de ce qu’elles sont sur le forum : riches, ouvertes, concrètes, attentives.
Ce fut vraiment passionnant de découvrir les différents cas d’utilisation présentés par des institutions de divers domaines : santé, accès aux soins, lutte contre la malnutrition, cartographie d’urgence, lutte contre la pollution plastique, santé vétérinaire, qualité de l’air, maintenance d’installations industrielles, cartographie de sentiers de randonnée…
La présentation de la feuille de route d’ODK et le focus sur les entités ont permis à tous les participants de pouvoir discuter ensuite en ayant le même niveau d’information et la même perspective.
Au delà de ma motivation à participer plus encore à cette communauté et à promouvoir ODK, ces 3 jours m’ont donné envie de continuer à pratiquer l’anglais pour pouvoir plus facilement discuter avec tous et mieux saisir les détails des discussions. Je vais donc certainement retourner dépenser ce qu’il me reste de CPF au French American Center de Montpellier qui m’avait aidé l’an dernier à préparer mon arrivée au sein du TAB.
3 jours c’est long mais c’est court aussi quand on veut prendre le temps de discuter avec tout le monde. Ce que je n’ai pas pu faire. Donc si une prochaine occasion se présente j’espère avoir le temps de discuter avec Dan avec Kevin ainsi qu’avec les membres de l’équipe de GetODK qui nous aident tant dans nos missions quotidiennes.
La synthèse publiée par l’équipe reflète la richesse de nos échanges et la complémentarité de nos usages divers d’ODK.
Nous avons eu des discussions passionnantes sur de nombreux sujets : les entités, les aspects « géo » et « carto », les bonnes pratiques, leur partage au plus grand nombre, la formation, les sciences citoyennes…
De nombreuses discussions qui nous concernaient finalement tous, que nous travaillions dans le domaine de la conservation de la nature, de la santé ou de l’industrie. Ces différences nous ont permis de sortir de ces moments d’échange avec des objectifs et des expressions de besoins les plus étayées possibles dont l’équipe va s’emparer.
Enfin un dernier merci pour le post-it de remerciements à mon attention sur l’un des panneaux de brainstorming.
Un nouvel ensemble de fonction pour récupérer automatiquement les données de vos formulaires ODK dans votre base de données #PostgreSQL.
Ce nouvel ensemble de fonctions utilise pyODK (https://github.com/getodk/pyodk) dans des fonctions pl/python et permet l’utilisation de filtres (ex les données envoyées il y a moins de 48h). Le principe est le même qu’avec Central2PG, une tâche planifiée interroge à la fréquence voulue le serveur ODK Central.
Lors du premier appel les tables qui accueilleront les données sont créées dans la base de destination et sont remplie. Lors des appels suivants, si de nouvelles questions ont été ajoutées au formulaire, les colonnes correspondantes sont ajoutées aux tables, et les nouvelles données intégrées.
Vous trouverez dans ce dépôt un exemple complet : – une image docker (de test) d’un serveur PostgreSQL avec les fonctions – un formulaire ODK vierge – les instructions pour récupérer les données dans PostgreSQL – les instructions pour créer une tâche planifiée – les instructions pour afficher les afficher dans QGIS)
Comme pour l’article de Florian Mayer publié sur le forum d’ODK, il est question ici de suivi de tortues,
mais en France et sur une espèce d’eau douce, la Cistude d’Europe, Emys Orbicularis.
Même si la tortue Caouanne fait son retour sur nos plages de méditerranée, un suivi tel que celui mis en place en Australie n’est pas encore nécessaire 😉
Pour suivre le populations de cistude, les collègues posent les pièges le premier jours de la semaine, qu’ils relèvent les 3 jours suivants.
Les individus capturés sont marqués (s’ils ne le sont pas déjà) et mesurés. L’ensemble des information est actuellement noté sur une fiche papier.
Au cours du printemps 2022, Vivian Millet, en stage de formation Idgéo a developpé un formulaire dédié à ce protocole.
Au cours des discussions avec les collègues en charge du terrain, ils nous ont expliqué que les pièges changent de place toutes les semaines, et qu’un suivi plus fin de leur emplacement serait utile.
Jusqu’à maintenant, le numéro du piège était reporté sur la fiche de capture. Et les pièges localisés à la main sur une carte.
Nous avons proposé de gérer ce référentiel de pièges dans ODK, et de mettre à jour la liste des pièges mobilisables dans le formualire de capture quand ils sont déplacés.
Nous avons donc développé un formualire dédié à la pose des pièges.
Une fois ce formualire fonctionnel, nous avons voulu adapter ce test et le rendre aussi automatique que possible.
L’idée générale est la suivante :
si les pièges sont déplacés (= si on utilise le formulaire de pose de pièges)
alors on met à jour le référnetiel des pièges utilisés dans le formulaire de capture (= on génère ce référentiel avec les nouvelles données et on l’envoi à ODK Central)
et on met à jour le formulaire (= on publie une nouvelle version)
Mise ne oeuvre
C’est parti !
Nous avons donc développé deux formulaires :
_CMR_Cistude_pose_pieges_ utilisé pour la pose des pièges
et _CMR_Cistude_captures_ utilsisé pour le suivi des individus capturés
Toutes les requêtes SQL présentées ci-dessous sont executées dans notre base de données "métier". Rien n’est exécuté dans la BDD de Central à laquelle nous ne touchons jamais.
Nous utilisons une tâche cron (tous les jours à 22h) qui exécute les requêtes suivantes :
Nous utilisons pour cela les fonctions de central2pg, placées dans le schéma _data_fromcentral schema pour récupéréer les données relatives aux pièges :
SELECT data_from_central.data_from_central_to_pg(
'my_login','my_password','my.central.fdqn',5,
'CMR_Cistude_pose_pieges', -- form ID
'data_from_central', -- schema where to create tables and store data
'point,point_auto' -- columns to ignore in json transformation to database attributes (geojson fields of GeoWidgets)
);
Nous avons créé une vue appelée _cmr_cistude_pose_pieges_sessioncourante qui retourne seulement les pièges posés lors de la dernière sessions (max(date)).
Le resultat de cette vue est copié dans un fichier geojson, dans un endroit accessible en écriture à l’utilisateur postgres. (commande COPY TO…)
Pour le moment, cette requête est executée même s’il n’y a pas de nouveau piège.
COPY (
WITH places AS (
SELECT id_piege, label, value, geometry
FROM data_from_central.cmr_cistude_pose_pieges_session_courante
)
SELECT
json_build_object(
'type', 'FeatureCollection',
'features', json_agg(ST_AsGeoJSON(t.*)::json)
)
FROM places AS t
) to '/home/postgres/medias_odk/pieges.geojson';
Nous utilisons un numéro de version de formulaire que nous avons souhaité "porteur d’information".
Il est composé de l’année sur 4 caractères à laquelle nous concaténons le numéro du jour dans l’année (DOY) sur 3 caractères (complété par des 0 à gauche).
concat(extract(YEAR FROM date_max),lpad(extract(DOY FROM date_max)::text,3,’0′))
Nous comparons ensuite la version courante du formulaire avec son "hypothétique" nouvelle version.
Si cette dernière est plus grande que l’actuelle, nous créons un brouillon de formulaire.
Pour cela et pour les autres étapes, nous avons ajouté de nouvelles fonctions à la bibliothèque "central2pg"..
SELECT data_from_central.create_draft('my_login','my_password','my.central.fdqn',5,'CMR_Cistude_captures')
FROM data_from_central.cmr_cistude_pose_pieges_session_courante
WHERE concat(extract(YEAR FROM date_max),lpad(extract(doy FROM date_max)::text,3,'0')) > data_from_central.get_form_version('my_login','my_password','my.central.fdqn',5,'CMR_Cistude_captures')
LIMIT 1;
Une fois le brouillon créé, nous poussons le geojson comme pièce jointe à ce brouillon.
SELECT data_from_central.push_media_to_central('my_login','my_password','my.central.fdqn',5,'CMR_Cistude_captures', '/home/postgres/medias_odk', 'pieges.geojson')
FROM data_from_central.cmr_cistude_pose_pieges_session_courante
WHERE concat(extract(YEAR FROM date_max),lpad(extract(doy FROM date_max)::text,3,'0'))::integer > data_from_central.get_form_version('my_login','my_password','my.central.fdqn',5,'CMR_Cistude_captures')::integer
LIMIT 1;
Et nous publions la nouvelle version 😉
SELECT data_from_central.publish_form_version('my_login','my_password','my.central.fdqn',5,
'CMR_Cistude_captures', concat(extract(YEAR FROM date_max),lpad(extract(doy FROM date_max)::text,3,'0'))::integer )
FROM data_from_central.cmr_cistude_pose_pieges_session_courante
WHERE concat(extract(YEAR FROM date_max),lpad(extract(doy FROM date_max)::text,3,'0')) > data_from_central.get_form_version('my_login','my_password','my.central.fdqn',5,'CMR_Cistude_captures')
LIMIT 1;
Suite aux discussions sur le formualire « 2020 » une série d’améliorations ont été apportées au formulaire « Sicen ». Le détail est à voir ici (en anglais) :
Et c’est la version 14 de TAXREF qui est intégrée et que vous retrouverez dans les listes.
Voici donc un tutoriel, sous forme de captures d’écrans, allant de la configuration d’ODK Collect à la fin de la saisie d’une donnée dans le formualire.
Évolution technique d’ODK
Avant de commencer, un (tout petit) peu de contexte technique. ODK a remplacé le serveur Aggregate par un serveur plus moderne appelé Central. Cela est transparent pour vous mais entraîne quelques changements dans l’usage que vous faites de Collect. La mise à jour des formulaires sur votre téléphone est désormais automatique, tout comme l’envoi des données finalisées au serveur.
Pour ce qui concerne les géomaticiens, Central nous permet de gérer des groupes d’utilisateurs qui accèdent à différents formulaires (Bénévoles, prestataires, partenaires…).
Enfin, un des gros avantages de Central réside dans le fait que les formulaires réalisés pour vos téléphones sont aussi diffusés sous la forme de formulaires web (grâce à Enketo), utilisables eux aussi en mode déconnecté.
Nous pouvons donc désormais utiliser ODK pour lancer des enquêtes web participatives, ou des sondages relatifs à un évènement particulier, en remplacement des framaforms et autres limesurvey.
Tout d’abord, la connexion au serveur de formulaires (nommé Central) se fait par le scan d’un QRcode qui vous a été ou vous sera fourni
Paramètres
Configurer par QRCode
Une fois le code scanné, votre application est configurée et interroge le serveur pour savoir quels formulaires sont disponibles, et les télécharge.
Identité de l’utilisateur
Il nous faut maintenant renseigner les données d’identification qui permettront de vous faire connaitre une fois pour toutes dans les différents formulaires et de vous attribuer correctement vos données.
→ Veillez à renseigner l’adresse mail en minuscules.
Cartes → Choisir Mapbox
Autres paramètres utiles
De retour sur l’écran des paramètres, vous pourrez modifier :
la taille de la police qui sera utilisée dans les formulaires
la manière de naviguer d’un écran à l’autre
en faisant glisser le doigt sur l’écran de gauche à droite pour avancer et de droite à gauche pour reculer
en affichant des boutons en bas de l’écran
en utilisant les deux méthodes
Vous êtes maintenant prêts à saisir votre premier formulaire. ODKCollect est configuré pour proposer systématiquement les dernières versions des formulaires disponibles sur le serveur.
Saisie de données
Sur la page d’accueil de l’application, cliquons sur Remplir un formulaire
Choisissons Sicen
Les 3 premiers écrans vous présentent le paramétrage de l’application. A la première utilisation, les fonctionnalités seront toutes activées par défaut. Libre à vous de désactiver celles qui vous semblent provisoirement ou définitivement inutiles. A l’utilisation suivante, chacune des fonctionnalité sera proposée dans l’état d’activation ou elle était lors de votre dernière utilisation. Vous pourrez là encore valider ou modifier chacun de ce choix. Les fonctionnalités désactivées ici seront masquées pendant votre utilisation du formulaire.
Écran de paramétrage n°1 → l’identité de l’utilisateur
Les champs sont remplis par défaut avec les valeurs saisies dans les paramètres généraux de l’application (voir début de ce tutoriel)
Écran de paramétrage n°2 → types de géométries créées
points
lignes
polygones
Écran de paramétrage n°3 → Types de données (thématiques) et paramétrage de l’autocomplétion
La dernière question vous permet de choisir le nombre de caractères à saisir dans le recherche des espèces avant de déclencher l’interrogation du référentiel. 3 est le minimum, 7 le maximum (pour permettre l’utilisation du « code taxon » par exemple « ERI RUB »)
Une fois les paramétrages vérifiés et ou modifiés vous pouvez
Choisir l’étude
A terme nous aimerions générer dynamiquement et régulièrement cette liste d’études pour ne faire apparaître que les études en cours et pourquoi pas que celles qui concernent l’utilisateur de l’application
Choisir le protocole
Ici aussi, nous devrions pouvoir limiter la liste des protocoles selon l’étude choisie ou l’utilisateur de l’application.
Une fois ces paramètres de « session » renseignés, nous pouvons commencer la saisie de données proprement dite.
Création d’une localité
Il s’agira d’un point, d’une ligne ou d’un polygone.
Le GPS peux vous aider à dessiner automatiquement lignes et contours, que vous pouvez aussi dessiner à la main sur l’écran.
Saisie d’une ou plusieurs observation à cet endroit
Une fois l’emplacement créé, nous allons pouvoir y créer autant d’observation que nous le souhaitons, de chacun des types d’observations autorisés dans les paramétrages du formulaire. Screenshot_2021-03-15-16-20-591080×1920 124 KB
Commençons par une espèce végétale. Vous pouvez saisir le nom de l’espèce ou son « code » composé des 3 lettres du genre suivies d’un espace et des 3 lettre de l’espèce (ex. ERI RUB).
Propositions des taxons de référence et des synonymes qui correspondent aux lettres tapées
D’abord les taxons de rangs supérieurs puis les espèces et sous espèces.
On peut aussi utiliser un code espèce compose ds 3 premières lettres du Genre et des 3 premières de l’espèce et le cas échéant des 3 premières de la sous-espèce :
Renseignement de l’effectif observé
Pour clarifier la collecte de données d’absence, nous avons ajouté une question explicite :Si le taxon n’a pas été vu, c’est qu’il était recherché et absent. Dans ce cas les questions relatives à la saisie de l’effectif ne seront pas affichée.
Mais si l’espèce a été observée, les écrans suivant (ou leurs homologues pour la Faune sont affichés)
Ici pour les espèces végétales il s’agit d’un effectif par classes d’abondance
Informations sur la « qualité » de la donnée
Notez que l’observation pourra être retrouvée dans la navigation du formulaire, avec l’heure de l’emplacement et l’espèce observée.
Renseignement de détails optionnels, prise de photo
Si oui on revient à la saisie d’une observation sur l’emplacement courant.
Si non il nous est proposé d’ajouter une nouvelle localité
Si oui on revient à l’ajout d’une localité (point, ligne ou polygone) Si non, on finalise le formualire en renseignant la présence d’éventuels accompagnateurs
Renseignement des accompagnateurs éventuels
Au fur et à mesure de la saisie, n’hésitez pas à utiliser l’icône de la disquette pour enregistrer le formulaire en cours sur votre téléphone.
Revenir sur des données précédemment saisies :
L’icône représentant une flèche montrant un point permet de naviguer dans les observations déjà saisie pour les vérifier ou les modifier.
Une fois ceci fait on peut aller au bout du formulaire et le marquer comme finalisé.
