[OSM-talk-fr] Rendu du nom d'une commune nouvelle
Philippe Verdy
verdy_p at wanadoo.fr
Jeu 14 Juil 10:59:37 UTC 2016
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 <stephane.peneau at wanadoo.fr> 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 <verdy_p at wanadoo.fr> 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 <cquest at openstreetmap.fr> 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
>>>> Talk-fr at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> _______________________________________________
> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160714/f1fabcbe/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr