[OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux

[Frédéric Rodrigo]

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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>