Le commencement de cet article date du 2 février 2020, jour de « lucky day » en Asie*. Je discutais avec un ami d’enfance vivant à Singapour qui me rapportait que de nombreuses cérémonies sont malheureusement annulées à cause de l’épidémie du Coronavirus. Dans cet article, on fait comme tous les médias, le sujet traité est le Coronavirus. Mais, l’objectif n’est pas de faire du sensationnalisme, ni d’alimenter une psychose. On parle bien entendu de carte du Coronavirus et des outils des Systèmes d’Informations Géographiques (SIG) associés. Par ailleurs, tout le monde a dû voir le « big buzz » médiatique lié à une carte du Coronavirus élaboré par le Center of Systems Sciences and Engineering (CSSE) de l’Université de médecine Johns Hopkins. Cette dernière, fondée en 1876, se situe à Baltimore dans l’État du Maryland aux États-Unis.

Pour ma part, plusieurs choses m’ont chagriné concernant ce SIG:

• La première est que la carte du Coronavirus construite par le CSSE est hébergée sur un serveur cartographique propriétaire et donc non libre.
• D’autre part, les données géographiques des cas recensés du Coronavirus ne sont pas mises à disposition au public. Certes, si on lit le blog des créateurs du tableau de bord SIG, on note que le travail de recensement des cas de Coronavirus, issus de différentes sources, doit être relativement chronophage. Mais, quitte à diffuser de la donnée spatialisée, concernant de surcroît une cause mondiale commune, autant le faire jusqu’au bout! N’est-ce pas?

Plan de la chaîne de traitements de données

En outre, l’idée de cet article est de construire une chaîne de traitements à l’aide de différents outils SIG Open Source. En clair, notre système prend en charge des sources de données externes de manière automatisée à une échelle de temps régulière. Puis, on bancarise ces données. Enfin, elles sont diffusées aux utilisateurs via les protocoles HTTP WMS et WFS. Par extension, le process construit est reproductible pour de nombreuses thématiques.

• I. Base de données des cas de Coronavirus
• I.1. Lecture des données géographiques du Coronavirus en format JSON depuis une URL
• I.2. Création de la table PostgreSQL / PostGIS des cas de Coronavirus
• I.3. Import quotidien des données du Coronavirus dans la base de données
• II. Carte du Coronavirus avec GeoServer et OpenLayers
• II.1. GeoServer : publication des données du Coronavirus
• II.2. Carte du Coronavirus : Interface avec OpenLayers
• III. Discussions sur la carte du Coronavirus en direct
• III.1. Faiblesses de la chaîne de traitements de données
• III.2. Carte du Coronavirus : les atouts du procédé mis en place

I. Base de données des cas de Coronavirus

I.1. Lecture des données géographiques du Coronavirus en format JSON depuis une URL

Dans la majorité des cas, les données géographiques affichées sur une cartographie interactive sont au format JSON ou XML. Par l’examen des réseaux de la page internet, on recherche donc la provenance de ces données. Puis on s’assure qu’elles sont accessibles. A titre d’exemple, le script suivant en langage Python permet de lire et de décoder les données JSON depuis une URL.

#!/usr/bin/python3

import urllib.request
import json

url = 'https://...';
with urllib.request.urlopen(url) as dataurl:
	datajson = json.loads(dataurl.read().decode())
	print(datajson)

Bien entendu, il est possible de lire les données en format JSON depuis une URL avec d’autres langages de programmation comme par exemple le PHP et le JavaScript. De manière générale, la lecture de données montrent soit :

1. des situations géographiques en format textuel tels un nom de pays, de région, de ville, etc;
2. des coordonnées géographiques avec les longitudes et les latitudes.

Pour créer une géométrie (point, ligne, polygone, etc) à partir de ces données géographiques, il faudra dans le premier cas s’appuyer sur une table de référence. En effet, cette dernière sert à fournir les géométries des entités géographiques correspondantes aux noms du ou des situations géographiques retournées depuis l’URL. Dans le second cas, les coordonnées géographiques sont transformées en géométrie de type point à l’aide de fonctions PostGIS.

Dans notre cas, les deux solutions sont possibles pour créer une géométrie. Toutefois, pour des raisons de facilité -et de manque de temps-, on choisit de transformer les coordonnées géographiques en géométrie ponctuelle.

Donc, après l’observation des données, on construit une table dans le SGBD PostgreSQL afin de les bancariser.

I.2. Création de la table PostgreSQL / PostGIS des cas de Coronavirus

Dans cette section, on créé la table PostgreSQL / PostGIS appelée « coronavirus » dans le schéma « sante » d’une base de données. Le choix des champs de la table dépend des données retenues lors de l’import. Ainsi, de manière spécifique pour cette étude de cas, le code SQL ci-après possède des champs :

