[OSM-talk-fr] près de 200 nouvelles communes au 1er jv 2016

Sam 19 Déc 22:28:54 UTC 2015

Ca va très bien pour qualifier cet admin_level=9. Y compris les
arrondissements de Paris/Lyon/Marseille, les communes déléguées, les
communes associées.

Pour être complet on devrait aussi mettre un "admin_type:FR=*" sur
l'admin_level=8 au moins pour les communes ayant ces subdivisions
admin_level=9, mais la loi ne leur donne pas vraiment de nom distinctif
(sauf pour les "communes nouvelles") et les désigne simplement comme
"communes", quelle que soit leur organisation.
.
En revanche pas besoin d'admin_type pour les communes simples en
admin_level=8 où n'existe donc qu'un seul maire de droit commun (pas de
maires délégués, de maires de secteurs, de maires d'arrondissements... un
seul registre d'état-civil, un seul code INSEE, un seul plan cadastral).
c'est encore l'immense majorité.

Le 19 décembre 2015 à 22:15, Jérôme Amagat <jerome.amagat at gmail.com> a
écrit :

> c'est vrai que border_type c'est pour les frontières alors pourquoi pas
> admin_type.
>
> ça pourrait faire pour les communes nouvelles, (comme les autres communes)
> :
> type=boundary
> boundary=administrative
> admin_level=8
> name=*
> et
> source=* (Arrêté préfectoral)
> start_date=2016-01-01
>
> et pour les communes déléguées :
> type=boundary
> boundary=administrative
> admin_level=9
> name=*
> et
> source=* (Arrêté préfectoral)
> start_date=2016-01-01
> admin_type:FR=commune déléguée
>
> Et je pense que vu que le 01 janvier 2016, c'est dans moins de 2 semaines
> on peut faire les changements dès maintenant sans que ça pose problème.
>
>
>
>
> Le 18 décembre 2015 à 20:12, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> Le tag "admin_level=9" va bien, mais plutôt que "border_type" qui est
>> bien chargé (avec ses valeurs génériques en anglais), je verrais plutôt
>> "admin_type:FR=*" (avec le suffixe :FR pour le statut strictement
>> franco_français).
>>
>> Je garderais aussi "boundary=administrative" pour ce niveau 9 et non pas
>> boundary=local_authority (qui n'a pas d'admin_level, surtout pas en France
>> quand les EPCI peuvent être à chevel entre des entités adminsitrative de
>> niveau différents et grouper des entités de statut légal différents).
>>
>> Il ne s'agit en effet pas de différencier les types de frontières (même
>> pas visuellement) ni la disposition hiérarchique.
>>
>> De plus cette différenciation est à mettre non pas sur les ways
>> frontières, mais sur les relations définissant les surfaces. Sur les ways
>> frontières le border_type est là uniquement pour dfiférencier visuellement
>> le tracé entre deux administratives (ou plus avec la hiérarchie applicable
>> à chaque côté), ou pour diférencier des frontières qui ne sont pas
>> nécessairement fermées (exemple les limites maritimes) et le typenon pas
>> des entités séparées par cette frontière mais de l'accord qui les lie me^me
>> quand les entites séparées sont de types différents (ce qui est courant sur
>> des limites internationales). Le border_type sur un chemin frontière ne
>> peut pas indiquer précisément le type des entités situées à droite et/ou à
>> gauche
>>
>> On a un autre cas similaire pour le niveau 6 des deux entitées de
>> l'ancien Rhône (département ou métropole ?), ou encore pour le niveau 3
>> pour les statuts des entités composant la France en Outremer. ou encore au
>> niveau 2 sur des frontières contestées par d'autres pays.
>>
>> Ici il s'agit juste de pouvoir non pas changer les niveaux hiérarchiques
>> mais pouvoir ensuite détailler le statut réel de chaque entité territoriale
>> (avec un statut légal donné ici purement franco-français) qui utilise (ou
>> pas!) les chemins frontières. administrivement dans la hiérarchie
>> nationale, "admin_level=*" modélise la déconcentration de l'Etat, mais on
>> cherche à coder séparément les tyopes de collectivités territoriales selon
>> leur autonomie de fonctionnement propre., mais cette précision n'est
>> souvent mpême pas nécessaire sauf en tant qu'annotation pour révéler leur
>> statut complet détaillé (sachant que le décodage de leurs noms officiel est
>> assez compliqué à faire et plein d'exceptions spécifiques).
>>
>>
>>
>> Le 18 décembre 2015 à 14:52, Jérôme Amagat <jerome.amagat at gmail.com> a
>> écrit :
>>
>>> Vu l'ampleur pris par ces communes nouvelles et donc l'explosion des
>>> communes déléguées, je pense que l'on devrait créer un tag pour
>>> différencier ces anciennes communes de quartiers ou d'autres choses taguer
>>> avec admin_level=9 ou 10.
>>> Je verrai bien quelque chose sur le modèle des communauté de communes :
>>> type=boundary
>>> boundary=local_authority
>>> local_authority:FR=commune déléguée (ainsi que "commune associée" pour
>>> l'ancien système de fusion de communes)
>>>
>>> ou alors utiliser admin_level=9 avec le tag border_type (
>>> http://wiki.openstreetmap.org/wiki/Key:border_type) pour différencier
>>> les types de frontières :
>>> type=boundary
>>> boundary=local_authority
>>> admin_level=9
>>> border_type=commune déléguée
>>>                   commune associée
>>>                   arondissement
>>>
>>>
>>> Le 17 décembre 2015 à 10:11, adrien carpentier <ad.carpentier at gmail.com>
>>> a écrit :
>>>
>>>> Salut à tous!
>>>> je viens de recevoir cette info :
>>>> http://www.maire-info.com/article.asp?param=19055&PARAM2=PLUS&nl=1
>>>> il y a du gâteau de Noël dans l'air...
>>>> idem, une nouvelle CU en NPDC
>>>>
>>>> http://www.lagazettedescommunes.com/420297/vers-une-nouvelle-communaute-urbaine-dans-le-pas-de-calais/?utm_source=quotidien&utm_medium=Email&utm_campaign=27-11-2015-quotidien
>>>> @ bientôt
>>>> adrien
>>>>
>>>> _______________________________________________
>>>> 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 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
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20151219/c276344c/attachment.htm>