État de l’art – Synchronisation d’extraction d’OpenStreetMap sous contrainte de qualité

1 Contexte

OpenStreetMap est un projet de données cartographiques collaboratives. Les données sont mises à jour en continu par les contributeurs. La nature des contributeurs et les motivations sont variées¹ ². Les contributeurs sont des particuliers, des lobbyistes (vélo, randonnées…) ou des professionnels de collectivités locales, de petites ou grandes entreprises³ ⁴.

Ces acteurs contribuent à OpenStreetMap comme un commun numérique pour partager la connaissance du territoire et sa diffusion. Mais aussi, dans un objectif souvent premier, de réutiliser eux-mêmes les données qu’ils contribuent à créer et à maintenir avec le reste de la communauté.

La problématique de la qualité de la donnée est une question récurrente. Elle porte sur deux entrées.

Les données de la base commune d’OpenStreetMap ou toutes les modifications sont prises en compte en direct, sans validation à priori. Des outils de suivis et de validation à posteriori des données sont disponibles.
Des données d’OpenStreetMap extraites puis réutilisées et diffusées par les acteurs via d’autres canaux.

Les critères de qualité peuvent être globaux à la communauté ou spécifique à des acteurs, sous-communauté ou thématiques.

Nous cherchons ici à assurer la qualité du second type d’entrée pour utiliser et diffuser des données.

L’objectif n’est pas de garantir la qualité de façon absolue, cela nécessiterait un référentiel de comparaison. Si nous utilisons OpenStreetMap, c’est que nous ne disposons pas de ce référentiel ou d’un référentiel satisfaisant. OpenStreetMap est alors la solution qui à la meilleure couverture, le meilleur moyen de diffusion ou de rapidité de mise à jour.

À contrario de la qualité absolue, l’objectif est de garantir la stabilité relative de la qualité. C’est-à-dire, d’assurer que la qualité reste stable ou s’améliore.

1.1 Solutions existantes pour adresser la qualité

1.1.1 Adresser la qualité à priori

Il s’agit de contrôler les données « contribuées » avant qu’elles ne soient envoyées dans la base de données OpenStreetMap.

Les contributions à OpenStreetMap sont réalisées par un ensemble ouvert d’outils qui envoient des modifications sur une API commune. Le service de l’API n’effectue aucune validation des modifications de données elles-mêmes.

Les outils d’édition de données se basent sur un même « schéma » de données qui n’est pas formel. On peut le voir comme un schéma coutumier⁵. Ces « coutumes » ne sont pas unifiées, bien qu’il existe des formalisations partagées, ces différents outils ont des usages⁶ comportant des nuances. À noter que ces coutumes ont également des nuances selon les territoires et les groupes de contributeurs.

Ces usages variés au niveau du(des) schéma(s) ne peuvent être qu’amplifiés au niveau de la validation des données préalables à l’envoi vers l’API d’OpenStreetMap.

Les outils ont plus ou moins de règles de validations, elles-mêmes plus ou moins facultatives. Toutes fois l’éditeur le plus utilisé, JOSM, est celui qui dispose également du plus de règle de validations⁷. Le second éditeur le plus utilisé, iD, dispose également d’un autre jeu de règles de validation⁸.

Prenant en compte tout cela, il est évident que l’on ne peut supposer d’aucun respect de règles de qualité des données d’OpenStreetMap, mais uniquement d’une tendance de celles-ci à se rapprocher d’usages coutumiers.

1.1.2 Adresser la qualité à posteriori

1.1.2.1 Adresser la qualité des données à posteriori

Pour améliorer la qualité des données de la base d’OpenStreetMap il existe des outils de validation : global, thématique ou territorial. Ils valident l’état en cours de la base de données.

Ces outils de validation ont également l’avantage de ne pas être restreints à la zone de données courant lors des sessions de contributions. En effet les outils d’édition ne valident que les données sur les zones de travail.

Ces outils de validation effectuent des signalements de possibles anomalies que les contributeurs peuvent utiliser pour améliorer les données.

On trouve principalement trois outils de ce type au fonctionnement similaire : Keep Right⁹, OSM Inspector¹⁰ et Osmose-QA¹¹. Ils analysent de manière au mieux journalière les données avec des règles (encore une fois propre à chaque outil) et produisent des listes de signalements consultables sur une carte. Tous les contributeurs peuvent visualiser et traiter ces signalements.

