CartOdroid outil d'aide à l'acquisition de données géographiques pour les ONG sur terrain déconnecté

Introduction

Les ONG ont besoin de connaitre leur territoire "sur le bout des doigts". Sans cela, elles ne pourraient orienter leur effort auprès des populations et des espaces prioritaires. Les informations sont en partie récoltées sur le terrain mais comment font elles lorsque ces territoires sont des zones mal desservies, voir dépourvues de technologie et réseau de communication internet (3G / 4G) ?

Nous allons dans un premier temps voir un protocole standard du processus de récolte d'information géographique sur le terrain ?

Ensuite nous présentons les avantages de Cartodroid, outil d'aide à la saisie terrain déconnecté.

1 - Récolter l'information géographique sur terrain sans connexion internet

Quels sont les choix en moyens humains et en matériel :

  • Seul, en équipe. On peut aussi impliquer les populations.
  • on a souvent à disposition des formulaires de saisie
  • Grâce à des capteurs : positionnement (GNSS, giro), type caméra (RVB, PIR, thermique), météo, sonde, compteur (plaque enterrée, laser etc...), sonore.

Évidement cela dépend de l'objectif mais on note que la diversité est grande.

  • On dispose potentiellement d'informations géographiques acquises précédemment lors d'une mission antérieure ou d'une source externe (par exemple le fond de carte OSM, une orthophoto acquise par drone, des images satellites, toute sorte de cartographie... )

Quelle est la méthode :

  • se localiser,
  • récolter les données par saisie manuelle ou automatique
  • passer à la localisation suivante (en évitant de saisir deux fois la même information).

2 - Que ce passe t-il avant et après la mission ?

Avant :

  • Prise de conscience de la nécessité d'une campagne de récolte d'information géographique
  • Préparer les supports cartographiques et des formulaires de saisi (semi automatique ou manuel), la méthode
  • formation et briefing les personnes qui vont participer à la campagne de récolte (définir les zones)

Après :

  • vérifier la qualité des données (homogénéité, exhaustivité, on évacue les erreurs, etc.)
  • intégrer les données récoltées dans un ensemble plus global (base de donnée)
  • utilisation d'outils d'aide à l'analyse et cartographie (SIG)

-> Décision

Quels outils peuvent aider à améliorer la fluidité de ce protocole, sachant qu' entre jeux : moyens humains, méthodes de saisie et des moyens techniques variés.

3 - Les outils d'aide à la récolte sur le terrain

En premier lieu, si on considère une approche la moins technologique, et bien on se repport sur le support papier. Alors l'outil FieldPaper semble le plus adapté.

Avantages

  • pas besoin d’électricité
  • coût de production est très faible (impression).

Inconvénients

  • nécessite un peu de préparation en amont de la campagne pour la création de l'atlas
  • en aval une lourde phase de contrôle et d'intégration.
  • Support cartographique à échelle statique et un fond de carte simple et épuré est nécessaire pour la lisibilité (souvent OSM).
  • Le papier s’abîme sous l'eau, se déchire, s'envole et se brûle.
  • risque d'erreur de saisie, lisibilité de l’écriture.
  • Il y a parfois duplication ou des "trous" d'information (quiproquo entre deux enquêteurs sur le partage de leur zone d'action).
  • Des difficultés à reporter sa localisation sur la carte papier.

Admettons maintenant que nous n'avons pas de contrainte technologique comme l'accès à l’électricité et donc nous pouvons utiliser d'autres outils ce qui permet d'avoir d'autres avantages et mais aussi d'autres inconvénients.

Applications sur smartphone

Les terminaux smartphones, tablettes et pocket PC sont des outils adaptés aux missions de récolte de données de terrain grâce notamment à un écran tactile et des applications de saisie de formulaire cartographiques. on en compte de nombreuses et dans le monde de l’open-source les plus réputées et prometteuses sont :

  • Cybertracker,
  • QField,
  • OSMAND,
  • OpenMapKit,
  • SMART
  • et bien d'autre

Avantages

  • Le coût matériel est relativement faible moins de (entre 50 et 200 € ) et le coût d'une licence logiciel (open source) est nulle.
  • Les formulaires de saisie peuvent être complexes et pas plus compliqués à saisir.
  • Grâce au numérique on profite des listes d’auto complétion ce qui accélère la saisie et permet d’éviter de erreurs,
  • Au cours de la saisie on dispose d'informations dynamique pour l'aide à la saisie (cartographie, images, bases de données, tout type de documents numérisés etc...).
  • On dispose des capteurs internes au terminal (camera, GPS, micro ...)
  • L'intégration des données récoltés en base de donnée et plus rapide (pas de double saisie)
  • Un terminal peut être tout terrain (enfin waterproof...) mais le coût est plus élevé.
  • Les performances d'accès aux ressources numériques mises en cache sont en général excellentes.

Inconvénients

  • Pré-configuration du terminal nécessaire avant le début de la mission (complexe si beaucoup de terminaux, encore plus si les terminaux ne sont pas dédié uniquement à cela).
  • Maintenance de l'installation de l'app sur le terminal.
  • L'adéquation de la Version OS et de l'App nécessite des tests de contrôle sur le smartphone suite à une nouvelle version de l'app ou de l'OS (le gros bordel des montées en version),
  • Les informations dynamiques à rendre disponible sur le terrain doivent impérativement être mise en cache sur tous les terminaux (lourd lorsque plusieurs terminaux sont utilisés).
  • Dans le cas d'un campagne en équipe, lors de la phase de récoltes les informations ne sont pas mises à jours sur les autres terminaux : risque de double saisie.

Les microcomputeurs (serveurs portables)

L'idée est de créer un réseau sur le terrain. On créé un hotspot wifi pour rendre accessible l'ensemble des données en cours de collecte ainsi que toutes les autres ressources. On obtient un réseau intranet en quelque sorte.

La croix rouge US à mis au point un serveur pour son application POSM

Avantages

  • Coût relativement faible (350€ environ). Serveur très performant (un peu trop ?). Roadmap : déploiement sur Raspberry Pi.
  • Adapté aux campagnes importantes de récolte avec plusieurs terminaux environs 15 smartphones connectés en même temps au serveur.
  • Mutualisation du stockage des données et des ressources, les informations SONT alors mises à jours sur tous les terminaux de saisi : aucun risque de double saisie.
  • Maintenance des données largement simplifiée.
  • Suite à la phase de saisie, une seule synchronisation est nécéssaire pour l'intégration des données récoltées sur la base de référence (OSM en l’occurrence).

Inconvénients

  • Nécessite l'usage de terminaux Android (coût supplémentaire)
  • Maintenance de l'App sur l'OS Android uniquement, ce qui implique que l'on évacue pas les inconvénients de l'usage d'une application sur smartphone.

et on ajoute que

  • La porté WiFi entre le serveur et les terminaux est limitée à une centaine de mètres, qui plus est contrainte par les masques (bâtiments).
  • Les performances d'accès aux ressources numériques sont réduites et contraintes par la bande passante du réseau WiFi.

Geoppopy/CartOdroid ce sont des microcomputeurs (Raspberry et Odroid).

L'idée est de créer un réseau sur le terrain. On créé un hotspot wifi pour rendre accessible l'ensemble des données en cours de collecte ainsi que toutes les autres ressources. On obtient un réseau intranet en quelque sorte.

Le projet Geoppopy fonctionne sur ce principe sous Raspberry Pi 2 et 3. Les applications coté serveur sont QGIS-Serveur, PostGis et Lizmap. L'administration du serveur est réalisée avec Docker (gros gain de temps pour les installations et la maintenance).

Le choix de Lizmap permet d'offrir une logique SIG aboutie et de disposer d'une continuité entre Qgis desktop et le terrain. On dispose ainsi des mêmes outils et projets sur le terrain qu'au bureau.

Des différences avec POSM :

  • c'est d'une part le matériel utilisé
  • le choix de déployer l'application coté serveur plutôt que sur le client. Le client c'est uniquement le navigateur internet du terminal.

Avantages

