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

2015-12-19 Par sujet Jérôme Amagat 
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  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  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 
>> a écrit :
>>
>>> Salut à tous!
>>> je viens de recevoir cette info :
>>> http://www.maire-info.com/article.asp?param=19055=PLUS=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_medium=Email_campaign=27-11-2015-quotidien
>>> @ bientôt
>>> adrien
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
>

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

2015-12-19 Par sujet Philippe Verdy 
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  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  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  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
>>>

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

2015-12-18 Par sujet Jérôme Amagat 
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  a
écrit :

> Salut à tous!
> je viens de recevoir cette info :
> http://www.maire-info.com/article.asp?param=19055=PLUS=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_medium=Email_campaign=27-11-2015-quotidien
> @ bientôt
> adrien
>
> ___
> 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

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

2015-12-18 Par sujet Philippe Verdy 
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  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 
> a écrit :
>
>> Salut à tous!
>> je viens de recevoir cette info :
>> http://www.maire-info.com/article.asp?param=19055=PLUS=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_medium=Email_campaign=27-11-2015-quotidien
>> @ bientôt
>> adrien
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2015-12-17 Par sujet adrien carpentier 
Salut à tous!
je viens de recevoir cette info :
http://www.maire-info.com/article.asp?param=19055=PLUS=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_medium=Email_campaign=27-11-2015-quotidien
@ bientôt
adrien
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr