subject:"\[OSM\-talk\-fr\] niveaux admin_level=7 \(était \: Limites communales\)"

Le 25/09/2010 23:58, Vincent de Chateau-Thierry a écrit :
Le
25/09/2010 20:24, Benoît ROUSSEAU a écrit :

Euh... ;-) ok.

Pourquoi "mais il ne faut surtout pas boundary=administative" ?
Après

tout c'est bien une limite administrative du même ordre que les
communes

?Seule la nature change, par délégation de pouvoirs.

L'intérêt de "nature" (ou autre) est qu'on pourrait en plus
décomposer

les différentes natures administratives (les académies avec
"education",

les préfectures (même si incluses dans les arrondissements avec
"police,

les zones des centres d'impôts avec "fiscal", ...).

Réponse globale avant : Ca ne me gène pas de
faire le distinguo dès le boundary. C'était une réflexion sur la
notion de com2com qui n'est pas trahie par une différentiation
immédiate.
Tout
à fait d'accord pour rentrer en base différentes natures de
limites comme celles que tu cites. Cependant, je préfère une
distinction dès le tag "boundary=*", plutôt que de coller
"boundary=administrative" et devoir via un tag nature=* distinguer
les types de limites. Je ne verrais de commun à toutes ces limites
que le tag de premier niveau, à savoir type=boundary. Ensuite,
pourquoi pas des boundary=électorale, statistique, linguistique,
militaire, académique (?), etc. A traduire bien sûr :-).

L'usage jusque là, donné par le wiki, est d'associer
boundary=administrative au tag admin_level=*. Et j'imagine mal
placer dans le grand tableau _mondial_ du wiki[1] de multiples
notions autres que la commune pour l'admin_level 8, avec un
distingo "nature=*".

Pour garder homogène le "grand tableau
mondial" ok.
Selon moi, le niveau 7 correspondrait aux
arrondissements départementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre
chapitre "Cadre" pour ce qui est du thème de l'administration.
Pour ce qui est des quartiers en niveau 10, je ne sais pas quoi en
penser, car je ne sais pas s'il existe "légalement" des organismes
d'administration des quartiers. Les Conseils de quartier par
exemple, n'ont qu'un avis consultatif selon http://fr.wikipedia.org/wiki/Conseil_de_quartier.
Pour
résumer mon point de vue là-dessus, à l'exception du niveau
cantonal, essayons de garder boundary=administative et
admin_level=* pour les découpages du territoires donnés par le COG
[2], et déclinons d'autres valeurs du tag boundary=* pour les
autres styles de découpage, quitte à ce qu'ils s'appuient
eux-mêmes sur les unités du COG, comme les communes. Tiens, ça me
rappelle les communautés de communes, ça :-)

:-). Pour ma part sans enlever les références
au COG, je me baserai sur le découpage du chapitre "Cadre" de http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre
avec les communes et les arrondissements municipaux en plus. Il y
aurait ainsi seulement 6 niveaux administratifs : A - Pays, B -
Régions, C - Départements(Préfectures), D - Sous-Préfectures
(sachant qu'elles sont "sous tutelle" de la Préfecture au niveau
départemental), E - Communes, F- Arrondissements municipaux. Avec
une hésitation pour les Sous-préfectures... Avec ce découpage, les
territoires s'emboitent, les limites communales sont partagées
entre les niveaux et il me semble que le sens premier de
boundary=administative est respecté et compréhensible.

vincent

[1] : http://wiki.openstreetmap.org/wiki/Admin_level

[2] :
http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp

Benoît R.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)


Le 25/09/2010 20:24, Benoît ROUSSEAU a écrit :

Euh... ;-) ok.

Pourquoi "mais il ne faut surtout pas boundary=administative" ? Après
tout c'est bien une limite administrative du même ordre que les communes
?Seule la nature change, par délégation de pouvoirs.
L'intérêt de "nature" (ou autre) est qu'on pourrait en plus décomposer
les différentes natures administratives (les académies avec "education",
les préfectures (même si incluses dans les arrondissements avec "police,
les zones des centres d'impôts avec "fiscal", ...).


Tout à fait d'accord pour rentrer en base différentes natures de limites 
comme celles que tu cites. Cependant, je préfère une distinction dès le 
tag "boundary=*", plutôt que de coller "boundary=administrative" et 
devoir via un tag nature=* distinguer les types de limites. Je ne 
verrais de commun à toutes ces limites que le tag de premier niveau, à 
savoir type=boundary. Ensuite, pourquoi pas des boundary=électorale, 
statistique, linguistique, militaire, académique (?), etc. A traduire 
bien sûr :-).
L'usage jusque là, donné par le wiki, est d'associer 
boundary=administrative au tag admin_level=*. Et j'imagine mal placer 
dans le grand tableau _mondial_ du wiki[1] de multiples notions autres 
que la commune pour l'admin_level 8, avec un distingo "nature=*".
Pour résumer mon point de vue là-dessus, à l'exception du niveau 
cantonal, essayons de garder boundary=administative et admin_level=* 
pour les découpages du territoires donnés par le COG [2], et déclinons 
d'autres valeurs du tag boundary=* pour les autres styles de découpage, 
quitte à ce qu'ils s'appuient eux-mêmes sur les unités du COG, comme les 
communes. Tiens, ça me rappelle les communautés de communes, ça :-)


vincent

[1] : http://wiki.openstreetmap.org/wiki/Admin_level
[2] : http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 17:24, Vincent de Chateau-Thierry a écrit :

  
  
  Le 25/09/2010 16:51, Benoît ROUSSEAU a écrit :
  
    Autre proposition :


Actuellement pour les limites administratives des communes ont
utilise

quelque chose :


des way décrits comme suit :


version="1" changeset="1221617" user="monsieur a"
uid="97101">




















des relations d'appartenance décrites comme suit :


version="6" changeset="3344785" user="MrsPeel" uid="206119">



























version="4" changeset="3072415" user="EtienneChoveBot"
uid="183561">
































Pourquoi ne pas simplement ajouter des relations com2com comme
suit avec

un tag "nature" (les anglophones traduiront) pour les
distinguées des

communes au même niveau et ca résout le pb :


version="4" changeset="30724185" user="quidam" uid="1883561">























EPCI" />




Ca ne change quasiment rien au schéma actuel puisque c'est de la
même

veine que le tag natural=coastline. Pas de region pas de
subarea, ... et

si j'ai bien compris c'est la proposition exprimée par Vincent
de

Château-Thierry.


  
  
  Euh...:-)
  
  Une différence avec ce que je propose, c'est que dans une relation
  com'com basée sur des limites, il faut le tag type=boundary 
  (puisqu'on parle de limites), mais il ne faut surtout pas
  boundary=administative. D'où ma proposition de
  boundary=local_authority.
  
  
  Après oui, si on regarde par exemple la définition actuelle de
  Saint-Quentin-en-Yvelines :
  
  
  
  
  
  
  
  (...)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  pour la "convertir" dans le modèle que j'imagine, il y a très peu
  à changer :
  
  - supprimer admin_level=7
  
  - changer boundary=administrative en boundary=local_authority (ou
  autre si on trouve mieux)
  
  - ajouter les tags relatifs à la nature et aux compétences de
  l'EPCI
  
  ...et c'est tout.
  
  
  vincent
  

Euh... ;-) ok.

Pourquoi "mais il ne faut surtout pas boundary=administative" ?
Après tout c'est bien une limite administrative du même ordre que
les communes ? Seule la nature change, par délégation de pouvoirs. 
L'intérêt de "nature" (ou autre) est qu'on pourrait en plus
décomposer les différentes natures administratives (les académies
avec "education", les préfectures (même si incluses dans les
arrondissements avec "police,  les zones des centres d'impôts avec
"fiscal", ...).

Benoît R.

  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

compris.

Le 25/09/2010 19:10, Emilie Laffray a écrit :

  Petite clarification. Ce qui me gêne c'est l'utilisation qu'il
en fait en Espagne et en Pologne où les données géométriques
sont mélangées avec des relations avec le rôle subarea. Pour moi
cela n'a aucun sens.
Dans le cas d'une relation boundary, si les données géo ne sont
pas mélangées, ça ne me gêne pas.
  Emilie Laffray
  On 25 Sep 2010 12:28, "Benoît ROUSSEAU"

wrote:
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3158 - Date: 09/25/10 08:34:00

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-25 Par sujet Emilie Laffray

Petite clarification. Ce qui me gêne c'est l'utilisation qu'il en fait en
Espagne et en Pologne où les données géométriques sont mélangées avec des
relations avec le rôle subarea. Pour moi cela n'a aucun sens.
Dans le cas d'une relation boundary, si les données géo ne sont pas
mélangées, ça ne me gêne pas.

Emilie Laffray
On 25 Sep 2010 12:28, "Benoît ROUSSEAU"  wrote:
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)




Le 25/09/2010 16:51, Benoît ROUSSEAU a écrit :

  Autre proposition :

Actuellement pour les limites administratives des communes ont utilise
quelque chose :

des way décrits comme suit :











des relations d'appartenance décrites comme suit :































Pourquoi ne pas simplement ajouter des relations com2com comme suit avec
un tag "nature" (les anglophones traduiront) pour les distinguées des
communes au même niveau et ca résout le pb :















Ca ne change quasiment rien au schéma actuel puisque c'est de la même
veine que le tag natural=coastline. Pas de region pas de subarea, ... et
si j'ai bien compris c'est la proposition exprimée par Vincent de
Château-Thierry.



Euh...:-)
Une différence avec ce que je propose, c'est que dans une relation 
com'com basée sur des limites, il faut le tag type=boundary  (puisqu'on 
parle de limites), mais il ne faut surtout pas boundary=administative. 
D'où ma proposition de boundary=local_authority.


Après oui, si on regarde par exemple la définition actuelle de 
Saint-Quentin-en-Yvelines :
version="24" changeset="5253787" user="ToineToine" uid="313558">



(...)








pour la "convertir" dans le modèle que j'imagine, il y a très peu à 
changer :

- supprimer admin_level=7
- changer boundary=administrative en boundary=local_authority (ou autre 
si on trouve mieux)

- ajouter les tags relatifs à la nature et aux compétences de l'EPCI
...et c'est tout.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Autre proposition :

Actuellement pour les limites administratives des communes ont
utilise quelque chose :

des way décrits comme suit :

   
   
   
   
   
   
   
   


