Examen des données OSM

Révisé le 24 avril 2017

• Examen des données OSM
  • Contrôles quotidiens
    • Validation des données
    • Utilisation de la recherche JOSM
  • Re-sondage
    • Correction des erreurs
    • Rapport sur l’exactitude
  • Requêtes SQL
    • Préparer les données
    • Requêtes SQL
  • Résumé

Cette section couvre les processus de vérification de la qualité des données, en particulier dans le cadre d’un projet de cartographie OSM dirigé, tel que ceux entrepris par le Équipe humanitaire OpenStreetMap dans différents pays et Open Cities des projets au Bangladesh, au Sri Lanka et au Népal. Les méthodes démontrées peuvent être utiles dans d’autres contextes également, lorsque l’examen de la qualité des données est une tâche régulière.

Lorsque nous essayons de cartographier un ensemble complet de caractéristiques et d’attributs dans une zone donnée, nous avons besoin de moyens pour vérifier les erreurs et évaluer la précision du travail. Dans ce tutoriel, nous allons étudier plusieurs méthodes de vérification des données, en expliquant les étapes de la méthode et la raison d’être de chacune. Un projet de cartographie bien géré comprendra chacun de ces trois processus, tant pour évaluer et corriger les données que pour établir des rapports.

• Contrôles quotidiens
• Re-sondage
• Requêtes SQL

Ces méthodes d’examen prennent de l’importance à mesure que le modèle de données se développe et que le nombre de caractéristiques recueillies devient assez important. Par exemple, il ne faudrait pas beaucoup de temps et d’efforts pour évaluer un modèle de données qui ne comporte que des points d’intérêt (POI) :

Dans ce cas, les questions à poser seraient les suivantes :

• Les POI ont-ils été cartographiés dans tous les endroits ?
• L’attribut “nom” manque-t-il à certains POI ?
• L’attribut ‘‘type’’ manque-t-il à certains POI ?
• L’attribut “numéro de téléphone” manque-t-il à certains POI ?
• La valeur du champ ‘‘nom’’ est-elle correctement capitalisée ?
• Le numéro de téléphone a-t-il un sens ?

Cependant, un modèle de données est généralement beaucoup plus complexe, comme dans le cas de la cartographie des bâtiments. Considérons un modèle de données qui comprend ceci :

Maintenant, vous pouvez cartographier des milliers de bâtiments qui ont de nombreux attributs, et l’analyse devient plus critique. Dans ce tutoriel, nous utiliserons les bâtiments comme exemple, bien que les mêmes méthodes puissent être appliquées pour examiner d’autres types d’éléments.

Contrôles quotidiens

La façon la plus immédiate de vérifier les données est de les examiner et de les valider sur une base régulière. Cela peut être quotidien ou tout au plus hebdomadaire. Pour le superviseur d’une équipe de cartographes, il s’agit d’une tâche importante car le fait de repérer rapidement les erreurs et les mauvaises pratiques d’édition permet de les corriger et d’apprendre aux éditeurs à faire les choses correctement.

Nous allons examiner ici quelques méthodes pour vérifier les données en utilisant simplement le JOSM. Voici quelques-unes des questions que nous nous posons sur nos données :

• Y a-t-il des erreurs topologiques (comme des bâtiments qui se chevauchent ou des relations incorrectes) ?
• Y a-t-il des erreurs de balisage (balises mal orthographiées, combinaisons clé-valeur mal utilisées) ?
• Les données sont-elles complètes selon le modèle de données ?

Voyons comment nous pouvons trouver des réponses à ces questions dans le JOSM. Nous supposerons que nous examinons le travail d’autres personnes, mais les mêmes processus fonctionneront parfaitement (et devraient être plus faciles) lorsque vous analyserez votre propre travail.

Nous allons utiliser un exemple de fichier de données provenant du projet de cartographie Open Cities à Dhaka. Pour nous suivre, téléchargez le fichier suivant : dhaka_validation_example.osm

N’essayez PAS de sauvegarder vos modifications sur OpenStreetMap. Ces exercices sont uniquement destinés à des fins de démonstration.

Validation des données

La première étape pour vérifier les données est d’exécuter l’outil de validation dans le JOSM, qui vérifiera automatiquement les données que vous avez ouvertes pour détecter les erreurs suspectes. Cet outil est particulièrement utile pour trouver des erreurs de topologie, mais peut ne pas être aussi utile pour trouver des étiquettes incorrectes.

• Activez l’outil en cliquant sur le bouton Outil de validation sur le côté gauche de JOSM. (Cette opération est inutile si le panneau de validation est déjà ouvert).

• Ensuite, assurez-vous que rien n’est sélectionné en cliquant dans un endroit vide de votre cartographe. Si des éléments sont sélectionnés lorsque vous exécutez l’outil de validation, seuls ces éléments sélectionnés seront vérifiés (parfois, vous pouvez vouloir vérifier uniquement certains éléments, mais pour l’instant, nous allons vérifier l’ensemble du fichier).
• Cliquez sur le bouton “Validation” du panneau.

• Vous verrez apparaître une liste d’avertissements :

• Une nouvelle couche apparaît également, montrant où se trouvent les erreurs. Vous trouverez peut-être pratique de cacher cette couche pour l’instant.

Examinons quelques-uns de ces avertissements. Vous pouvez voir qu’il y a quatre avertissements “Croisement de bâtiments”. Cet avertissement signifie que des bâtiments se chevauchent quelque part. Sélectionnez le premier élément de cette liste, faites un clic droit et cliquez sur “Zoom sur le problème”.

Cliquez également sur le bouton “Select” en bas de la fenêtre de validation pour sélectionner les voies en question. Cela montre que ces deux voies ont un problème :

• Il s’agit d’une erreur que nous n’aurions jamais détectée sans l’outil de validation. Si vous faites un zoom très précis, vous pouvez voir qu’il y a un minuscule chevauchement entre les bâtiments, ce qui est une erreur topologique, car les bâtiments ne se chevauchent généralement pas. Pour résoudre ce problème, le nœud central doit être déplacé. Si les bâtiments se touchent réellement, ce qui est probablement le cas, le nœud du milieu peut être joint à la voie.
• Une fois cette correction effectuée, nous pouvons relancer l’outil de validation et cet avertissement aura disparu de la liste.

Cette méthode de vérification automatique des données est un moyen efficace de corriger les erreurs de topologie, en particulier celles qui seraient difficiles à remarquer par une personne. Dans la liste des avertissements de validation, vous pouvez voir que d’autres avertissements tels que “Bâtiment dans un bâtiment” sont le résultat d’une erreur similaire.

D’autres avertissements, tels que “Traverser une voie d’eau/une autoroute”, ne sont pas nécessairement des erreurs. Cela montre que l’outil de validation est bon pour trouver les erreurs possibles, mais il faut que quelqu’un aille voir si l’erreur est importante ou non.

Examinons l’avertissement sous “Chemins de même nom” pour voir une erreur qui n’est pas topologique. Cliquez sur “Select” pour sélectionner les deux voies en question.

Pouvez-vous dire quelle est l’erreur ? Nous avons ici deux segments de route différents, qui sont en fait la même route, mais qui ont été nommés de manière légèrement différente - “route” prend la majuscule sur l’une des voies mais pas sur l’autre. Il est logique qu’ils aient le même nom, et dans ce cas, le mot “route” doit être mis en majuscule.

Utilisation de la recherche JOSM

La recherche dans JOSM est un moyen puissant d’examiner les données. Elle vous permet de fournir des termes de recherche, également connus sous le nom de requêtes, pour sélectionner uniquement les caractéristiques que vous souhaitez.

• Pour accéder à la recherche, allez dans Édition -> Recherche ou appuyez sur CTRL + F sur votre clavier.

• Il existe un grand nombre de types de requêtes que vous pouvez rechercher ici, et vous pouvez voir des détails et des exemples dans le champ de recherche lui-même et en cliquant sur le bouton “Aide”.

• Pour l’instant, essayons de sélectionner tous les bâtiments. Presque tous les bâtiments auront le tag building=yes et quelques-uns auront building=construction. Cela signifie que nous pouvons construire une requête qui dit :

  building = yes OU building=construction

• Cela devrait sélectionner tous les bâtiments, mais juste au cas où quelqu’un aurait appliqué la mauvaise étiquette à un bâtiment, nous pouvons utiliser un caractère générique à la place, ce qui sélectionnera toutes les caractéristiques qui ont la clé bâtiment.

• Tous les bâtiments seront sélectionnés.

C’est très bien, mais comment cela nous aide-t-il à examiner les données ? Eh bien, maintenant que toutes les caractéristiques d’un même type ont été sélectionnées, nous pouvons rechercher les étiquettes incorrectes.

