creation d'associatedStreet incomplète

[Bibi56]

La création d'associatedStreet ajoute bien les points d'adresse manquants mais oublie d'ajouter les PdA existants quand ils comprennent addr:street.

Exemple :
https://bano.openstreetmap.fr/fantoir/index.html#insee=29150&tab=1

La relation a été créée (https://www.openstreetmap.org/changeset/94600597) par contre les points d'adresse préexistants tels que https://www.openstreetmap.org/node/4565574899 n'ont pas été intégrés.

Les points d'adresse devraient être intégrés et nettoyés (addr:street supprimés, addr:city et addr:postcode s'ils sont portés par la relation de la commune).

[Bibi56]

Salut @vdct, la relation créée (Rue Cécile Ravallec) reste avec des points d'adresse manquants tels que https://www.openstreetmap.org/node/4604126013. Bon c'est un cas particulier (car créé avant la correction du bogue), je peux corriger à la main mais j'attends ton retour car il me semble intéressant de voir si des points adresses manquent à la relation.

[vdct]

Il y a 2 raisons cumulées :

• la possibilité de cliquer sur "Relation" dans l'interface est supprimée car on n'a pas détecté d'adresse manquant dans OSM par rapport à l'inventaire BAN
• en jouant manuellement la requête liée au clic, à savoir https://bano.openstreetmap.fr/fantoir/requete_numeros.py?insee=29150&fantoir=291500225Y&modele=Relation certains numéros ne remontent en effet pas. La raison est l'absence de l'accent aigu sur le é de Cécile pour ces points, dans leur tag name. La requête qui essaie de repêcher les points d'adresse s'appuie sur le nom contenu dans BANO, ici c'est celui du tag name de la relation, accentué...

[Bibi56]

OK , c'est vrai que j'ai mis l'accent sur la rue, pas sur les points d'adresse, je comptais sur un super-outil pour recoller les morceaux. Devine lequel ;-).
Là j'ai corrigé du coup ils apparaissent bien : https://bano.openstreetmap.fr/fantoir/requete_numeros.py?insee=29150&fantoir=291500016W&modele=Relation.
Par contre je ne sais lire du XML avec JOSM.

Du coup le point 1 est gênant car on ne détecte pas les relations incomplètes. La vérification doit être simple (comparer le nombre de points dans la BAN et le nombre de membres house dans la relation).

[vdct]

OK , c'est vrai que j'ai mis l'accent sur la rue, pas sur les points d'adresse, je comptais sur un super-outil pour recoller les morceaux. Devine lequel ;-).

Un intérêt de BANO est de relever les incohérences, typos et autres ;)

Là j'ai corrigé du coup ils apparaissent bien : https://bano.openstreetmap.fr/fantoir/requete_numeros.py?insee=29150&fantoir=291500016W&modele=Relation.
Par contre je ne sais lire du XML avec JOSM.

Soit tu enregistres le XML dans un fichier, par exemple avec une extension .osm, et JOSM le reconnaitra, soit tu places danston navigateur une URL comme
http://127.0.0.1:8111/import?url=https://bano.openstreetmap.fr/fantoir/requete_numeros.py?insee=29150&fantoir=291500016W&modele=Relation
et ça ouvrira le contenu directement dans JOSM via la télécommande

Du coup le point 1 est gênant car on ne détecte pas les relations incomplètes. La vérification doit être simple (comparer le nombre de points dans la BAN et le nombre de membres house dans la relation).

Rien d'impossible mais ça n'est pas prioritaire ici. Le propos est surtout d'ajouter des adresses, sans la prétention d'homogenéiser le modèle. Sinon à quoi bon proposer le schéma Points et le schéma Relation ? Si on trouve là dessus un consensus alors ok pour faire de l'outil un outil de conversion systématique. Mais on n'y est pas...

[Bibi56]

Un intérêt de BANO est de relever les incohérences, typos et autres ;)

Tu veux dire que le site pourrait prioriser les voies dont le nommage est incomplet ? ;-)

Sinon à quoi bon proposer le schéma Points et le schéma Relation ?

Avec un outil qui permet de créer facilement les relations (et de vérifier leur complétude) et les avantages offerts par les relations, le consensus sera plus simple à trouver. D'ailleurs tu pourrais ne présenter les points que pour les lieux-dits sans rue nommée^^.

[zorglubu]

Bonjour, c'est vraiment très pratique.
J'ai testé en zone rurales : quelques points se balladent mais c'est bon.
Par contre j'ai tenté de mettre à jour la relation de la rue du Gué (940381470B) à l'haÿ les roses (INSEE 94038), tous les points arrivent en doublon (ils sont déjà dans OSM). Merci.

[Bibi56]

@zorglubu; comme tu as mis à jour https://www.openstreetmap.org/relation/7632318#map=18/48.77449/2.32664, @vdct ne pourra plus voir la raison, tu nous en dégotes une autre ou tu regardes de près ce qui clochait (tu es passé de 33 à 39 membres, quels doublons ?). Sinon je ne vois pas l'intérêt de garder addr:city et addr:postcode quand ils sont donnés par la commune, ici https://www.openstreetmap.org/relation/79593.

[zorglubu]

Bonjour,
Mais quel boulet je suis ! Désolé. Je vous dirai si jamais je reproduis.
Il reste par contre 6 numéros positionnés 400m au sud-est lorsqu'on clique sur le bouton Relation ou le bouton 7 points.
(note : est-ce que ça ne viendrait pas de la similitude entre rue du gué et rue duguesclin ?)

Je partage totalement la totale inutilité des addr:city et addr:postcode, mais comme ID incite à les mettre, j'avoue ne pas perdre de temps à les enlever lorsqu'ils sont ajoutés par quelqu'un d'autre.

[zorglubu]

Je viens de réussir à reproduire le problème des doublons sur les 17 points du Sentier des Closeaux (940381470B), à l'Haÿ les Roses toujours.

[vdct]

Vu, merci pour le nouvel exemple. Je le garde au chaud

[vdct]

Je viens de réussir à reproduire le problème des doublons sur les 17 points du Sentier des Closeaux (940381470B), à l'Haÿ les Roses toujours.

Dans ce cas le problème vient des données. La voie pour laquelle on propose 17 points à intégrer est celle du Fantoir 940381470B, qui est valide. Mais en même temps il existe une relation associatedStreet avec un tag ref:FR:FANTOIR=940381471C qui est un code annulé pour le même nom de voie.
Ce qui se passe quand on clique sur 'Relation' dans ce cas :

• on va d'abord chercher les adresses avec le code Fantoir 940381470B connues de la BAN et pas d'OSM (donc les 17)
• on va ensuite chercher s'il existe une relation associatedStreet avec le même nom de voie dans la même commune. Comme c'est le cas on l'utilise pour y ajouter les 17 points. Sauf qu'ils sont en doublon vu que cette relation est déja complète.

Ca peut se corriger par du code, en vérifiant que soit il n'y a pas de code Fantoir sur la relation, soit c'est le bon. Mais ça ferait passer à côté du bug de données qui consiste en l'utilisation d'un code Fantoir annulé, en lieu et place d'un code valide.

Il y a 2 actions à mon avis :

• pour cette relation en particulier, supprimer le code Fantoir de la relation ou le remplacer par le bon code
• pour les codes Fantoir annulés, les mettre en évidence dans l'interface, ce qui est déjà identifié comme amélioration via Indiquer les rapprochements sur FANTOIRs annulés #116

[zorglubu]

Merci beaucoup pour l'explication. J'ai corrigé ce code fantoir.
Je découvre un peu cette liste Fantoir. Comme j'ai remarqué de nombreux codes périmés (ailleurs), je me demandais s'il ne serait pas judicieux de faire pour tout le pays une correction totalement automatique lorsqu'on a un code "annulé" sur une rue OSM qui a de plus le bon "libellé".
Bien cordialement.

[vdct]

Je découvre un peu cette liste Fantoir. Comme j'ai remarqué de nombreux codes périmés (ailleurs), je me demandais s'il ne serait pas judicieux de faire pour tout le pays une correction totalement automatique lorsqu'on a un code "annulé" sur une rue OSM qui a de plus le bon "libellé".

Je vois bien l'idée mais il y a trop d'exceptions côté FANTOIR pour pouvoir appliquer un traitement uniforme sur les données France entière en comptant sur le fait qu'il corrige sans abîmer. Mais le sujet reste d'actualité comme je disais juste au dessus. De plus, une nouvelle page existe depuis ce soir, grâce au travail d' @Olyon et qui permet de traiter au cas par cas le sujet des FANTOIRs annulés

[Bibi56]