des relations d'appartenance décrites comme suit :

   
   
   
   
   
   
   
   
   
   
   



   
   
   
   
   
   
   
   
   
   
   
   
   
   


Pourquoi ne pas simplement ajouter des relations com2com comme suit
avec un tag "nature" (les anglophones traduiront) pour les
distinguées des communes au même niveau et ca résout le pb :

   
   
   
   
   
   
   
   
   
   
  
  


Ca ne change quasiment rien au schéma actuel puisque c'est de la
même veine que le tag natural=coastline. Pas de region pas de
subarea, ... et si j'ai bien compris c'est la proposition exprimée
par Vincent de Château-Thierry.

Benoît R.


  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 15:09, Vincent de Chateau-Thierry a écrit :

  
  
  Le 25/09/2010 14:38, Vincent Pottier a écrit :
  
  Il me semble qu'il y a une différence de
nature entre un département et

une communauté de commune.

Un département n'est pas une agrégation de commune, mais un
territoire,

une collectivité territoriale dont les limites coïncident avec
elles de

M, N

Une communauté de commune, quant à elle, est une agrégation de
communes

à laquelle adhèrent M, N...

  

Posons-nous la question : si on voulait un jour récupérer ces
informations de découpage administratif comment voudrions nous les
voir représentées ? Je ne parle pour l'instant que du découpage,
ensuite on verra comment intégrer les informations connexes. Le
découpage administratif de manière général est un arbre, pas une
pile. On sait décrire un arbre en XML. Commençons par la structure
avec des tags fictifs pour débuter, piochons dans l'existant puis
nous définirons ce qui manque.

  
  Oui. Mon raisonnement pour parler d'agrégation est à voir sous
  l'angle des primaires géométriques dans la base, avec en tête une
  question : comment rendre la base cohérente en terme de
  construction, à la fois pour ceux qui la constituent (nous) et
  pour ceux qui s'en servent/serviront (nous aussi, entre autres).
  
  Dans les 2 cas, depts et com'com, la construction _dans osm_se
  fait en assemblant un puzzle dont les pièces sont des communes
  (*). Et je ne trouve pas d'argument pour dire : en fonction du
  nombre de pièces du puzzle, je vais prendre des pièces "limites"
  ou des pièces "surfaces".
  

Sous l'angle des primaires géométriques, difficile de trancher, car
dans le cas des limites administratives puisque définissons des
limites (frontières) de surfaces (territoires), qui donc doivent
boucler. Ces limites donc pourraient très bien être des définies en
surfaces sans en changer le sens. Pour ma part je préférerai des
area en place des boundary, mais définir des boundary n'est pas
moins illogique..

  
  

Mais bon, je ne suis pas spécialiste...

  
  
  Alors on est 2 :-)
  
  
  vincent
  
  
  (*) Je mets de côté la démarche "Cartographes Associés" qui
  partait directement de l'échelle "département" pour les
  constituer, vu qu'on supprime cette source doucement mais
  sûrement, pour lui substituer une géométrie et un maillage plus
  fins.
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3158 - Date: 09/25/10 08:34:00




  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)




Le 25/09/2010 14:38, Vincent Pottier a écrit :

Il me semble qu'il y a une différence de nature entre un département et
une communauté de commune.
Un département n'est pas une agrégation de commune, mais un territoire,
une collectivité territoriale dont les limites coïncident avec elles de
M, N
Une communauté de commune, quant à elle, est une agrégation de communes
à laquelle adhèrent M, N...


Oui. Mon raisonnement pour parler d'agrégation est à voir sous l'angle 
des primaires géométriques dans la base, avec en tête une question : 
comment rendre la base cohérente en terme de construction, à la fois 
pour ceux qui la constituent (nous) et pour ceux qui s'en 
servent/serviront (nous aussi, entre autres).
Dans les 2 cas, depts et com'com, la construction _dans osm_se fait en 
assemblant un puzzle dont les pièces sont des communes (*). Et je ne 
trouve pas d'argument pour dire : en fonction du nombre de pièces du 
puzzle, je vais prendre des pièces "limites" ou des pièces "surfaces".




Mais bon, je ne suis pas spécialiste...


Alors on est 2 :-)

vincent

(*) Je mets de côté la démarche "Cartographes Associés" qui partait 
directement de l'échelle "département" pour les constituer, vu qu'on 
supprime cette source doucement mais sûrement, pour lui substituer une 
géométrie et un maillage plus fins.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 14:16, Vincent de Chateau-Thierry a écrit :
Bonjour,
  
  
  Le 25/09/2010 13:27, Benoît ROUSSEAU a écrit :
  
  

Pour les subarea je n'est remarqué aucun consensus, Pierre
Quenee nous a

proposé, comme base de travail, l'adaptation sur un modèle
existant et

Émilie à évoqué subarea en nous disant "ca ne me plait pas mais
ça

existe par ailleurs".

  
  Oui, tout à fait. Mais hier soir je disais : "_si_ il y a
  consensus".
  

Je reformule :p avec avoir en prime : je n'ai pas remarqué qu'on se
dirigeai vers un consensus... 

  
  Mis a part le modèle proposer qui reste à
affiner, renommer les tags, le

compléter, il n'y a pas incohérence avec le modèle actuel bien
au

contraire c'est un complément indispensable ! C'est le modèle
actuel qui

nous amène à l'incohérence. Soit en hiérarchisant de haut en bas
: des

éléments qui pour certains ne sont pas des limites
administratives ou

des élément qui devraient être au même niveau administratif sur
des

niveaux différents. Même si nous rajoutions une numérotation de
niveau a

plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le
modèle

qui fait consensus dans la base est limité que nous devons le
reproduire

bêtement à l'infini en entrant des données dedans au chausse
pied en

considérant que c'est un fourre tout. Tagguer un admin level 7
pour une

communauté de commune est une erreur si les communes sont en 8 !
Ou

alors il faut compléter le modèle actuel en ajoutant des
compléments

d'information pour distinguer les limites administratives
placées au

même niveau.

  
  
  Je viens de relire ce que je disais hier, et ça prête à confusion,
  je comprends ta réponse. Je ne parlais (ne voulais parler) que de
  la manière de construire l'objet com'com : par une relation de
  type boundary=*, ou par une autre de type region=*. Il est clair
  pour moi que dans un cas comme dans l'autre, le tag admin_level=*
  n'a rien à faire dans cette relation. En revanche, il est présent
  dans chacun des membres de la relation.
  
  En essayant de reformuler : "quand on agrège des communes pour
  construire un département, on utilise boundary=*, pourquoi ne pas
  utiliser aussi boundary="autre chose" pour agréger des communes à
  l'échelle d'une com'com."
  

Là, il va me falloir du temps pour simuler avec un cas concret pour
bien comprendre avant de répondre.

  
  La solution de la relation est très
pratique et flexible puisqu'elle

évite d'avoir nécessairement à ressaisir les contours en
incluant les

contours des communes. L'argument comment on fait s'il n'y à pas
de

contours de communes ne tient pas, il faut les tracer.

  
  Facile à dire, et j'aimerais être d'accord avec ça, mais il faut
  être lucide, la courbe de croissance des limites admin est plutôt
  faible. Construire une version temporaire de com'com, avec les
  nodes place=* permet déjà d'identifier la com'com et ses communes
  constituantes (via leur ref:INSEE) ainsi que, au mieux, ses
  domaines de compétence. Le jour où les contours de commune
  existent, on remplace le node place=* par la relation
  boundary=administrative, mais au moins comme ça on ne créé pas
  d'adhérence entre les objets com'com et limite admin. Utiliser le
  node place=* est une suggestion pour gérer une situation
  transitoire, pas ce qui devrait être le modèle définitif.
  

Courbe de croissance faible oui. Je m'éloigne du sujet précis pour
illustration

Pour exemple je vais prendre mon comportement face aux adresses et
aux rivières. Les rivières j'ai essayé, j'ai arrêté après avoir lu
le wiki et ses 50 (exagéré) manières de faires et les discussions
sur la liste qui en amenaient encore d'autres. Les adresses c'est en
stanby alors que j'ai les moyens d'importer des millions d'adresses
(j'ai fait les essais) automatiquement car le modèle "Karl", est
passé de proposition à norme et aujourd'hui à standard
indéboulonnable. Il me semble inapproprié, car lui aussi mélange
différents type d'adresses (administrative, géographique, postales),
dans quelque chose qui devient systématiquement contradictoire entre
ceux qui militent pour l'administrative, la postale et la
géographique. Soit je fais le forcing en imposant un nouveau
stan

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-25 Par sujet Vincent Pottier


On 25/09/2010 14:16, Vincent de Chateau-Thierry wrote:


Je viens de relire ce que je disais hier, et ça prête à confusion, je 
comprends ta réponse. Je ne parlais (ne voulais parler) que de la 
manière de construire l'objet com'com : par une relation de type 
boundary=*, ou par une autre de type region=*. Il est clair pour moi 
que dans un cas comme dans l'autre, le tag admin_level=* n'a rien à 
faire dans cette relation. En revanche, il est présent dans chacun des 
membres de la relation.
En essayant de reformuler : "quand on agrège des communes pour 
construire un département, on utilise boundary=*, pourquoi ne pas 
utiliser aussi boundary="autre chose" pour agréger des communes à 
l'échelle d'une com'com."
Il me semble qu'il y a une différence de nature entre un département et 
une communauté de commune.
Un département n'est pas une agrégation de commune, mais un territoire, 
une collectivité territoriale dont les limites coïncident avec elles de 
M, N
Une communauté de commune, quant à elle, est une agrégation de communes 
à laquelle adhèrent M, N...
Aussi, ça ne me gène pas d'utiliser un modèle 'somme des areas' pour la 
com'com, et une 'somme des boundaries' pour le département, la commune...


Par ailleurs, les quartiers ou arrondissements de départements sont des 
subdivisions de la collectivité supérieure.


Peut-être que la question est "qui a compétence, en droit, pour 
ériger/supprimer/fusionner tel territoire, quartier,arrondissement PLM, 
commune, com'com, arrondissement de département, département... ?"


Mais bon, je ne suis pas spécialiste...
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)


Bonjour,

Le 25/09/2010 13:27, Benoît ROUSSEAU a écrit :


Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee nous a
proposé, comme base de travail, l'adaptation sur un modèle existant et
Émilie à évoqué subarea en nous disant "ca ne me plait pas mais ça
existe par ailleurs".

Oui, tout à fait. Mais hier soir je disais : "_si_ il y a consensus".


Mis a part le modèle proposer qui reste à affiner, renommer les tags, le
compléter, il n'y a pas incohérence avec le modèle actuel bien au
contraire c'est un complément indispensable ! C'est le modèle actuel qui
nous amène à l'incohérence. Soit en hiérarchisant de haut en bas : des
éléments qui pour certains ne sont pas des limites administratives ou
des élément qui devraient être au même niveau administratif sur des
niveaux différents. Même si nous rajoutions une numérotation de niveau a
plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le modèle
qui fait consensus dans la base est limité que nous devons le reproduire
bêtement à l'infini en entrant des données dedans au chausse pied en
considérant que c'est un fourre tout. Tagguer un admin level 7 pour une
communauté de commune est une erreur si les communes sont en 8 ! Ou
alors il faut compléter le modèle actuel en ajoutant des compléments
d'information pour distinguer les limites administratives placées au
même niveau.


Je viens de relire ce que je disais hier, et ça prête à confusion, je 
comprends ta réponse. Je ne parlais (ne voulais parler) que de la 
manière de construire l'objet com'com : par une relation de type 
boundary=*, ou par une autre de type region=*. Il est clair pour moi que 
dans un cas comme dans l'autre, le tag admin_level=* n'a rien à faire 
dans cette relation. En revanche, il est présent dans chacun des membres 
de la relation.
En essayant de reformuler : "quand on agrège des communes pour 
construire un département, on utilise boundary=*, pourquoi ne pas 
utiliser aussi boundary="autre chose" pour agréger des communes à 
l'échelle d'une com'com."



La solution de la relation est très pratique et flexible puisqu'elle
évite d'avoir nécessairement à ressaisir les contours en incluant les
contours des communes. L'argument comment on fait s'il n'y à pas de
contours de communes ne tient pas, il faut les tracer.
Facile à dire, et j'aimerais être d'accord avec ça, mais il faut être 
lucide, la courbe de croissance des limites admin est plutôt faible. 
Construire une version temporaire de com'com, avec les nodes place=* 
permet déjà d'identifier la com'com et ses communes constituantes (via 
leur ref:INSEE) ainsi que, au mieux, ses domaines de compétence. Le jour 
où les contours de commune existent, on remplace le node place=* par la 
relation boundary=administrative, mais au moins comme ça on ne créé pas 
d'adhérence entre les objets com'com et limite admin. Utiliser le node 
place=* est une suggestion pour gérer une situation transitoire, pas ce 
qui devrait être le modèle définitif.


 Personne ne se

pose la question de tracer une route sans ways ou d'indiquer des sorties
d'autoroutes sans l'autoroute. Qui plus est la relation permet d'ajouter
un contour propre à la com'com.
Le plus important même si l'on tâtonne en base est d'avoir l'ensemble
des informations cohérentes pour transtyper automatiquement ces éléments
si nécessaire dans le futur. Ca la relation et le modèle proposé le
permettent.


Tout à fait. Et cela peut valoir aussi bien pour membres de la relation 
(de node place=* à boundary=administrative) que pour les tags. A mon 
avis :-)


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 24/09/2010 23:03, Vincent de Chateau-Thierry a écrit :
Bonsoir,
  
  
  Le 24/09/2010 22:03, Pierre-Alain Dorange a écrit :
  
  

Pieren  wrote:



  En ce qui concerne les rôles :
admin_center



  
  Attention à la syntaxe anglaise : admin_centre (et non
  admin_center). Erreur
  
  très courante, en particulier chez les français (on se demande
  pourquoi ;-)
  


Concernant les EPCI je crois pas que admin_centre soit pertinent
; il

n'y a pas de réel centre administratif (un adresse postale c'est
tout).

Aucune commune n'a d'égénomie (en théorie, car souvent c'est la
ville

principale qui assume ce rôle).


Mais la relation proposée est très intéressante.

  
  
  Oui, et à double titre, puisqu'elle permet de "faire la place"
  pour les arrondissements départementaux ;o)
  
  
  Pour revenir sur les propositions d'aujourd'hui, je reste partisan
  du modèle par limite (boundary=*) plutôt que par surface
  (region+subarea), pour la raison invoquée hier : la capacité de
  définir le périmètre de la com'com même en l'absence des limites
  admin de certains villes constituantes. Même si, comme le dit
  justement Pieren, les regroupements dans ce cas concernent bien
  peu de communes en comparaison de ce que regroupe un département.
  Néanmoins, un autre point, déjà évoqué, est celui de la cohérence
  de modèle. Je trouve dommage de s'éparpiller sur 2 modélisations
  pour, finalement, la "même" chose (avec quelques guillemets) : la
  définition d'une zone par agrégat de communes. Je ne vois pas de
  raison majeure pour faire de 2 manières distinctes : somme de
  limites versus somme de surfaces. Et l'usage boundary=* étant un
  consensus pour les contours administratifs à l'échelle de toute la
  base OSM, je trouve que ça légitime d'autant plus de continuer
  pour la déclinaison com'com.
  
  Maintenant s'il y a consensus sur region+subarea, je
  l'appliquerai, que ce soit clair, mais bon... en grognant :-)
  


2
  autres points :
  
  - il faut prévoir la situation où l'on veut définir une com'com en
  l'absence de limites communales. Comment inclure une commune sans
  limites administatives tracées ? A priori en plaçant dans la
  relation com'com le node place=* qui représente la commune ? Le
  rôle subarea ne me plaît pas s'agissant d'un node. Peut-être
  peut-on laisser le node sans rôle ?
  
  - je vois dans l'exemple "cobaye" de Pierre Quenee ma proposition
  de tag "local_authority". Ca n'est qu'une proposition, faut-il le
  rappeler.
  
  
  vincent
  

Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee
nous a proposé, comme base de travail, l'adaptation sur un modèle
existant et Émilie à évoqué subarea en nous disant "ca ne me plait
pas mais ça existe par ailleurs".
Mis a part le modèle proposer qui reste à affiner, renommer les
tags, le compléter, il n'y a pas incohérence avec le modèle actuel
bien au contraire c'est un complément indispensable ! C'est le
modèle actuel qui nous amène à l'incohérence. Soit en hiérarchisant
de haut en bas : des éléments qui pour certains ne sont pas des
limites administratives ou des élément qui devraient être au même
niveau administratif sur des niveaux différents. Même si nous
rajoutions une numérotation de niveau a plus de 10 échelons, ce
serait faux ! Ce n'est pas parce que le modèle qui fait consensus
dans la base est limité que nous devons le reproduire bêtement à
l'infini en entrant des données dedans au chausse pied en
considérant que c'est un fourre tout. Tagguer un admin level 7 pour
une communauté de commune est une erreur si les communes sont en 8 !
Ou alors il faut compléter le modèle actuel en ajoutant des
compléments d'information pour distinguer les limites
administratives placées au même niveau.
La solution de la relation est très pratique et flexible puisqu'elle
évite d'avoir nécessairement à ressaisir les contours en incluant
les contours des communes. L'argument comment on fait s'il n'y à pas
de contours de communes ne tient pas, il faut les tracer. Personne
ne se pose la question de tracer une route sans ways ou d'indiquer
des sorties d'autoroutes sans l'autoroute. Qui plus est la relation
permet d'ajouter un contour propre à la com'com.
Le plus important même si l'on tâtonne en base est d'avoir
l'ensemble des informations cohérentes pour transtyper
automatiquement ces éléments si nécessaire dans le futur. Ca la
rel

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Vincent de Chateau-Thierry


Bonsoir,

Le 24/09/2010 22:03, Pierre-Alain Dorange a écrit :


Pieren  wrote:


En ce qui concerne les rôles : admin_center



Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur
très courante, en particulier chez les français (on se demande pourquoi ;-)


Concernant les EPCI je crois pas que admin_centre soit pertinent ; il
n'y a pas de réel centre administratif (un adresse postale c'est tout).
Aucune commune n'a d'égénomie (en théorie, car souvent c'est la ville
principale qui assume ce rôle).

Mais la relation proposée est très intéressante.


Oui, et à double titre, puisqu'elle permet de "faire la place" pour les 
arrondissements départementaux ;o)


Pour revenir sur les propositions d'aujourd'hui, je reste partisan du 
modèle par limite (boundary=*) plutôt que par surface (region+subarea), 
pour la raison invoquée hier : la capacité de définir le périmètre de la 
com'com même en l'absence des limites admin de certains villes 
constituantes. Même si, comme le dit justement Pieren, les regroupements 
dans ce cas concernent bien peu de communes en comparaison de ce que 
regroupe un département. Néanmoins, un autre point, déjà évoqué, est 
celui de la cohérence de modèle. Je trouve dommage de s'éparpiller sur 2 
modélisations pour, finalement, la "même" chose (avec quelques 
guillemets) : la définition d'une zone par agrégat de communes. Je ne 
vois pas de raison majeure pour faire de 2 manières distinctes : somme 
de limites versus somme de surfaces. Et l'usage boundary=* étant un 
consensus pour les contours administratifs à l'échelle de toute la base 
OSM, je trouve que ça légitime d'autant plus de continuer pour la 
déclinaison com'com.
Maintenant s'il y a consensus sur region+subarea, je l'appliquerai, que 
ce soit clair, mais bon... en grognant :-)


2 autres points :
- il faut prévoir la situation où l'on veut définir une com'com en 
l'absence de limites communales. Comment inclure une commune sans 
limites administatives tracées ? A priori en plaçant dans la relation 
com'com le node place=* qui représente la commune ? Le rôle subarea ne 
me plaît pas s'agissant d'un node. Peut-être peut-on laisser le node 
sans rôle ?
- je vois dans l'exemple "cobaye" de Pierre Quenee ma proposition de tag 
"local_authority". Ca n'est qu'une proposition, faut-il le rappeler.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Pierre-Alain Dorange

Pieren  wrote:

> > En ce qui concerne les rôles : admin_center
> >
> >
> Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur
> très courante, en particulier chez les français (on se demande pourquoi ;-)

Concernant les EPCI je crois pas que admin_centre soit pertinent ; il
n'y a pas de réel centre administratif (un adresse postale c'est tout).
Aucune commune n'a d'égénomie (en théorie, car souvent c'est la ville
principale qui assume ce rôle).

Mais la relation proposée est très intéressante.
-- 
Pierre-Alain Dorange
OSM experiences : 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Benoît ROUSSEAU



  
  
Le 24/09/2010 10:29, Pierre Quenee a écrit :
Bonjour,
  
  
  Merci de vos éclairages divers, parfois contradictoire mais
  néanmoins enrichissants.
  
  
  J'ai creusé le problèmes des relations et je suis tombé sur :
  
  
  http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region
  
  
  qui n'est bien sur qu'une proposition, mais qui correspond bien au
  problème posé.
  
  
  J'ai donc amendé ma proposition
  
  
  http://www.openstreetmap.org/browse/relation/1187442
  
  
  en la structurant ainsi
  
  
  type = region
  
  region_category = administrative
  
  region_type = EPCI
  
  
  (local_authority:FR:)EPCI = CC -- une labelisation à approfondir
  
  
  Citation de Vincent de Chateau-Thierry
  
  
  Je pense par ailleurs qu'on n'échappera pas à un espace de noms du
  style
  
  local_authority:FR un peu sur le modèle de school:FR si on veut
  
  introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) :
  
  "Les communautés urbaines (CU), communautés d'agglomération (CA),
  
  communautés de communes (CC), syndicats d'agglomération nouvelle
  (SAN)"
  
  
  
  ref:EPCI  = 123456789  ou 123 456 789  (forme SIRET)  le numéro
  est le même, mais le numéro SIRET fait parti de bases de données
  (infogreffe) dont les droits sont réservés ...
  
  
  admin_level=8  (Organisation horizontale avec délégués se situant
  donc sur le même niveau hiérarchique que la commune)  ou
  considérant que l'information figure déja dans chaque commune
  abandon de cette référence ?
  
  
  et dans la rubrique facultatif :
  
  
  adress = adresse postale mais aussi situation de la maison de la
  communauté distincte des Mairies.
  
  website = http://...
  
  
  En ce qui concerne les rôles : admin_center  (commune de situation
  de la maison de la communauté), et subarea (proposé par défaut
  dans JOSM)  ou subregion (proposé dans la page wiki sus
  référencés.
  
  
  Merci pour tout.
  
  
  
  
  Pour le code postal de la première version, c'était une séquelle
  de copier/coller, mais les erreurs font parfois surgir des
  suggestions tout à fait pertinentes.
  
  

Bonjour,

Ca plait bien ça. Vis à vis des précédente discussions, à première
vue, ça concilie le plus d'avantages et il me semble qu'on peut en
obtenir tout le nécessaire à un traitement utile. Ce qui suit n'est
que pinailleries positives.

Je recopie le code avec des annotations en (x)
: 

 
- 
- 
  admin_center"
/> (1)
  subarea" /> (2)
  subarea" /> 
  subarea" /> 
  subarea" /> 
  subarea" /> 
  subarea" /> 
   (3)
   
   
  

  "ref:EPCI" v="246 301 105"
/> (4)
   
   
   
  "http://www.cc-ambert.com/" /> 
  
  

(1) - Je ne suis pas certain qu'il faille
donner plus d'importance à l'une des communes. Le "admin_centre" (voir courrier Pieren et "It is British
vs Americal English issue." dans la page de proposition) laisse
supposer qu'il y a un "chef". Dans le cas des communautés de
communes, même si c'est parfois le cas dans le poids de chaque vote,
je ne crois pas que ce soit exacte et général. Je les mettrai tous
au même niveau.
(2) - Dans ce cas, pour le rôle des limites communales
  membres, je préfererai un subboundary à un subarea. Avec
un subarea, je m'attends a trouver un area en ref.
(3) - je pense qu'il faudrait quelque chose du
type "address:centre" pour indiquer l'adresse du siège. Mais je
connais pas l'usage.
(4) - je penche pour une ref INSEE en priorité et/ou
indiquer le type de source ref. dans le cas présenté, on a une
référence mais on ne sait pas à quelle nomenclature elle fait
référence donc difficile à utiliser par la suite => "ref:SIRET" v="246 301 105" /> "ref:INSEE" v="246301105" />. puisqu'on est dans une
  relation contenant je ne répèterai pas nécessairement EPCI dans la
référence.

En tous cas cette proposition offre une solution et permettrai une
évolution future vers d'autres solutions car il semble que tout y
est, tant au niveau géométrique que hiérarchique. Donc, si a
l'avenir une meilleure représentation pour traiter le pb venait à
apparaitre, un traitement automatisé permettrai la conversion. Ce
point me semble le plus important. Je pense que c'est donc une
solution plus satisfaisante que l'existant, même si ce n'est pas la
seule.

Benoît R.
  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/ta

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Emilie Laffray

2010/9/24 Pieren 

> 2010/9/24 Pierre Quenee 
>
> En ce qui concerne les rôles : admin_center
>>
>>
> Attention à la syntaxe anglaise : admin_centre (et non admin_center).
> Erreur très courante, en particulier chez les français (on se demande
> pourquoi ;-)
>

Ou chez les américains :p

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Pieren

2010/9/24 Pierre Quenee 

> En ce qui concerne les rôles : admin_center
>
>
Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur
très courante, en particulier chez les français (on se demande pourquoi ;-)

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-24 Par sujet Pieren

2010/9/23 Vincent de Chateau-Thierry 

>
> Je penche pour le recours à la même modélisation que celle utilisée pour
> les départements, à savoir une somme de ways qui forment un contour.
>
>
Attention, je n'ai pas dis que j'étais contre l'autre modélisation mais
qu'il fallait simplement utiliser des tags mieux différenciés pour éviter la
confusion (autre que "boundary" puisqu'on ne représente pas les limites
extérieures mais une liste des communes).
L'argument de dire qu'on peut compléter les relations plus vite sans avoir
toutes les communes tient moins amha pour les communautés de communes que
pour les départements (une dizaine dans le premier cas contre plusieurs
centaines dans le deuxième).

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Pierre Quenee


Bonjour,

Merci de vos éclairages divers, parfois contradictoire mais néanmoins 
enrichissants.


J'ai creusé le problèmes des relations et je suis tombé sur :

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region

qui n'est bien sur qu'une proposition, mais qui correspond bien au 
problème posé.


J'ai donc amendé ma proposition

http://www.openstreetmap.org/browse/relation/1187442

en la structurant ainsi

type = region
region_category = administrative
region_type = EPCI

(local_authority:FR:)EPCI = CC -- une labelisation à approfondir

Citation de Vincent de Chateau-Thierry

Je pense par ailleurs qu'on n'échappera pas à un espace de noms du style
local_authority:FR un peu sur le modèle de school:FR si on veut
introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) :
"Les communautés urbaines (CU), communautés d'agglomération (CA),
communautés de communes (CC), syndicats d'agglomération nouvelle (SAN)"


ref:EPCI  = 123456789  ou 123 456 789  (forme SIRET)  le numéro est le 
même, mais le numéro SIRET fait parti de bases de données (infogreffe) 
dont les droits sont réservés ...


admin_level=8  (Organisation horizontale avec délégués se situant donc 
sur le même niveau hiérarchique que la commune)  ou considérant que 
l'information figure déja dans chaque commune abandon de cette référence ?


et dans la rubrique facultatif :

adress = adresse postale mais aussi situation de la maison de la 
communauté distincte des Mairies.

website = http://...

En ce qui concerne les rôles : admin_center  (commune de situation de la 
maison de la communauté), et subarea (proposé par défaut dans JOSM)  ou 
subregion (proposé dans la page wiki sus référencés.


Merci pour tout.



Pour le code postal de la première version, c'était une séquelle de 
copier/coller, mais les erreurs font parfois surgir des suggestions tout 
à fait pertinentes.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

Le 23/09/2010 23:21, Vincent de Chateau-Thierry a écrit :
Bonsoir,

Le 23/09/2010 15:25, Benoît ROUSSEAU a écrit :

Le 23/09/2010 14:44, Pieren a écrit :

2010/9/23 Benoît ROUSSEAU

Reste à déterminer l'étiquetage ? Des propositions ?

Benoît R.

Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la

proposition actuelle:

http://www.openstreetmap.org/browse/relation/1187442

je vois quelques problèmes dont le principal est de mélanger
des

relations définissant des limites (somme de frontières
extérieures

formant une surface) avec des regroupements de communes (somme
de

surfaces) en utilisant la même famille de tags (type=boundary;

boundary=administrative). Donner un "role=relation" n'est pas

suffisament distinctif ce qui pourrait compliquer leur
exploitation

par logiciel, amha (on ne tague pas pour les logiciels mais il
faut

garder une certaine cohérence tout de même; la question s'est
déjà

posée pour les départements, régions, etc).

Je suis d'accord avec ça. Je penche pour le recours à la même
modélisation que celle utilisée pour les départements, à savoir
une somme de ways qui forment un contour. Il y a la raison de
cohérence que donne Pieren, et j'en ajouterai une autre : avoir
une somme de limites / bordures permet de définir l'emprise
complète du territoire sans disposer de tous ses constituants.
L'exemple des départements plaide pour ça : on a aujourd'hui la
définition des limites de tous les départements, tout en ayant (et
de loin :-( ) pas encore toutes les limites de communes. Si on
avait défini les départements comme des sommes de surfaces
communales, on ne saurait pas proposer un découpage départemental
complet de la France. Et encore pour un petit bout de temps...

Ok pour moi, je suis convaincu par tes
arguments => contours. En plus ecla facilite le tracé et le
rendu même si "on ne tag pas...".

Un autre problème dans

cette proposition est d'y avoir ajouter
le code postal qui se trouve

déjà dans les sous-relations. Je ne sais pas si la création de

communautés de communes implique toujours la fusion en un seul
code

postal mais les codes postaux devraient figurer dans une seule

relation à la fois pour éviter les risques d'incohérences
ultérieures.

Autant que je sache, il n'y a pas de fusion des CPs à la création
d'une communauté de communes. Et si cela arrive, ça n'est pas une
règle. En France, hormis pour quelques communes avec plusieurs
codes postaux, le niveau "commuune entière" reste le plus
pertinent pour stocker cette info. donc dans osm la relation
d'admin_level=8

Tout a fait d'accord, le type "boundary"
ne convient pas. Pour les

surfaces il y aurait "area". De même pour le code postal qui n'a
rien à

faire ici. Par contre l'INSSE donne un code EPCI pour ces
regroupement

dans le document téléchargeable ici :

http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France

Ce code pourrait être inclu.

Chouette, un nouveau ref:INSEE :-)

Il faudrait, a discuter, voir en terme de
groupement, car relation

exprime un regroupement administratif de territoires. Ce n'est
pas une

description géométrique qui est déjà définie par les limites des

communes concernées. Je ne pense donc pas qu'il faille définir
un

contour pour les communautés de communes car 1- il est
intrinsèque 2 -

les communauté de communes changes relativement rapidement.
Utiliser une

relation permet d'inclure ou d'exclure des communes facilement.

Plutôt pas d'accord (voir + haut)

Ok voir plus haut.

J'arrête le franglish => un truc
type=groupe ou groupement_administratif

seraient ils trop simples et pas assez descriptif ?>

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet Vincent de Chateau-Thierry

Bonsoir,

Le 23/09/2010 15:25, Benoît ROUSSEAU a écrit :

Le 23/09/2010 14:44, Pieren a écrit :

2010/9/23 Benoît ROUSSEAU mailto:adressepossi...@free.fr>>

Reste à déterminer l'étiquetage ? Des propositions ?
Benoît R.

Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la
proposition actuelle:
http://www.openstreetmap.org/browse/relation/1187442

Je suis d'accord avec ça. Je penche pour le recours à la même
modélisation que celle utilisée pour les départements, à savoir une
somme de ways qui forment un contour. Il y a la raison de cohérence que
donne Pieren, et j'en ajouterai une autre : avoir une somme de limites /
bordures permet de définir l'emprise complète du territoire sans
disposer de tous ses constituants. L'exemple des départements plaide
pour ça : on a aujourd'hui la définition des limites de tous les
départements, tout en ayant (et de loin :-( ) pas encore toutes les
limites de communes. Si on avait défini les départements comme des
sommes de surfaces communales, on ne saurait pas proposer un découpage
départemental complet de la France. Et encore pour un petit bout de
temps...

Un autre problème dans

cette proposition est d'y avoir ajouter le code postal qui se trouve
déjà dans les sous-relations. Je ne sais pas si la création de
communautés de communes implique toujours la fusion en un seul code
postal mais les codes postaux devraient figurer dans une seule
relation à la fois pour éviter les risques d'incohérences ultérieures.

Autant que je sache, il n'y a pas de fusion des CPs à la création d'une
communauté de communes. Et si cela arrive, ça n'est pas une règle. En
France, hormis pour quelques communes avec plusieurs codes postaux, le
niveau "commuune entière" reste le plus pertinent pour stocker cette
info. donc dans osm la relation d'admin_level=8

Tout a fait d'accord, le type "boundary" ne convient pas. Pour les
surfaces il y aurait "area". De même pour le code postal qui n'a rien à
faire ici. Par contre l'INSSE donne un code EPCI pour ces regroupement
dans le document téléchargeable ici :
http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France
.
Ce code pourrait être inclu.

Chouette, un nouveau ref:INSEE :-)

Il faudrait, a discuter, voir en terme de groupement, car relation
exprime un regroupement administratif de territoires. Ce n'est pas une
description géométrique qui est déjà définie par les limites des
communes concernées. Je ne pense donc pas qu'il faille définir un
contour pour les communautés de communes car 1- il est intrinsèque 2 -
les communauté de communes changes relativement rapidement. Utiliser une
relation permet d'inclure ou d'exclure des communes facilement.

Plutôt pas d'accord (voir + haut)

J'arrête le franglish => un truc type=groupe ou groupement_administratif
seraient ils trop simples et pas assez descriptif ?>

En modélisant le contour plutôt que la surface, je proposais hier
boundary=local_authority,
qui se traduit plus ou moins par "collectivité locale", ce qui, j'en
conviens, ne tombe pas pile sur ce qu'on veut décrire. Ce sera bien de
trouver autre chose.

Je pense par ailleurs qu'on n'échappera pas à un espace de noms du style
local_authority:FR un peu sur le modèle de school:FR si on veut
introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) :
"Les communautés urbaines (CU), communautés d'agglomération (CA),
communautés de communes (CC), syndicats d'agglomération nouvelle (SAN)"

Donc tout ça nous fait au moins 2 points à trancher : modélisation par
limites ou par surface, et vocabulaire des tags.

A vous lire,
vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

Le 23/09/2010 14:44, Pieren a écrit :

2010/9/23 Benoît ROUSSEAU

Reste à déterminer
l'étiquetage ? Des propositions ?
Benoît R.

Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la
proposition actuelle:
http://www.openstreetmap.org/browse/relation/1187442

je vois quelques problèmes dont le principal est de mélanger
des relations définissant des limites (somme de frontières
extérieures formant une surface) avec des regroupements de
communes (somme de surfaces) en utilisant la même famille de
tags (type=boundary; boundary=administrative). Donner un
"role=relation" n'est pas suffisament distinctif ce qui
pourrait compliquer leur exploitation par logiciel, amha (on
ne tague pas pour les logiciels mais il faut garder une
certaine cohérence tout de même; la question s'est déjà posée
pour les départements, régions, etc). Un autre problème dans
cette proposition est d'y avoir ajouter le code postal qui se
trouve déjà dans les sous-relations. Je ne sais pas si la
création de communautés de communes implique toujours la
fusion en un seul code postal mais les codes postaux devraient
figurer dans une seule relation à la fois pour éviter les
risques d'incohérences ultérieures.

Pieren

Tout a fait d'accord, le type "boundary" ne convient pas. Pour les
surfaces il y aurait "area". De même pour le code postal qui n'a
rien à faire ici. Par contre l'INSSE donne un code EPCI pour ces
regroupement dans le document téléchargeable ici : http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France.
Ce code pourrait être inclu.

Il faudrait, a discuter, voir en terme de groupement, car relation
exprime un regroupement administratif de territoires. Ce n'est pas
une description géométrique qui est déjà définie par les limites des
communes concernées. Je ne pense donc pas qu'il faille définir un
contour pour les communautés de communes car 1- il est intrinsèque 2
- les communauté de communes changes relativement rapidement.
Utiliser une relation permet d'inclure ou d'exclure des communes
facilement.

J'arrête le franglish => un truc type=groupe ou
groupement_administratif seraient ils trop simples et pas assez
descriptif ?

Benoît R.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet Emilie Laffray

2010/9/23 Pieren 

> 2010/9/23 Benoît ROUSSEAU 
>
>  Reste à déterminer l'étiquetage ? Des propositions ?
>> Benoît R.
>>
>>
> Je suis d'accord qu'il faut revoir l' "étiquetage".  Avec la proposition
> actuelle:
> http://www.openstreetmap.org/browse/relation/1187442
>
> je vois quelques problèmes dont le principal est de mélanger des relations
> définissant des limites (somme de frontières extérieures formant une
> surface) avec des regroupements de communes (somme de surfaces) en utilisant
> la même famille de tags  (type=boundary; boundary=administrative). Donner un
> "role=relation" n'est pas suffisament distinctif ce qui pourrait compliquer
> leur exploitation par logiciel, amha (on ne tague pas pour les logiciels
> mais il faut garder une certaine cohérence tout de même; la question s'est
> déjà posée pour les départements, régions, etc). Un autre problème dans
> cette proposition est d'y avoir ajouter le code postal qui se trouve déjà
> dans les sous-relations. Je ne sais pas si la création de communautés de
> communes implique toujours la fusion en un seul code postal mais les codes
> postaux devraient figurer dans une seule relation à la fois pour éviter les
> risques d'incohérences ultérieures.
>
>
Il faut noter que la Pologne et l'espagne utilise des relations subarea. Je
ne suis pas tres fan de cela mais cela est fait.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet Pieren

2010/9/23 Benoît ROUSSEAU 

>  Reste à déterminer l'étiquetage ? Des propositions ?
> Benoît R.
>
>
Je suis d'accord qu'il faut revoir l' "étiquetage".  Avec la proposition
actuelle:
http://www.openstreetmap.org/browse/relation/1187442

je vois quelques problèmes dont le principal est de mélanger des relations
définissant des limites (somme de frontières extérieures formant une
surface) avec des regroupements de communes (somme de surfaces) en utilisant
la même famille de tags  (type=boundary; boundary=administrative). Donner un
"role=relation" n'est pas suffisament distinctif ce qui pourrait compliquer
leur exploitation par logiciel, amha (on ne tague pas pour les logiciels
mais il faut garder une certaine cohérence tout de même; la question s'est
déjà posée pour les départements, régions, etc). Un autre problème dans
cette proposition est d'y avoir ajouter le code postal qui se trouve déjà
dans les sous-relations. Je ne sais pas si la création de communautés de
communes implique toujours la fusion en un seul code postal mais les codes
postaux devraient figurer dans une seule relation à la fois pour éviter les
risques d'incohérences ultérieures.

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)



  
  
Le 23/09/2010 13:25, Pierre-Alain Dorange a écrit :

  Pierre Quenee  wrote:


  
Est ce que le codage des Communautés de Communes peut être codé en 
relation père ?
par exemple :

http://www.openstreetmap.org/api/0.6/relation/1187442

auquel cas l'intéret d'un niveau 7 devient relatif.

En effet, si à (long) terme les communautés devait se substituer aux 
communes
l'application du même niveau 8 pour cette structure se révélerait 
pertinente.

  
  
C'est une excellente proposition.



Reste à déterminer l'étiquetage ? Des propositions ?
Benoît R.
  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-23 Par sujet g.d

Le 23 sept. 2010 à 11:23, Benoît ROUSSEAU a écrit :
> Dans ce cas on arrête les routes :p "avec le nombre de projets de déviations 
> et de constructions, ca ne sert à rien". La réforme territoriale elle se 
> fera, mais ça ne résoudra pas nos pb pour autant de prendre des décisions 
> quant à comment l'arbre. Les mêmes problèmes se poseront.
> Benoît R.

Tu as bien raison, je pense, et, comme j'écrivis, *rien* n'empêche d'y aller, 
de faire.
Juste être conscient que probablement ce sera à refaire de fond en comble d'ici 
deux ou trois ans.

Fut un temps j'avais tracé, re-tracé, re-re-re-tracé les tronçons de la A 750, 
au fur et à mesure des modif's de chantier, aux environs de Gignac, durant un 
ou deux ans, jusqu'à abandon.
Le tracé final ensuite a été dessiné sur osm par d'autres contributeurs (Merci 
à eux !).
Ce n'est qu'un exemple "local", délimité dans l'espace-temps.

Ce que je voulais dire était, 
s'attaquer à un territoire grand comme la France, pour y tracer des 
"sous-admin" desquels on sait par avance que d'ici deux, trois ans ça pourrait 
changer complètement, pourrait peut-être être un peu prématuré.
Rien n'empêche de le faire. Je n'en émets aucun "jugement", loin de moi, que 
Dieu m'en préserve.
Peut-être les cantons et circonscriptions resurgiront, mais qui sait ?

Tant que "là-haut" ça se débat avec les principes de démocratie et ses 
variantes, nous ci-bas ne sommes sûrs de rien.
Difficulté complémentaire étant, qu'un peu tout peut être déclaré 
rétroactivement, ou peut être invalidé sans que ça paraisse au JO,
ça rend difficile à savoir sur quel pied danser.

Mon souci pour osm au sujet "cantons vs communes vs agglos vs autres 
regroupements" simplement est, que nous sommes si peu d'osm'eurs, par rapport à 
la quantité de données bancales qui déjà sont dans la bdd et qui demandent 
d'être remis à l'endroit,
que je doute qu'il soit utile d'en ajouter, quand on sait que dans peu de temps 
ce sera changé.

Ça aurait sa valeur historique, valeurs irremplaçables, c'est sûr.
On en a parlé, de faire des versions historiques de la carte, mais en pratique 
on n'en est pas encore là.
(Il serait chouette, d'un jour avoir Cassini, voire Piri-Reis, dans osm... hm, 
blêmes de projection à prévoir...).

 Juste être conscient que rien n'est éternel.

Out, over, je rends l'antenne.
Gerhard.

(Post scriptum : 
L'import sans regarder les chevauchements et superpositions insensés que ça 
donne, ça commence à barber.
Dans beaucoup d'agglomérations, selon la carte osm, on rentre droit dans le 
mur. 
C'est quoi, ça ?!
Il n'est pas la quantité de données qui ferait la qualité et utiisabilité d'une 
carte.
Quand un higway:primary passe dans l'arrière-cour, et un bus-stop se retrouve 
au fond du jardin, il y a un couack.
Et ce n'est pas seulement "ponctuel", on en a dans quasi toutes le villes. Ça 
devient inquiétant. 
On aura pour des années, à rectifier ces bourdes grossières. Pitié ! 
J'abandonne.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet Pierre-Alain Dorange

Pierre Quenee  wrote:

> Est ce que le codage des Communautés de Communes peut être codé en 
> relation père ?
> par exemple :
> 
> http://www.openstreetmap.org/api/0.6/relation/1187442
> 
> auquel cas l'intéret d'un niveau 7 devient relatif.
> 
> En effet, si à (long) terme les communautés devait se substituer aux 
> communes
> l'application du même niveau 8 pour cette structure se révélerait 
> pertinente.

C'est une excellente proposition.

-- 
Pierre-Alain Dorange
OSM experiences : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet alexis gayte

+1 aussi bonne idée
Le 2010 9 23 11:26, "Benoît ROUSSEAU"  a écrit :
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)



  
  
Le 23/09/2010 09:40, Pierre Quenee a écrit :
Bonjour,
  
  Est ce que le codage des Communautés de Communes peut être codé en
  relation père ?
  
  par exemple :
  
  
  http://www.openstreetmap.org/api/0.6/relation/1187442
  
  
  auquel cas l'intéret d'un niveau 7 devient relatif.
  
  
  En effet, si à (long) terme les communautés devait se substituer
  aux communes
  
  l'application du même niveau 8 pour cette structure se révélerait
  pertinente.
  
  
  Par ailleurs j'ai cru comprendre que les outils de rendu avait des
  problèmes avec ces structures complexes, mais est ce une raison
  pour ne pas les utiliser ?
  
  
  Quelles rôles (au sens JOSM) doit t'on appliquer à chaque membre
  (Validator ne semble pas aimer les roles vides)
  
  
  Merci pour vos éclairages
  
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  




+5
L'idée de relation pour les communautés de communes, les communautés
d'agglomérations, ... est une bonne idée qui représente bien la
structure. Ca me semble cohérent. Le même niveau d'admin rend bien
compte de la situation actuelle ou ces communauté se substutuent sur
certains point de gestion, le ramassage des ordures, les transports
en commun, ...
Benoît R.
  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)



  
  
Dans ce cas on arrête les routes :p "avec le nombre de projets de
déviations et de constructions, ca ne sert à rien". La réforme
territoriale elle se fera, mais ça ne résoudra pas nos pb pour
autant de prendre des décisions quant à comment l'arbre. Les mêmes
problèmes se poseront.
Benoît R.

Le 23/09/2010 10:09, g.d a écrit :

  
me demande s'il est utile

  
  
Hm, ouaipch, probablement tu n'as pas tort...

Peut-être vaudrait-il mieux, d'attendre voir ce qui adviendra,
et s'atteler à décrire le résultat ensuite, une fois qu'ils auront décidé,

au lieu de maintenant y engager la sueur du front,
pour dans quelque temps devoir re-modifier ?
Parfois, il peut être urgent, d'attendre.

L'énergie des osm'eurs est tellement précieuse, 
et nous avons déjà tellement à faire, à re-caoutchouter les ways (and means...) suite aux imports en masse, 
à éviter que les rues traversent les maisons, éviter que l'arrêt de bus se retrouve dans l'arrière-cour, éviter que des hameaux se retrouvent dans du landuse:forest, "port du casque obligatoire" ? , il y a du boulot sur la planche...

Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empêcher qui que ce soit, de faire ce qu'il veut faire !
C'est simplement, que je trouverais triste, si de l'énergie précieuse soit engagée là où probablement dans deux, trois ans il faudra reprendre, et que personne pour l'instant encore ne sait ni quoi ni comment...
Amicalement
Gerhard
---

Le 23 sept. 2010 à 00:44, Christian Rogel a écrit :


  
Dans une discussion similaire, j'ai rappelé que l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait élu un conseiller territorial.
Il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription.

De mauvaises langues disent que la réforme sera finalement sabordée.
En attendant la fin de ce suspense, je me demande s'il est utile de s'intéresser à une bagarre canton versus communauté.

Christian

  
  


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3152 - Date: 09/22/10 08:34:00




  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-23 Par sujet g.d

> me demande s'il est utile

Hm, ouaipch, probablement tu n'as pas tort...

Peut-être vaudrait-il mieux, d'attendre voir ce qui adviendra,
et s'atteler à décrire le résultat ensuite, une fois qu'ils auront décidé,

au lieu de maintenant y engager la sueur du front,
pour dans quelque temps devoir re-modifier ?
Parfois, il peut être urgent, d'attendre.

L'énergie des osm'eurs est tellement précieuse, 
et nous avons déjà tellement à faire, à re-caoutchouter les ways (and means...) 
suite aux imports en masse, 
à éviter que les rues traversent les maisons, éviter que l'arrêt de bus se 
retrouve dans l'arrière-cour, éviter que des hameaux se retrouvent dans du 
landuse:forest, "port du casque obligatoire" ? , il y a du boulot sur la 
planche...

Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empêcher qui 
que ce soit, de faire ce qu'il veut faire !
C'est simplement, que je trouverais triste, si de l'énergie précieuse soit 
engagée là où probablement dans deux, trois ans il faudra reprendre, et que 
personne pour l'instant encore ne sait ni quoi ni comment...
Amicalement
Gerhard
---

Le 23 sept. 2010 à 00:44, Christian Rogel a écrit :

> Dans une discussion similaire, j'ai rappelé que l'actuelle réforme 
> territoriale a pour ambition de supprimer le canton et de le remplacer par un 
> territoire dans lequel serait élu un conseiller territorial.
> Il a été avancé que les communautés de communes (après des fusions 
> obligatoires après 2013) pourraient être cette circonscription.
> 
> De mauvaises langues disent que la réforme sera finalement sabordée.
> En attendant la fin de ce suspense, je me demande s'il est utile de 
> s'intéresser à une bagarre canton versus communauté.
> 
> Christian



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

2010-09-23 Par sujet Pierre Quenee


Bonjour,
Est ce que le codage des Communautés de Communes peut être codé en 
relation père ?

par exemple :

http://www.openstreetmap.org/api/0.6/relation/1187442

auquel cas l'intéret d'un niveau 7 devient relatif.

En effet, si à (long) terme les communautés devait se substituer aux 
communes
l'application du même niveau 8 pour cette structure se révélerait 
pertinente.


Par ailleurs j'ai cru comprendre que les outils de rendu avait des 
problèmes avec ces structures complexes, mais est ce une raison pour ne 
pas les utiliser ?


Quelles rôles (au sens JOSM) doit t'on appliquer à chaque membre 
(Validator ne semble pas aimer les roles vides)


Merci pour vos éclairages


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Pierre-Alain Dorange

Vincent de Chateau-Thierry
 wrote:

> Le fait est que les 2 notions (cantons et com'com) existent aujourd'hui
> et obéissent chacune à leur logique. En tant que découpages 
> géographiques, elles ont à mon sens toutes les 2 leur place dans osm dès
> lors qu'on saura (saurait) les qualifier avec des tags appropriés. Le
> début de la discussion provient justement du caractère inapproprié -à
> mon avis- de l'admin_level 7 pour les com'com. Bien les tagguer 
> permettrait de "libérer" l'admin_level 7 pour les arrondissements 
> départementaux.

+1

> Concernant les cantons, pourquoi pas les ranger eux aussi à part, en 
> utilisant le boundary=political déjà suggéré. 

Concernant les cantons je reste plus circonspect... La définition des
Arrondissements, c'est qu'ils sont composés de Cantons...
Mais je n'ai pas de solution non plus...

-- 
Pierre-Alain Dorange
OSM experiences : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)


Bonjour,

Le 23/09/2010 00:44, Christian Rogel a écrit :


Dans une discussion similaire, j'ai rappelé que l'actuelle réforme
territoriale a pour ambition de supprimer le canton et de le remplacer
par un territoire dans lequel serait élu un conseiller territorial.
Il a été avancé que les communautés de communes (après des fusions
obligatoires après 2013) pourraient être cette circonscription.