• Regardez dans la fenêtre Propriétés - ce que nous voyons, ce sont toutes les balises de chaque objet sélectionné. Elles partagent toutes les mêmes clés, mais comme chaque caractéristique a des valeurs différentes, elles sont marquées comme <different>.

• Cliquez sur la balise building:use, puis cliquez sur “Modifier”.

• FAITES ATTENTION ! Vous ne voulez pas modifier la valeur et cliquer sur OK, car cela modifierait cette balise pour chaque élément de construction. Ce serait très mauvais.
• Cliquez plutôt sur la case déroulante située à côté de Valeur.

• Remarquez que tous les éléments en gras sont accompagnés d’un nombre entre parenthèses. Il s’agit du nombre d’éléments sélectionnés qui ont cette valeur de balise.

Nous pouvons comparer cela avec les balises OpenStreetMap qui ont été cartographiées dans notre modèle de données, et rechercher les erreurs. Par exemple, cette balise représente l’utilisation du bâtiment. Au début du projet Open Cities Dhaka (d’où proviennent ces données), il y avait une incertitude quant à savoir si un bâtiment à usage mixte devait être étiqueté building:use=multipurpose ou building:use=mixed. Comme la première étiquette avait déjà été utilisée dans d’autres pays, elle a été choisie. Cependant, nous voyons ici qu’un des bâtiments a été étiqueté comme mixed. Nous devons corriger cela. (Une autre erreur évidente sont les trois termes différents pour garage, mais nous ne la corrigerons pas ici).

• Nous ne pouvons pas modifier la caractéristique qui a la balise building:use=mixed ici, car nous avons des centaines de caractéristiques sélectionnées. Donc, pour corriger l’erreur, nous devons d’abord la trouver. Comment ? Vous l’avez deviné : avec l’outil de recherche.
• Cliquez sur “Annuler” pour quitter cette boîte de dialogue. N’oubliez pas que cliquer sur OK peut être dangereux.
• Ouvrez à nouveau la recherche et saisissez la requête suivante : “building:use”=mixed
• Notez que les guillemets sont nécessaires car les deux points ( :) ont également une signification de recherche. Cela devrait permettre de sélectionner le seul bâtiment qui possède cette balise. Il peut maintenant être corrigé avec la valeur multipurpose.

Rappelez-vous que si vous suivez ce tutoriel, NE TENTEZ PAS d’enregistrer vos modifications sur OpenStreetMap. Ces exercices sont uniquement destinés à des fins de démonstration.

Re-sondage

Lorsqu’on gère un projet tel qu’une étude détaillée d’un bâtiment, il faut prévoir une méthode supplémentaire de contrôle de la qualité, à la fois pour améliorer le travail et pour rendre compte de la précision à la fin du projet.

Si de nombreuses équipes de cartographes collaborent à la collecte d’informations sur une zone, il est courant qu’une ou plusieurs d’entre elles ne fassent pas un travail satisfaisant. Même les équipes qui font un travail efficace et précis feront des erreurs. Imaginez des équipes qui cartographient chacune 100 bâtiments par jour - il n’est pas improbable qu’un petit pourcentage des attributs qu’elles collectent soit incorrect.

Ainsi, un bon projet comprendra un processus de revérification d’une partie du travail effectué, de correction des erreurs, de détermination des équipes de cartographes dont les performances sont satisfaisantes, et d’approximation du pourcentage d’erreurs pour un rapport final.

Bien sûr, il ne sert à rien de refaire une enquête sur tous les bâtiments d’une zone cible, mais 5 à 10 % des bâtiments devraient être examinés. Les zones à examiner doivent être choisies parmi différentes zones afin de permettre une comparaison entre les équipes d’enquête. Les équipes d’enquêteurs peuvent se relancer mutuellement ou, si possible, des responsables plus expérimentés peuvent se charger des révisions. Il est courant que les responsables consacrent un jour par semaine à la réévaluation de certaines parties de la zone cible.

Correction des erreurs

Que faut-il faire lorsque des erreurs sont constatées ?

S’il y a un petit nombre d’erreurs (moins de 5 % des bâtiments), les problèmes doivent être portés à l’attention de l’équipe de cartographes d’origine afin qu’elle soit consciente et ne fasse plus les mêmes erreurs. Les données doivent être corrigées dans OpenStreetMap et les résultats de la nouvelle enquête doivent être enregistrés.

