Si la nouvelle commune réutilise le code attribué à Cherbourg-Octeville (qui était déjà une fusion de communes déléguées, avec encore des codes existants pour les communes déléguées), ce qui permet de distinguer n'est pas le code insee seul mais aussi alors admin_level=8 ou 9. On retrouve encore ces "anciens" codes toujours utilisés par le cadastre même après la fusion, pour codifier les planches. Il faut relancer le projet pour mettre à jour les 700 communes déléguées ou associées et aller au delà des seuls arrondissements communaux de P/L/M.
On avait déjà évoqué ici le cas très ancien de Lille avec des rues homonymes selon les communes déléguées/associées membre de la commune actuelle. Ces rues n'ont jamais été renommées, et localement on connait toujours ces noms d'anciennes communes (qu'on confond parfois improprement comme des "quartiers"). Ces noms sont jours visibles sur le terrain sur les panneaux (Hellemmes, Wazemmes...) Pourtant on ne les voit pas du tout encore dans OSM. on avait "fini" les communes il y a presque deux ans mais on a laissé de coté les communes associées; certaines ont été réjoutées à l'occasion du chantier des découpage cantonaux (certains cantons de mars 2015 y faisant directement référence dans leur définition, même quand la "fusion" ou "association" était très ancienne... comme quoi les limites ne disparaissent pas après une fusion et ont encore une valeur légale, qui peut aboutir aussi à des défusions. Le cadastre ne les oublie pas dans le découpage et la codification des zones cadastrales) Lors d'une fusion je vois d'un mauvais oeil le fait de modifier une "ancienne" commune pour l'agrandir aux ancienns communes voisines. Plutôt les garder, changer juste un tag (admin_level de 8 à 9 ce qui laisse aussi leurs propres quartiers inchangés au niveau 10), et créer un nouvel objet. Et pour les anciennes communes renommer le tag ref=*(insee) en "old_ref" pour garder le code inchangé. Il n'est pas inutile non plus de mettre start_date=* pour la nouvelle commune, end_date=* pour les anciennes (passées en admin_level=9 si déléguées), et aussi annoter la source avec un lien vers Legifrance. Ca permet de retrouver plus tard facilement Plus compliqué le cas des fusions ne laissant aucune délégation (ce cas est plus rare) on ne pourra mettre aucun admin_level, mais je suis partisan de garder les frontières aussi... à moins que le PLU ou autres plans communaux et le cadastre soit redéfini avec un nouveau découpage des quartiers administratif au niveau 10 passant outre les anciennes frontières intercommunales. Le 10 septembre 2015 10:38, Vincent de Château-Thierry <osm.v...@free.fr> a écrit : > > > De: "Francescu GAROBY" <windu...@gmail.com> > > > > La question de Christophe portait sur la gestion, par la commune > > nouvelle, des risques d'homonymie. Une solution qui lèverait ce > > risque, pour les utilisateurs d'OSM comme pour les autres, seraient > > de renommer une des 2 rues homonymes, c''est tout ! > > Tu peux glisser la suggestion à l'adjoint au maire ;) > > > (et ça n'interdit pas de garder les contours des communes déléguées > > dans OSM, perso je n'ai rien contre) > > Pour le passage des communes déléguées en niveau 9 : lorsqu'on a attribué > le niveau 9 aux arrondissements communaux, un critère pour les distinguer > des quartiers (niveau 10) était qu'on savait leur attribuer un code INSEE. > Sauf réutilisation d'un code INSEE actuel pour la future commune de > Cherbourg-en-Cotentin, on devrait pouvoir appliquer ce schéma. Et d'accord > avec Philippe pour leur utilisation : il faut exploiter la combinaison des > niveaux 8 et 9 côté applications clientes pour lever au mieux les > ambiguïtés sur les possibles rues homonymes. > > vincent > > _______________________________________________ > 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