Les avantages sont similaires à ceux de POSM (on pourrait techniquement être déployé sur ce serveur et inversement, c'est d'ailleur ce qu'ils envisagent de faire). - Mutualisation du stockage des données et des ressources, les informations SONT alors mises à jours sur tous les terminaux de saisi en temps réel : aucun risque de double saisie. - Maintenance des données largement simplifiée. - Suite à la phase de saisie, une seule synchronisation est nécéssaire pour l'intégration des données récoltées dans la base de référence. - Très grande possibilité d'évolution et d'adaptation au cas particulier (intégration de capteur spécifiques, écran, télécommande ...) - Le serveur peut être administré à distance en SSH lorsqu'il est connecté a internet

et on ajoute que

  • Coût deux à trois fois plus faible que le serveur utilisé par la croix rouge US pour POSM.
  • On a pas d'application cliente (donc pas de maintenance sur différents système iOS android, windows),

Inconvénients

  • Nécessite néanmoins l'usage de terminaux (coût supplémentaire),
  • La porté WiFi entre le serveur et les terminaux est limitée à une centaine de mètres, qui plus est contrainte par les masques (bâtiments).

  • Les performances d'accès aux ressources numériques sont réduites et contraintes par la bande passante du réseau WiFi.

  • Le montage du serveur nécéssite l'intervention d'un admin system

  • L'administration du système se fait par un géomaticien

Le développement du projet CartOdroid

Mon projet conciste à améliorer Geoppopy tant dans son aspect matériel (plus de portabilité), que dans sa partie synchronisation des données (avec par exemple GeoGig. L'objectif est que le serveur soit plug-and-play mais aussi unplug-and-map :) et bien entendu de rester opensource.

Pourquoi porter le projet sur un autre serveur ?

Odroid est un concurent sérieux au Raspberry Pi (RPI). Son point fort est qu'il est plus puissant pour un prix équivalent.

Deuxièmement, l'Odroid est particulièrement bien adapté aux projets portables. C’est particulièrement vrai pour l'Odroid C0 car il embarque avec lui un module d'alimentation batterie Lipo. Faites l'achat d'une batterie et le serveur devient autonome (avec switch on/off intégré). Cela est évidement possible sur le Raspberry Pi (RPI), mais nécéssite l'adjonction d'une carte HAT, ou d'un ensemble de composant pour assurer un fonctionement simple. L'Odroid C2 doit aussi être équipé d'une telle carte supplémentaire mais celle-ci est disponible à l'achat contrairement au RPI pour lequel les ruptures de stock sont très fréquentes et où les prix sont finalement assez élevés.

Comparatif des coûts de base

  • odroid C0 (25 $)

  • odroid C2 (40 $)

  • raspberri Pi 3 (35 $)

Avec ajout d'un module pour l'autonomie

  • odroid C0 (12 $ ). Coût de la Batterie lipo 3000 mAp.

  • odroid C2 : USP3 (49 $). Le prix contient la carte HAT, une batterie lipo 3000 mAp + un chargeur secteur.

  • Raspberri Pi 3 (environs 70 $). Des cartes existes mais les stocks sont épuisés.

Il faut ajouter à cela un chargeur secteur 2A à 6$ (ou un cable USB uniquement pour charger sur une batterie portable : 2$ ).

Avec ajout d'un module wireless

Les odroids n'ont pas de wifi intégré alors que RPI3 intégre ce module. Comptez 8$ supplémentaire.

Récapitulatif

Materiel nécéssaire pour un Ordroid C2

Libellé Tarif $
ODROID – C2 40
ODROID – C2 USP 3 (batterie module contient bat 3A et chargeur secteur) 49
Wifi module 3 8
USB GPS Ublox 6010 chipset with a patch antenna 50-channel u-blox 6 engine 25

Materiel nécéssaire pour un Ordroid C0

Libellé Tarif $
ODROID – C0 25
Batterie 3000 mAp 12
Alimentation secteur 5v/2A 5,50
Wifi module 3 8
USB GPS Ublox 6010 chipset with a patch antenna 50-channel u-blox 6 engine 25

Développement kit

Libellé Tarif $
USB-UART connector kit 10

Frais de port et de douane (import Corée du Sud)

Libellé Tarif $
Frais de port 30
Frais de douane 30%

Stockage système

Les odroids sont équipés de la technologie emmc ce qui permet d'augmenter la vitesse de lecture et d'écriture sur la carte memoire. Mais celle ci à un coût supplémentaire (facultatif).

Libellé Tarif $
Carte SD classe 10, 16 go 10
Usb Stick mini 64 go 25
ou memoire eMMC
8GB eMMC Module C2 Linux Black 18
16GB eMMC Module C2 Linux Black 26
32GB eMMC Module C2 Linux Black 39
64GB eMMC Module C2 Linux Black 59
128GB eMMC Module C2 Linux Black 78

Conclusion

C'est odroid C0 qui revient le moins chers de tous mais les performances les meilleurs sont celles de l'Odroid C2. Le Raspberry pi 3 hors course tant que le module de batterie interne sera inaccessible. De plus Le RPI est légèrement moins performant que Odroid C2.
On s'apperçoit que les prix reste néanmois équivalents. Ce qui fait pencher la balance ce sont les performances (processeur, RAM et carte mémoire eMMC) ainsi que la disponibilité des composants pour le module d'autonomie.

Documentation - manuel

Pour faire fonctionner le projet sur une carte Odroid, il faut néanmoins ajuster la configuration initiale de Julien Ancelin pour garder la même logique efficace.

La documentation complète est disponible ici sur Read The Doc !

Réalisation d'un Proof of concept

  • J'ai réalisé et documenté le portage RPI -> Odroid C2 (Docker: QGIS, Postgis, Lizmap).
  • L'usage d'une batterie interne (3000mAp) permet d'avoir une autonomie de 2h d'activité environs (que l'on peut augmenter facilement grâce à l'utilisation de batteries USB. L'usage d'une batterie interne permet surtout d'éviter les extinctions inopinées qui peuvent causer des risques de perte de données en mémoire. En cas de batterie vide, le serveur s'éteind proprement, de manière automatique.

Précisions techniques et configuration initiale additive

  • Le serveur portable fonctionne de manière autonome (pas en multi-serveur), c'est le serveur Master, utilisé à la fois au bureau et sur le terrain. Cela signifie qu'actuelement la base de donnée de référence est hebergé sur ce serveur. Néanmoins, des backups peuvent être réalisés sur un autre serveur.
  • Un serveur de fichier Samba peut être installé pour effectuer les transfert de fichiers (projets Qgis) sur le réseau local.
  • Qgis desktop accède à la base Postgis directement via le protocole TCP/IP et peut éditer les données sur le serveur lorsqu'il est connecté au réseau local ou via la connection wifi directe.
  • Un DYNDNS a été parametré pour trasmettre l'envois de l'adresse IP de la box internet dans le cas ou le fournisseur internet applique des IP dynamiques (utile pour l'administration du serveur à distance via SSH).

Les suites à donner

  • du point de vue des performances, il faut encore évaluer le débit/temps d'affichage, la portée WiFi selon différent terrain, le nombre de terminaux potentiels connectés.

  • effectuer le POC sur ordoid C0 et comparer les performances.

  • fonctionnement multi-serveur : implémenter un module de synchronisation type GeoGig (Pull-Push et branche) pour interfacer le serveur portable à une base principale situé sur un serveur fixe.

  • création d'un boîtier pour Odroid C2/C0 (anti-éclaboussures mais pas hermétique à 100% : risque de chauffe et utilité potentiellement limitée au vu du coût, un tuperware peut faire l'affaire en cas de besoin tuperware
  • impression et montage de boutons plastiques pour switch ON/OFF adapté à l'Odroid C2/C0.
  • trouver une solution pour réaliser un shutdown propre (avec un bouton dédié interface web ?),
  • définir et ajuster le comportement réseau suite à plug-unplug du câble Ethernet.

Quelles retombées pour CartONG

Ce projet permet à CartONG de proposer la fourniture de materiel d'acquisition ou de suivi SIG aux équipes des ONGs déployées sur des terrains difficiles. Les coûts du materiels étant faibles, il est simple d'en faire profiter les ONG qui n'ont pas toujours connaissance de ces outils. CartONG se positionne ainsi comme founisseur et support de l'outil.

Les potentialités des microcomputeurs sont immenses et POSM ou CartOdroid n'en sont qu'une expression. Ce projet a de forte potentialité d'innovation et sera amené à être amélioré pour répondre à des usages encore plus spécifiques.

Équipe développement et budget de développement du projet

Je ferai en sorte d'impliquer le créateur du projet Geoppopy Julien Ancelin (INRA), des bénévoles CartOng, d'autres utilisateurs de cette solution et d'un réseau géomatique opensource plus large.

Pour la partie matériel, je ferai une présentation du projet au Fablab de Toulouse pour obtenir de l'assistance dans la conception de :

  • l’électronique (switch on/off)
  • de la conception de boîtiers et bouton plastique avec imprimante 3D et/ou découpe laser (qui sera facturé par le FabLab)

Des frais de mise en service la version démo seront facturés 300€ HT par Geodatup, hébérgé dans la SCOP de la Maison de l'iniative à Toulouse afin de soutenir financièrement le développement du projet.

Des frais de présentation / communication / frais communication / déplacement, seront facturés à hauteur de 300€ HT par Geodatup afin d'assurer un minimum la finalisation la documentation, réalisation des supports de présentations du produit avec et auprès des bénévoles qui le souhaite.

Des frais de développement des fonctionnalités supplémentaires suivantes seront facturés par Geodatup :

  • programmation de la fonction de la mise sous tension / hors tension avec le bouton « shutdown » : 100€ HT
  • mise en place de la fonction multi-serveur avec synchronisation (GeoGig ?) : 300 € HT

Les tests fonctionnels seront des essais réalisés par une ou deux ONG du réseau CartOng. Je serai en support bénévole durant les tests, accompagné des autres bénévoles de CartOng ayant souhaité participer au projet.

Je fais la gestion du projet (Hugo Roussaffa) avec les bénévoles qui le souhaitent.

Méthode et outils de communication et suivi de projet

  • Forge : Github
  • Gestion des taches, bugtracking : Zoho project, Github
  • Communication : Trello, mail, googlegroup
  • Documentation : Readthedoc, Github

Calendrier (6 mois)

3 points d'étapes rythmerons le projet. Ce seront des points de suivi de projet sous forme de comité de pilotage avec un représentant de CartOng / une ONG test / l'équipe de développement.

La liste suivante à pour but de donner une idée du calendrier mais pourra être amenée à évoluer.

  • GO / NO GO : validation du projet par CartOng semaine O
  • contact Julien Ancelin (Geoppopy) semaine O
  • communication : présentation / recrutement bénévole, semaine 1
  • communication : materiel de présentation interne/externe, semaine 1-2
  • communication : présentation du projet auprès d'ONGs, semaine 2-3
  • point d'étape (GO / NO GO) : retour sur le démarage du projet, l'étude de marché. Une ou deux ONG seront ciblées pour être testeur/cobaye semaine 4
  • commande materiel (facturé) semaine 4-5
  • développement : mise en place du serveur de développement / demo (facturé)semaine 6
  • communication : présentation / recrutement bénévole,semaine 7
  • communication : présentation Fablab Toulouse,semaine 7
  • développement : conception / création boitier (facturé)semaine 8
  • développement : conception / création bouton ON/OFF pour alimentation (facturé)semaine 8
  • développement : fonction de la mise sous tension / hors tension avec button shutdown (facturé)semaine 9
  • point d'étape (GO / NO GO) : Avancement projet, évaluation réelle du coût de prodution materiel semaine 9
  • développement : fonction synchro GeoGig ou autre (facturé) semaine 9-12
  • développement : fonctions supplémentaires (hors budget) semaine 13
  • tests unitaires semaine 14
  • documentation : manuel semaine 15
  • tests fonctionnels : envoi d'un cartOdroid à une ONG (don ?) semaine 16-20
  • tests fonctionnels : retour tests et ajustement semaine 21-22
  • développement de nouvelles fonctionnalitées semaine 22-23
  • communication : présentation du projet auprès d'ONGs semaine 24
  • point d'étape (GO / NO GO) : mise en production auprès de nouvelles ONGs semaine 25