<div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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)</div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 14 juillet 2016 à 08:38, Stéphane Péneau <span dir="ltr"><<a href="mailto:stephane.peneau@wanadoo.fr" target="_blank">stephane.peneau@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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.<br>
<br>
Je réitère une de mes questions :<br>
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 ?<br>
<br>
Stf<div><div class="h5"><br>
<br>
Le 13/07/2016 à 21:52, Jérôme Amagat a écrit :<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">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)<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 13 juillet 2016 à 18:23, Philippe
Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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).
<div><br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 13 juillet 2016 à 18:07,
Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Un
noeud place=* fait le job, exemple: <a href="http://www.openstreetmap.org/node/4284576845" rel="noreferrer" target="_blank">http://www.openstreetmap.org/node/4284576845</a>
<div>
<div><br>
<br>
<br>
Le 13/07/2016 à 17:55, Stéphane Péneau a écrit
:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello !<br>
<br>
Une note laissée sur <a href="http://osm.org" rel="noreferrer" target="_blank">osm.org</a> 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.<br>
<br>
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é.<br>
J'ai rêvé ou pas ?<br>
<br>
Actuellement, le tag name du noeud "place"
semble être prioritaire sur le name de la
relation.<br>
<br>
Une solution serait le tag label dans la
relation, mais il semble ne toujours pas
être supporté par mapnik.<br>
<br>
À part demander des changements sur le
rendu, quelqu'un voit une solution ?<br>
<br>
La note en question :<br>
<a href="http://www.openstreetmap.org/note/626633#map=12/47.1389/-1.9281" rel="noreferrer" target="_blank">http://www.openstreetmap.org/note/626633#map=12/47.1389/-1.9281</a><br>
<br>
Stf<br>
<br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote>
<br>
<br>
</div>
</div>
<span><font color="#888888">
-- <br>
Christian Quest - OpenStreetMap France</font></span>
<div>
<div><br>
<br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Talk-fr mailing list
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<p><br>
</p>
</div></div></div>
<br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>