1.1.2.2 Adresser la qualité des changements à posteriori

En plus de contrôler l’état courant de la base de données OpenStreetMap, il existe au moins un outil pour le contrôle des modifications apportées par les contributeurs : OSMCha¹². D’autres outils mineurs existent, ils ne sont pas détaillés ici : par exemple : osm-analytic-tracker¹³ et osmada¹⁴.

Les contributions sont envoyées à l’API d’OpenStreetMap dans des sessions de travail nommées changesets. Ces changesets regroupent les modifications effectuées par un contributeur avec un outil dans une session de travail. À noter que ces changesets ne sont pas des groupes de modifications transactionnels au sens des bases de données.

De fait, ces changesets ont souvent une forme de cohérence propre, bien que ce ne soit pas requis. Par exemple une cohérence territoriale liée à une session de contribution sur le terrain, ou une cohérence thématique liées à une session de contribution avec l’usage d’un outil de signalement d’anomalie qualité.

L’utilisation de règles de validation des changements et de la cohérence interne des changesets permettent ici de signaler de potentielles détériorations de la qualité.

Comme pour les autres outils qualités, les contributeurs peuvent se saisir de ces signalements pour intervenir.

1.1.2.3 Une approche itérative

Le traitement de la qualité est donc une approche itérative qui consiste à améliorer de façon continue les données existantes.

Toutefois, en parallèle sont effectuées d’autres contributions réalisées sans assurance sur la qualité.

L’on peut donc imaginer que même si, ponctuellement et sur un périmètre thématique et/ou territorial, l’on peut se rapprocher d’un objectif donné de qualité cet état n’est toutefois que local et ne va pas perdurer dans le temps.

1.2 Stratégie d’extraction de données de qualité

Pour rappel, l’on souhaite extraire, réutiliser et diffuser des données de qualité basées sur OpenStreetMap.

Par extraction, l’on entend ici une copie synchronisée totale ou partielle suivant des découpages territoriaux et/ou thématiques.

L’on ne définit pas ici des critères de qualité, ils sont hors de l’approche de la méthode discutée ici. Les critères de qualité sont discutés plus loin.

1.2.1 Extraction puis correction hors d’OpenStreetMap

L’approche la plus simple consiste à faire une extraction. Si ces données ne correspondent pas aux objectifs qualités, l’on peut alors directement corriger les données extraites.

Cette approche a le défaut de ne pas reporter les corrections dans OpenStreetMap. Le reste de la communauté et nous-mêmes n’en profiterons pas lors de la prochaine extraction.

Une solution est alors d’effectuer en parallèle les mêmes corrections dans OpenStreetMap. Ce n’est évidemment pas une approche souhaitable.

Figure 1: Contribution non contrôlé à OpenStreetMap. Extraction non contrôlé. Correction de l’extraction.

1.2.2 Itération d’extraction et de correction dans OpenStreetMap

L’alternative est d’effectuer les corrections directement dans OpenStreetMap et d’effectuer à nouveau l’extraction des données.

L’avantage est de n’effectuer qu’une seule fois les corrections et de les partager avec la communauté. Pour être efficace, il est nécessaire de disposer de l’outillage qui permet de faire cette extraction de façon automatisée et avec des délais faibles de prise en compte des corrections.

Cette approche à l’inconvénient d’intégrer au fil des itérations des données contribuées parallèlement hors critères de qualité. Ce qui a pour conséquences :

de nécessiter plus d’itérations pour converger vers le niveau de qualité souhaité ;
d’intégrer suffisant de « turbulence » pour risquer de ne jamais arriver à atteindre les critères de qualité à un instant donnée. Obligeant, soit à terminer les corrections directement dans les données extraites hors d’OpenStreetMap, soit à abaisser le niveau de qualité attendu. Aucune de ces deux approches n’étant souhaitée.

Figure 2: N itérations de correction dans OpenStreetMap suivi d’extractions.

1.2.3 Mise à jour d’extractions

Les mises à jour de ces extractions peuvent être faites en reproduisant à nouveau le même processus. C’est-à-dire en réitérant sur l’extraction de données OpenStreetMap jusqu’à atteindre de nouveaux les critères de qualité.

Ces boucles d’itérations peuvent prendre du temps pour faire converger la qualité. Ce qui induit que le temps d’effectuer ces itérations, une nouvelle réplication ou extraction ne peut pas être faite.

