Vous l’avez manqué ? Sachez que notre guide dédié à la programmation de scripts shell est actuellement de retour en kiosque ! Au menu : une première partie qui vous permettra de mettre le pied à l’étrier en programmant votre premier script shell, vous passerez ensuite aux choses sérieuses en vous frottant aux structures de contrôle et à la gestion de processus, et pour finir vous découvrirez les fonctions avancées du shell Bash et les bonnes techniques à adopter. Un cas pratique vous attend en bonus de ce hors-série. Retrouvez ce numéro spécial chez votre marchand de journaux, sur notre boutique en ligne ainsi que sur notre plateforme de lecture en ligne Connect !

Au sommaire

1 – PROGRAMMEZ VOTRE PREMIER SCRIPT SHELL : BIEN PLUS QU’UN SIMPLE FICHIER DE COMMANDES

p. 08 Écrivez votre premier script « Shell »

2 – PROGRESSEZ DANS L’ÉCRITURE DE SCRIPTS GRÂCE AUX STRUCTURES DE CONTRÔLE ET À LA GESTION DE PROCESSUS

p. 44 Utilisez les structures de contrôle et autres mécanismes de la programmation « Shell »

p. 76 Gérez vos processus et sous-processus

3 – MAÎTRISEZ LES BONNES TECHNIQUES ET UTILISEZ LES FONCTIONS AVANCÉES DU SHELL BASH

p. 90 Découvrez les fonctionnalités avancées du « Bash » et les bonnes pratiques

BONUS

p. 112 Mise en pratique : réalisation d’un outil de contrôle de qualité de scripts « Shell »

3.3 Activation du driver Kernel

La partie device tree étant faite, il nous reste à activer le support du driver gpio-exporter au sein de notre image Kernel (zImage). Pour ce faire, nous passerons une fois de plus par l’environnement Yocto/OE, en invoquant la commande suivante :

$ bitbake linux-fslc-imx -c menuconfig

Puis dans Devices Drivers > GPIO Support il nous faudra activer l’option comme le montre la figure 8.

Fig. 8: CONFIG_GPIO_EXPORTER au sein de menuconfig

Remarque
L’ensemble des patchs relatifs au kernel (gpio-exporter, dts et fichier defconfig), sont directement intégrés au sein de la couche distribution mis à disposition par les auteurs : https://github.com/bdx-iot/meta-iot/tree/master/recipes-kernel (au travers une recette dérivée)

Nous pourrons dès à présent relancer une phase de compilation pour générer le fichier zImage et notre nouveau fichier dtb (transformation en un fichier binaire du fichier dts), qui sera donc imx7s-warp-relay.dtb :

$ bitbake linux-fslc-imx

3.4 Intégration

Nous allons, dans cette sous-partie, mettre à jour le fichier zImage ainsi que le fichier imx7s-warp-relay.dtb sur notre cible. Pour ce faire, il sera question, ici aussi, de monter la partition eMMC en mode mass storage via u-boot. Nous finirons naturellement cette sous-partie par une phase de test sur cible.

3.4.1 zImage et .dtb

Pour la copie de la zImage :

$ sudo cp tmp/work/imx7s_warp-poky-linux-gnueabi/linux-fslc-imx/4.1-1.0.x+gitAUTOINC+9d3f7f9343-r0/build/arch/arm/boot/zImage /media/<username>/Boot imx7s-/

Pour la copie du fichier dtb spécifique à la gestion du relais :

$ sudo cp tmp/work/imx7s_warp-poky-linux-gnueabi/linux-fslc-imx/4.1-1.0.x+gitAUTOINC+9d3f7f9343-r0/build/arch/arm/boot/dts/imx7s-warp-dtb /media/<username>/Boot imx7s-/

Plaçons-nous maintenant côté cible et spécifions à notre chargeur d’amorçage (u-boot dans notre cas) que nous souhaitons utiliser le nouveau fichier dtb fraichement généré (imx7s-warp-relay.dtb) intégrant la partie gpio-exporter pour la gestion de nos relais, mais nous souhaitons, dans une moindre mesure, que celui-ci soit pris en compte par défaut, ceci afin d’éviter l’obligation d’une connexion série à chaque démarrage de la cible, il nous suffit donc de faire :

=> setenv fdt_file imx7s-warp-relay.dtb

Ceci surcharge la variable fdt_file, variable qui contient la référence vers le fichier dtb à utiliser (de base, imx7s-warp.dtb dans les sources de u-boot). Sauvegardons maintenant notre environnement :

=> save
Saving Environment to MMC...
Writing to MMC(0)... done

Il nous est maintenant possible de démarrer notre cible via l’exécution de la commande bootcmd (qui contient une suite de commandes à exécuter au démarrage) :

=> run bootcmd
switch to partitions #0, OK
...
6390056 bytes read in 94 ms (64.8 MiB/s)
Booting from mmc ...
reading imx7s-warp-relay.dtb
37834 bytes read in 12 ms (3 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x618128 ]
## Flattened Device Tree blob at 83000000
...
Starting kernel ...

3.4.2 Test en espace utilisateur