• de situation géographique en format texte concernant les pays et les provinces des cas de Coronavirus;
• numériques montrant l’état des personnes ayant contracté le virus. Les trois états de santé sont : cas de coronavirus confirmés, décès liés au coronavirus, guérisons du coronavirus;
• des coordonnées géographiques. Les latitudes et longitudes retournées ont une précision de 14 décimales;
• date de type timestamp qui stocke la date de bancarisation des données.

En outre, on considère quelques règles reproductibles :

• la création d’un identifiant unique de type Serial. Ce type créée une séquence. Le champ « gid » constitue aussi la clé primaire;
• l’affectation d’un ou des utilisateurs avec des droits particuliers sur la table;
• la définition du champ de la ou les géométries retenues pour l’entité géographique. Ici, la géométrie est un point dans la projection EPSG 4326;
• Enfin, la création d’un index sur la ou les colonnes requêtées dans les applications afin d’optimiser les temps de prises en charge.

-- Table: sante.coronavirus

-- DROP TABLE sante.coronavirus;

CREATE TABLE sante.coronavirus -- Table des cas de coronavirus dans le monde (source : CSSE/JHU; OMS)
(
  gid SERIAL PRIMARY KEY, -- Identifiant unique
  country_region character varying(255), -- Pays des cas de coronavirus recensés
  province_state character varying(255) DEFAULT NULL, -- Province
  confirmed integer, -- Cas de coronavirus confirmés
  deaths integer, -- Décès liés au coronavirus
  recovered integer, -- Guérisons du coronavirus
  latitude numeric(16,14), -- Latitude
  longitude numeric(17,14), -- Longitude
  date_actualisation timestamp without time zone, -- Date de la mise à jour des données
  geom geometry(Point,4326) DEFAULT NULL, -- Géométrie du point en EPSG 4326
  CONSTRAINT coronavirus_pkey PRIMARY KEY (gid)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE sante.coronavirus OWNER TO user;

CREATE INDEX coronavirus_geom_idx ON sante.coronavirus USING GIST(geom);

On exécute enfin le script SQL afin d’implémenter la table dans la base de données.

I.3. Import quotidien des données du Coronavirus dans la base de données

Dans un premier temps, on réalise un script afin d’importer les données géographiques dans la table « sante.coronavirus » créée précédemment. En Python, le module psycopg2 permet de manipuler les données avec PostgreSQL. Puis, la requête SQL utilisée est une insertion de données. Les fonctions PostGIS ST_SetSrid et ST_MakePoint définissent respectivement une projection géographique à la géométrie et créent une géométrie ponctuelle.

ST_SetSrid(ST_MakePoint(%(longitude)s,%(latitude)s),4326))

La source de données du Conoravirus en JSON indique des dates d’actualisation aléatoires. Ainsi, on décide de déclencher le script d’importation et de bancarisation dans PostgreSQL tous les jours. Pour cela, un planificateur de tâches sur Windows ou un crontab sur Unix est défini. Pour cette étude de cas, on déclenche le script Python tous les jours à 5h AM. Sur le fichier crontab crontab –e, on saisit la ligne :

0 5 * * * REPETOIRE_PYHTON/bin/python3 REPETOIRE_APP/fichier.py

Enfin, on note que l’insertion quotidienne n’écrase pas les anciennes données des cas de Coronavirus. L’idée est de pouvoir réaliser une série temporelle à des fins statistiques par exemple. Par conséquent, la création d’une vue prenant en charge les données de la dernière date assure une observation en temps réel (Figure 1). Dans notre cas, on nomme cette vue « coronavirus_last » intégrée dans le schéma « sante ».

A ce stade, la chaîne de traitements est mise en place. On peut désormais s’occuper de la carte du Coronavirus.

II. Carte du Coronavirus avec GeoServer et OpenLayers

Dans cette section, on diffuse les données géographiques du Coronavirus en WMS et WFS sécurisés. Puis, ce dernier protocole HTTP est appelé pour afficher les cas de Coronavirus sur une carte interactive.

II.1. GeoServer : publication des données du Coronavirus

GeoServer est un serveur cartographique Open Source basé sur les standards de l’OGC. Tout d’abord, on créé un espace de travail nommé « sante ». Puis, un entrepôt de type PostGIS garantie la connexion à la base de données. On publie les tables spatiales « coronavirus » et « coronavirus_last ».

L’avantage de GeoServer par rapport à QGIS Server par exemple est la mise en place d’une politique de sécrurité sur les données et sur les différents services (WMS, WFS, etc). Ici, on créé un utilisateur pouvant lire les données du Coronavirus issues des deux tables en WMS et WFS. Et, pour le WFS, seul un accès en lecture est autorisé.

Le logiciel QGIS affiche les données du Coronavirus en WMS et WFS. Pour cela, il suffit d’éditer les détails de connexion des protocoles HTTP :

• le WMS : l’URL est https://map.geomatick.com/geoserver/sante/wms ;
• le WFS : l’URL est https://map.geomatick.com/geoserver/sante/wfs ;
• les deux protocoles, l’authentification de base est pour l’utilisateur : Enjoy et le mot de passe : YourLife .

