Le 6 juin 2012 16:04, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > Tu mets le doigt sur _la_ difficulté. Un moteur d'adressage multi-pays, c'est > potentiellement autant de cas à gérer que de pays couverts. Plaquer un même > schéma > partout ne rime pas à grand chose. Et faire rentrer dans un même moule les > limites > admin niveau 8 de France, les limites postales US, les "zones" (je ne sais > même pas > comment les nommer, tiens) de découpage UK, c'est un joli casse-tête. En > créant ses > multipolygon place=*, il gère à la marge son problème, mais pas forcément par > le bon > bout.
Mouais... mais franchement qu'est-ce qu'il y a comme tag spécifique dans ces doublons que n'apporte pas les relations originales ? l n'y a aucun moyen dans ce qu'il a mis de faire la différence, même concernant l'usage qu'il veut en faire. La question ne se pose donc pas, ces doublons sont inutiles même pour son usage et la façon doit il le conçoit puisqu'il se retrouvera forcément aussi à devoir analyser ces doublons et à en éliminer un sans aucun critère discriminant. On peur les enlever sans problème même s'il ne fait rien. A mon avis c'est juste qu'il n'a pas vérifié que les relations en question n'existaient pas déjà et qu'il les a importées en masse. Il a même introduit une difficulté à sa propre analyse. Bref on garde les relations qui ont l'ID le plus petit et qui correspond à l'usage le plus ancien pour minimiser l'impact, on élimine ces doublons sans problème. Surtout si en plus il ne fournit aucune justification pour leur existence, ni aucun tag spécifique ni aucun membre spécifique qui n'est pas **déjà** dans les relations d'origine. Ces doublons compliquent les choses pour strictement aucun bénéfice à quelque niveau d'analyse que ce soit. A mon avis il n'était même pas conscient de créer ces doublons et n'a pas filtré ses imports pour vérifier ce qui était déjà dans la base, et n'a pas cherché du tout. La seule chose qu'il doit changer c'est sa table locale de correspondance des identifiants dans sa propre base. Strictement aucun tag n'est à changer puisque les relations d'origine ont déjà tous les tags qu'il a dupliqués (partiellement, mais fidèlement sans même changer leurs valeurs) dans les nouvelles relations qu'il a ajoutées. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