Figure 3: M itérations de mise à jour.

1.2.4 Flux différentiels

Les contributions à la base de données commune OpenStreetMap sont faites en flux continu. Il en est de même pour les réplications de la base de données et les extractions que l’on peut en faire. Il est possible de les mettre à jour en appliquant en flux continu ou en différé ces mêmes modifications.

1.2.5 Mise à jour des extractions en continu

Pour conserver les critères de qualité sur la réplication ou l’extraction il faut contrôler que si après une mise à jour les critères de qualité ne vont plus être respectés, alors il n’est pas possible d’appliquer cette mise à jour.

Il est alors nécessaire de corriger les données dans OpenStreetMap pour que les mises à jour cumulées permettent à nouveau de respecter les critères de qualité.

Cette approche à l’avantage de pouvoir rendre automatique des mises à jour tant que les critères de qualité sont respectés. À noter que l’on aurait pu atteindre le même résultat par ré-extraction. La mise à jour par flux différentiel réduit uniquement la quantité de données à valider et les temps de traitement.

Une fois que les mises à jour ne satisfont plus les critères de qualité, il faut intervenir dans OpenStreetMap pour revenir à cet état. À noter que cette méthode porte les mêmes inconvénients que l’approche précédente par ré-extraction. Elle permet seulement de réduire le délai entre l’extraction et l’original, tant que les critères de qualité sont respectés.

*Figure 4: Mise à jour différentielle de l’extraction.*

1.3 Une troisième voie : mise à jour partielle

Cette approche consiste donc à partir de données OpenStreetMap en l’état, ou après une première montée en qualité par l’approche précédente. On ne va ensuite venir mettre à jour la réplication ou l’extraction qu’avec des modifications partielles, qui une fois appliquées n’introduisent pas une baisse de la qualité.

Si des mises à jour ne remplissent pas les critères, elles sont rejetées et signalées. Les données doivent être corrigées dans OpenStreetMap et les mises à jour partielles cumulées peuvent alors être intégrées lorsque la qualité est à nouveau satisfaisante.

On assure ainsi l’invariant de stabilité ou de croissance de la qualité des données extraites.

L’avantage de cette mise à jour partielle est de pouvoir intégrer raidement et automatiquement les mises à jour ou correction qui peuvent l’être. Les données rejetées pour raison de qualité peuvent être traités de façon asynchrone.

Cette approche pose par contre des problèmes de consistance de l’état de l’extraction avec uniquement des mises à jour partielles.

Figure 5: Mise à jour partielle de l’extraction.

2 Structure et échanges de données OpenStreetMap

2.1 Méta-schéma

Les données d’OpenStreetMap ne sont pas structurées comme des données cartographiques classiques. Elles reposent sur :

les « nodes », des points ;
les « ways », des lignes brisées ;
les « relations », des groupes de points, lignes ou groupes ;
Des « tags », des couples de clé-valeurs libres.

Il n’y a pas de schéma au sens classique pour la définition des champs. Cela relève des coutumes.

2.2 Filtres et API Overpass

Le premier moyen pour filtrer de données passe par des listes de tags : clés uniquement, ou clé-valeurs à conserver ou rejeter. Les filtres peuvent également porter sur la nature du support (nodes, ways, relations).

Des filtres sur les liens entre les éléments peuvent ensuite être utilisés : topologie, relation spatial, sémantique…

Ces filtres peuvent être effectués par des outils sur des fichiers binaires, dans des bases de données telle que PostgreSQL+PostGis ou par un langage et une API dédiée à OpenStreetMap : Overpass API¹⁵.

2.3 Diff

Les données d’OpenStreetMap sont diffusées par export (« dump ») dans un format XML¹⁶ ou PBF¹⁷ binaire spécifique. Ces formats sont relationnels et non spatiaux.

Les mises à jour (« diff ») sont diffusées dans un format identique. Ils ne contiennent que les objets modifiés. Ces mises à jour sont diffusées suivant les fournisseurs à la minute, à l’heure ou à la journée. Ces mises à jour sont globales ou territoriales.

Ces mises à jour peuvent être accumulées et combinées : diff_a→b + diff_b→c = diff_a→c

2.4 Changeset

Les changesets sont des groupes de modifications, au même format que les diff. Un changeset est associé à une session de contribution.

Un changeset peut s’étaler dans le temps, modifier plusieurs fois le même objet, modifier des objets contribués par d’autres contributeurs en parallèle dans d’autres changesets.

Il n’est pas possible de rejouer les changesets de façon unaire, ils ne sont pas transactionnels, on ne peut pas les accumuler et les combiner.

3 Solutions existantes

3.1 Solutions de suivis des changements

3.1.1 OSMCha

OSMCha¹⁸ est un outil en logiciel libre de contrôle qualité des changesets déjà contribués à OpenStreetMap. C’est un contrôle à posteriori.

Les contributeurs peuvent traiter les signalements et corriger les données dans OpenStreetMap.

Figure 6: Changesets dans le temps et l’espace. Lignes verticales, évolution des versions d’un même objet dans le temps. Ajout en vert, modification en orange, suppression en rouge. Les groupes sont les changesets, sans obligation de cohérente temporelle ou spatiale. Uniquement la précédence des versions des objets est garantie.

Figure 7: OSMCha. Interface utilisateur de consultation des changesets signalés.

3.1.1.1 Critique de cette approche

OSMCha n’est pas une solution de synchronisation de données, mais permet le contrôle à posteriori.

Elle offre cependant un contrôle des changements ouvert à la communauté. La validation est faite collaborativement.

C’est l’historique des changesets qui est adressé. Les changesets ou objets peuvent déjà être périmés au moment du contrôle manuel par un contributeur.

Les signalements peuvent n’être adressés par personne.

3.2 Solutions de synchronisations

3.2.1 IdeoMap, Teritorio

IdeoMap est la solution historique à Teritorio de synchronisation d’une extraction de base de données OSM. Cette une solution interne à Teritorio qui n’est pas publique.

IdeoMap permet de configurer un territoire et des thématiques de données à répliquer. Ces thématiques sont définis par des filtres de tags OpenStreetMap.

L’extraction initiale se fait par récupération des données d’OpenStreetMap en l’état. Des requêtes à l’API Overpass sont faites pour récupérer par thématique et territoire les données. IdeoMap convertit tous les objets sous forme de point.

Les mises à jour sont déclenchés manuellement. Pour chaque couple (territoire, thématique) une requête à l’API Overpass est faite pour faire une nouvelle extraction. La liste des différences entre l’extraction locale et la nouvelle extraction est affiché à l’utilisateur. Lorsque la version de l’objet OpenStreetMap a changé, l’objet est identifié comme différent.

Pour chaque objet de la liste des différences, l’utilisateur peut choisir de l’intégrer à la copie locale.

Pour les différences qui ne conviennent pas, l’utilisateur peut aller corriger les données dans OpenStreetMap. Puis redemander un différentiel.

Le choix et le moment de l’intégration des mises à jour, objet par objet, repose entièrement sur l’utilisateur.

*Figure 8:IdeoMap, gestion de la synchronisation. Version des objets synchronisés en gras. Les objets sont complètement indépendant.*

Figure 9: IdeoMap, interface utilisateur. Extrait de la liste des objets disponibles à la synchronisation.

3.2.1.1 Critique de cette approche

La solution IdeoMap affiche relativement peu de contexte pour décider ou non de l’intégration d’objets. Mise à part le nom du dernier contributeur, ces informations sont à trouver à l’extérieur de la solution.
La synchronisation ne peut se faire qu’avec l’état actuel d’OpenStreetMap.
Les objets portant des différences sont tous soumis à un contrôle manuel. Les validateurs peuvent vite être dépassés par le volume de données à valider.
L’outil de synchronisation traite tous les types d’objets, mais ne produit que des points.
Les objets sont traités de façon indépendante.
L’outil n’est pas indépendant d’un autre outil de mise en forme de l’information pour le web.
L’outil ne permet de suivre et de synchroniser qu’une liste de tags configurée. Les autres attributs concomitants dans OpenStreetMap ne sont pas pris en compte.

3.2.2 LeBonTag, Geonov

LeBonTag est une solution en logiciel libre de synchronisation d’extractions thématiques de données d’OpenStreetMap.

Un territoire et des filtres thématiques sont configurés. Le contrôle des thématiques et les attributs peuvent être affectés à des vérificateurs.

L’import initial est fait à date et en l’état avec toutes les données du territoire issues d’OpenStreetMap.

Lors de chaque mise à jour journalière, un différentiel entre la date d’import initial et l’état actuel est produit via l’API Overpass, pour l’ensemble des données OpenStreetMap.

Les objets ciblés par les filtres dont la version est différente de celle dans la copie synchronisée sont soumis à l’utilisateur qui a en charge la validation.

Les versions des objets validés sont intégrées un à un dans la copie synchronisée. Les objets qui ne satisfont pas le validateur sont à corriger dans OpenStreetMap. Les corrections seront récupérées à la prochaine mise à jour.

Avant de pouvoir être intégré dans la copie synchronisée, un objet a besoin d’être validé dans toutes les thématiques dans lesquelles il est ciblé. Si des attributs sont soumis à des validateurs différents, tous les validateurs doivent avoir validé l’objet.

3.2.2.1 Critique de cette approche

Les objets portant des différences sont tous soumis à un contrôle manuel. Les validateurs peuvent vite être dépassés par le volume de données à valider.
Les mises à jour des objets sont faites de façon indépendante.
L’outil est adapté à suivre des nodes ou ways, mais pas des relations.
L’outil manque d’information de contexte pour aider la validation (modifications intermédiaires de l’historique, logiciel d’édition utilisé…)
Il faut attendre le lendemain pour récupérer les données corrigées dans OpenStreetMap.
L’API Overpass n’est pas adaptée à la synchronisation du volume de données non thématiques sur de larges territoires.

3.2.3 MaRS, Facebook

3.2.3.1 Contexte

Facebook utilise OpenStreetMap pour la cartographie dans ces différentes applications. Dans ce cadre ils ont contribué massivement à OpenStreetMap. Ils ont également mis en place une solution pour s’assurer de la qualité des cartes qu’ils diffusent.

Cette réplication contrôlée des données OpenStreetMap est mise à jour en flux et republié sous forme d’export de temps en temps. Cette distribution des données OpenStreetMap est nommé Daylight¹⁹. Cette version des données est réutilisée par d’autres acteurs dont Esri²⁰ ou MapTiler²¹.

Pour produire cette réplication contrôlée, Facebook a développé un outil spécifique : MaRS²² ²³. Cet outil n’est pas diffusé, n’est pas accessible et sa configuration n’est pas connue, seul le résultat des données produites Daylight l’est.

3.2.3.2 MaRS

Les objectifs de cette solution sont les suivants.

Avoir une copie des données d’OpenStreetMap aussi proche que possible de l’original.
Avoir une représentation du monde réel aussi correcte que possible.

La stratégie consiste à adresser les deux axes de façon indépendante.

La qualité est traitée en marquant les modifications suspectes et en les corrigeant le plus rapidement possible dans OpenStreetMap.
La représentation réelle du monde est traitée en étant le plus à jour possible avec les données OpenStreetMap d’origine.

Comme pour les autres outils, il est posé comme invariant que seule la base OpenStreetMap d’origine peut être éditée.

3.2.3.3 LoChas

Les contributions à OpenStreetMap sont faites dans des changesets dont la cohérence interne est incertaine. L’idée ici est d’adresser la question de la cohérence des modifications en ne traitant pas les objets un à un, ni par changeset, ou changesets cumulés. Mais plutôt par groupe d’objets modifiées connexes (topologiquement et contextuellement). L’intervalle temporel des modifications prise en compte dans ces groupes n’a pas d’importance. Les groupes sont alors l’unité d’intégration atomique à la copie synchronisée d’OpenStreetMap. Ils sont nommés LoChas (logical changesets).

L’objectif est d’assurer la cohérence locale lorsqu’un groupe de modifications partielles est intégré à la réplication.

Plus on attend pour intégrer les modifications, plus les LoChas risquent d’agréger de plus en plus d’objets de proche en proche. Il est donc nécessaire d’avoir des algorithmes de découpe des LoChas en unité de taille raisonnable tout en essayant d’intégrer rapidement les modifications.

Dans ce but une intégration automatique des changements acceptables aide à conserver le stock de LoChas faible en même temps que leurs tailles petites. Cette acceptation des LoChas est traitée par des règles, de l’apprentissage automatique et le cas échéant de la validation et correction humaine de données dans OpenStreetMap.

Cette approche permet de traiter en flux l’intégration partielle des changements tout en conservant la cohérence locale.