De mauvaises langues disent que la réforme sera finalement sabordée.
En attendant la fin de ce suspense, je me demande s'il est utile de
s'intéresser à une bagarre canton versus communauté.


bagarre ??

Le fait est que les 2 notions (cantons et com'com) existent aujourd'hui 
et obéissent chacune à leur logique. En tant que découpages 
géographiques, elles ont à mon sens toutes les 2 leur place dans osm dès 
lors qu'on saura (saurait) les qualifier avec des tags appropriés. Le 
début de la discussion provient justement du caractère inapproprié -à 
mon avis- de l'admin_level 7 pour les com'com. Bien les tagguer 
permettrait de "libérer" l'admin_level 7 pour les arrondissements 
départementaux.
Concernant les cantons, pourquoi pas les ranger eux aussi à part, en 
utilisant le boundary=political déjà suggéré. Il y en a 89 dans la base 
actuellement :

http://tagwatch.stoecker.eu/Planet/En/tagstats_boundary_political.html
qui semblent plutôt des initiatives individuelles qu'une démarche 
consensuelle :

http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Benoît ROUSSEAU



  
  
Le 22/09/2010 22:56, Vincent de Chateau-Thierry a écrit :

  
  
  Le 22/09/2010 21:43, Benoît ROUSSEAU a écrit :
  
    Le 22/09/2010 21:32, Benoît ROUSSEAU a
écrit :

Le 22/09/2010 20:26, Pierre-Alain
  Dorange a écrit :
  
  Vincent de Chateau-Thierry

  wrote:


Le problème, c'est que la logique
  "arborescente" des niveaux
  
  adminsitratifs en France ne colle pas avec les
  regroupements de communes
  
  types CA/CU. Rien n'empêche des communes de départements
  différents de se
  
  regrouper au sein d'une communauté.
  

En effet mais il en va un peu de même pour les cantons par
exemple.

De plus cette "logique" arborescente qui existe pour
certains

admin_level n'est pas définit (je n'en trouve pas de traces
dans le

wiki).

Certes c'est pratique etça parait logique et plus simple,
mais est-ce

une nécessité  des admin_level ?