@vdct et @Olyon : La page en question appelle http://bano.openstreetmap.fr/fantoir/fantoir_annule.py qui nous fait un 500 non remonté à l'interface. 2 améliorations : afficher le message d'erreur et éviter qu'il apparaisse^^.

[vdct]

merci @Bibi56 d'avoir pointé le souci, c'est corrigé maintenant

[Bibi56]

Merci d'avoir corrigé aussi vite ! Je pense que l'info est bonne, par contre elle pourrait être mieux valorisée : j'ai pris le premier gros paquet du 29, 29069, j'ai trouvé par l'adresse Fantoir qu'il s'agissait de Guilers et vu le nouvel onglet.

Dans OSM et inconnu de FANTOIR

20 voies et emprises OSM inconnues de FANTOIR

C'est ce que j'allais demander ;-).

Sauf que la liste brute donne 103. Est-ce uniquement des codes utilisés dans OSM ? Sinon ils nous intéressent peu.

Vu de loin - et comme @zorglubu je peux me tromper - est-ce qu'il n'y a pas trois cas faciles :

• non utilisé dans OSM, je propose de ne pas les voir
• utilisé dans OSM mais https://bano.openstreetmap.fr/fantoir/index.html arrive d'après le nom à les recoller (pour les fusions de commune tu donnes la règle, donc automatisable si même emprise ?)
• utilisé dans OSM et https://bano.openstreetmap.fr/fantoir/index.html n'arrive à les recoller. Peut-être Dans OSM et inconnu de FANTOIR?

Sur https://bano.openstreetmap.fr/fantoir/index.html#insee=29069&tab=6, Allée Jean Henry, ce serait sympa de pouvoir signaler un faux positif : la voirie existe bien (cf. ortho, https://www.openstreetmap.org/edit?editor=id#map=19/48.40696/-4.52796) mais est privée (hors cadastre) d'accès autorisé au public.

[vdct]

Merci d'avoir corrigé aussi vite ! Je pense que l'info est bonne, par contre elle pourrait être mieux valorisée : j'ai pris le premier gros paquet du 29, 29069, j'ai trouvé par l'adresse Fantoir qu'il s'agissait de Guilers et vu le nouvel onglet.

Dans OSM et inconnu de FANTOIR

20 voies et emprises OSM inconnues de FANTOIR

C'est ce que j'allais demander ;-).

Sauf que la liste brute donne 103. Est-ce uniquement des codes utilisés dans OSM ? Sinon ils nous intéressent peu.

103 : je ne comprends pas à quoi fait référence ce chiffre ?
Cet onglet (qui n'est pas nouveau) recense les objets des différents types OSM candidats aux rapprochements FANTOIR et pour lesquels le rapprochement a échoué Partout en France les critères sont identiques, mais le contenu local peut largement varier. Par exemple dans certaines communes on peut trouver dans FANTOIR des écoles, dans d'autres pas.

Vu de loin - et comme @zorglubu je peux me tromper - est-ce qu'il n'y a pas trois cas faciles :

* non utilisé dans OSM, je propose de ne pas les voir

Le listing recense des objets OSM donc par nature ce qu'on voit ici est utilisé dans OSM. Je n'ai pas compris ce point

* utilisé dans OSM mais https://bano.openstreetmap.fr/fantoir/index.html arrive d'après le nom à les recoller (pour les fusions de commune tu donnes la règle, donc automatisable si même emprise ?)

* utilisé dans OSM et https://bano.openstreetmap.fr/fantoir/index.html n'arrive à les recoller. Peut-être `Dans OSM et inconnu de FANTOIR`?

Je ne comprends pas de quels pages ou listes tu parles ici.

Sur https://bano.openstreetmap.fr/fantoir/index.html#insee=29069&tab=6, Allée Jean Henry, ce serait sympa de pouvoir signaler un faux positif : la voirie existe bien (cf. ortho, https://www.openstreetmap.org/edit?editor=id#map=19/48.40696/-4.52796) mais est privée (hors cadastre) d'accès autorisé au public.

Ce serait bien en effet mais cette liste de noms d'objets ne stocke pas d'identifiants stables, donc impossible de rappeler d'une fois sur l'autre qu'une ligne est en faux positif.

Je pense qu'on a pas mal dérivé par rapport au sujet initial du ticket. Je ferme ici, ne pas hésiter à en ouvrir de nouveaux pour préciser les dernières questions non résolues