J'ai commencé à utiliser le tag addr:place systématiquement pour les communes qui ont disparu dans les communes associées et les communes fusionnées. J'ai un peu hésité avec le tag addr:hamlet, les deux pourraient fonctionner. C'est clair qu'il faut un tag spécifique, ne serait-ce que pour gérer les noms de rues en double dans certaines communes fusionnées résultantes.
2014-06-23 16:11 GMT+02:00 Philippe Verdy <verd...@wanadoo.fr>: > 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
