Le problème c'est que ces communes associées sont un résidu de fusion-association mais ne sont pas des communes en tant que telles.
Elles ne figurent plus dans la liste des communes actuelles, leur code INSEE semble conservé à titre plus ou moins historique mais n'a en fait plus d'usage... Elle ne figure que dans le fichier "historique" disponible en téléchargement. FANTOIR ne les connait plus non plus. Donc pour moi, ce code INSEE n'est plus "actuel" car plus utilisé. Pour les problèmes d'adresse postale, il faut indiquer le nom de l'ancienne commune pour lever l'ambiguité sur les noms de rues communs (plus de 100 cas de ce type à Lille)... parfois il reste un bureau distributeur (cas des grosses agglos comme Lille), parfois il n'y en a pas (fusion de communes rurales). Entièrement d'accord pour trouver une modélisation adapté dans OSM, BANO s'adaptera et pas l'inverse. Pour les relations avec admin_level=10, elles ont été utilisées pour les fusions récentes de communes dont on connaissait les limites, afin de les conserver. C'est peut être pas idéal, mais au moins, on a gardé l'info plutôt que de la perdre. On voit que c'est c'est utile car pour Neuville connaitre la limite serait bien utile. ah oui... Neuville-les-Dieppe a pour code postal 76370 alors que c'est 76200 pour Dieppe, donc c'est bien un bureau distributeur différent C'est peut être à gérer comme une frontière de code postal ? http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code auquel il faudrait ajouter un postal_code:name ? Le 23 juin 2014 14:53, Pieren <pier...@gmail.com> a écrit : > 2014-06-23 14:06 GMT+02:00 Christian Quest <cqu...@openstreetmap.fr>: > > Oui, encore une particularité à gérer et pas facile à gérer. Il y a plus > de > > 700 communes associées d'après > > https://fr.wikipedia.org/wiki/Commune_associ%C3%A9e > > Il faut d'abord régler le problème de modélisation dans OSM avant de > le faire avec BANO. Si je comprend bien, il y a une seule commune du > point de vue du cadastre ("Dieppe") mais deux du point de vue de > l'INSEE (COG) : "Dieppe 76217" et "Neuville-Lès-Dieppe 76466". > En regardant un peu, je tombe sur un cas similaire, Lomme, commune > associée à Lille, qui est en admin_level 10 dans OSM > http://www.openstreetmap.org/relation/58409#map=13/50.6440/3.0083&layers=D > dans un commentaire dit que le code INSEE 59355 n'est plus valide > (alors qu'il l'est encore dans le COG). Le noeud "place" est en > "town", et non "suburb" comme pour les quartiers > > Pour OSM, je trouverais assez malin cette solution qui distingue les > quartiers périphériques (place=suburb/neighbourhood) et les communes > associées ("place=town/village"), non pas sur l'admin_level 10 de la > relation (s'il y en a une) mais sur la valeur du tag "place". > Mais pour le ref:INSEE, il va y a voir un problème. On ne peut pas > conserver le ref:INSEE sur la grande commune, sinon un point > géographique pourrait appartenir à deux codes INSEE. Et la relation 1 > code insee pour 1 relation commune (admin_level 8) ne tient plus (voir > http://wiki.openstreetmap.org/wiki/FR:Key:ref:INSEE). > Pour les adresses, je n'ai pas compris si la mention de l'ancienne > commune était encore obligatoire ou juste un ancien usage (quid du > code postal ?). Si la solution précédente n'est pas suffisante, on > pourrait utiliser l' "addr:place" comme pour les communes fusionnées. > Une page wiki récapitulant tous les cas de figures et leur solution > dans OSM serait des bienvenues. > Qui a dit que la simplification du mille-feuille administratif était en > route ? > > Pieren > > _______________________________________________ > 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