Figure 10: MaRS, gestion de la synchronisation Groupement dans l’espace des objets en LoChas. En gras les LoChas et version des objets synchronisées.

3.2.3.4 Critique de cette approche

C’est une solution interne à Facebook, difficilement réplicable. Peu d’information sur le logiciel sont disponibles.

La diffusion publique de Daylight est intéressante (et requise par la licence de données), mais les critères de production ne sont pas connus. Étant produit en interne, il n’est pas non plus possible d’en produire des variantes. Les publications de Daylight sont aujourd’hui espacées d’environ un mois.

3.3 Critique générale des approches

	Monitoring tools			Synchro avec validation
	OSMCha	Osm-analytic-tracker	osmada	ideoMap	LeBonTag	MaRS / Daylight
Méta information
Code source	Public – Github – ISC (BSD 2-Clause / MIT like) https://github.com/mapbox/osmcha-frontend	Public – Github – GNU GPL 2.0 https://github.com/MichaelVL/osm-analytic-tracker	Public – Github – AGPL https://github.com/Cartocite/osmada	Private	Public – Gitlab – GPL 3.0 https://gitlab.com/Geonov/le-bon-tag	Private
Validation	Collaborative	Collaborative	Mono utilisateur	Mono utilisateur, privé	Multi-utilisateur mais privé	Multi-utilisateur mais privé
Online public instance	https://osmcha.org/	HS https://osm.expandable.dk/	–	–	–	–
Sortie	Alertes	Alertes	ADiff / CSV	« SIG », Convertit tout en point	« SIG »	OSM
Méthode
Temporalité	Historique des changesets	OSM actuel	OSM actuel	OSM actuel	OSM actuel	OSM actuel
Ciblage	Tout	Configurable	Configurable	Configurable	Configurable	Tout
Segmentation	Changeset	Changeset	Par objet	Par objet	Par objet	Par objet (changement non significatif) Par LoCha (spatial)
Validation	par changeset	par changeset	–	Validation des diff sur les objets et non par thématique.	Validation par thématique Mais besoin de valider un objet dans toutes les thématiques	Par LoCha

Seul LeBonTag est un outil de synchronisation au code source libre.
Seul OSMCha est un outil collaboratif ouvert à la communauté et travail collaboratif. Les autres outils sont prévus pour un usage interne. Cependant il existe des cas d’usage où plusieurs entités pourraient collaborer sur un même territoire à valider ensemble des données.
Seul MaRS produit des données en sortie au format OpenStreetMap.
Seul MaRS adresse la problématique de la cohérence des modifications en introduisant le concept de LoCha.

4 Qualité et acceptabilité des changements

4.1 IdeoMap, Teritorio

La solution cible des tags d’OpenStreetMap. Un changement sur ces tags entraîne la nécessité d’une revalidation humaine.
Les changements de géométrie ne sont pas surveillés.
Les objets sont à valider un à un et indépendamment les uns des autres.

Il n’y a pas de critère propre à l’outil ou d’autre configuration possible que des tags à surveiller.

4.2 LeBonTag, Geonov

La solution cible des tags d’OpenStreetMap. Un changement sur ces tags entraîne la nécessité d’une revalidation humaine.
Les changements de géométrie sont surveillés. Les petites différences de géométrie sont filtrées et écartées pour ne pas être considéré comme des modifications.
Une liste de contributeurs permet d’accepter automatiquement les objets dont ils sont les derniers contributeurs.
Un indice de confiance est accordé aux contributeurs pour aider le travail de validation. Les contributeurs sont notés en fonction de la validation ou l’invalidation de leurs précédentes contributions.
Les objets sont à valider un à un et indépendamment les uns des autres.

Il n’y a pas de critère propre à l’outil ou d’autres configurations possibles que des tags à surveiller.

4.3 MaRS, Facebook

Contrairement aux autres solutions l’idée est de valider automatiquement tout ce qui peut l’être. L’objectif est de minimiser la nécessité de validation humaine tout en réduisant les délais de validation.

Contrairement aux autres outils, les objets ne sont pas validés de façon indépendante, mais groupés de façon cohérente : les LoChas.

Des règles permettent d’accepter automatiquement des modifications, à commencer par les modifications mineures de géométrie et les tags non ciblées. L’ensemble de ces règles sont internes et non publiquement disponibles.
Un moteur de validation construit par apprentissage automatique est ensuite utilisé. Son comportement ainsi que les données ayant servi à son apprentissage et son modèle sont internes et non publiquement disponibles.
Les LoChas restant sont ensuite revues manuellement. Les corrections nécessaires sont faites dans OpenStreetMap.