Mais (voir mon autre message dans l'ancienne enfilade) les

intercommunalités ont aussi des caractéristiques différentes
des autres

: les représentants ne sont pasélus au suffrage direct
(maisça

pourrait changer un jour), la division ne me semble pas
administrative

(dans le sens décidé  par l'administration) ; il s'agit de
regroupement

autour de compétences.


L'autre problème c'est de placer les cantons et
arrondissement qui vont

aussi entre le département et la commune...


  
  A mon sens les cantons ne sont pas des "admin_level" au sens
  
  administratif, mais électoral. La partie administrative est le
  
  département pour les cantons, car les conseillers généraux
  siègent au
  
  Conseil général. Ce sont des représentants politiques, pas des
  des
  
  fonctionnaires dans cette fonction (même s'il peuvent l'être
  par
  
  ailleurs). C'est le Conseil général qui gère
  administrativement, selon
  
  ses prérogatives, le département dont la population est
  représentée
  
  par des élus de fractions électorales de ce territoire. Même
  si les
  
  conseillers municipaux sont élus sur des secteurs électoraux
  ont ne
  
  tag pas ces secteurs en admin_level mais on tag les quartiers
  qui n'y
  
  correspondent pas... et qui d'ailleurs ne sont pas a
  proprement parler
  
  des admin_level, sauf si les conseils de quartiers... sont
  légalement
  
  obligatoires et on un rôle administratif (je ne sais pas à
  vérifier).
  
  
  Les Sous-préfectures avec leurs arrondissements administratifs
  oui,
  
  c'est une fraction de territoire de police, avec des
  fonctionnaires. A
  
  ce titre, les Académies auraient plus leur place, en
  admin_level, que
  
  les cantons. Les Académies sont bien des fractions
  administratives de
  
  l'état, elles déterminent, par exemple, par ricoché les
  périodes de
  
  congés scolaires, l'endroit où inscrire les enfants à l'école
  
  publique, ...
  
  
  Le découpage électoral ne suit pas le découpage administratif,
  nous
  
  sommes tous d'accord. Mais c'est à mon avis une erreur de
  vouloir les
  
  intégrer au niveau d'admin_level il faudrait un découpage
  électoral à
  
  part, qui existe je crois. D'ailleurs on risque d'avoir le
  même pb à
  
  l'inverse quand on voudra monter le découpage électoral, des
  morceaux
  
  seront en admin_level, les autres en "electoral_level", ...
  
  
  Benoît R.
  

Je poursuis avec un complément...


Quant au n° de niveau administratif, vouloir "emboiter" les
niveaux

comme des poupées russes avec un seul type par niveau est une
erreur. Si

on prends Académie et préfecture (sauf erreur - mais qu'importe
pour la

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Christian Rogel

Dans une discussion similaire, j'ai rappelé que l'actuelle réforme 
territoriale a pour ambition de supprimer le canton et de le remplacer 
par un territoire dans lequel serait élu un conseiller territorial.
Il a été avancé que les communautés de communes (après des fusions 
obligatoires après 2013) pourraient être cette circonscription.


De mauvaises langues disent que la réforme sera finalement sabordée.
En attendant la fin de ce suspense, je me demande s'il est utile de 
s'intéresser à une bagarre canton versus communauté.


Christian



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)




Le 22/09/2010 23:26, Pierre-Alain Dorange a écrit :


Vincent de Chateau-Thierry
  wrote:


Il y a en effet bien plus qu'une manière de subdiviser le territoire :
Les Académies, les régions militaires, etc. Pour faire simple, je pense
qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce
qui est consultable ici :
http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp
c'est à dire la représentation imbriquée des différents niveaux de
découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki.


Pas tout à fait puisque la COG imbrique
Région>  Département>  Arrondissement>  Canton>  Commune
Les admin_level actuels (wiki) n'ont rien pour les cantons et
arrondissements.


Pour les arrondissements, on essaie justement d'y remédier :-)
Pour les cantons, ça reste comme déjà dit par Benoît un découpage à 
part. On peut avoir plusieurs communes dans un canton, mais aussi 
plusieurs cantons dans une commune, donc difficile à "ranger" de manière 
homogène.


Les intercommunalités sont probablement a gérer à part, ainsi que les
autres frontières évoqués : académie (qui n'ont qu'un sens très
restreint) ou région militaire. On peut ajouter les bassins hydrauliques
ou les massifs comme exemple géographique pur.


Reste (au moins pour les interco) à leur trouver le(s) tag(s) ad'hoc.

Est-ce que boundary=local_authority irait pour commencer ? Merci aux 
anglophones de corriger/améliorer...




Arrondissement de la Charente (COG) :
http://insee.fr/fr/methodes/nomenclatures/cog/carte_arrdep.asp?codedep=1
6
et cantons de l'arrondissement de Cognac :


Dans les exemples (de mon coin) ci-dessus de la COG on notera que le cas
des cantons nord et sud de Cognac (la vilel est coupé sur 2 cantons)
sont "évacués" sur la carte qui représentent les cantons Nord et Sud
sans inclure la ville de Cognac qui est graphiquement représenté comme
une commune à part (appartenant au 2 cantons à la fois)



vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Pierre-Alain Dorange

Vincent de Chateau-Thierry
 wrote:

> Il y a en effet bien plus qu'une manière de subdiviser le territoire :
> Les Académies, les régions militaires, etc. Pour faire simple, je pense
> qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce
> qui est consultable ici :
> http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp
> c'est à dire la représentation imbriquée des différents niveaux de 
> découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki.

Pas tout à fait puisque la COG imbrique 
Région > Département > Arrondissement > Canton > Commune

Les admin_level actuels (wiki) n'ont rien pour les cantons et
arrondissements.

Les intercommunalités sont probablement a gérer à part, ainsi que les
autres frontières évoqués : académie (qui n'ont qu'un sens très
restreint) ou région militaire. On peut ajouter les bassins hydrauliques
ou les massifs comme exemple géographique pur.

Arrondissement de la Charente (COG) :
http://insee.fr/fr/methodes/nomenclatures/cog/carte_arrdep.asp?codedep=1
6
et cantons de l'arrondissement de Cognac :


Dans les exemples (de mon coin) ci-dessus de la COG on notera que le cas
des cantons nord et sud de Cognac (la vilel est coupé sur 2 cantons)
sont "évacués" sur la carte qui représentent les cantons Nord et Sud
sans inclure la ville de Cognac qui est graphiquement représenté comme
une commune à part (appartenant au 2 cantons à la fois)

-- 
Pierre-Alain Dorange
OSM experiences : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)




Le 22/09/2010 21:43, Benoît ROUSSEAU a écrit :

  Le 22/09/2010 21:32, Benoît ROUSSEAU a écrit :

Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit :

Vincent de Chateau-Thierry
  wrote:


Le problème, c'est que la logique "arborescente" des niveaux
adminsitratifs en France ne colle pas avec les regroupements de communes
types CA/CU. Rien n'empêche des communes de départements différents de se
regrouper au sein d'une communauté.

En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique etça parait logique et plus simple, mais est-ce
une nécessité  des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pasélus au suffrage direct (maisça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé  par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...


A mon sens les cantons ne sont pas des "admin_level" au sens
administratif, mais électoral. La partie administrative est le
département pour les cantons, car les conseillers généraux siègent au
Conseil général. Ce sont des représentants politiques, pas des des
fonctionnaires dans cette fonction (même s'il peuvent l'être par
ailleurs). C'est le Conseil général qui gère administrativement, selon
ses prérogatives, le département dont la population est représentée
par des élus de fractions électorales de ce territoire. Même si les
conseillers municipaux sont élus sur des secteurs électoraux ont ne
tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y
correspondent pas... et qui d'ailleurs ne sont pas a proprement parler
des admin_level, sauf si les conseils de quartiers... sont légalement
obligatoires et on un rôle administratif (je ne sais pas à vérifier).

Les Sous-préfectures avec leurs arrondissements administratifs oui,
c'est une fraction de territoire de police, avec des fonctionnaires. A
ce titre, les Académies auraient plus leur place, en admin_level, que
les cantons. Les Académies sont bien des fractions administratives de
l'état, elles déterminent, par exemple, par ricoché les périodes de
congés scolaires, l'endroit où inscrire les enfants à l'école
publique, ...

Le découpage électoral ne suit pas le découpage administratif, nous
sommes tous d'accord. Mais c'est à mon avis une erreur de vouloir les
intégrer au niveau d'admin_level il faudrait un découpage électoral à
part, qui existe je crois. D'ailleurs on risque d'avoir le même pb à
l'inverse quand on voudra monter le découpage électoral, des morceaux
seront en admin_level, les autres en "electoral_level", ...

Benoît R.

Je poursuis avec un complément...

Quant au n° de niveau administratif, vouloir "emboiter" les niveaux
comme des poupées russes avec un seul type par niveau est une erreur. Si
on prends Académie et préfecture (sauf erreur - mais qu'importe pour la
démo) elle devrait être au même niveau, l'une est juste sous l'état
France par le Ministère de l'éducation, l'autre par le Ministère de
l'intérieur. Et il existe d'autres découpages administratifs, comme par
exemple celui des centres d'impôts, qui ne correspond à aucun autre, ...

Benoît R.


Il y a en effet bien plus qu'une manière de subdiviser le territoire : 
Les Académies, les régions militaires, etc. Pour faire simple, je pense 
qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce 
qui est consultable ici :

http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp
c'est à dire la représentation imbriquée des différents niveaux de 
découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki.
Sur le caractère arborescent, le wiki ne dit rien explicitement, en 
effet, mais il parle de "hiérarchie". La modélisation en arbre des 
différents niveaux administratifs n'est pas nouvelle dans les bases de 
données géographiques. On trouve dans les documentations des éditeurs 
commerciaux à peu près exactement la même littérature que les grands 
tableaux de la page admin_level du wiki [2] . Le but est toujours le 
même : tenter d'harmoniser à un niveau international les spécificités 
nationales, de manière à ce que des applications clientes de ces 
contenus puissent les utiliser de façon homogène d'un pays à l'autre.


vincent

[1] : http://fr.wikipedia.org/wiki/Code_officiel_g%C3%A9ographique
[2] : http://wiki.openstreetmap.org/wiki/Admin_level

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Emilie Laffray

2010/9/22 Benoît ROUSSEAU 

>  A mon sens les cantons ne sont pas des "admin_level" au sens
> administratif, mais électoral. La partie administrative est le département
> pour les cantons, car les conseillers généraux siègent au Conseil général.
> Ce sont des représentants politiques, pas des des fonctionnaires dans cette
> fonction (même s'il peuvent l'être par ailleurs). C'est le Conseil général
> qui gère administrativement, selon ses prérogatives, le département dont la
> population est représentée par des élus de fractions électorales de ce
> territoire. Même si les conseillers municipaux sont élus sur des secteurs
> électoraux ont ne tag pas ces secteurs en admin_level mais on tag les
> quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a
> proprement parler des admin_level, sauf si les conseils de quartiers... sont
> légalement obligatoires et on un rôle administratif (je ne sais pas à
> vérifier).
>
> Les Sous-préfectures avec leurs arrondissements administratifs oui, c'est
> une fraction de territoire de police, avec des fonctionnaires. A ce titre,
> les Académies auraient plus leur place, en admin_level, que les cantons. Les
> Académies sont bien des fractions administratives de l'état, elles
> déterminent, par exemple, par ricoché les périodes de congés scolaires,
> l'endroit où inscrire les enfants à l'école publique, ...
>
> Le découpage électoral ne suit pas le découpage administratif, nous sommes
> tous d'accord. Mais c'est à mon avis une erreur de vouloir les intégrer au
> niveau d'admin_level il faudrait un découpage électoral à part, qui existe
> je crois. D'ailleurs on risque d'avoir le même pb à l'inverse quand on
> voudra monter le découpage électoral, des morceaux seront en admin_level,
> les autres en "electoral_level", ...
>

boundary = political
admin_level = *

peut etre?

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Benoît ROUSSEAU



  
  
Le 22/09/2010 21:32, Benoît ROUSSEAU a écrit :

  
  Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit :
  
Vincent de Chateau-Thierry
 wrote:



  Le problème, c'est que la logique "arborescente" des niveaux
adminsitratifs en France ne colle pas avec les regroupements de communes
types CA/CU. Rien n'empêche des communes de départements différents de se
regrouper au sein d'une communauté.


En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique et ça parait logique et plus simple, mais est-ce
une nécessité des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pas élus au suffrage direct (mais ça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...


  
  A mon sens les cantons ne sont pas des "admin_level" au sens
  administratif, mais électoral. La partie administrative est le
  département pour les cantons, car les conseillers généraux siègent
  au Conseil général. Ce sont des représentants politiques, pas des
  des fonctionnaires dans cette fonction (même s'il peuvent l'être
  par ailleurs). C'est le Conseil général qui gère
  administrativement, selon ses prérogatives, le département dont la
  population est représentée par des élus de fractions électorales
  de ce territoire. Même si les conseillers municipaux sont élus sur
  des secteurs électoraux ont ne tag pas ces secteurs en admin_level
  mais on tag les quartiers qui n'y correspondent pas... et qui
  d'ailleurs ne sont pas a proprement parler des admin_level, sauf
  si les conseils de quartiers... sont légalement obligatoires et on
  un rôle administratif (je ne sais pas à vérifier).
  
  Les Sous-préfectures avec leurs arrondissements administratifs
  oui, c'est une fraction de territoire de police, avec des
  fonctionnaires. A ce titre, les Académies auraient plus leur
  place, en admin_level, que les cantons. Les Académies sont bien
  des fractions administratives de l'état, elles déterminent, par
  exemple, par ricoché les périodes de congés scolaires, l'endroit
  où inscrire les enfants à l'école publique, ...
  
  Le découpage électoral ne suit pas le découpage administratif,
  nous sommes tous d'accord. Mais c'est à mon avis une erreur de
  vouloir les intégrer au niveau d'admin_level il faudrait un
  découpage électoral à part, qui existe je crois. D'ailleurs on
  risque d'avoir le même pb à l'inverse quand on voudra monter le
  découpage électoral, des morceaux seront en admin_level, les
  autres en "electoral_level", ... 
  
  Benoît R.

Je poursuis avec un complément...

Quant au n° de niveau administratif, vouloir "emboiter" les niveaux
comme des poupées russes avec un seul type par niveau est une
erreur. Si on prends Académie et préfecture (sauf erreur - mais
qu'importe pour la démo) elle devrait être au même niveau, l'une est
juste sous l'état France par le Ministère de l'éducation, l'autre
par le Ministère de l'intérieur. Et il existe d'autres découpages
administratifs, comme par exemple celui des centres d'impôts, qui ne
correspond à aucun autre, ...

Benoît R.
  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Benoît ROUSSEAU



  
  
Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit :

  Vincent de Chateau-Thierry
 wrote:


  
Le problème, c'est que la logique "arborescente" des niveaux
adminsitratifs en France ne colle pas avec les regroupements de communes
types CA/CU. Rien n'empêche des communes de départements différents de se
regrouper au sein d'une communauté.

  
  
En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique et ça parait logique et plus simple, mais est-ce
une nécessité des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pas élus au suffrage direct (mais ça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...



A mon sens les cantons ne sont pas des "admin_level" au sens
administratif, mais électoral. La partie administrative est le
département pour les cantons, car les conseillers généraux siègent
au Conseil général. Ce sont des représentants politiques, pas des
des fonctionnaires dans cette fonction (même s'il peuvent l'être par
ailleurs). C'est le Conseil général qui gère administrativement,
selon ses prérogatives, le département dont la population est
représentée par des élus de fractions électorales de ce territoire.
Même si les conseillers municipaux sont élus sur des secteurs
électoraux ont ne tag pas ces secteurs en admin_level mais on tag
les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont
pas a proprement parler des admin_level, sauf si les conseils de
quartiers... sont légalement obligatoires et on un rôle
administratif (je ne sais pas à vérifier).

Les Sous-préfectures avec leurs arrondissements administratifs oui,
c'est une fraction de territoire de police, avec des fonctionnaires.
A ce titre, les Académies auraient plus leur place, en admin_level,
que les cantons. Les Académies sont bien des fractions
administratives de l'état, elles déterminent, par exemple, par
ricoché les périodes de congés scolaires, l'endroit où inscrire les
enfants à l'école publique, ...

Le découpage électoral ne suit pas le découpage administratif, nous
sommes tous d'accord. Mais c'est à mon avis une erreur de vouloir
les intégrer au niveau d'admin_level il faudrait un découpage
électoral à part, qui existe je crois. D'ailleurs on risque d'avoir
le même pb à l'inverse quand on voudra monter le découpage
électoral, des morceaux seront en admin_level, les autres en
"electoral_level", ... 

Benoît R.
  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Pierre-Alain Dorange

Vincent de Chateau-Thierry
 wrote:

> Le problème, c'est que la logique "arborescente" des niveaux
> adminsitratifs en France ne colle pas avec les regroupements de communes
> types CA/CU. Rien n'empêche des communes de départements différents de se
> regrouper au sein d'une communauté.

En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique et ça parait logique et plus simple, mais est-ce
une nécessité des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pas élus au suffrage direct (mais ça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...

-- 
Pierre-Alain Dorange
OSM experiences : 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)

2010-09-22 Par sujet Bruno Cortial

Le 22/09/10, Damouns  a écrit :

> > Au passage, il serait profitable de trouver une meilleure définition pour
> ces
> > communautés de communes que boundary=administrative / admin_level=7,
> histoire de pouvoir affecter cet admin_level
> > aux arrondissements départementaux (= les subdivisions départementales
> par sous-préfecture).
>
> On pourrait redéfinir les niveaux en passant les départements à
> admin_level=5, les arrondissements à : admin_level=6, et les
> communautés de communes (et CA et CU) à : admin_level=7 ? Mais
> existe-t-il des communautés de communes à cheval sur plusieurs
> arrondissements ? Comment les gérer ?


La communauté de commune CAP Atlantique (déjà dans OSM) regroupe des
communes de Loire-Atlantique et d'Ille-et-Vilaine. Pas le même département
ni la même région. Elle est taguée en admin_level=7. Si on met de côté
l'aspect hiérarchique, dans OSM ça marche ! On peut imaginer pour cette
entité remplacer admin_level un admin_struture="Communauté d'agglomération".

Wikipédia me signale également :
la communauté de communes

la communauté urbaine

le SIVU et le SIVOM

le syndicat mixte

le pays

le SICTOM
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)