Forum OSM France

PoC Planet+ (le côté technique)

Comme ça me démangeais, j’ai écrit quelques lignes de bash (une vingtaine) pour fusionner un fichier PBF avec les données BANO.

Sur l’ile-de-france ça prend moins d’une minute pour :

  • convertir les CSV de BANO en .osm
  • fusionner ce .osm avec le .pbf d’origine, qui passe de 316Mo à 342Mo :slight_smile:

Outils utilisés:

  • wget (pou récupérer les fichiers)
  • sed et awk pour passer de CSV à XML .osm
  • osmium pour faire la fusion
2 Likes

Etape suivante : lors de la fusion

  • virer les tags addr:housenumber présents dans le pbf d’origine
    – quand ils sont sur des noeuds isolés avec juste addr:street, virer ces noeuds
    – quand ils sont sur des noueds isolés avec d’autres tags (amenity, shop…) garder ces noeuds
  • virer les relations associatedStreet

j’ai pas trop idée des cas bizarres qu’on va rencontrer. Il faudra aussi un mécanisme pour limiter nos suppressions à la France (dans le cas de BANO) et plus généralement délimiter toute modif/suppression en fonction de l’emprise du jeu de données qui viendra remplacer la thématique

Hum… pas facile de détecter les noeuds isolés, dans un premier temps on peut juste retirer les tags et les laisser sauf si osmium permet de faire ce ménage.

Oui, à la reflexion, un noeud isolé ET sans tags n’a que peu de chances d’être consommé, et devrait passer au travers de tous les filtres de consommation. Donc un peu de bruit, mais sans gravité, sauf si le volume devient conséquent et alourdit le pbf de manière trop visible

Une ligne de bash de plus, et l’élimination des tags addr:* / associatedStreet est faite :slight_smile:

C’est trop simple !

Traitement complet IDF… 3mn et fichier final de 338Mo

Je n’ai pas bien compris ce que ça donne en finale: est-ce qu’on garde des adresses venant dans OSM ou pas, vu que tu as l’air de tout supprimer dans le pbf venant d’OSM ?

Ou est-ce que les données venant de BANO gérent la fusion OSM/BAL, en recréant les nodes et les relations associatedStreet ?
Si c’est ce dernier cas, je me demande ce que ça veut dire pour les relation-id dans le pbf final, et si ça voudrait dire qu’ils changent à chaque génération.

Un nœud adresse OSM isolé est potentiellement mieux localisé que dans BANO ?
Ne faut-il pas le garder et ignorer celui de BANO ?

Avec Overpass ou l’API OSM on peut facilement détecter si un nœud est isolé ?

J’ai compris qu’on supprime toutes les adresses venant d’OSM.

On supprimerait toutes les relations associatedStreet d’OSM et elles ne sont pas recréées à partir des données de la BAL.

Les adresses OSM sont là au final, vu que BANO les a récupéré ET priorisées :slight_smile:

Les ID des objets dans ce pbf n’ont potentiellement plus de rapport avec les données OSM.

Dans mon petit test, j’ai attribué des ID très élevés aux adresses BANO pour ne pas venir en colision avec des node OSM ni permettre l’utilisation de ces objets pour de l’édition (ils ont un numéro de version mis à 9999 que l’API rejettera, ils n’ont pas non plus de metadata uid/changeset/timestamp).

Oui unitairement, mais c’est à faire sur une masse bien plus importante et nécessite donc soit un très grand nombre d’appels à des API, soit à tout monter dans une BDD pour faire ça en local, ce que j’ai évité pour l’instant.

Des noeuds orphelins (ni tags, ni utilisé par un way ou une relation) cela ne pose aucun soucis aux outils qui utilisent les données (il y en a déjà dans les data OSM), ils occupent juste un peu de place pour rien ce qui n’est pas un problème si cela reste marginal par rapport au reste des données.
Avec osm2pgsql, ils ne prennent même pas de place dans la base postgres ni dans le fichier des flatnodes.

Je viens de vérifier et en fait la priorisation est effective pour l’export JSON, mais pas pour le CSV qui a priori servirait ici. Je viens de créer Garantir la prise en compte prioritaire des coordonnées OSM dans l'export CSV · Issue #271 · osm-fr/bano · GitHub en conséquence

Oh !

C’est bizarre ça, les différents formats devraient contenir la même chose. Je me suis planté quelque part ?

Sur les serveurs d’OSM France il y a déjà une BDD :grinning:
(mais pas encore d’instance Overpass ?)

Ok, par exemple un nœud adresse à qui on supprime ses tags.

Même si ce jeux de donné est réinjecté dans un géocodeur (ex: une instance locale de Nominatim), les adresses seront quand même bien localisées :grinning:

Toi non, moi oui en réécrivant les exports il y a quelques trimestres suite à l’arrivée de la source BAN

C’est une BDD au schema « API » qu’il faut pour faire ça efficacement, ce qu’on n’a pas (peut être pour osmose ?).

C’est une BDD au schema « API » qu’il faut pour faire ça efficacement, ce qu’on n’a pas (peut être pour osmose ?).

Oui on en a une base Osmosis sur osm110 pour Osmose.

1 Like

Et l’intérêt est ?

Virer les adresses d’OSM pour mettre celles de BANO, c’est normalement une opération blanche partout où on avait des adresses OSM, vu qu’elles seront remplacées par… elles-mêmes. Donc en soi aucun intérêt à ces endroits là en particulier. L’intérêt est ailleurs, de 2 ordres :

  • proposer des adresses y compris là où OSM n’en a pas
  • proposer les adresses issues d’OSM et celles hors OSM (essentiellement celles de la BAN) avec une unique modélisation, uniforme sur tout le territoire, en mode noeuds isolés avec les tags addr:housenumber et addr:street

Donc l’intérêt est à voir globalement plutôt que localement. Ca colle avec l’idée de départ qui est d’avoir un jeu de données plus facile à consommer & plus complet, donc plus « encourageant » pour un consommateur, à qui on abaisse un peu la marche. Si ça peut permettre à OSM de gagner par ci par là des parts de marché (ouh le gros mot) dans le paysage, on ne s’en plaindra pas (enfin, pas moi)

2 Likes

Merci pour tes explications (et ta patience !) : c’est beaucoup plus clair pour moi (et ça diminue un peu la hauteur de la marche).

Donc virer les relations associatedStreet au passage ? Ou je n’ai rien compris ?

Dans BANO aussi bien les relations associatedStreet que la modélisation avec addr:street sur noeud ou polygone, tout ça est harmonisé en noeuds isolés avec n° et nom de voie. La simplicité serait en effet de virer, uniquement dans le planet+, toutes les adresses quelle que soit leur modélisation, pour remplacer par des noeuds avec 2 tags partout. Ca ne signifie surtout pas de virer quoi que ce soit d’OSM, évidemment. On ne parle que du « produit dérivé » planet+ (faudra lui trouver un vrai nom un jour, hein)

1 Like

Quand fait comme ca, il sera meilleur de mettre l’adresse intégrale: addr:housenumber, addr:street, addr:city, addr:postcode. Ca simplifiera beaucoup le traitement des adresses par le logiciel.

Autre observation de côté Nominatim: quand l’adresse se trouve sur un polygone, Nominatim peut ‹ transmettre › l’adresse aux POIs qui sont dans le polygone. On perde cette information quand on passe aux nœuds. Pas grave, juste quelque chose de s’en rendre compte.

1 Like