Si les erreurs sont nombreuses, il faudra peut-être prendre des mesures plus importantes. Il faudra s’adresser à l’équipe de levés de manière appropriée, et les zones qu’elle a cartographiées devront peut-être même être entièrement réétudiées, en fonction du degré d’inexactitude des données. Un taux d’inexactitude supérieur à 10 % est très probablement inacceptable.

Rapport sur l’exactitude

Le deuxième objectif de la nouvelle enquête est de pouvoir rendre compte de l’exactitude des données à la fin du projet. Les utilisateurs des données voudront connaître vos paramètres et vos méthodes d’évaluation de la qualité des données.

En incluant ce processus dans votre méthodologie d’examen, vous serez en mesure d’expliquer clairement comment vous avez évalué la qualité des données et de fournir des chiffres concrets indiquant le pourcentage d’erreur probable contenu dans vos données d’enquête.

Par exemple, imaginons que nous gérons un projet qui cartographie 1000 bâtiments. Nous décidons de cartographier 10% d’entre eux, soit 100 bâtiments, choisis au hasard dans la zone cible. Nous nous rendons sur place et constatons que sur les 100 bâtiments que nous avons réétudiés, six d’entre eux présentent un niveau élevé d’imprécision. Disons que nous définissons l’inexactitude par le fait que plus d’un attribut est incorrect. Nous pouvons corriger ces erreurs, mais nous devons quand même extrapoler qu’environ 6 % des 1 000 bâtiments sont probablement inexacts. Cela doit être signalé comme l’erreur probable à la fin du projet.

Il faut refaire l’enquête tout au long du projet. Imaginez que nous ayons attendu jusqu’à la fin dans cet exemple et que 40 bâtiments sur 100 soient faux ! Cela pourrait ruiner l’ensemble du projet. Il est préférable de détecter les erreurs à grande échelle à un stade précoce afin de pouvoir les corriger.

Requêtes SQL

Le meilleur outil d’analyse est probablement l’exécution de requêtes SQL dans un système SIG, tel que Quantum GIS. Cette méthode est similaire à la recherche de données dans JOSM, mais elle offre une analyse plus puissante, même si elle peut prendre un peu plus de temps à mettre en place. L’utilisation de JOSM est un moyen rapide et régulier de vérifier les erreurs de base, tandis que l’interrogation dans QGIS est plus adaptée à la recherche de données manquantes ou d’attributs incorrects.

