A ce sujet il semblerait que les deux communes en question fusionnées en janvier 2016 sont toujours sur OSM dans des communautés de commune séparées, ce qui ne devrait plus être le cas. Arthon-en-Retz faisait partie de la CC de Pornic, Chéméré faisait partie de la CC du Pays de Retz.
Depuis janvier elles ont du se concerter dans le nouveau conseil municipal réuni de Chaumes-en-Retz et choisir (il me semble qu'elles avaient moins de 3 mois pour le faire) et dès lors négocier les transferts avec les CC respectives (qui doivent aussi accepter), ou bien sortir totalement des deux CC (la transition doit être à cette date décidée même s'il reste des procédures en cours jusqu'en fin d'année, par des arrongements comptables et fiscaux entre les deux CC et les deux communes, pour que les CC fonctionnent correctement et que les engagements financiers avec les tiers publics ou privés soient valides légalement, et déjà la commune nouvelle doit avoir la capacité de prendre des décisions valides). Je ne sais pas quelle CC la commune nouvelle a choisi (il devrait y avoir un arrêté préfectoral officialisant la décision pour les deux communes déléguées, la commune nouvelle, les deux CC et tous les tiers concernés ayant des engagements avec ces collectivités). Rechercher ausi les codes SIREN respectifs (en principe les codes SIREN des communes déléguées n'ont pas changé, il y a un nouveau code SIREN pour la commune nouvelle), car ils sont plus spécifiques que les codes INSEE. Les codes INSEE ne changent pas en principe (ils sont encore utilisés pour le référencement cadastral dans chaque commune déléguée, même si c'est la commune nouvelle qui gère maintenant le même cadastre, on les trouve sous forme des trois chiffres ajoutés pour qualifier les lettres de zones cadastrales de chaque commune déléguée, sauf son chef-lieu utilisant souvent "000" au lieu de son propre code communal INSEE). La commune nouvelle en principe adopte pour elle **aussi** le même code INSEE de la commune déléguée: cela ne fait pas doublon cependant car ce ne sont pas les mêmes types d'entité: voir "admin_type:FR=commune nouvelle" ou "admin_type:FR=commune déléguée" en plus du tag "admin_level=8" ou 9 moins précis d'OSM). Les outils cherchant les codes INSEE ne peuvent trouver un doublon apparent que s'il ne tiennent pas compte de l'admin_level pour les différencier. Les codes SIREN sont cependant toujours différents et uniques (les communes nouvelles ont un code SIREN non formé sous la forme "21..." avec le numéro communal dedans, les communes déléguées conservent leur SIREN venant de leur ancien état en tant que communes de plein exercice; ce SIREN ne sera ensuite supprimé que qand les communes déléguées ont clos leur dernier exercice comptable et finalisé tous les transferts, publié leur comptes, et n'ont plus aucune existence légale en tant que personnes morales). Les SIREN sont stables et jamais réutilisés par d'autres entités. Cependant quand une commune ou une CC voit ses frontièrs modifiées, si la personne morale reste la même (juste un changement de statut interne), leur SIREN n'est pas modifié, ce n'est pa un numéro strictement géographique (pas plus que le code INSEE des communes) Le 14 juillet 2016 à 08:38, Stéphane Péneau <[email protected]> a écrit : > Je suis d'accord avec mes prédécesseurs. Tu tagues pour le rendu. C'est > d'autant plus surprenant que tu as la main sur le rendu osm-fr. > > Je réitère une de mes questions : > Je me trompe, ou bien précédemment, le rendu par défaut affichait aussi le > nom des relations admin en plus de l'admin center ? > > Stf > > > Le 13/07/2016 à 21:52, Jérôme Amagat a écrit : > > Je n'aime pas bien ça , créé un noeud place= avec le nom de la nouvelle > commune juste pour le rendu! Ici Montholon n'est pas un village et a cette > endroit il n'y a rien, (en plus ici le nom apparaît sur le rendu alors que > la commune nouvelle n'existe pas encore). Le nom est sur la relation > commune et ca suffit pour avoir des données justes. Ce qui s'appelle > Montholon c'est tout le territoire de la commune est pas un point ou un > village quelquepart. Si ca n'apparait pas sur le rendu, c'est pas de la > faute aux données mais au rendu qui n'affiche pas le nom des communes. Soit > il faut changer le rendu soit laissé comme ça sans le nom des commune. Est > ce que ses nom sont bien important? c'est pas nouveau des communes avec un > nom qui n'est pas un nom de village (ou accumulation de plusieur nom) > > Le 13 juillet 2016 à 18:23, Philippe Verdy <[email protected]> a écrit : > >> Bof... recule un peu tu ne vois plus que les communes déléguées. Et ce >> placement n'est pas celui du chef-lieu de la commune, c'est posé un peu >> n'importe où, en fait plus là pour taguer pour le rendu. Ce noeud devrait >> être cependant un rôle label, pas un noeud place=*, ni avoir le rôle >> admin_centre (dont le noeud garde le nom et le placement de la commune >> déléguée). >> >> >> Le 13 juillet 2016 à 18:07, Christian Quest <[email protected]> a >> écrit : >> >>> Un noeud place=* fait le job, exemple: >>> http://www.openstreetmap.org/node/4284576845 >>> >>> >>> >>> Le 13/07/2016 à 17:55, Stéphane Péneau a écrit : >>> >>>> Hello ! >>>> >>>> Une note laissée sur osm.org m'a fait remarqué que lorsqu'une commune >>>> nouvelle a comme chef-lieu une des anciennes communes - ce qui doit être la >>>> majorité des cas - elle ne s'affiche pas sur le rendu par défaut, ni sur le >>>> rendu osm-fr. C'est plutôt ennuyant. >>>> >>>> Pourtant, il me semble qu'il y a quelque temps, on voyait le nom de la >>>> commune au centroïde des limites admin ET le nom de la commune du tag >>>> place. Ce n'était pas très heureux lorsque les 2 noms étaient identiques, >>>> mais dans le cas présent, ça aurait son utilité. >>>> J'ai rêvé ou pas ? >>>> >>>> Actuellement, le tag name du noeud "place" semble être prioritaire sur >>>> le name de la relation. >>>> >>>> Une solution serait le tag label dans la relation, mais il semble ne >>>> toujours pas être supporté par mapnik. >>>> >>>> À part demander des changements sur le rendu, quelqu'un voit une >>>> solution ? >>>> >>>> La note en question : >>>> http://www.openstreetmap.org/note/626633#map=12/47.1389/-1.9281 >>>> >>>> Stf >>>> >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> >>> >>> -- >>> Christian Quest - OpenStreetMap France >>> >>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> >> >> _______________________________________________ >> Talk-fr mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > _______________________________________________ > Talk-fr mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
