L’annotation de données, ou la saisie de données, est un préalable essentiel à l’IA. Car plus il y aura de données, si possible de bonne qualité, et mieux elle apprendra.
L’IA permet d’atteindre des facteurs d’échelle tels que dessiner 1000 emprises de stationnement pour l’entraînement, peut potentiellement vous permettre d’en détecter des dizaines de milliers, voire soyons fous, des millions.
Dans le précédent article, nous avons esquissé quelques réflexions autour de l’annotation de données sous QGIS vis-à-vis de celle sur des logiciels plus classiques en IA comme LabelStudio.
Ici, nous nous intéresserons à la configuration de l’environnement technique sous QGIS pour l’annotation, toujours en nous intéressant aux emprises de stationnement.
Tout d’abord, définissons ce que nous voudrons caractériser sur ces emprises :
- La géométrie bien entendu ;
- La forme du stationnement (voir billet précédent) qui peut être en bataille, épi ou longitudinal (parallèle) ;
- La destination Personnes à Mobilité Réduite.
Environnement
L’annotation doit remplir plusieurs objectifs :
- Obtenir beaucoup de données ;
- Avoir des données de bonne qualité ;
- Fournir aux annotateurs un environnement de travail adapté.
Selon moi, les trois piliers de l’annotation pourraient être ceux-ci :

Concernant la charge mentale associée à la tâche d’annotation, il est essentiel de fournir un environnement adapté, ergonomique : double écran, outils conviviaux. Il est important de faire des pauses, de s’arrêter lorsqu’une fatigue cognitive apparaît, de diversifier les tâches.
Concernant la reconnaissance, il est inutile de se le cacher : l’annotation pâtit d’une mauvaise image, peu valorisée d’un point de vue sociétal, mal payée, souvent dissimulée, car confiée le plus souvent à des “travailleurs du clic”, le plus souvent localisés dans des pays du tiers-monde ou en voie de développement. Alors qu’il s’agit du métier essentiel de l’IA.
La reconnaissance de cette activité est un point essentiel : il est important de la rétribuer correctement, y compris symboliquement. Les auteur.es de ces annotations ne sont jamais cités, noyés dans la masse des données.
Géométrie et sémantique
Précédemment, nous avons vu que l’intérêt de QGIS était de pouvoir dissocier la saisie des géométries de celle des attributs.
Il y a deux façons principales de saisir les objets, pour lesquels on pourra juger de la rapidité, à augmenter, et de la charge mentale associée, à réduire au maximum.
La première consiste à saisir les géométries dans une première passe, puis d’éditer les attributs sémantiques dans une seconde.

La seconde consiste à saisir objet par objet, soit pour chaque objet de le dessiner, puis de saisir ses attributs.

Je ne me suis pas intéressé à des études sur la charge cérébrale associée à l’annotation, mais il me semble qu’un continuum de mêmes activités, ou d’activités similaires, est à la fois à même d’atteindre une certaine rapidité, mais aussi de réduire la charge mentale d’un cerveau qui changera moins de mode à chaque fois.
Personnellement, dans le cas présent, je découperais le projet en trois phases
- La saisie des géométries ;
- Une pause ☁️ ;
- La caractérisation de la forme de stationnement ;
- Une pause ☁️ ;
- La caractérisation de la place PMR ou pas PMR ;
- Fini !
Ergonomie du poste de travail
N’étant pas ergonome, je vous laisserai le soin de consulter vers des articles traitant de ce sujet.
Concernant la station assise, je pense qu’elle pourrait être questionnée. La tâche d’annotation étant une tâche harassante, je pense qu’il faut nous autoriser à bouger, à agiter ses jambes, et donc de s’autoriser la station debout.
Concernant les écrans, dans l’idéal, il faut disposer :
- d’un écran pour la saisie des géométries, par exemple à gauche ;
- d’un autre pour la visualisation ou l’édition des attributs, à droite.

Cependant, si vous n’avez pas de double écran, vous pouvez émuler cet environnement en choisissant d’insérer la table d’attributs dans le dock à droite grâce à ce bouton :

Déplacez ensuite la table à droite :

Comme sur l’image ci-dessus, vous pouvez alléger l’interface en supprimant le contrôle des couches, puisque vous n’agirez que sur la couche Places, et en positionnant l’outil d’ajout de polygones à gauche.
Concernant les souris, certaines souris assez sophistiques disposent de touches configurables dont certaines pourraient correspondre à des classes différentes de l’objet : un bouton pour PMR, un autre pour Non PMR, par exemple.
Dessin
Pour dessiner les places, vous pouvez activer l’outil de forme, en choisissant le mode Rectangle à partir de trois points.

Dans ce mode, vous saisissez deux points, le troisième point crée un rectangle déporté, projeté. Le rectangle s’agrandit au fur et à mesure où vous éloignez le troisième point.

Formulaires
Type liste de valeurs
Dans un premier temps, nous allons créer un formulaire afin de remplir l’ensemble de ces champs.
Concernant la forme du stationnement, nous pouvons créer un champ forme et configurer le formulaire sous la forme classique d’une liste déroulante :

Derrière, la donnée est modélisée d’une façon propre, respectant le standard.
Cependant, lors du remplissage, cela demandera deux clics : un clic pour déployer pour la liste et un clic pour choisir l’item.
Deux clics :

Personnellement, afin de faciliter la saisie, je préfèrerai créer un champ par forme de type booléen : bataille, epi et longitudinal