Nous supposerons ici que vous avez une certaine connaissance des SIG, et nous nous concentrerons sur la construction de requêtes qui peuvent vous aider à examiner les données OpenStreetMap. Pour les exercices ci-dessous, nous utiliserons à nouveau les données du projet Open Cities Dhaka, que vous pouvez télécharger sur [dhaka_sql.zip] (http://learnosm.org/files/dhaka_sql.zip). Les données OpenStreetMap ont été exportées à l’aide de l’outil d’exportation HOT (export.hotosm.org) et les limites de la zone cible ont été définies au début du projet.

Préparer les données

Décompressez les fichiers et chargez les deux fichiers shapefiles dans QGIS. Nous commencerons par découper uniquement les bâtiments situés dans la zone du projet, afin de simplifier nos requêtes par la suite.

• Commençons par sélectionner uniquement les polygones qui se trouvent dans la zone cible. Pour ce faire, nous allons utiliser le plugin Requête spatiale. Si vous ne l’avez pas encore installé, allez dans Plugins -> Gérer et installer les plugins pour le trouver et l’installer.
• Allez dans Vecteur -> Requête Spatiale -> Requête Spatiale.
• Vous devez remplir les paramètres pour sélectionner les caractéristiques de planet_osm_polygon qui sont dans la zone cible.

• Cliquez sur Appliquer. Seuls les polygones situés dans la zone cible seront sélectionnés.

• Cliquez avec le bouton droit de la souris sur la couche et enregistrez la sélection en tant que nouveau fichier shapefile. Ajoutez-le au projet.

• Ensuite, filtrons uniquement les polygones qui sont des bâtiments et qui ont été collectés dans le cadre de ce projet.
• Cliquez avec le bouton droit de la souris sur planet_osm_polygon et cliquez sur “Filtrer…”.
• Entrez la requête suivante :

“building” != NULL AND “source” = ‘Open Cities Dhaka Survey’

• Cliquez sur OK. Le filtrage des données à l’aide de cette requête n’affiche que les polygones qui ont quelque chose dans la colonne bâtiment. Elle supprime également les bâtiments qui n’ont pas l’étiquette source associée à ce projet.
• Sauvegarder ces données comme un nouveau shapefile. Nous utiliserons ce fichier pour nos requêtes SQL.

Requêtes SQL

Nous pouvons maintenant exécuter des requêtes sur la couche des bâtiments pour trouver d’éventuelles erreurs. Réfléchissons à certaines choses que nous pourrions vouloir interroger. Le modèle de données de ce projet indique les attributs qui devraient être collectés pour chaque bâtiment - ils sont :

• name
• building
• building:levels
• building:use
• building:vertical_irregularity
• building:soft_storey
• building:material
• building:structure
• start_date
• building:condition

Notez que dans le fichier shapefile, ces noms d’attributs sont tronqués, puisque les noms de colonnes sont limités à 10 caractères.

Alors, quel genre de questions voulons-nous poser ? Quelles sont les erreurs probables ? Une erreur courante est qu’un bâtiment a été cartographié, mais que tous les attributs n’ont pas été collectés. Nous voulons donc exécuter une requête qui montre tous les bâtiments qui n’ont pas un ensemble complet d’attributs. Bien sûr, pour certains attributs, comme le nom et la date de début (année de construction), il est tout à fait normal qu’ils soient vides, car tous les bâtiments n’ont pas un nom et parfois l’année de construction est inconnue. Mais les autres attributs doivent toujours être collectés.

Essayons d’élaborer une requête à ce sujet :

• Faites un clic droit sur la couche des bâtiments (la couche que nous avons créée dans la section précédente) et cliquez sur “Filtrer…” Cela ouvrira le constructeur de requêtes. Ici, nous pouvons écrire des requêtes complexes pour retourner uniquement les données que nous voulons.
• Vous pouvez construire votre propre requête en double-cliquant sur les champs, les opérateurs et les valeurs, ou vous pouvez copier la requête que nous avons construite ici :

“building_c” = NULL OR “building_s” = NULL OR “building_l” = NULL OR “building_m” = NULL OR “vertical_i” = NULL OR “soft_store” = NULL OR “building_u” = NULL

• Cliquez sur “Test” et vous verrez que cette requête renvoie 125 caractéristiques. Cela signifie que sur les quelque 3500 bâtiments qui ont été cartographiés, 125 d’entre eux ne possèdent pas un ou plusieurs de ces attributs.

• Cliquez sur OK pour afficher uniquement les bâtiments qui répondent aux conditions de la requête.

• Ces bâtiments peuvent ensuite être examinés de plus près afin d’identifier les attributs manquants et de déterminer s’ils doivent faire l’objet d’une nouvelle enquête. Il est alors possible d’utiliser QGIS pour créer une cartographie qu’une équipe de relecture pourrait utiliser pour corriger les attributs manquants des bâtiments.

Quelles sont les autres requêtes qui pourraient être utiles ? Eh bien, vous pouvez également vouloir vérifier les attributs qui ne sont pas contenus dans votre schéma de données. Nous l’avons fait dans la section de recherche du JOSM. Vous pouvez utiliser une requête pour trouver tous les bâtiments dont les attributs ne correspondent pas à votre modèle de données.

Vous pouvez également l’utiliser pour rechercher des anomalies, qui sont probablement mais pas nécessairement des erreurs. Par exemple, si nous ouvrons le générateur de requêtes, que nous sélectionnons bâtiment_l et que nous cliquons sur “Tous” pour charger toutes les valeurs d’attribut possibles, nous constatons que la plupart des bâtiments ont un nombre compris entre un et 20 (cet attribut est building:levels, le nombre d’étages du bâtiment). Mais il y a aussi un 51. Il semble peu probable qu’il y ait un bâtiment de 51 étages dominant tout dans cette zone, nous pouvons donc le localiser et noter de le vérifier auprès des cartographes.

L’interrogation peut être un moyen efficace de rechercher d’éventuelles erreurs dans l’ensemble des données. Combinée à d’autres fonctionnalités de QGIS, elle peut être utilisée pour produire des cartographies qui peuvent être utilisées pour examiner les données d’une zone.

Résumé

Dans ce tutoriel, nous avons passé en revue plusieurs méthodes efficaces pour maintenir la qualité des données au cours d’un projet et effectué quelques exercices pratiques pour nous entraîner à examiner les données OSM. Lorsque vous organisez un projet de cartographie, ou même lorsque vous évaluez les données d’une zone pour un usage personnel, ces méthodes peuvent s’avérer utiles.