4.4 OSMCha

OSMCha est le seul outil public apportant des règles de validation des changements. La validation est faite au niveau des changesets.

	Monitoring tools	Synchro avec validation
	OSMCha	ideoMap	LeBonTag	MaRS / Daylight
changement non significatif	Règles	liste de tags inclus	liste de tags inclus (Delta geom?)	x
Heuristique	Règles	–	Utilisateur de confiance	x
ML	–	–	–	x
Manuel	x	x	x	x

L’on constate l’existence de plusieurs natures de règles de contrôle :

règles sur le contexte de contribution : confiance en l’utilisateur, outil d’édition utilisé ;
règles sur les changements eux-mêmes : par exemple, suppression de dizaines d’objets à la fois ;
règles sur l’état final après application du changeset, cible uniquement le contenu du changeset : par exemple, introduction d’une insulte dans un nom.

4.5 Critique global des approches

Peu de règles de validation des changements sont publiquement disponibles. Les seules disponibles sont celle de OSMCha portant sur les changesets et non les LoChas.

À noter que les autres outils qualité, comme Keep Right, OSM Inspector et Osmose-QA validement également un état final. Mais contrairement à OSMCha, ils valident l’ensemble des données et non uniquement les changements. Par exemple Osmose-QA peut détecter que deux boulangeries identiques se trouvent cote-à-cote (ce qui constitue un doublon), alors que les changements apportés en eux-mêmes peuvent être tout à fait valides (ajout d’une seule boulangerie).

On peut retenir que différents niveaux de validation peuvent être mis en place pour faciliter la validation.

Accepter automatiquement toutes les modifications insignifiantes.
Contrôler le changement lui-même.
Contrôler l’état final après changement.
Contrôler l’état global après changement (aucun des outils de synchronisation étudié ne propose ça).
La validation peut être basée sur des règles, de l’apprentissage automatiquement et du contrôle manuel.
Utiliser le contexte de contribution (méta-informations).

5 Conclusion

MaRS semble être l’outil offrant le plus de fonctionnalité. Malheureusement c’est un outil interne, non réutilisable et dont peu d’informations publiques existent.

MaRS n’est pas non plus un outil collaboratif ni un outil configurable pour un usage propre, ce n’est pas un outil qui adresse des données thématiques.

OSMCha apport un aspect collaboratif, mais n’est pas un outil de synchronisation de données et la revue des modifications est facultative.

LeBonTag et IdeoMap s’adressent à des collectivités et traitent de données territoriales et thématiques mais n’automatisent que peu la validation des changements.

Seul MaRS adresse la problématique de la cohérence des données synchronisées.

1 Des TIC au TOC1. Contribuer à OpenStreetMap : entre commun numérique et utopie cartographique. Marina Duféal et Matthieu Noucher 2017. https://journals.openedition.org/netcom/2635

2 ECCE Carto- Des Espaces de la Contribution à la Contribution sur l’Espace – Profils, pratiques et valeurs d’engagement des contributeurs d’OpenStreetMap (OSM). Marina Duféal, Camille Jonchères, Matthieu Noucher 2016. https://shs.hal.science/halshs-01371544/

3 https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities

4 Corporate Editors in the Evolving Landscape of OpenStreetMap. Jennings Anderson, Dipto Sarkar and Leysia Palen 2019. https://www.mdpi.com/2220-9964/8/5/232

5 https://fr.wikipedia.org/wiki/Coutume

6 https://fr.wikipedia.org/wiki/Usage_local_ayant_force_de_loi

7 https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator

8 https://github.com/openstreetmap/iD/tree/develop/modules/validations

9 https://wiki.openstreetmap.org/wiki/Keep_Right

10 https://wiki.openstreetmap.org/wiki/OSM_Inspector

11 https://wiki.openstreetmap.org/wiki/Osmose

12 https://wiki.openstreetmap.org/wiki/OSMCha

13 https://github.com/MichaelVL/osm-analytic-tracker

14 https://github.com/Cartocite/osmada

15 https://wiki.openstreetmap.org/wiki/Overpass_API

16 https://wiki.openstreetmap.org/wiki/OSM_XML