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 fred.rodr...@gmail.com: 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 fred.rodr...@gmail.com: 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 fred.rodr...@gmail.com 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
[OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
Bonjour, Suite à la libération du lien entre codes postaux et les codes INSEE j'ai pu ajouter un analyse Osmose pour détecter les manques et faire des proposition d'ajouts. http://osmose.openstreetmap.fr/fr/map/#item=7160 http://osmose.openstreetmap.fr/fr/map/#item=8221 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. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