Pour l’appel de la vue « coronavirus_last » en WFS, on note un bug non présent dans la prise en charge de ce protocole via OpenLayers.

II.2. Carte du Coronavirus : Interface avec OpenLayers

La construction d’un tableau de bord simplifié montre le suivi quotidien du Coronavirus dans le monde. On y retrouve :

• les dernières données globales des cas de Conoravirus avec les cas confirmés, les décès et les guérisons;
• ensuite, un tableau listant les dernières données par pays et par province/État;
• une carte du Coronavirus;
• enfin, un graphique montrant l’évolution quotidienne des cas confirmés du Coronavirus, des décès et des guérisions dans le monde.

Les principales API Open Source pour réaliser des cartes interactives sont OpenLayers et Leaflet. Ici, on utilise OpenLayers pour charger les données vectorielles en WFS. Des exemples liés au WFS sont disponibles sur le site d’OpenLayers. De plus, pour lire le WFS sécurisé, il ne faut pas oublier de spécifier l’authentification dans le headers pour retourner les objets.

Enfin, toutes les données des cas et la carte du Coronavirus sont mises à jour quotidiennement.

III. Discussions sur la carte du Coronavirus en direct

Dans cette section, on discute des faiblesses et des atouts de la mise en œuvre de la chaîne de traitements de données pour la réalisation de la carte du Coronavirus en direct.

III.1. Faiblesses de la chaîne de traitements de données

Les faiblesses de la chaîne de traitements de données observées à ce jour sont :

1. La dépendance liée à la source de données externe. En effet, ici, on décide arbitrairement d’alimenter la base de données à partir d’une URL externe. Comment savoir si le robinet ne sera pas coupé demain? De nombreux facteurs pourraient provoquer l’arrêt de l’import des données. Par exemple, on peut citer des changements de libellés des champs, un changement d’URL ou encore l’arrêt du service externe.
2. Comme expliqué dans la section 1.1., les géométries ponctuelles sont basées sur les coordonnées géographiques obtenues dans le JSON. Or, pour la carte du Coronavirus, la prise en charge de géométries polygonales correspondant à celles des pays concernées favoriseraient la mise en place d’une symbologie claire.
3. En outre, la symbologie des couches en WMS est inexistante.
4. Le tableau de bord des cas de Coronavirus est minimaliste. Par exemple, une seule couche SIG regroupe toutes les informations sur les cas de Coronavirus. Il faudrait afficher les cas confirmés, les décès et les guérisons. A venir…
5. Enfin, la dernière faiblesse, si cela en est une, est le temps de mise en place de cette chaîne de traitements de données. Ici, de l’import des données jusqu’à l’affichage des données, on a fait au plus simple pour des questions de temps. Si on veut réellement créer un procédé complet, de nombreux éléments pourraient être développés comme une API par exemple.

III.2. Carte du Coronavirus : les atouts du procédé mis en place

Les atouts du procédé mis en place pour la réalisation de la carte du Coronavirus sont :

1. L’automatisation de la chaîne de traitements est complète. En clair, une fois les outils SIG installés, configurés et développés, l’importation des données du Coronavirus est automatique. Il en va de même pour les données diffusées en WMS et WFS ainsi que pour la carte du Coronavirus.
2. Puis, tous les utilisateurs peuvent exploiter les données du Coronavirus librement à partir du protocole WFS.
3. Ensuite, cette chaîne de traitements de données est totalement reproductible dans de nombreuses thématiques tels l’Environnement, le BTP, l’Urbanisme, le Foncier, l’Agriculture, etc.
4. Et enfin, tous les outils utilisés ici sont libres et Open Source : Serveur Debian, PostgreSQL / PostGIS, Apache, Tomcat, GeoServer, OpenLayers.

En conclusion, vous pouvez utiliser les protocoles WMS et WFS des données du Coronavirus et exploiter les data pour réaliser une carte du Coronavirus. Je serai également reconnaissant de lire vos critiques constructives ou tout simplement vos commentaires, voire vos études sur le sujet.

*Pourquoi cette date est considérée comme un « lucky day »? Tout simplement car elle est un parfait palindrome dans le monde entier. En effet, pour les différents formats de date employés, le 2 février 2020 est caractérisé par une symétrie. Les systèmes de date les plus courants s’écrivent JJ/MM/AAAA ou AAAA/MM/JJ. En ce jour, on a donc : 02022020 ou 20200202 et dans les deux cas, on observe un parfait palindrome à huit chiffres. Bref, on s’écarte du sujet mais comme il faudra attendre 101 ans pour retrouver un fait similaire, cela méritait d’être souligné. 101 ans, c’est loin et ce n’est pas dans les préoccupations immédiates de la population mondiale.

Pour information, les deux prochains articles SIG seront liés aux WFS-Transactionnel et au drone.