Afin de simplifier (encore plus) l’accès aux GPIO (via gpio-exporter), les auteurs auront préféré mettre en place la notion de lien symbolique afin de se créer un point d’accès dans /dev/mikrobus/*. En temps normal l’accès aux GPIO s’effectue dans /sys/devices/platform/gpio-exporter//out_RL*. Cette technique nous donnera donc le résultat suivant sur notre plateforme :

root@iot:~# ls -l /dev/mikrobus/out_RL*
lrwxrwxrwx 1 root root 50 Nov 18 10:26 /dev/mikrobus/out_RL1 -> /sys/devices/platform/gpio-exporter//out_RL1/value
lrwxrwxrwx 1 root root 50 Nov 18 10:26 /dev/mikrobus/out_RL2 -> /sys/devices/platform/gpio-exporter//out_RL2/value

Liens Symboliques
Le script concernant la génération des liens symboliques est entièrement consultable sur le github des auteurs : https://github.com/bdx-iot/meta-iot/blob/master/recipes-iot/clicks-board-init/clicks-board-init/mikrobus.sh.

Tout comme en section précédente, nous pouvons de façon très simple, et ceci sans connaître le numéro de la GPIO, piloter nos relais (plutôt pas mal non ?) :

root@iot:~# echo 1 > /dev/mikrobus/out_RL1 // Pour activer le relais
root@iot:~# echo 0 > /dev/mikrobus/out_RL2 // Pour désactiver le relais

4. Mise en situation …

Nous clôturerons cet article sur un mini-projet (par simple habitude des auteurs) permettant ainsi au lecteur de mettre en pratique les notions évoquées tout au long de l’article. Celui-ci nous permettra d’aborder quelques nouvelles techniques, comme par exemple l’introduction au QML.

4.1 Présentation du projet

Nous nous servirons du travail effectué durant cette première partie de l’ article, qui de ce fait, nous servira de base pour notre application « connectée ». Nous proposons ici de faire une évolution du serveur BLE du précédent article.

L’idée sera donc de créer :

• une application « serveur BLE », permettant le pilotage de notre carte « relay click », application qui sera sur la WaRP7.
• un client associé, qui, lui, sera sous forme d’application Android et qui enverra les données au serveur BLE (commande des relais).

La figure 9 (ci-après) illustre l’architecture globale que l’on se propose de mettre en œuvre durant cette dernière partie de l’article :

Fig. 9: structure du projet

4.2 Le Serveur

Interaction avec nos GPIO

La première étape consistera à créer une fonction nous permettant d’écrire sur les GPIO. Il suffit d’utiliser la classe QFile[12] qui permet la gestion de fichiers (et oui, sous Linux tout est fichier) :

m_relay1File = new QFile("/dev/mikrobus/out_RL1");
m_relay2File = new QFile("/dev/mikrobus/out_RL2");

Ceci étant fait, il ne reste plus qu’à ouvrir (via l’appel open()) le fichier (avec la permission d’écriture !), écrire la valeur souhaitée (0 ou 1) puis le refermer via l’appel close() :

m_relay1File->open(QIODevice::ReadWrite);
m_relay1File->write(data);
m_relay1File->close();

Dans le cas présent, « data » est de type QByteArray (simple tableau d’octets) contenant la valeur à envoyer sur notre GPIO. Nous verrons plus tard comment cette dernière est envoyée.

Et la partie BLE ?

Dans cet exemple, nous avons décidé de ne pas utiliser les services[13]/caractéristiques[14] standards proposés par le protocole Bluetooth, et de ce fait, nous avons créé les nôtres pour les besoins de cet article, c’est bien plus ludique quand même !

La figure 10 indique comment nous allons architecturer nos données.

Fig. 10: Architecture du serveur BLE

Il faut donc d’abord avoir nos propres UUID (Service + Caractéristiques) :

#define SERVICE_UUID 0x1820
#define CHAR_UUID_RELAY1 0x2aa4
#define CHAR_UUID_RELAY2 0x2aa5

Que nous allons ensuite « caster » en QBluetoothUuid :

QBluetoothUuid serviceRelayUuid((quint32)SERVICE_UUID);
QBluetoothUuid charRelay1Uuid((quint32)CHAR_UUID_RELAY1);
QBluetoothUuid charRelay2Uuid((quint32)CHAR_UUID_RELAY2);

Les présentations étant faites, nous pouvons rentrer dans le vif du sujet, la création du serveur. Et bien, pour ce faire, rien de plus simple avec l’API proposé par Qt :

Nous déclarons dans un premier temps un « advertiser » qui définit la configuration de base de notre serveur, ceci grâce à la classe suivante :

QLowEnergyAdvertisingData m_advertisingData;

Configurons son mode, son nom (GLMF_200_BLE) et nous y ajoutons un nouveau service (serviceRelay dans notre exemple) :

//Mode d'accessibilité
m_advertisingData.setDiscoverability(
      QLowEnergyAdvertisingData::DiscoverabilityGeneral);
//Nom du serveur
m_advertisingData.setLocalName("GLMF_200_BLE");
//Ajout du service Relais
m_advertisingData.setServices(QList<QBluetoothUuid>() <<
      serviceRelayUuid
      );

Nous créons ensuite les caractéristiques voulues (charRelay1). Le descripteur va définir la gamme de fonctionnalités de la caractéristique associée.

QLowEnergyCharacteristicData charRelay1;
charRelay1.setUuid(charRelay1Uuid); //uuid définie de la caractéristique
charRelay1.setValue(QByteArray(2, 0));
charRelay1.setProperties(type); //précise le type de la propriété
const QLowEnergyDescriptorData clientConfig( //Descripteur standard
      BluetoothUuid::ClientCharacteristicConfiguration,
      QByteArray(2, 0));
charRelay1.addDescriptor(clientConfig);

Puis nous les associons au service préalablement configuré. Nous définissons son type comme « Primaire » car il donne accès aux fonctionnalités standard des services :

//Couplage du service avec la caractéristique créée.
QLowEnergyServiceData serviceRelayData;
serviceRelayData.setType(QLowEnergyServiceData::ServiceTypePrimary);
serviceRelayData.setUuid(serviceRelayUuid);
serviceRelayData.addCharacteristic(charRelay1); //Ajout relai 1
serviceRelayData.addCharacteristic(charRelay2); //Ajout relai 2

La dernière étape arrive. Il ne reste plus qu’à créer le contrôleur, qui est, entre autres, le point d’entrée des périphériques Bluetooth. On ajoute alors le service relais à celui-ci et on démarre le serveur. Ainsi on rend la connexion possible :

//création du controlleur BLE
m_bleController = QLowEnergyController::createPeripheral();
//Permettra de savoir si un client se déconnecte afin de relancer l’”advertising”
connect(m_bleController,
SIGNAL(stateChanged(QLowEnergyController::ControllerState)),
this, SLOT(controllerStateChanged(QLowEnergyController::ControllerState)));
//ajout du service
m_serviceRelay = m_bleController->addService(serviceRelayData);
//permettra de récupérer les données reçues
connect(m_serviceRelay,
   SIGNAL(characteristicChanged(QLowEnergyCharacteristic,QByteArray)),
   this, SLOT(characteristicChanged(QLowEnergyCharacteristic,QByteArray)));
//démarrage "advertising"
m_bleController->startAdvertising(QLowEnergyAdvertisingParameters(),m _advertisingData, m_advertisingData);

Il ne reste donc plus qu’à implémenter la fonction qui traite la réception d’une donnée afin de savoir à quel relais elle s’applique et dans quel état nous devons le mettre. Il suffit assez simplement de lire l’UUID de la caractéristique reçue et de commuter celui concerné en fonction :

void CServerBLE::characteristicChanged(QLowEnergyCharacteristic c, QByteArray data)
{
   switch(c.uuid().toUInt32())
   {
   case CHAR_UUID_RELAY1:
      m_relay1File->open(QIODevice::ReadWrite);
      m_relay1File->write(data);
      m_relay1File->close();
      break;

   case CHAR_UUID_RELAY2:
      m_relay2File->open(QIODevice::ReadWrite);
      m_relay2File->write(data);
      m_relay2File->close();
      break;
   }
}

Le travail est fini et le serveur est ainsi prêt à fonctionner. Si le lecteur veut s’y tenter, il pourra d’ores et déjà compiler l’application pour la déployer sur la cible (bitbake ServiceRelay). Pour de plus amples informations sur la gestion des paquets/déploiement, les auteurs renverront le lecteur sur un excellent article de Pierre Ficheux[15]).

Température
Dans l’exemple complet proposé sur le Github des auteurs, nous avons rajouté la lecture de la température présente sur la Warp7 afin de donner un peu de vie à l’interface.

4.3 « Dans la peau du client »

Création de notre environnement

Le serveur est fonctionnel, donc prêt à être piloté. Il ne manque plus qu’à lui associer un client. L’idée ici est de proposer une application Android avec le framework Qt en QML.

QML
QML (pour Qt Meta Language) est un langage de programmation graphique qui ressemble beaucoup au JSON. Il a été créé principalement pour les applications mobiles, son utilisation étant bien plus simple que le Designer standard pour plateforme mobile.

Avant de pouvoir démarrer le projet, il faut mettre en place notre environnement. Pour cela, il est suggéré ici, de suivre le tutoriel Qt pour Android qui est très bien documenté (http://doc.qt.io/qt-5/android-support.html), qui consiste en l’installation de la chaîne de compilation Qt pour Android ainsi que le NDK et le SDK fournis par Google. Il faudra bien entendu installer Java !

Afin de ne pas sacrifier de nombreuses pages, les auteurs renverront le lecteur sur le GitHub en ce qui concerne l’ensemble des sources à télécharger. A la suite de cela, nous pouvons alors ouvrir Qt Creator et :

• – Dans Tool > Options > Android, il faudra ici remplir correctement les arborescences (JDK, NDK et SDK) comme le montre la figure 11.

Fig. 11: Configuration de notre environnement

• Puis dans Tool > Options > Build & Run > Kits, il faudra créer le Kit associé (voir figure 12).

Fig. 12: Configuration de notre Kit

Un premier projet

En premier lieu, créons notre premier projet QML (Qt Quick Application) tout en sélectionnant le Kit Android pour le futur déploiement (smartphone).

Une application QML se scinde toujours en deux parties :

• une partie C++
• une partie script QML.

Il existe donc plusieurs outils pour communiquer entre les deux couches que nous expliciterons au cours de cette partie.

La partie C++

Dans cette partie, nous décrirons le client Bluetooth Low Energy. Et surtout, comment envoyer une donnée au serveur.

Dans un souci de simplicité, nous avons retiré les méthodes de découverte des périphériques présents. Partons du postulat que nous connaissons déjà l’adresse (MAC) de notre serveur. Nous chercherons simplement à nous y connecter de façon directe.

Identifier l’adresse mac de l’interface BLE
Pour connaître l’adresse physique de l’interface bluetooth de notre WaRP7, il suffira d’exécuter la commande suivante :

root@iot:~# hciconfig
hci0: Type: BR/EDR Bus: UART
      BD Address: 43:43:A1:12:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
      UP RUNNING PSCAN ISCAN
      RX bytes:766 acl:0 sco:0 events:52 errors:0
      TX bytes:1766 acl:0 sco:0 commands:52 errors:0

Voici donc l’introduction des premières lignes de code. Le type d’adresse peut être soit « Public » soit « Random ». Le premier définit un mode de fonctionnement standard avec une adresse « statique » et le second définit un mode dans lequel l’adressage peut évoluer, c’est une sécurité dont nous n’avons pas besoin pour la suite :

//création du contrôleur avec l'addresse du serveur en paramètre
m_controller = new QLowEnergyController(QBluetoothAddress(address), this);
//on crée les connections
//Pour récupérer les services présents
connect(m_controller,
      SIGNAL(serviceDiscovered(QBluetoothUuid)),
      this,
      SLOT(addLowEnergyService(QBluetoothUuid)));
//Pour savoir quand la connection est faite
connect(m_controller,
      SIGNAL(connected()),
      this,
      SLOT(deviceConnected()));
//on se connecte
m_controller->setRemoteAddressType(QLowEnergyController::PublicAddress);
m_controller->connectToDevice();

La connexion n’est pas instantanée, mais une fois faite, on lance alors la découverte des services associés au périphérique :

m_controller->discoverServices();

Puis, à la réception des services, il est possible de lancer la découverte des caractéristiques associées au service via la fonction « discoverDetails() » :

//on stock l'addresse du pointeur
m_connectedService = service;
if (m_connectedService->state() == QLowEnergyService::DiscoveryRequired)
{
//permet de récupérer une mise à jour des caractéristiques venant du serveur
connect(m_connectedService,
   SIGNAL(characteristicChanged(QLowEnergyCharacteristic,QByteArray)),
   this,
   SLOT(serviceCharacteristicChanged(QLowEnergyCharacteristic,QByteArray)));
//Permet de découvrir les caractéristiques associées au service
connect(m_connectedService,
   SIGNAL(stateChanged(QLowEnergyService::ServiceState)),
   this,
   SLOT(serviceDetailsDiscovered(QLowEnergyService::ServiceState)));
//démarrer la découverte des caractéristiques
m_connectedService->discoverDetails();
}

Et enfin, à la réception des caractéristiques, on conserve la valeur contenue dans celles-ci et on met à jour l’interface en fonction. Les caractéristiques se reconnaîtront grâce à leurs UUID :

//on récupère le service
   QLowEnergyService *service = qobject_cast<QLowEnergyService *>(sender());
   //on récupère ses caractéristiques
   const QList<QLowEnergyCharacteristic> chars = service->characteristics();
   //on les parcours pour les traiter
   foreach (const QLowEnergyCharacteristic &ch, chars)
   {
      //relay1, on met à jour relay1
      if (ch.uuid().toUInt32() == CHAR_UUID_RELAY1)
      {
      m_relay1Characteristic = ch;
      m_relay1Changed = ch.value().toInt();
      Q_EMIT relay1Changed();
   }
   //Si uuid relay2, on met à jour relay2
   if (ch.uuid().toUInt32() == CHAR_UUID_RELAY2)
   {
      m_relay2Characteristic = ch;
      m_relay2Changed = ch.value().toInt();
      Q_EMIT relay2Changed();
   }
}

Le plus dur est fait et, afin d’envoyer une nouvelle valeur au serveur en vue de changer l’état d’un des deux relais, il suffira d’utiliser la fonction suivante :

void CBLEDiscover::switchRelay1(bool value)
{
   m_connectedService->writeCharacteristic(
   m_relay1Characteristic,
   QByteArray::number(value));
}

A partir de là, il ne reste plus qu’à créer notre interface !

La partie QML

Lorsque l’on crée un fichier QML, on peut soit le modifier sous la forme d’un script, soit via le designer QML de Qt. Il existe donc deux types de fichiers qml :

• Fichier.ui.qml qui pourra être édité via l’éditeur et/ou par script,
• Fichier.qml qui pourra être modifié uniquement par script

Généralement, les fichiers.ui.qml sont associés à un fichier.qml afin de créer les connexions vers le C++. Dans l’exemple, nous avons créé deux fichiers .qml (associés chacun à un fichier.ui.qml) :

• main.qml : qui consiste en un simple bouton permettant d’enclencher la connexion directement avec le serveur dont l’adresse est celle spécifiée dans le code principal.
• Relay.qml : permet de piloter les deux relais.

Pour que le QML puisse communiquer avec notre classe, il faut pour ce faire, passer celle-ci en paramètre. Nous pouvons alors charger la page main.qml :

QQmlApplicationEngine engine;
//Charger la classe
CBLEDiscover *bleDiscover = new CBLEDiscover();
engine.rootContext()->setContextProperty("BLEDiscover", bleDiscover);
//Charger le QML
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));

Au chargement de l’application, nous aurons donc la page main.qml qui s’affichera constituée d’un simple bouton. Pour gérer l’évènement du clique, il suffit d’utiliser le script suivant :

connectButton.onClicked: {
   BLEDiscover.start();
   pageLoader.source = "Relay.qml"
}

Afin que la fonction start soit appelée, il est nécessaire qu’elle soit invocable[16] depuis le C++ :

Q_INVOKABLE void start();

L’objet pageLoader permet de charger une nouvelle page QML et est défini par :

Loader { id: pageLoader }

La page Relay.qml est alors chargée. Elle est composée de deux switchs qui permettront de piloter les deux relais. De la même manière, le changement d’état des switchs se gère de la façon suivante :

relay1.onClicked:{
   if (relay1.checked == true)
      BLEDiscover.switchRelay1(true)
   else
      BLEDiscover.switchRelay1(false)
}

L’application est bientôt terminée. Nous avons vu comment insérer et appeler une fonction depuis le QML vers le C++. Il ne reste plus qu’à expliquer comment mettre à jour la parité QML avec le C++. Pour réaliser le lien, Qt propose l’utilisation des Q_PROPERTY[17] qui seront liées à des signaux de mise à jour. Par exemple, si nous voulons mettre à jour l’état d’un relais nous définirons la Q_PROPERTY suivante :

//Q_PROPERTY
Q_PROPERTY(bool relay1State MEMBER m_relay1Changed NOTIFY relay1Changed)
//valeur membre
bool m_relay1Changed;
//signal à émettre lors d’une mise à jour
Q_SIGNAL void relay1Changed();

Et côté QML, la connexion au signal se fait de la manière suivante :

relay1 {
   checked: BLEDiscover.relay1State;
   font.pointSize: 7;
}

4.4 Le rendu final

Pour avoir un aperçu du projet réalisé, voici ci-après le fruit du travail réalisé durant cet article. La première étape consiste au lancement de l’application (.apk disponible ici : https://github.com/bdx-iot/RelayGUI/blob/master/GLMF_200_GUI_BLE.apk)

Fig. 13: Démarrage de l’application

L’étape suivante nous indique de nous connecter à notre périphérique (figure 14) :

Fig. 14: Connexion

Une fois connectés, nous avons la satisfaction de pouvoir interagir avec nos relais, lire la température du capteur Altimètre (MPL3115), mais surtout, de pouvoir jouer avec une simple ampoule comme le montre notre environnement sur la figure 15.

Fig. 15: IoT : L’environnement de test

Agissons maintenant sur le relais 1 (figure 16) :

Fig. 16: IoT : Rendu globale avec RL1 activé

Puis activons le 2ème relais (figure 17) :

Fig. 17: IoT : Rendu globale

Rappelons une fois de plus que le lecteur pourra retrouver l’ensemble des sources sur le référentiel git suivant : https://github.com/bdx-iot. Se trouvera sur celui-ci :

• La couche « meta-iot » mise à disposition par les auteurs, comprenant :
• La recette dérivée du Kernel (gestion du fichier dts et fichier deconfig),
• La recette permettant la gestion des liens symboliques : https://github.com/bdx-iot/meta-iot/tree/master/recipes-iot/clicks-board-init
• La recette du « serveur BLE » et son script init associé (pour un démarrage automatique de l’application) : https://github.com/bdx-iot/meta-iot/tree/master/recipes-iot/service-relay
• Ainsi que d’autres recettes.
• Les sources de l’application serveur : https://github.com/bdx-iot/ServiceRelay
• Les sources de l’application client : https://github.com/bdx-iot/RelayGUI

Conclusion

Dans cet article, nous avons découvert le standard MikroBUS et nous avons ainsi pu le mettre en application sur notre plateforme cible. De par l’intégration, nous avons d’autre part, découvert des notions comme le device tree ou encore le langage QML.

Finalement, nous avons mis en pratique l’ensemble des notions pour créer un véritable objet connecté (jusqu’à la création de la partie client pour la gestion de celui-ci), le tout basé sur du Bluetooth Low Energy. Ceci n’étant qu’une introduction au vu du potentiel, le lecteur pourra s’inspirer et imaginer d’autres applications (domotique) via les modules Mikrobus de MikroElektronika.

En parlant de domotique, n’oublions pas que cette plateforme dispose d’une interface caméra, autre périphérique qu’il serait intéressant de mettre en œuvre afin de créer un environnement connecté pour la surveillance de nos enfants (vidéo/température/gestion de la veilleuse), ceci en ne négligeant pas l’aspect low energy de notre objet bien entendu.

Références

[1] Article « A la découverte de la WaRP7 » par Pierre-Jean TEXIER et Jean CHABRERIE, Open Silicium n°20
[2] Site d’Element14 :
https://www.element14.com/community/docs/DOC-79058/l/warp7-the-next-generation-iot-and-wearable-development-platform
[3] Page NXP présentant l’architecture du i.MX7 :
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-7-processors/i.mx-7solo-processors-heterogeneous-processing-with-arm-cortex-a7-and-cortex-m4-cores:i.MX7S
[4] Documentatio du projet Yocto (version 2.1 : krogoth) :
http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html
[5] Documentation relative à l’outil repo : https://source.android.com/source/using-repo.html
[6] Couche distribution des auteurs : https://github.com/bdx-iot/meta-iot
[7] Ensemble des cartes « click » par MikroElektronika : http://www.mikroe.com/click/
[8] Documentation dans les sources du Noyau Linux sur l’utilisation des GPIO en espace utilisateur : https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
[9] Driver gpio-exporter : https://patchwork.kernel.org/patch/6207321/
[10] Article « Périphériques découvrables, découverts ou à découvrir » par Pierre FICHEUX, Open Silicium n°20
[11] Article « Introduction au « device Tree »sur ARM » par Thomas PETAZZONI, Open Silicium n°17
[12] Documentation de la classe Qfile :
http://doc.qt.io/qt-5/qfile.htmlhttp://doc.qt.io/qt-5/qfile.html
[13] Spécifications des services bluetooth :
https://www.bluetooth.com/specifications/gatt/services
[14] Spécifications des caractéristiques bluetooth :
https://www.bluetooth.com/specifications/gatt/characteristics
[15] Article « IoT sous Yocto, un cas d’utilisation » par Pierre FICHEUX, Open Silicium n°20
[16] Explication de la macro Q_INVOKABLE :
http://doc.qt.io/qt-5/qobject.html#Q_INVOKABLE
[17] Explication de la macro Q_PROPERTY :
http://doc.qt.io/qt-5/qobject.html#Q_PROPERTY

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

L’important choix de cartes intégrant des capteurs/actionneurs, en fait aujourd’hui, un choix difficile pour l’utilisateur final. C’est pour ces raisons que MikroElektronika a créé un standard : MikroBUS. Il facilite l’interaction entre microcontrôleur ou microprocesseur et les cartes d’extensions, appelées « add-ons », utilisant cette connectique. Cet article se propose d’explorer la partie MikroBUS d’un des tous derniers SBC (Single Board Computer) du marché : la WaRP7 (« WearAble Reference Platform »). On commencera dans un premier temps par une succincte présentation de la WaRP7 et d’une partie « board bring-up » (via Yocto/OE). Puis, viendra la partie MikroBUS qui sera mise en avant à travers un mini projet architecturé autour du Bluetooth Low Energy et du framework Qt5 pour Android tout en y intégrant une carte add-ons, carte qui se base sur le standard MikroBUS.

Le présent article s’inscrit dans la continuité des manipulations ayant permis la rédaction d’un article précédent paru dans le n°20 d’Open Silicium [1], les auteurs renverront vers celui-ci les lecteurs qui désirent avoir de plus amples connaissances sur la diversité que propose la cible utilisé dans ce numéro de Linux Magazine. Dans le premier article, il était question de découvrir la WaRP7 et ses capteurs au travers une application « IoT » minimaliste (récupération d’une température, la pression atmosphérique ainsi qu’une valeur représentant le rythme cardiaque), ceci en utilisant la connectivité Bluetooth et le framework Qt5, le tout basé sur une distribution Yocto/OE mis à disposition par les auteurs.

Que le lecteur ne pouvant pas se procurer le premier article soit rassuré, on se permettra tout de même ici de faire des rappels (ouf !) quant aux éléments essentiels (présentation de la cible, génération et installation de l’image sur notre cible, une partie Bluetooth, puis quelques mots sur le SDK Yocto/Qt5).

1. Introduction

1.1 La cible : « WaRP7 », petit rappel

La plateforme cible [2] est composée de 2 cartes :

• Une carte « fille », qui est construite autour d’un System on Chip NXP i.MX7 Solo [3] (avec un coeur Cortex A7 + un coeur Cortex M4). De plus, cette carte embarquera la gestion de la connectivité (Wifi/BLE) ;
• Une carte « mère », qui contiendra l’ensemble des capteurs (Gyroscope, Altimètre, etc.), ainsi que l’extension MikroBUS (qui nous intéresse particulièrement dans cet article).

Fig. 1: Non, la WaRP7 n’est pas timide

1.2 Construction de notre distribution « IoT »

La génération de la distribution pour notre cible, repose sur l’utilisation du BSP (Board Support Package) NXP articulé autour du projet Yocto [4] et de deux couches supplémentaires (nous ne ferons pas ici, de détails quant à l’utilisation de Yocto/OE, le lecteur pourra en outre, se référer aux différents articles parus dans les précédents numéros d’open silicium).

La première étape consiste donc à récupérer l’ensemble des sources contenues dans le BSP. Pour ce faire, NXP utilise l’utilitaire repo (outil Python développé par Google [5]), ceci afin de permettre une meilleure gestion des référentiels Git compris dans celui-ci :

$ mkdir ~/bin
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ PATH=${PATH}:~/bin
$ mkdir warp7_glmf200
$ cd warp7_glmf200
$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b krogoth
$ repo sync

Comme prévu, après récupération de notre base logicielle, nous pouvons maintenant télécharger les deux couches supplémentaires essentielles à la bonne construction de notre image.

Téléchargeons dans un premier temps la couche distribution mis à disposition par les auteurs [6], pour rappel, cette couche spécifique est intimement liée à l’article (ceci afin de ne pas se perdre dans le framework qu’est Yocto/OE) :

$ cd sources/
$ git clone https://github.com/bdx-iot/meta-iot.git

Dans un second temps, récupérons la couche permettant d’intégrer l’environnement Qt5 à notre distribution :

$ cd sources/
$ git clone https://github.com/meta-qt5/meta-qt5.git

Nous voilà maintenant en possession de l’ensemble des sources. L’étape d’après consiste en la création de l’environnement, on retrouve ci-après les différentes étapes :

• création du dossier de construction warp7-build/,
• appel du script oe-init-build-env,
• mise à jour de la variable MACHINE,
• puis un prompt concernant la licence FSL EULA (à accepter).

La commande suivante s’occupera donc de nous placer dans un environnement de travail spécifique à notre plateforme de développement :

$ MACHINE=imx7s-warp source setup-environment warp7-build/

Il reste maintenant à définir les chemins vers les couches précédemment téléchargées, pour ce faire, modifions le fichier conf/bblayers.conf pour y rajouter les deux lignes suivantes :

${BSPDIR}/sources/meta-iot \
${BSPDIR}/sources/meta-qt5 \

Dernière étape avant de pouvoir lancer la construction de l’image, il nous faut spécifier la distribution utilisée (dans notre cas une distribution spécifique à l’article dérivé de la distribution poky) dans conf/local.conf, en mettant à jour la variable DISTRO :

DISTRO ?= 'iot'

Lançons maintenant la construction de notre image par le biais de la commande bitbake :

$ bitbake iot-qt-image

Après cette longue étape qu’est la construction, l’utilisateur pourra retrouver très facilement l’ensemble des fichiers utiles au bon démarrage de la plateforme (Bootloader, Kernel, RootFileSystem) dans tmp/deploy/images/imx7s-warp.

1.3 Premier Flash, premier Boot, …

Rappelons qu’afin de mettre à jour le système avec l’ensemble des binaires compilés, les étapes se déroulent comme suit :

• Connexion en liaison série (via un émulateur de terminal comme microcom), puis arrêt de l’auto-boot au niveau du bootloader (u-boot) :

$ microcom --speed 115200 --port /dev/ttyUSB0
...
U-Boot 2016.07+fslc+ge6b4241 (Sep 14 2016 - 11:21:52 +0200)
CPU: Freescale i.MX7S rev1.2 at 792MHz
...
Hit any key to stop autoboot: 0

• Montage de la partition eMMC côté bootloader :

=> ums 0 mmc 0

• Décompression et opération de copie coté système hôte sur le device spécifique :

$ cd tmp/deploy/images/imx7s-warp
$ gunzip qt-image-imx7s-warp-20161118195314.rootfs.sdcard.gz
$ sudo dd if=qt-image-imx7s-warp-20161118195314.rootfs.sdcard of=/dev/sdX (où X représente le device)

Une fois la copie terminée, l’utilisateur pourra redémarrer la carte pour voir apparaître la séquence de démarrage :

Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.1.32-fslc+g9d3f7f9 (pjtexier@bdxiot) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT
...
IOT powered by Yocto/OE (Welcome to Bordeaux) 2.1.1 iot /dev/ttymxc0
iot login: root
Password: iot
___ ___ _____
|_ _/ _ \_ _|
| | | | || |
| | |_| || |
|___\___/ |_|

root@iot:~#

1.4 Activation de l’interface Bluetooth

Rappelons ici, comment attacher, initialiser et activer notre interface Bluetooth, afin que celle-ci soit accessible par les autres périphériques compatibles :

root@iot:~# hciattach ttymxc2 bcm43xx 3000000 flow -t 20
root@iot:~# hciconfig hci0 up
root@iot:~# hciconfig hci0 name 'Hello GLMF200' // Nom de l'interface visible depuis n'importe quel périphérique bluetooth
root@iot:~# hciconfig hci0 piscan

1.5 SDK Qt5

1.5.1 Génération

Nous avons évoqué lors de l’article précédent la notion de SDK et chaîne de compilation croisée (mais pas que). Ceci afin de pouvoir générer du code Qt5 sur notre cible. La commande ci-dessous permettra la génération d’un SDK générique et compatible Qt5 :

$ bitbake meta-toolchain-qt5

Une fois la génération terminée, le script d’installation du SDK se trouvera dans tmp/deploy/sdk.

1.5.2 Installation

Elle se fera tout simplement en exécutant le script suivant où il conviendra de spécifier le chemin d’installation (/opt/iot/sdk dans cet exemple) :

$ cd tmp/deploy/sdk
$./iot-glibc-x86_64-meta-toolchain-qt5-cortexa7hf-neon-toolchain-2.1.1.sh
IOT powered by Yocto/OE (Welcome to Bordeaux) SDK installer version 2.1.1
=========================================================================
Enter target directory for SDK (default: /opt/iot/2.1.1): /opt/iot/sdk

1.5.3 Intégration à l’IDE Qt creator

Afin de se voir l’environnement de compilation croisée, intégré à notre IDE préféré, il nous faudra :

• Dans Outils > Options > Compiler et Exécuter
• Puis dans la section Compilateurs > Ajouter , choisir « GCC »
• On donnera un nom à notre GCC spécifique (par exemple WaRP7_GLMF200),
• Puis nous spécifierons le chemin du compilateur : /opt/iot/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
• Dans Versions de Qt, Qt est normalement automatiquement détecté. Sinon le lecteur devra ajouter le chemin vers qmake : /opt/iot/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake
• Dans Kits, il ne reste plus qu’à choisir les éléments précédemment mis en place (Compilateur et version), il sera aussi recommandé de spécifier le mkspecs « linux-oe-g++ » :

2. MikroBUS

Dans cette partie nous aborderons, dans un premier temps, le standard MikroBUS, nous présenterons autant les aspects matériels que les aspects logiciels que propose celui-ci. Nous ferons ensuite un bref tour d’horizon sur les modules que propose MikroElektronika.

2.1 Le standard : introduction

Le standard MikroBUS définit les connectiques des cartes principales (on parle souvent de carte mère) ainsi que celles des cartes additionnelles (add-on) utilisées pour l’interfaçage du microcontrôleur ou du microprocesseur avec les circuits et modules complémentaires. De plus, il spécifie la disposition physique du brochage, les broches de communication et les broches d’alimentation utilisées.

On remarque, bien évidemment, que l‘objectif de mikroBUS est de jouer sur la flexibilité matérielle, permettant ainsi un interfaçage plus facile avec un grand nombre de cartes complètes, qui plus est, standardisées (plus de 200 modèles commercialisés par MikroElektronika tout de même !), chacune avec un simple capteur (humidistance), un module radio (RFID), un écran (OLED), une connectique (RS232), ou tout autre module électronique[7].

Remarque
A noter que mikroBUS est un standard ouvert et donc n’importe qui peut prétendre implémenter mikroBUS dans sa conception matérielle, à condition bien sûr de respecter les conditions de MikroElektronika.

2.2 Le standard : Description du connecteur MikroBUS

Le connecteur MikroBUS est composé de 16 broches (2×8). L’ensemble de celles-ci est toujours positionné de la même manière comme le montre la figure 2.

Fig. 2: pinout du standard MikroBUS

On retrouvera sur chaque module :

• Des broches par type de bus de communication : SPI, UART, I²C.
• 4 broches complémentaires : PWM (ou MLI en français), interruption matérielle (INT), entrée analogique (AN) et reset (RST).
• Puis un couple pour les alimentations :
• 3,3V / GND
• 5V / GND

2.3 Quelques Examples :

Il est bien évidemment compliqué de présenter ici l’ensemble des modules proposés par la firme MikroElektronika. Afin de donner au lecteur un bref aperçu des cartes disponibles, les auteurs auront choisi d’en exposer 2 au travers de cet article :

2.3.1 La « Relay Click Board » :

Fig. 3: La Relay Click sous les projecteurs

Cette carte embarque deux relais de puissance (G6D1AASI-5DC de référence Omron). Le pilotage vers la carte principale (dans notre cas la WaRP7) s’effectue via les broches suivantes du connecteur MikroBUS :

• Broche PWM pour le Relais 1 (RL1),
• Broche CS pour le Relais 2 (RL2).

De notre point de vue, ce ne sera ni plus ni moins que l’activation (état haut ou état bas) d’une broche GPIO (ouverture ou fermeture du relais).

2.3.2 La « custom » :

Fig. 4: L’inconnu au bataillon

Comme remarqué précédemment, il est possible de réaliser sa propre carte autour du standard MikroBUS. Dans cet exemple, le module est composé d’un gpio expander (microchip mcp23s08) pilotable au travers d’une interface SPI (mais aussi via le bus i²c). Cette option permet d’étendre les capacités de la carte principale quand celle-ci arrive à ses limites (ou si aucune GPIO physique n’est présente sur la carte mère).

3. Jouons un peu avec la « relay click board »

Viens maintenant le temps de jouer un peu avec notre module MikroBUS, celui-ci permettant d’étendre les capacités de notre WaRP7, nous mettant ainsi des relais à disposition (ceci afin de commander par exemple une lampe, ou tout autre objet …). Dans ce chapitre nous verrons comment les piloter de façon simpliste en accédant aux GPIO depuis l’espace utilisateur. Nous aborderons ensuite le sujet du device tree et l’accès à la configuration des GPIO depuis celui-ci.

3.1 Plug !

Insérons notre module relais et constatons qu’il est très facile d’intégration entre notre plateforme cible et les modules MikroBUS (WaRP7 <-> Relay Click Board), ceci grâce à la standardisation :

Fig. 5 : La WaRP7 en position !

3.2 And Play !

Sous GNU/Linux, l’accès aux GPIO [8] s’effectue dans /sys/class/gpio/gpioN où N représente le numéro de la GPIO (à condition que le driver associé soit présent → GPIO_SYSFS).

Nous savons par le biais de la schématique (disponible en [2]), que le relais 1 et sur la broche CPU « GPIO7_IO8 », qui, en espace utilisateur devient gpio200.

Comment calculer le numéro de gpio utilisé en mode userspace ?
Le calcul est sous la forme : ((port_GPIO – 1)*32) + n°gpio.
Exemple pour le relais 1 : ((7-1)*32) + 8 = 200

La première étape consistera à exporter cette GPIO pour la rendre accessible depuis le système de fichier virtuel /sys, la commande si après créera donc un point d’accès gpio200 :

root@iot:~# echo 200 > /sys/class/gpio/export

L’interface étant disponible, il nous faut la paramétrer en tant que broche de sortie :

root@iot:~# echo out > /sys/class/gpio/gpio200/direction

Une fois configurée, il nous est possible de la piloter, ceci en agissant simplement sur la tension de sortie de la broche, via la commande suivante :

root@iot:~# echo 1 > /sys/class/gpio/gpio200/value

La broche de sortie passée à l’état haut, il nous est facile de constater le résultat sur la carte relais (led REL1), comme nous le montre la figure 6 :

Fig. 6: Relais 1 en fonctionnement

Nous ferons de même pour le relais numéro 2 (RL2 sur la « relay click ») qui lui est sur « GPIO4_IO23 » :

root@iot:~# echo 119 > /sys/class/gpio/export
root@iot:~# echo out > /sys/class/gpio/gpio119/direction
root@iot:~# echo 1 > /sys/class/gpio/gpio119/value

Fig. 7 : Relais 2 en fonctionnement

3.2 Intégration au device-tree : « gpio-exporter & pin-muxing »

L’inconvénient des étapes (export/direction) précédentes réside dans le fait qu’il nous est obligatoire de les réexécuter à chaque démarrage de la WaRP7, car non statique au sein de la configuration matérielle. Il serait donc intéressant d’avoir une entrée statique. Nous irons un peu plus loin que la simple configuration des GPIO.

En effet, il serait aussi plaisant de pouvoir associer un nom à nos GPIO lors de la configuration de celles-ci, pour ce faire, nous intégrerons le travail de Martin FUZZEY[9] (qu’on ne manquera pas de remercier pour le travail effectué), qui a en effet développé un driver Kernel permettant d’avoir au sein de l’espace utilisateur, un lien nom/numéro de GPIO. L’avantage de cette solution est que finalement, l’utilisateur ne se soucie plus du numéro de la GPIO, de ce fait, la configuration est beaucoup plus portable et maintenable.

3.2.1 Device tree : une petite introduction

L’arbre de périphériques (device tree ou encore DT) est une structure de données permettant de décrire le matériel d’un système, dérivée du format utilisé par Open Firmware pour encapsuler les informations de plateforme et les transmettre au noyau, qui utilise alors les données du DT pour trouver et enregistrer les périphériques du système.

La structure de données elle-même est un arbre de nœuds nommés et de propriétés. Chaque nœud contient des propriétés de simples paires « nom-valeur » et des nœuds fils. Afin d’être interprétée correctement par le noyau, l’arborescence doit suivre une structure prédéfinie. Une « liaison » (en anglais, binding) est une description de la façon dont un périphérique est décrit dans le DT. Un grand nombre de périphériques disposent de liaisons bien établies et documentées.

3.2.2 Anatomie de notre fichier dts « imx7s-warp-relay.dts »

Afin de ne pas surcharger le fichier dts (device tree source) principal (imx7s-warp.dts), les auteurs auront choisi de créer un fichier dts spécifique à l’intégration du module « relay click », en voici sa constitution :

#include "imx7s-warp.dts"

/ {

      gpio_exporter: gpio-exporter {
         compatible = "linux,gpio-exporter";
         pinctrl-names = "default";
         pinctrl-0 = <&pinctrl_gpioexporter_relay>;

         out_RL1 {
            gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
            output;
            initial-state = <0>;
         };

         out_RL2 {
            gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
            output;
            initial-state = <0>;
         };
      };
};

&iomuxc {
      pinctrl-names = "default";
      imx7s-warp {
         pinctrl_gpioexporter_relay: gpioexportergrp {
            fsl,pins = <
               MX7D_PAD_ENET1_RGMII_TD2__GPIO7_IO8 0x14
               MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14
            >;
         };
      };
};

Essayons de détailler celui-ci :

• #include « imx7s-warp.dts » fera référence au fichier principal la WaRP7 (définition de la carte), qui lui-même inclus la définition du SoC (System on Chip) i.MX7 (imx7d.dtsi).
• Au niveau du contenu du fichier :
• La création d’un nœud (node) avec son label associé, que l’on appellera gpio-exporter :

gpio_exporter: gpio-exporter {
   compatible = "linux,gpio-exporter";

• Le mot clé compatible est une propriété qui permettra de faire le lien avec la partie driver (respectant la règle du plateform driver comme présenté par Pierre Ficheux en [10]). Ceci via la structure of_device_id qui sera utilisée avec le tableau gpio_exporter_dt_ids[]. Le lecteur curieux pourra jeter un coup d’oeil au code source dans tmp/work/imx7s_warp-polky-linux-gnueabi/linux-fslc-imx/4.1-1.0.x+gitAUTOINC+9d3f7f9343-r0/git/drivers/gpio/gpio-exporter.c :

static const struct of_device_id gpio_exporter_dt_ids[] = {
   { .compatible = "linux,gpio-exporter", },
} ;

• La propriété pinctrl-0 permet de donner la liste des broches qui seront soumises à une définition spécifique de leur état, ceci grâce au sous-système pinctrl qui permet de gérer le multiplexage des broches. Dans notre cas, la configuration s’effectuera dans le nœud fils pinctrl_gpioexporter_relay : 

pinctrl-0 = <&pinctrl_gpioexporter_relay>;

• Il convient ensuite de créer un nœud fils (child node), le nom de celui-ci représentera le nom exposé au sein de l’espace utilisateur, nous garderons la même syntaxe que la carte « relay click », à savoir RL1 pour le pilotage du relais 1 :

out_RL1 {
      gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
      output;
      initial-state = <0>;
   };

Il nous faudra aussi renseigner les propriétés à notre nœud fils :

• gpios : Référence vers la GPIO à exporter (binding standard défini dans les sources du Noyau Linux : Documentation/devicetree/bindings/gpio/gpio.txt). En plus du phandle (nœud vers le contrôleur associé), nous retrouverons le numéro de GPIO, 8 pour notre application. Puis le second argument signifie que celle-ci est active sur un niveau haut (GPIO_ACTIVE_HIGH).
• output : pour spécifier que l’on désire la positionner en sortie,
• initial-state : où on fixera sont état initial (état bas dans notre cas)

Il en sera de même pour le relais numéro deux, où seul le nom du sous-nœud et de la GPIO associé seront donc à modifier pour le piloter :

out_RL2 {
      gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
      output;
      initial-state = <0>;
   };
};

Nous en resterons là quant à la présentation du fichier device tree, le lecteur pourra se référer au très bon article écrit par Thomas Petazzoni paru dans le n°17 d’Open Silicium [11].

Pierre-Jean TEXIER
[Ingénieur Linux Embarqué, Intervenant Linux Embarqué à ESTEI Bordeaux ,
Co-auteur de l’ouvrage « Yocto For Raspberry-pi »]

Jean CHABRERIE
[Ingénieur Systèmes Embarqués, Qt Enthousiaste]

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

4. À la pointe de la technologie : OpenLayers 3

Dans la course aux fonctionnalités, nous ne cessons de casser ce qui marche pour mettre à jour les nouvelles fonctionnalités. Pourquoi donc casser ce bel exemple OpenLayers2 pour le remplacer par OpenLayers3 ? La déformation excessive des cartes aux latitudes élevées est un défaut bien connu de la projection de Mercator utilisée par défaut par tous les environnements cartographiques de la toile (projection de code 900913 – l’écriture leet de Google – puisque la norme choisie n’a pas été validée par l’instance qu’est l’EPSG). Étant conscients des déficiences de la projection de Mercator, nous voudrions pouvoir sélectionner un mode de projection localement tangent à la région considérée – à savoir Universal Transverse Mercator (UTM). Et nous en arrivons à l’excuse pour passer de OpenLayers 2 à 3 : la version actuelle d’OpenLayers ne permet pas la projection au vol des images, et impose donc une sortie déformée, particulièrement gênante lorsque nous nous éloignons de l’équateur.

Nous reprenons donc toutes nos investigations, mais cette fois dans le contexte d’OpenLayers 3, avec la nécessité pour chaque nouvelle couche de préciser le mode de projection d’entrée (toutes nos données sont stockées en coordonnées sphériques, donc WGS84 de code EPSG:4326. OpenLayers ne connaît pas tous les modes de projection de sortie : nous devons les définir selon nos besoins (voir figure 5).

Fig. 5: Gauche : le passage à une projection locale WGS84/UTM33N résout la déformation observée auparavant dans OpenLayers 2 et son Google Mercator. Cependant, cette projection n’a pas prétention de s’étendre à tout le globe, et réduire le grossissement met en évidence la déformation sur les régions adjacentes, ici le nord Canada et la Sibérie (droite). Cet exemple est disponible sur jmfriedt.sequanux.org/reproj.html.

Heureusement, proj4 se charge de cette opération pour nous, et http://spatialreference.org/ref/epsg/wgs-84-utm-zone-33n/ nous informe de la façon de définir WGS84/UTM33N (la bande qui couvre la Norvège – nous aurions choisi UTM31N pour la France). Ainsi, le mode de projection qui va nous intéresser se définit par :

proj4.defs('EPSG:32633','+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +towgs84=0,0,0 +no_defs');

Et nous pouvons faire appel aux outils de conversion de la forme :

var osmLayer = new ol.layer.Tile({ source: new ol.source.OSM() });
var map = new ol.Map({
   controls: ol.control.defaults().extend([new ol.control.ScaleLine()]),
   target: 'map',
   view: new ol.View({projection: 'EPSG:32633',center: ol.proj.fromLonLat([10, 79], 'EPSG:32633'),zoom: 9})
});
var dm_wms2013 = new ol.layer.Tile({
   preload: Infinity,
   visible: true,
   source: new ol.source.TileWMS(({
      url: 'http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi',
      params: {'LAYERS': '2013_0830utm33n', 'TILED': true, 'VERSION': '1.3.0',
      'FORMAT': 'image/png8', 'WIDTH': 256, 'HEIGHT': 256, 'CRS': 'EPSG:4326'},
      serverType: 'geoserver'
   }))
});
...

map.addLayer(osmLayer);
map.addLayer(dm_wms2013);

Ici la projection de la carte respecte la norme EPSG (WGS84/UTM33N s’appelle EPSG:32633) que nous avons défini par proj4 auparavant, tandis que les données en entrée (ici issues de la fonction WM(T)S du serveur) sont au format WGS84 en coordonnées sphériques (aussi nommée EPSG:4326).

5. Ajout automatique de toutes les couches WMS d’un projet qgis-server dans OpenLayers2

Une dernière question que nous pouvons nous poser, dans le contexte d’un travail collaboratif où chaque utilisateur est susceptible d’ajouter ses propres couches, tient en la capacité à automatiser la génération d’une page Web contenant toutes les couches fournies par un serveur QGis. Cela signifie donc récupérer la description XML des capacités du serveur, découper cette description pour extraire le nom des couches disponibles, et finalement générer automatique le script JavaScript affichant toutes ces couches. De telles fonctionnalités sont fournies (paquet php-xml dans la distribution Debian) par simplexml. Ainsi, un premier script qui se contente de lister toutes les couches disponibles en recherchant d’abord les fonctionnalités WMS du serveur, puis en étudiant [5] la liste des propriétés (FeatureTypeList) et finalement les propriétés de chacun de ces objets (FeatureType) pour en extraire le nom (FeatureTypeList->FeatureType->Name) ressemble à :

<html><head><title>XML depuis PHP</title></head><body>
<?php
   if (extension_loaded(’simplexml’)) {
      echo "extension installed:<hr>";
      $mypix = simplexml_load_file(urlencode(
         ’http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi? SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities’));
         foreach ($mypix->FeatureTypeList as $pixinfo):
            foreach ($pixinfo->FeatureType as $nam):
               if ($nam->Name!=’’) echo $nam->Name,"<br>";
            endforeach;
         endforeach;
   }
   else echo "missing extension<br>";
?>

</body></html>

Ayant compris ce mécanisme, il devient simple de générer les champs décrivant chaque couche WMS affichée, en lui attribuant le même nom de couche que celui utilisé dans QGis. Le résultat est :

<html><head><title>Toutes les couches WMS depuis openlayers</title>
   <script src="http://openlayers.org/api/OpenLayers.js"></script>
</head>
<body>
   <div style="width:100%;height:100%" id="map"></div>
   <script defer="defer" type="text/javascript">
      var map=new OpenLayers.Map(’map’);
      ls=new OpenLayers.Control.LayerSwitcher({’div’:OpenLayers.Util.getElement(’layerswitcher’)});
      map.addControl(ls);
      ls.maximizeControl();
      var wms=new OpenLayers.Layer.WMS("Basic map",
         "http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
<?php
   $k=1;
   if (extension_loaded(’simplexml’)) {
      $mypix = simplexml_load_file(urlencode(
         ’http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities’));
      foreach ($mypix->FeatureTypeList as $pixinfo):
         foreach ($pixinfo->FeatureType as $nam):
            if ($nam->Name!=’’)
               {echo "var dm_",$k,"=new OpenLayers.Layer.WMS(\"",$nam->Name,"\",";
                echo "\"http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi\",";
                echo "{layers: \"",$nam->Name,"\",";
                echo "transparent:\"true\", format:\"image/png\"},{isBaseLayer: false});\n";
                $k++;
            }
         endforeach;
      endforeach;
      echo "map.addLayer(wms);\n";
      echo "map.setCenter(new OpenLayers.LonLat(12,79),9);\n";
      for ($x=1;$x<$k;$x++) {echo "map.addLayer(dm_$x);\n";}
   } else echo "missing extension<br>";
?>
</script></body></html>

Ce qui donne la figure 6. Il serait d’une part très fastidieux d’ajouter à la main toutes les couches de ce projet, mais surtout dans cet exemple l’affichage s’adapte automatiquement aux nouvelles couches ajoutées par les divers contributeurs au projet.

Fig. 6: Ajout automatique de toutes les couches fournies par un serveur WMS sur dans un contexte d’OpenLayers2. Le script d’exemple /opt/qgis-server/plugins/HelloServer qui affiche le logo de QGis a été volontairement laissé en place pour distinguer le serveur en production (qgis.sequanux.org) du serveur de tests (127.0.0.1).

6. Ajout d’images orthorectifiées produites par microdrone

Nous avions présenté le flux de traitement permettant de générer une série d’images orthorectifiées et de modèles numériques d’élévation associés avec le souci de comparer ces jeux de données entre eux, mais sans prétention de les positionner dans un référentiel absolu partagé par convention entre plusieurs utilisateurs. Il s’avère [6] que la solution de simplement translater un jeu de données par rapport à l’autre ne suffit plus lorsque la zone considérée s’étend sur plusieurs hectares. Nous avons observé que dans ce cas, le positionnement par GPS (mono-fréquence, telle que fournie sur microdrone DJI Phantom3 Professional) n’est exact qu’à une dizaine de mètres, alors que nous visons un positionnement au décimètre près pour des comparaisons de vols successifs. Il s’avère que vouloir corriger les défauts d’échelle et de position du modèle numérique d’élévation en lui appliquant les corrections permettant de superposer les images orthorectifiées est une approche peu judicieuse, et qu’il vaut mieux insérer dans le flot de traitement l’étape d’exploitation des points de contrôle au sol pour corriger les défauts du modèle de caméra et de leur position (http://forum-micmac.forumprod.com/campari-residuals-differ-from-the-point-cloud-t881.html). Pour notre part, les points de contrôle au sol (GCP) sont acquis a posteriori dans Google Earth – les coordonnées sphériques fournies avec 6 décimales sont précises à 11 cm à l’équateur : 7 points aisément reconnaissables dans les jeux de données sont d’une part identifiée dans Google Earth (bandes de parking, barrière, coin à la base de bâtiments) avec des coordonnées converties de coordonnées sphériques (WGS84) vers un référentiel projeté localement tangent à la Terre (WGS84/UTM31N), et d’autre part leur position (en pixel) identifiée sur les images acquises par drone. Ce couple de fichiers (coordonnées dans l’espace v.s coordonnées sur les photographies) alimente l’outil Campari de Micmac. Après traitement dans ces conditions, nous observons une exactitude de position par rapport aux couches vectorielles de Openstreetmaps mais surtout par rapport à une image aérienne de l’IGN (BD ORTHO, convertie de Lambert93 à WGS84/UTM31N puisque nous avons vu que OpenLayers 2 ne sait pas le faire à la volée) meilleure qu’une vingtaine de centimètres – erreur attribuable à notre manque d’assiduité à pointer les points de contrôle. Ce jeu de données est disponible sur http://qgis.sequanux.org/cgi-bin/project/femto/qgis_mapserv.fcgi.

Fig. 7: Résultat de l’insertion de trois images orthorectifiées, en comparaison de données de référence que sont les images aériennes de la BD ORTHO de l’IGN et les données vectorielles de Opensteetmaps. En haut à gauche : deux images orthorectifiées acquises à 30 minutes d’intervalle positionnées au moyen de 7 GCPs. En haut à droite : le même jeu de données, positionné uniquement par les positions GPS du drone au moment de la prise de vue. Le trait rouge, indiquant la différence de position, est long de 9,8 m. En bas à gauche : superposition d’une image produite par drone (moitié gauche) avec une image IGN (moitié droite). En bas à droite : comparaison de deux orthophotos produites à un mois d’intervalle.

Conclusion

Nous avons proposé un environnement de travail permettant de disséminer des informations géoréférencées soit vers des utilisateurs de logiciels dédiés de gestion de systèmes d’informations géographiques (SIG) ou vers les API Web associées (OpenLayers). Est-ce que ce mode de dissémination est réellement utilisé en pratique ? L’institut polaire norvégien (NPI) propose ses informations dans ce format tel que décrit sur http://geodata.npolar.no/#basemap-services. Ainsi, sous QGis, configurer l’onglet WM(T)S vers http://geodata.npolar.no/arcgis/rest/services/Basisdata/NP_Ortofoto_Svalbard_WMTS_25833/MapServer/WMTS? donne accès aux informations bitmap que sont les photographies aériennes de très haute résolution (jusquà 16 cm/pixel !) tandis que l’url http://geodata.npolar.no/arcgis/services/CryoClim/glaciers/MapServer/WmsServer? dans l’onglet WFS donne accès aux informations vectorielles que sont les limites des glaciers extraites des images satellitaires SPOT.

Le lecteur est encouragé à reproduire ces expériences sur ses propres zones d’intérêt. Compte tenu de la résolution médiocre de Landsat, le résultat est peu convaincant pour la vallée de Chamonix, mais les glaciers groenlandais (Illulisat près de la baie de Disco) ou la banquise antarctique sont parfaitement appropriés à cette démonstration, voir la mer d’Aral sur http://www.nasa.gov/mission_pages/landsat/news/40th-top10-aralsea.html (un peu pénible à assembler car de superficie supérieure à ce que le site de l’USGS permet d’analyser) ou la mer morte sur http://earthobservatory.nasa.gov/IOTD/view.php?id=77592 et pour laquelle l’extension des bassins d’exploitation du sel est particulièrement visible. Le lecteur saura-t-il calculer la surface ainsi affectée ? Indice : tracer un polygone avec l’outil New Shapefile puis dans la table des attributs, créer un nouveau champ pour chaque polygone avec la variable $area.

Une autre voie d’étude qui semble intéressante dans le cadre de la diffusion sur le Web de données géoréférencées est qgis2web, greffon de QGis actuellement inexploitable sous Debian testing/sid compte tenu d’une dépendance cassée. Finalement, étant donné que toutes les informations pertinentes à une utilisation en surface sont disponibles sur OpenStreetMaps, ne serait-il pas temps de commencer à considérer la cartographie des services sous terrains (eau, gaz, électricité), qui même s’ils sont propriété de leurs exploitants respectifs, sont devenus des services nécessaires au quotidien d’un habitant d’Europe occidentale actuel : chaque kilomètre de route contient plusieurs dizaines de kilomètres de services sous terrains [7] qui ne demandent qu’à être cartographiés à l’occasion des ouvertures de routes.

Jean-Michel FRIEDT
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]

Émile Carry
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]

Références et Notes

[1] PIERROT-DESEILLIGNY M. et FRIEDT J.-M, « La photogrammétrie pour tous : MicMac pour la reconstruction 3D de scènes géoréférencées à partir de photographies numériques », tutorial à FOSS4G-fr 2016, décrit sur jmfriedt.free.fr/foss4g_2016
[2] FRIEDT J.-M. Friedt, TOLLE F., et BERNARD É., « Utilisation de Micmac pour la génération de modèle numérique d’élévation par traitement d’images acquises par microdrone », GNU/Linux Magazine France 191, pp.48–57 (Mars 2016)
[3] ERLE S., GIBSON R., et WALSCH J., « Building the geospatial web », dans « Mapping Hacks – Tips & Tools for Electronic Cartography », O’Reilly (2005)
[4] GIBSON R. et ERLE S., « Google Maps Hacks – Tips & Tools for Geographic Searching and Remixing », O’Reilly (2006)
[5] Les divers champs se déduisent de l’analyse de la sortie de wget -O – « http://127.0.0.1/cgi-bin/mon_projet/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities »
[6] LISEIN J., PINEUX N., PIERROT-DESEILLIGNY, DEGRÉ A., et LEJEUNE P., « Détection de l’érosion dans un bassin versant agricole par comparaison d’images multidates acquises par drone », Colloque Drones et moyens légers aéroportés d’observation, 26/06/2014 (Montpellier), disponible sur http://orbi.ulg.ac.be/handle/2268/171616
[7] Chaque kilomètre de route à Hong-Kong recouvre 47 km de services enterrés, http://www.uti.hk/media/attachments/2nd_ICUMAS_full_paper.pdf ou http://www.scmp.com/news/hong-kong/article/1647088/small-army-utility-specialists-keeps-hongkongers-safe-pipes-cables, ou en d’autres termes il existe 47 câbles, tuyaux, fibres optiques et autres modes de transmission de fluides et d’informations sous chaque route.

Remerciements

J.-P Culas (CM-Drones, Besançon) a effectué les vols au-dessus du parking de FEMTO-ST. Les membres du forum Micmac (http://forum-micmac.forumprod.com/) ont une fois de plus partagé leurs connaissances pour corriger les défaillances dans les traitements que nous proposions initialement.

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Les données géoréférencées, générées par l’auteur ou distribuées par les agences telles que l’ESA (sentinels.copernicus.eu) ou l’USGS (earthexplorer.usgs.gov), sont disséminées au travers d’un service accessible par le Web selon les formats WFS ou WMTS. Ces données sont alors exploitables au travers de logiciels spécialisés tels que QGis, ou de l’API OpenLayers pour être intégrées dans des pages Web.

Tout possesseur de téléphone portable devient en mesure aujourd’hui de produire de la donnée géoréférencée, qu’il s’agisse de photographies numériques ou de traces de parcours pour les données brutes, ou des données issues d’informations géoréférencées acquises. Nous avons par exemple présenté au FOSS4G-fr [1] et dans ces pages [2] la génération de modèles de bâtiments par les photographies géoréférencées prises par téléphone, et leur intégration dans QGis sur fond de carte OpenStreetMaps (OSM).

Obtenir de telles données est bien, mais les partager avec une communauté d’utilisateurs, c’est mieux. Le mode de transmission le plus pratique pour les volumes de données dont il est question est évidemment internet, ne serait-ce que pour centraliser les données partagées en vue de garantir leur cohérence si plusieurs utilisateurs les manipulent.

Trois protocoles de dissémination ont été mis en place à cet effet [3][4] : WM(T)S, WFS et WCS. Le premier dissémine des images représentant les données traitées, avec une résolution adaptée à l’échelle de la carte de l’utilisateur. Ne fournissant qu’une image des informations transmises, il n’est plus possible pour l’utilisateur de s’approprier ou retraiter lui-même des informations. Les deux autres protocoles disséminent les données brutes, vectorielles ou matricielles. Nous nous proposons d’aborder séquentiellement trois problèmes : un serveur de données pour disséminer les informations qui auront été traitées dans QGis (qgis-server) ; la récupération des informations sur un logiciel dédié tel que Qgis pour le traitement des informations ; et finalement la récupération des données dans un client Web pour affichage comme couche OpenLayers. Afin de ne pas faire durer le suspens plus longtemps, le lecteur est encouragé à consulter qgis.sequanux.org/jmfwms.html et jmfriedt.sequanux.org/reproj.html pour se faire une idée du résultat recherché.

Le contexte de notre étude porte sur le retrait de glaciers à front marin en milieu arctique. Les images des satellites Landsat sont acquises depuis les années 1970 et mises à disposition par l’USGS, par exemple sur http://landsatlook.usgs.gov/viewer.html. Elles sont plus ou moins bien géoréférencées (une petite correction est parfois nécessaire, surtout pour les plus anciennes), mais surtout souffrent d’une résolution médiocre (de l’ordre de 30 m/pixel) compte tenu des standards actuels. Plus de 40 ans d’histoire d’images satellites en font néanmoins une source irremplaçable pour appréhender l’évolution des régions qui vont nous intéresser. Notre travail initial sous QGis a été d’importer toutes ces images, les reprojeter dans un référentiel localement plan (WGS84/UTM33N, le référentiel projeté approprié pour le nord de la Norvège tel que nous en informe http://spatialreference.org/ref/epsg/wgs-84-utm-zone-33n/), s’assurer par quelques points de référence que les images sont convenablement positionnées, et dans le cas contraire les repositionner au moyen de 4 ou 5 points de référence sur le pourtour de la région considérée (presqu’île de Brøgger, Svalbard). Ces informations matricielles sont alors utilisées pour tracer manuellement (création d’un shapefile comprenant des lignes) les fronts marins des glaciers, créant ainsi un jeu de données vectorielles. Par ailleurs, un trajet en avion a été enregistré au moyen du récepteur GPS d’un téléphone portable (logiciel OSMTracker sous Android) et nous désirons insérer la séquence de points au format GPX dans nos cartes. Sous QGis, l’opération est triviale (Vector > GPS Tools > Load GPX File) mais pourrons-nous exporter cette information par le Web et l’inclure dans les pages affichées par un navigateur ? Nous verrons que la réponse n’est pas aussi triviale qu’il pourrait paraître.

Fig. 1 :Projet QGis que nous désirons partager au travers d’internet, avec toutes les images sans nuages acquises par Landsat de la presqu’île de Brøgger au Svalbard, et la mesure de position des fronts, illustrant le recul de 4 km en 40 ans du Kongsbreen.

1. Le serveur : qgis-server

QGis a tout prévu pour nous : un projet QGis s’exporte dans un format accessible par le Web au travers de qgis-server. Le principal exercice va donc porter sur l’installation de cet outil, puisqu’exporter le projet se résume à Project > Projet Properties et activer WMS, WFS et WCS en cochant toutes les couches (Select All) dans les deux derniers cas.

L’installation de qgis-server ne présente aucune difficulté et est décrite parfaitement sur http://docs.qgis.org/testing/en/docs/user_manual/working_with_ogc/ogc_server_support.html. On notera cependant que bien que le service WM(T)S fonctionne convenablement avec des versions plus anciennes de qgis-server, l’export des couches vectorielles (formats WFS et WCS) ne semble pas opérationnel pour les versions précédent 2.12. Nous expérimenterons donc avec une version au moins supérieure à 2.14 de QGis et de son serveur qgis-server. Sous Debian GNU/Linux, cela signifie éviter Wheezy mais travailler dans la version stable à la date de cette rédaction.

À l’issue de l’installation du serveur comme service d’Apache2 (nécessitant le support FCGI fourni par libapache2-mod-fcgid), le bon fonctionnement du service est validé (dans le cas d’une installation locale) par :

$ wget -O - "http://127.0.0.1/cgi-bin/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities"

La réponse doit être du type :

<Service>
   <Name>WMS</Name>
   <!-- Human-readable title for pick lists -->
   <Title>QGIS mapserver</Title>
   <!-- Narrative description providing additional information -->
   <Abstract>A WMS service with QGIS mapserver</Abstract>
...

Le service étant fonctionnel, divers projets QGis (fichier .qgs) sont placés, avec toutes les données associées aux diverses couches du projet, dans des sous-répertoires de /usr/lib/cgi-bin, en complétant avec une copie du serveur Fast-CGI (qgis_mapserv.fcgi).

Attention !
Les liens symboliques entre /usr/lib/cgi-bin et, par exemple, un répertoire utilisateur, ne sont autorisés qu’en modifiant la configuration par défaut de Apache2 sous Debian dans /etc/apache2/conf-available/serve-cgi-bin.conf en remplaçant le + par un – de l’option SymLinksIfOwnerMatch.

Si le projet QGis autorise l’export des couches au format WM(T)S ou WFS, nous validons la capacité à rapatrier ces couches (dans notre cas le projet et ses fichiers se trouvent dans /usr/lib/cgi-bin/project/landsat de qgis.sequanux.org) par :

$ wget -O - "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&\
REQUEST=GetCapabilities"

La réponse est la liste des couches accessibles sous la forme :

<WFS_Capabilities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ...
<Service>
<Name>WFS</Name>
...
<FeatureType>
<Name>fronts5</Name>
<Title>fronts5</Title>
<Abstract></Abstract>
<SRS>EPSG:4326</SRS>
<Operations>
<Query/>
</Operations>
<LatLongBoundingBox maxx="12.2424" minx="12.103" maxy="79.0268" miny="78.9989"/>
</FeatureType>
...

Nous voyons donc que la projection dans laquelle les coordonnées des points formant la couche (ici vectorielle) est renseignée (EPSG:4326 signifie WGS84 en coordonnées sphériques tel que nous l’indique le CRS sous QGis), et l’extension de la couche (autour de 12°E et 79°N).

Ces points sont récupérés – au format GML – par une requête WFS de la forme :

$ wget -O - "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&\
REQUEST=GetFeature&typename=fronts5&featureid=fronts5.toto"

La réponse est :

<gml:LineString srsName="EPSG:4326">
<gml:coordinates cs="," ts=" ">12.11525618,79.02193675 12.1224397,79.02118041 12.11728195,
79.01669523 12.11808149,79.0123295 12.12970628,79.00850923 12.14676275,79.00549989 12.16023071,79.00480137
12.16426326,79.00331772 12.16469826,79.00161054 12.17939472,78.99997196 12.18340417,79.00381158 12.20189733,
79.00556583 12.21455655,79.00542793 12.2268052,79.00560265 12.2366082,79.00626179 12.24175315,79.00561112
</gml:coordinates>

Nous avons ici les diverses coordonnées qui forment la ligne d’une des couches vectorielles de notre projet QGis, accessible au travers d’une requête HTML. Ces données sont donc accessibles par la communauté, il reste à en faire un bon usage avec les divers outils à notre disposition. Nous présentons quelques exemples ci-dessous.

2. Le client : Qgis

Le premier environnement le plus simple pour accéder à ces données est QGis lui même. Dans la barre des icônes de gauche de QGis, les trois icônes en forme de globe proposent l’accès respectivement aux données au format WM(T)S, WCS et WFS. Dans tous les cas, il nous faut renseigner l’url du serveur, par exemple http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi. Lors de la connexion, la liste des couches accessibles est proposée, et cliquer sur une couche suivi de Add donne accès au jeu de données. La seule subtilité dans cette application tient à ne pas utiliser un serveur trop ancien (avant 2.12) sous peine de voir la liste des couches s’afficher, mais une liste vide de points être retournée par les requêtes WFS. WM(T)S semble avoir toujours bien fonctionné (voir figure 2).

Fig. 2: Obtention de couches WM(T)S – images au format bitmap des données (“fronts4”) – et WFS – informations vectorielles (“fronts3”), depuis QGis. Noter le logo de QGis qui est un effet de bord du serveur de test installé par le site web décrivant l’installation de QGis. Effacer /opt/qgis-server/plugins/HelloServer ou tout au moins /opt/qgis-server/plugins/HelloServer/icons/icon.png pour s’affranchir de cet effet.

3. Intégration dans une page web : OpenLayers 2

La portée de notre serveur se retreint encore à un public relativement averti puisque utilisateur de QGis. Nombreuses sont les cartes sur le Web qui ne sont pas destinées à un auditoire de géographes mais simplement pour illustrer un concept à des utilisateurs probablement spécialistes dans d’autres domaines. Afin d’insérer des cartes et les couches générées sous QGis, l’environnement de développement en JavaScript OpenLayers semble idéal puisque fournissant la capacité à charger des couches dans tous les formats qui nous intéressent – WM(T)S, WFS ou GPX pour les traces GPS. Nous avons initialement été sensibilisés à OpenLayers comme environnement de développement pour accéder aux couches fournies par l’IGN au travers de Géoportail. Nous allons dans un premier temps nous intéresser à la version stable d’OpenLayers (version 2) qui semble mature, mais verrons que la nouvelle mouture (version 3) offre des fonctionnalités précieuses qui justifient la migration vers l’environnement en cours de développement.

Une carte OpenLayers est formée d’un appel aux bibliothèques JavaScript (<script>…</script>), la création d’une carte remplie d’un fond par défaut – nous choisissons le fond vectoriel OpenStreeMaps (OSM) – et recouvert de diverses couches additionnelles que nous fournirons depuis qgis-server.

Dans son expression la plus simple, une page OpenLayers ressemble à :

<html>
   <head>
      <title>Essai de lecture de WMS depuis openlayers</title>
      <script src="http://openlayers.org/api/OpenLayers.js"></script>
   </head>
   <body>
      <div style="width:100%;height:100%" id="map"></div>
      <script defer="defer" type="text/javascript">
         var map=new OpenLayers.Map(’map’);
         var wms=new OpenLayers.Layer.WMS("Basic map","http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
         map.addLayer(wms);
         map.setCenter(new OpenLayers.LonLat(12,79),9);
      </script>
   </body>
</html>

Et tant que nous n’insérons que des couches WMS – donc des images (puisque les données, même vectorielles, sont transmises sous forme d’images avec une résolution adaptée au facteur de grossissement), tout se passe bien. Nous pouvons ainsi ajouter une image Landsat accessible sous forme WMS, voir même un des fronts de glacier :

<html>
   <head>
      <title>Essai de lecture de WMS depuis openlayers</title>
      <script src="http://openlayers.org/api/OpenLayers.js"></script>
   </head>
   <body>
      <div style="width:100%;height:100%" id="map"></div>
      <script defer="defer" type="text/javascript">
         var map=new OpenLayers.Map(’map’);
         var wms=new OpenLayers.Layer.WMS("Basic map","http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
         var dm_wms2013=new OpenLayers.Layer.WMS(
            "Landsat image 2013",
            "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
            {layers: "2013_0830utm33n", transparent:"true", format:"image/png" },
            {isBaseLayer: false}
         );
         var fronts1=new OpenLayers.Layer.WMS(
            "Glacier fronts1",
            "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
            {layers: "fronts4", transparent:"true", format:"image/png"},
            {isBaseLayer: false}
         );
         map.addLayer(wms);
         map.setCenter(new OpenLayers.LonLat(12,79),9);
         map.addLayer(dm_wms2013);
         map.addLayer(fronts1);
      </script>
   </body>
</html>

Le lecteur est encouragé à compléter cet exemple en ajoutant un front additionnel, par exemple la couche nommée fronts5, et observer la conséquence d’échanger l’ordre d’affichage des couches. Ces exemples sont fortement inspirés des excellents tutoriaux fournis par http://demo.3liz.com/wfst/wfs.html.

Pour WFS, le problème se corse : le principe de Same Origin impose que le serveur de données soit sur le même site que le serveur Web. Ceci est valable pour toute donnée vectorielle. Afin d’illustrer ce problème, nous proposons trois sources de données : un même fichier GPX stocké sur jmfriedt.sequanux.org, jmfriedt.free.fr, puis qgis.sequanux.org. Le serveur qgis-serveur fournissant les couches WFS est exécuté comme service Apache2 sur qgis.sequanux.org, tandis que la page Web qui fait appel à ce service peut être placée sur chacun de ces trois serveurs. La figure 3 illustre les interdictions d’accès rencontrées, tel qu’indiqué par Firebug : le fichier GPX stocké sur jmfriedt.sequanux.org peut être lu par la page http://jmfriedt.sequanux.org/jmfwfs.html mais est rejeté par la même page stockée sur http://jmfriedt.free.fr/jmfwfs.html. Cette dernière n’a accès qu’au même fichier GPX placé dans le répertoire du serveur jmfriedt.free.fr.

Fig. 3: Trois illustrations du problème de Same Origin pour se convaincre de la source du problème.

Les exemples de la figure 3 sont obtenus, après la définition de la carte, par l’appel aux couches vectorielles aux formats GPX ou WFS, de la forme :

var lgpxfree = new OpenLayers.Layer.Vector("GPX track free", {
   strategies: [new OpenLayers.Strategy.Fixed()],
   protocol: new OpenLayers.Protocol.HTTP({
      url: "http://jmfriedt.free.fr/May_6,_2016_11;20;10_2016-05-06_11-20-10.gpx",
      format: new OpenLayers.Format.GPX()
   }),
   style: {strokeColor: "red", strokeWidth: 5, strokeOpacity: 0.8}
});
var lgpxsqnx = new OpenLayers.Layer.Vector("GPX track sqnx", {
   strategies: [new OpenLayers.Strategy.Fixed()],
   protocol: new OpenLayers.Protocol.HTTP({
      url: "http://jmfriedt.sequanux.org/May_6,_2016_11;20;10_2016-05-06_11-20-10.gpx",
      format: new OpenLayers.Format.GPX()
   }),
   style: {strokeColor: "green", strokeWidth: 5, strokeOpacity: 0.8}
});
var fronts=new OpenLayers.Layer.Vector("Test WFS", { // WFS
   strategies: [new OpenLayers.Strategy.BBOX()],
   protocol: new OpenLayers.Protocol.WFS({
      url : "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
      featureType : "fronts5",
   }),
});

map.addLayer(wms); map.setCenter(new OpenLayers.LonLat(12,79),9);
map.addLayer(fronts);
map.addLayer(lgpxsqnx);
map.addLayer(lgpxfree);

Ce code fait appel au même fichier GPX stocké sur deux serveurs (afin de valider que seule la couche située sur le même serveur que la page Web appelante est acceptable), et la couche nommée fronts5 fournie au format WFS par qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi.

Fig. 4: En local (127.0.0.1), tout se passe bien, les données et le serveur sont au même endroit. L’intérêt en terme de diffusion reste limité : placer toutes ses données sur le même site que le serveur résout les problèmes de Same Origin (l’exemple de droite est accessible sur qgis.sequanux.org/jmfwms.html).

Ayant dépassé tous les écueils de configuration, nous avons finalement la satisfaction de voir toutes les couches s’afficher sur la même carte, en ajoutant l’onglet de commandes qui permet d’activer ou désactiver chaque couche afin d’aisément comparer la position des fronts des glaciers et leur évolution dans le temps :

var map=new OpenLayers.Map('map');
ls=new OpenLayers.Control.LayerSwitcher({'div':OpenLayers.Util.getElement('layerswitcher')});
map.addControl(ls);
ls.maximizeControl();

Il n’aura cependant pas échappé au lecteur que nos images satellites semblent fortement déformées (comparer les figures 1 et 4). Il s’agit ici de la conséquence de la projection de Mercator, qui tend à considérablement grossir l’axe des abscisses lorsque la zone considérée s’éloigne de l’équateur. Quoiqu’acceptable jusqu’à des latitudes de ±60°, l’effet devient vraiment significatif au-delà et carrément désagréable par 79°N. C’est pourquoi les projections locales, tentant de trouver un plan localement tangent à la sphère représentant le globe terrestre, ne prétendent pas à s’appliquer à l’ensemble de la Terre mais uniquement à un petit segment de longitude. Malheureusement, OpenLayers 2 ne supporte pas la reprojection à la volée des données bitmap, nous sommes coincés avec la projection imposée depuis Google Maps qui continue à déformer les pôles. Nous allons remédier à ce problème en passant sous OpenLayers 3 et retrouver ainsi les belles cartes de Qgis.

Jean-Michel FRIEDT
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]

Émile Carry
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !