Pour BANO, ce qui nous intéresse ce sont les adresses, pas les limits adminsitratives.
Encore une fois on tombe sur quelque chose qui est résolu dans les autres pays (même juste à cpoté de nous par exemple en BElgique ou en Allemagne, et même au Royaume-Uni), avec des relations pour les zones postales (boundary=postal_area). Une adresse postale n'est pas une entité administrative en tant que telle (et encore moins depuis que les services postaux sont ouverts à la concurrence, on ne parlera bientôt même plus d’administration postae, même si les salariés de la Poste conservent leur statut public, employé dans une société semi-publique qui a elle-même des actionnaires autres que l'Etat et joue déjà sur les marchés internationaux avec tout un tas de filiales, même en France comme Chronoposte). Bref il serait tant de tracer des zones postales (liées non pas au code INSEE d'une commune (ce qui n'a souvent pas de sens dans des adresses en bordure de commune desservies par le bureau d'une autre), qui ne suit pas non plus les évolutions du mille-feuille adminsitratif, mais bel et bien lié au code postal (quitte à mettre dans une zone donnée pour un même code postal un sous-découpage communal, ou infracommunal pour les communes associées ou anciennes communes. Ce découpage aura aussi l'avantage de conserver les noms des zones postales (communes ou sous-communes) les plus appropriés pour le courrier et la géolocalisation (le découpage postal est plus utile en fait que le découpage administratif pour la géolocalisation et on sait l'importance qu'a la géolocalisation pour utiliser nos cartes et y positionner des tas de services qui n'ont rien d'adminsitratif) Le 23 juin 2014 15:23, Christian Quest <cqu...@openstreetmap.fr> a écrit : > 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
