Le 08/12/2014 14:17, Christian Quest a écrit :
D'accord aussi
postal_code me semble bien adapté juste pour les boundary et les
addr:postcode / addr:city / addr:country sont à éliminer dans beaucoup
de cas (sauf quelques cas particuliers).
Maintenant que La Poste a publié la base officielle des codes postaux,
on peut faire une mise à jour globale.
Le problème c'est que :
1) le fichier de La Poste n'est pas exempt d'erreurs... les 2 cas
particuliers que j'ai vérifié étaient en erreur !
2) il ne détaille pas les communes pluridistribuées, celles où justement
le boundary est le plus intéressant.
Le problème aussi avec les boundary c'est que c'est (trop) facile à
casser et plus on a de relations plus on a de chance d'avoir ce genre de
problème.
Il nous manque des outils de monitoring pour détecter et réparer
rapidement ces relations cassées.
Oui c'est bien vrais.
On pourrait déjà avoir un couche dans layers pour ça.
Pour les générer on peut faire comme avec les EPIC ou les cantons en les
construisant automatiquement avec comcommaker en ligne de commande.
Pieren a écrit :
Je suis aussi d'accord. La tendance est d'utiliser "postal_code" sur
les zones et "addr:*" sur les adresses individuelles, sans doute
pour
des raisons historiques (le premier étant bien plus ancien dans OSM
que le second).
Par contre, je voudrais revenir sur l'Allemagne qui a accompli une
action de groupe pour modéliser tous ses codes postaux sur
l'ensemble
de son territoire avec la relation de type=boundary +
boundary=postal_code. Pourrait-on envisager le même type d'action en
France ? Cette modélisation est plus cohérente avec la réalité dans
nos pays puisque les codes postaux sont relativement
indépendants des
limites communales (plusieurs communes avec le même code postal
ou une
commune avec plusieurs codes postaux). A terme, plus il y aura
de pays
pour adopter ce type de relation, plus il y aura de chance pour que
les logiciels de géocodage l'adoptent et cela nous permettra de
nettoyer les "postal_code" et autres "addr:postcode" qui seraient à
l'intérieur de ce polygone et donc redondants (répétés sur les
relations "commune". les noeuds/ways "place" et sur de nombreuses
adresses individuelles).
Pieren
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
