Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
2014-12-06 19:34 GMT+01:00 Frédéric Rodrigo : > Note: cette analyse est basé sur la tag addr:postcode, que je considère pour > ma part comme n'étant pas le bon. Selon moi on devrait utiliser postal_code > pour les surfaces de code postaux. Voir mon mail sur talk-fr "De l'usage des > tags postal_code addr:postcode" qui n'a soulevait aucun intérêt. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
Le 08/12/2014 13:02, Pieren a écrit : 2014-12-06 19:34 GMT+01:00 Frédéric Rodrigo : Note: cette analyse est basé sur la tag addr:postcode, que je considère pour ma part comme n'étant pas le bon. Selon moi on devrait utiliser postal_code pour les surfaces de code postaux. Voir mon mail sur talk-fr "De l'usage des tags postal_code addr:postcode" qui n'a soulevait aucun intérêt. 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 Oui, tout a fait d'accord. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
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. 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
Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
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
Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
J'ai fait une rapide comparaison des codes postaux présents dans OSM et ceux du fichier officiel de La Poste... https://gist.github.com/cquest/15f266eccb5b5e81d17f C'est fait sur le addr:postcode présent sur les relations boundary des communes. Il y a 97 codes postaux dont on ne trouve pas l'équivalent quand addr:postcode est renseigné. Il y a 6992 relations boundary sans addr:postcode et 21 avec un "postal_code" Je vais faire de même sur les noeuds place=* Le 8 décembre 2014 14:25, Frédéric Rodrigo a écrit : > 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
