Merge - Split no ref of unkow ref

[deuzeffe]

Hello, Soit

clé	valeur
source	1155
item	7050
class	2
subclass	0
elems	node5564472385
lat lon	42.4976158 2.0329401
title
fr	Bureau de Poste sans attribut “ref:FR:LaPoste” ou non valide
timestamp	2019-04-13 20:59:02

pour l'élément :

clé	valeur
elem_index	0
type id	N 5564472385
tags
addr:postcode	66120
amenity	post_office
name	Odeillo
operator	La Poste
phone	+33468303240
post_office:type	post_partner
ref:FR:LaPoste	12361A	http://www.laposte.fr/particulier/outils/trouver-un-bureau-de-poste/bureau-detail/12361A/12361A
source	data.gouv.fr:LaPoste - 06/2015
wheelchair	no

semble signifier que le post_partner (détecté dans la base 2015) n'est plus dans la base en cours (mars 2019 si j'en crois analyser_merge_poste_FR.py)

Je ne sais pas trop comment on peut résoudre élégamment ce "bug".

HTH

[frodrigo]

C'est tout à fait possible que ça n'existe plus.

post_partner = Relais poste commerçant

http://osmose.openstreetmap.fr/fr/errors/?item=7050 http://osmose.openstreetmap.fr/fr/errors/graph.png?item=7050

Il y aurait plus ou moins 1000 "postes" qui n'existent pas.

[deuzeffe]

Vivi, j'avais intégré la notion de "relais poste chez commerçant".

On fait comment pour virer/corriger ce millier de fantôme ? Je ne sais pas si ce "non valide" est bien explicite (ça peut correspondre à une typo. ou à une réf. qui n'existe plus) ; tu verrais une meilleure formulation (du style "pas trouvé dans la base" mais en plus joli ^^) ?

Ça peut donner lieu à un challenge type MapRoulette ?

[frodrigo]

On peut faire un peu de comm sur la liste. Un MapRoulette est pas tres adapté, il faut connaitre le terrain.

[deuzeffe]

Ok, j'essaie de publier un truc sur talk-fr. Compris pour MapRoulette :)

[deuzeffe]

@Marc-marc-marc suggérait de couper l'analyse en deux :

1. sans attribut ref:FR:LaPoste (pour déceler les bureaux/relais Poste mal taggués)

2. ref:FR:LaPoste non valide (pour déceler les erreurs de ref. ou les bureaux/relais disparus).

Tu penses que c'est faisable ?

[frodrigo]

L'idée de séparer pas de ref et ref invalide est intéressante. Par contre c'est du code générique pour toute l'intégration opendata. On pourrait séparer en classe et continuer à l'afficher dans le même item du menu. Pas sûr que ça apporte quelque chose. Sinon il faut ajouter une dizaine d'items à Osmose.

[deuzeffe]

Et si tu sépares :

1. QA = absence de ref:* (items 2000 et suivants : attributs manquants)

2. OD = ref: invalide (item 8022 : à mettre à jour)

?

Mouais, ça revient vaguement au même :/ Et ça risque de multiplier d'autant les classes/items si on étend ça à tout l'OD...

Le seul intérêt, pour l'amélioratrice que j'essaie d'être, c'est de savoir exactement ce que j'ai à corriger (et comprendre où il faut que je recherche pour une correction efficace). Cependant, si ça met à mal ton schéma originel, je m'y adapterai ^^

[Marc-marc-marc]

je trouverais très utile d'avoir les infos séparés dans 2 classes différentes, cela permettrait de travailler sur 2 choses très séparées :

• sans ref : c'est généralement une intégration à faire (trouver la bonne ref à ajouter dans osm)
• ref invalide : soit une erreur d'encodage dans osm, soit un poi qui a fermé. le plus simple dans ce cas à mon avis est d'aller charger un ancien fichier OD s'il existe ou chercher une source disant que le poi a fermé

[Bibi56]

J'ai aussi trouvé des bureaux déplacés de 50 m et qui ont le droit à un nouveau code. Donc deux (bons) signalements par Osmose.