Correction des erreurs OSM et des entités non-pertinentes

Logique de doublon

Cependant si vous explorez vos données, vous pouvez constatez de visibles erreurs, des magasins trop rapprochés pour être réellement distintcs, ce sont des doublons pour l'usage que l'on veut en faire (pas de vrais doublons en général, mais ils ne sont pas pertinents pour nos futures zones isochrones, qui se superposeraient inutilement). On peut parler d'une logique de doublon.

Issus sans doute d'erreurs de saisie, de déménagements récents, de représentation de hangars, zones de livraison ou magasins déportés, nous allons les identifier en fonction de leur distance à vol d'oiseau entre eux (outil Vector/Analysis Tools/Distance Matrix). Choisissez les champs id en input et output.

En classant votre couche de sortie des distances les plus courtes aux moins courtes, vous pourrez zoomer proprement sur les magasins trop proches et les examiner. Remarquez que la couche matricielle est constituée d'entités multi-parties (zommez sur l'une d'entre elles et/ou examinez votre table attributaire).

Remarquez également qu'au vu du fonctionnement de l'outil Distance Matrix (calcul de la distance de chaque entité par rapport à toutes les autres), vous avez des doublons géométriques naturels dans la couche de sortie (de vrais doublons cette fois). Naturels, car normaux, bel et bien voulus par l'outil Distance Matrix ; géométriques, car seules les géométries sont en doublons, les données attributaires sont bien différentes, hormis le calcul de distance bien sûr.

Analysez les résultats pour trouver la meilleure logique à suivre (quelques vérifications sur Google Map par exemple). Il semblerait qu'en dessous d'une distance de 1700 mètres entre les magasins il s'agisse d'erreurs. Au-delà de ces 1700 mètres, nous arrivons dans les grandes villes où la proximité de plusieurs magasins uniques est probable (Paris, Marseille...).

Au 27 décembre 2020, à partir des données OSM, nous identifions 26 magasins Décathlon dans une logique de doublon. Bien sûr nous pourrions les corriger manuellement (ou mieux : directement dans OSM), mais imaginez que vous ayez 100, 1000 ou même 10 000 points en doublons. Mieux vaut savoir les corriger à la chaîne sur votre SIG.

Correction

Nous allons ici récupérer des points entre les magasins à supprimer. Ensuite nous supprimerons ces magasins, et nous les remplacerons par nos nouveaux points.

• Requête d'affichage sur la couche matricielle (Properties/Source/Query Builder).

"Distance" <= 1700

• Récupération des centroïdes des entités multipoints restantes (Vector/Geometry Tools/Centroids).
• Suppression des doublons géométriques des centroïdes (Processing Toolbox/Delete Duplicate geometries). En effet la couche matricielle ayant des doublons géométriques, nos centroïdes sont eux aussi en doublon.
• Sélection spatiale des magasins à supprimer en les intersectant avec la couche matricielle, outil Vectors/Research Tools/Select By Location. Mode Editing sur la couche des magasins et suppression de la sélection. La couche matricielle est à présent inutile, vous pouvez la supprimer.

Virtual Layers et requête UNION

Bien, il ne nous reste plus qu'à fusionner nos magasins restants avec les centroîdes extraits.

Cependant si vous examinez les données attributaires des 2 couches, vous y verrez de notables différences dans leur structure. Ainsi si l'outil Merge Vector Layers pourrait parfaitement fusionner les géométries, il nous produira 2 champs différents pour nos différents identifiants, que bien sûr nous souhaitons conserver de façon ordonnée.

Nous allons donc plutôt gérer cette fusion en SQL, avec une requête UNION, dans Database/DB Manager/Virtual Layers/Project Layers. Ici, sélectionnez une couche, n'importe laquelle, afin de faire apparaître le bouton SQL Window, ouvez la fenêtre SQL. Ici, dans l'onglet Query, nous allons pouvoir taper notre propre SQL.

Commencez par faire quelques requêtes de sélection simple, pour vous entrainez.

SELECT id, geometry FROM magasins

Observez que nous sommes capables d'appeler un champ pourtant invisible dans les données attributaire : la géométrie !

En effet à la manière de Postgres, les Virtual Layers peuvent requêter les géométries. Nous ferons d'ailleurs plus tard un peu de SQL spatial.

Mais pour l'instant, la requête UNION :

SELECT id, geometry FROM magasins
UNION SELECT InputId, geometry FROM magasins

Maintenant nos identifiants se superposent parfaitement, bien sûr nous n'oublions pas d'appeler les géométries. Exportez-en une couche (option Load as new layer).

Enfin, le 27 décembre 2020, nous identifions 308 magasins Décathlon dédoublonnés dans les données OSM.

Exportez-en un shape ici nommé decathlon_france, c'est à partir de lui que nous travaillerons. En effet la couche issue des Virtual Layers est une requête, si plus tard vous supprimez les couches qui la constituent, la requête sera invalide.

Normalisez les id (en enlevant les ways, nodes et autre slashs, et en préfixant les valeurs par la lettre d. En effet nous utiliserons ensuite les identifiants pour nommer des fichiers, et il n'est jamais bon de commencer le nom d'un fichier par un chiffre. Dans le Field Calculator de la couche :

REPLACE (id, 'way/', 'd')
...

Liens ou pièces jointes

isochrones15m.zip	[Les 308 zones isochrones fusionnées]	979 Ko
Code complet de création des zones isochrones avec le service ORS	[code Python]	2 Ko
isochrones_ORS.zip	[Les 308 fichiers GEOJSON des zones isochrones]	786 Ko
Export OSM des magasins de sports français le 27 décembre 2020	[key=shop ; value=sport ; in=France]	0 Ko