Même si cette modélisation n’est pas correcte d’un point de vue standard, elle permettra de n’opérer qu’un seul clic en cochant directement le type de forme.
N’oublions pas l’adage, :
🧙 Le mieux est parfois l’ennemi du bien
Cela dit, cela n’empêche pas par la suite de transformer la donnée au bon standard et de réunir les valeurs des trois colonnes dans un champ forme.
L’expression QGIS de transformation sera :
CASE
WHEN bataille is TRUE THEN 'bataille'
WHEN epi is TRUE THEN 'épi'
WHEN longitudinal is TRUE THEN 'longitudinal'
Ainsi, dans le process, nous aurions la donnée d’annotation à transformer ensuite en donnée brute, celle qui pourrait être par exemple diffusée en OpenData. Attention cependant à veiller à la compatibilité des deux modèles.
Cas booléen simple
Intéressons-nous à présent à la caractérisation PMR ou pas PMR.
Pour cela, les choses sont assez simples : il suffit de créer un champ PMR de type booléen. Ainsi, nous aurons une case à cocher pour dire si la place est PMR ou pas.
Il est possible de choisir la valeur NULL pour avoir trois modalités :
FALSE(Non PMR)TRUE(PMR)NULL(vide, soit pas caractérisée).

Visuellement, on peut faire la différence sur la case à cocher entre une place Non PMR et une place non caractérisée car la place avec la valeur NULL apparaîtra avec un rectangle gris.

Tandis que la place Non PMR (FALSE) apparaîtra avec un rectangle non coché.

Décocher la case nécessitera de cliquer deux fois, ce qui peut être pénible à la longue, d’autant plus qu’il y a bien davantage de places Non PMR que de places PMR.
Ce que je préfère faire est de créer deux champs booléens :
pmrnon_pmr
En mettant la valeur à FALSE (décoché) par défaut à toutes les deux.

- S’il y a
FALSEpour les deux, alors cela veut dire que la place n’a pas été caractérisée. - S’il y a l’une des deux valeurs, alors cela signifie que la place a été caractérisée.
- Par contre, s’il y a les deux valeurs à
TRUE, cela doit provoquer une erreur.
Vous pouvez faire ce contrôle de cohérence dans QGIS, dans les contraintes en ajoutant l’expression sur les deux champs :
pmr is not non_pmr

Ainsi, on aura ceci si les champs sont mal remplis :

NB : Vous pouvez changer le message en “NON MAIS OH CA VA PAS LA TÊTE !”
Par contre, si les informations sont bien saisies, on a :

🎉 Youpi !
Saisie multiple
Le plugin QuickMultiAttributeEdit permet de changer très facilement les attributs d’un ensemble d’objets, par exemple pour mettre un ensemble de places en non PMR.
Vous les sélectionnez, puis changez la valeur en ouvrant la fenêtre facilement par le raccourci F10.

Configurer la vue attributaire
Dans le cadre d’une saisie en deux temps, la seconde passe s’intéresse à l’édition des attributs associés à la place de stationnement.
Passez dans un premier temps la table en mode formulaire en ayant préalablement sélectionné dans la vue formulaire des propriétés de la couche uniquement les champs qui vous intéressent pour le remplissage (ma phrase est un peu trop longue, j’espère que vous avez suivi), de façon encore une fois à alléger l’interface et réduire la charge.
Le entités sont ordonnées par fid. Cela peut être bien : si vous vous étiez arrêté.e la veille à l’entité 500, notez que vous devrez reprendre à la 501e.
En haut, pour la visualisation rapide, vous pouvez afficher une expression qui vous indiquent les entités qui n’ont pas encore été remplies :
format('%1 %2',"fid", if(pmr is FALSE and non_pmr is FALSE , 'à voir', 'ok'))

Vous pouvez même filtrer les entités qui seront seulement à regarder en allant dans le filtre avancé de la table en bas en tapant pmr is FALSE and non_pmr is FALSE :

Il y a des boutons très pratiques qui permettent de naviguer aisément sur la carte d’entité en entité, que je vous conseille d’activer (soit le déplacement à échelle constante (pan), soit le zoom sur l’entité (1)) :

Clavier

Utiliser le clavier est très efficace par rapport à utiliser la souris.
En effet, la souris nécessite :
- de solliciter le cortex visuel pour déplacer la souris là où c’est nécessaire ;
- de solliciter le poignet, ce qui peut, à terme, faire mal aux articulations ;
- d’activer plusieurs régions et organes de notre corps ;
- Et nous sommes de gros feignants.
Vous pouvez le plugin Go2NextFeature pour passer d’une entité à une autre. Notamment, le raccourci F6 permet avec cette extension de passer à la prochaine entité.
Personnellement, je préfère configurer moi-même mes raccourcis. Notamment, je configure un raccourci Control+Flèche droite pour aller à l’entité suivante et pour la précédente.Control+Flèche gauche

Aller dans Préférences, Raccourcis Clavier

Après avoir cliqué sur Modifier, tapez votre combinaison de touches, pour moi Control + Flèche droite
Chercher également “Modifier l’entité précédente de la table d’attributs”

Conclusion
Dans cet article, nous avons vu quelques réflexions autour de la modélisation des données pour l’annotation en envisageant un modèle de données basique.
Nous avons vu comment configurer les champs de formulaires, y compris avec des contraintes.
Nous avons aussi vu comment configurer l’environnement de travail, ainsi que la vue formulaire en table d’attributs pour naviguer aisément entre entités, cibler celles à qualifier.
Nous avons vu comment configurer des raccourcis Clavier.
Nous avons, je l’espère, ri de temps en temps.
A suivre
Dans un prochain article, nous verrons comment renseigner automatiquement des champs utiles grâce aux expressions QGIS.
Goodie
Vous avez peut-être remarqué ce raccourci très utile à côté du nom de ma couche :

C’est grâce au plugin Attribute Shortcut.
Un clic sur cette icône affiche automatiquement la table attributaire. Très simple et pratique.

























































