Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Bonsoir,

Le 27/03/2011 12:00, Pierre-Alain Dorange a écrit :


Les cantons et arrondissement seront par contre redécoupés (cela
nécessitera des aménagements dans OSM). D'autres évolutions seront à
prévoir dans les années à venir mais on ne sait pas encore lesquelles.
C'est bien pour ça que j'aurai personnellement tendance a préférer le
modèle "" (relation de relations) qui permet des évolutions bien plus
aisées sans avoir a redéfinir les frontières lors des redécoupages.


Pour que nous puissions avancer, et profiter de cette discussion (qui 
s'étire, mes excuses) pour documenter finalement une marche à suivre sur 
le wiki, je suggère que les personnes favorables à ce modèle par 
"relations de relations" le documentent sur la page de discussion [1], 
ce qui permettra ensuite, par un vote, de choisir l'une ou l'autre des 
approches.



(...)



Coté dénomination, je suis d'avis de mettre le nom intégral pour limiter
les mélanges et éclairer les utilisateurs. SI on omet "Communes de..."
devant le nom des communes, c'est normal, c'est l'usage courant. Par
contre l'omettre devant le canton ou l'arrondissement va conduire a des
problèmes de repérage. De nombreux arrondissement portent lenom de la
commune centre, qui est aussi celui du canton et de la commune...
Comment différencier les 3 lors des rendus pour l'utilisateur final (il
faudra exploiter le type pour reconstruire le nom ?).


Oui, il faut exploiter le type pour construire un nom "étendu", typé. Tu 
parles d'utilisateurs et de rendu, et en effet l'inquiétude que tu 
soulèves est bien au niveau des applications, et des choix qu'elles font 
en exploitant le contenu. Le nommage, à notre niveau, ne concerne pas 
les applications mais la base de données, où le tag name doit stocker le 
nom, et rien que lui.


Concernant l'usage courant, il ne désigne pas forcément les communes. 
Les homonymies existent déjà entre entités de niveau différent, et ça ne 
gêne personne :

Bretagne est aussi une ville... du Territoire de Belfort :
http://www.openstreetmap.org/browse/node/290878852
Mayenne (la ville) est une ville de Mayenne (le département), Vienne 
(38) n'est pas si près que ça de Poitiers, etc. Aucun de ces cas ne 
justifie qu'on renomme la Bretagne (la région) en "Région Bretagne", la 
Vienne en "Département de la Vienne", etc. Je propose juste que les 
arrondissements fonctionnent comme tous les autres niveaux 
administratifs pour le remplissage du tag name.


vincent

[1] : 
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#EPCI


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> Les cantons et arrondissement seront par contre redécoupés (cela
> nécessitera des aménagements dans OSM). D'autres évolutions seront à
> prévoir dans les années à venir mais on ne sait pas encore lesquelles.
> C'est bien pour ça que j'aurai personnellement tendance a préférer le
> modèle "" (relation de relations) qui permet des évolutions bien plus
> aisées sans avoir a redéfinir les frontières lors des redécoupages.

Attention en ce qui concerne les cantons, ils ne représentent pas
toujours un nombre entier de communes mais peuvent être une fraction
de commune, seule, ou avec d'autres communes ou fractions. Donc pour
eux le modèle relation de relation est impossible (à moins de chercher
le plus petit dénominateur commun).

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Pierre-Alain Dorange]

Christian Rogel
 wrote:

> > Mais d'ici là, parler des cantons aujourd'hui "à titre historique",
> > entre deux tours d'élection cantonale, allons :-)
> 
> Les conseillers généraux ne sont, cette fois-ci élus que pour 3 ans.
> En 2014, les conseillers territoriaux seront élus selon un quota par 
> département qui, nulle part, ne correspond aux cantons.
> Le faire-part de ceux-ci est déjà envoyé, mais pas de précipitation...

La réforme territoriale ne prévoit pas la disparition des cantons ou des
arrondissements... Cette réforme (discuté et discutable mais c'est un
autre problème) vise à limiter le nombre d'élus.

Les cantons et arrondissement seront par contre redécoupés (cela
nécessitera des aménagements dans OSM). D'autres évolutions seront à
prévoir dans les années à venir mais on ne sait pas encore lesquelles.
C'est bien pour ça que j'aurai personnellement tendance a préférer le
modèle "" (relation de relations) qui permet des évolutions bien plus
aisées sans avoir a redéfinir les frontières lors des redécoupages.

Par ailleurs, je suis d'avis d'anticiper les usages et de prévoir tout
de suite un système de définition permettant d'inclure ce qui existe :
arrondissements, cantons, communautés de communes, urbaines, et des
autres EPCI variés (syndicats mixtes, syndicats des eaux, syndicats...).
Bien évidemment tout ça de doit pas être rendu mais pourra rendre de
grands services pour de futurs usages.

Coté dénomination, je suis d'avis de mettre le nom intégral pour limiter
les mélanges et éclairer les utilisateurs. SI on omet "Communes de..."
devant le nom des communes, c'est normal, c'est l'usage courant. Par
contre l'omettre devant le canton ou l'arrondissement va conduire a des
problèmes de repérage. De nombreux arrondissement portent lenom de la
commune centre, qui est aussi celui du canton et de la commune...
Comment différencier les 3 lors des rendus pour l'utilisateur final (il
faudra exploiter le type pour reconstruire le nom ?).

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 24/03/11 00:02, Vincent de Chateau-Thierry a écrit :


L'INSEE ajoute les syndicats d'agglomération nouvelle, les omets-tu
volontairement ?


Sur les 9 créés en 1984, 4 ont disparus et cela m'étonnerait que les 5 
restants ne se transforment pas, comme les autres,  en communauté d'agglo.



Mais d'ici là, parler des cantons aujourd'hui "à titre historique",
entre deux tours d'élection cantonale, allons :-)


Les conseillers généraux ne sont, cette fois-ci élus que pour 3 ans.
En 2014, les conseillers territoriaux seront élus selon un quota par 
département qui, nulle part, ne correspond aux cantons.

Le faire-part de ceux-ci est déjà envoyé, mais pas de précipitation...


Christian




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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 22:42, Christian Rogel a écrit :


Entendons-nous bien, je cherche à tracer la limite entre une carte où la
moindre délimitation de bassins, teritoires, micro-région de 3 hectares
serait incluse alors que seulement 30 pékins sauraient les maintenir en
opposition avec des éléments que le "citoyen lambda" ne perçoit pas,
mais dont il a besoin, au moins en arrière plan.
Le critère implicite est le fonctionnement institutionnel, dans lequel
il est personnellement impliqué, soit parce qu'il élit, soit parce qu'il
paye en le sachant (il le voit écrit sur sa feuille d'impôt).
Un autre critère est une forme de pérennité, d'où ce que je dis sur les
modifications en cours.
Dans l'état actuel des choses, les communes, les communautés de communes
(et assimilés), les départements et les régions ont des chances
raisonnables d'exister encore dans 10 ans.
Tout le reste est ou sera remanié, éventuellement en fonction des
alternances politiques.
Pieren a raison de pointer l'abus du sigle EPCI qui obscurcit le débat,
d'autant que ceux-ci peuvent avoir des objectifs et des natures très
différents.
Je propose de s'en tenir à "communauté de communes", "communautés
d'agglomération" et "communautés urbaines".
Les cantons et les arrondissements, à titre historique?

L'INSEE ajoute les syndicats d'agglomération nouvelle, les omets-tu 
volontairement  ?


Je te rejoins sur le recours au critère de pérennité. Néanmoins, je ne 
cherche pas à mapper par anticipation, en ne considérant des découpages 
qu'à la condition qu'ils soient toujours la dans x années. Ça me semble 
un horizon bien lointain à l'échelle de nos actions, a fortiori quand on 
lui rajoute un aléa dû aux alternances politiques. Le jour où cantons, 
et/ou arrondissements deviennent des découpages obsolètes, le seul 
traitement à leur réserver dans OSM, à mon avis, c'est la suppression. 
Mais d'ici là, parler des cantons aujourd'hui "à titre historique", 
entre deux tours d'élection cantonale, allons :-)


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 13:39, Vincent de Chateau-Thierry a écrit :


Je refuse de recourir au "citoyen lambda" pour cautionner ce qui doit
être mappé, et surtout ce qui ne doit pas l'être. En réduisant la base à
un dénominateur commun des intérêts de tous, on n'aurait à peu près rien
dans OSM ! On aurait, au mieux, le réseau routier, et encore.
Je vois OSM diamétralement à l'opposé de ta vision : comme la somme des
intérêts / motivations individuel(le)s de chaque mappeur. A suivre ton
raisonnement, on n'aurait pas d'objets avec un nom traduit en breton
dans la base, j'en ai peur ;-)

vincent


Entendons-nous bien, je cherche à tracer la limite entre une carte où la 
moindre délimitation de bassins, teritoires, micro-région de 3 hectares 
serait  incluse alors que seulement 30 pékins sauraient les maintenir en 
opposition avec des éléments que le "citoyen lambda" ne perçoit pas, 
mais dont il a besoin, au moins  en arrière plan.
Le critère implicite est le fonctionnement institutionnel, dans lequel 
il est personnellement impliqué, soit parce qu'il élit, soit parce qu'il 
paye en le sachant (il le voit écrit sur sa feuille d'impôt).
Un autre critère est une forme de pérennité, d'où ce que je dis sur les 
modifications en cours.
Dans l'état actuel des choses, les communes, les communautés de communes 
(et assimilés), les départements et les régions ont des chances 
raisonnables d'exister encore dans 10 ans.
Tout le reste est ou sera remanié, éventuellement en fonction des 
alternances politiques.
Pieren a raison de pointer l'abus du sigle EPCI qui obscurcit le débat, 
d'autant que ceux-ci peuvent avoir des objectifs et des natures très 
différents.
Je propose de s'en tenir à "communauté de communes", "communautés 
d'agglomération" et "communautés urbaines".

Les cantons et les arrondissements, à titre historique?
S'y ajoutent les syndicats de communes gérant les espaces naturels : 
parcs naturels régionaux.
On met aussi les espaces naturels non communaux  : parcs naturels 
nationaux, Conservatoire du littoral, réserves naturelles publiques ou 
privées, mais parce que c'est éventuellement "visitable".


Christian

Note : les autres langues que celles qu'il croit maîtriser  ne relèvent 
pas du citoyen lambda, mais de quelque chose qui le dépasse : les Droits 
de l'Homme.




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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 12:10, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 11:34 +0100, Christian Rogel a ecrit :


Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire
de ce dont il est amené à parler avec ses voisins et ses collègues.
Les EPCI en font partie , car ils lèvent l'impôt et mettent des
panneaux sur les routes.
Les autres devraient être des couches distinctes.


OK, mais puisqu'on n'a pas de "couches" dans OSM,


J'ai été trop rapide, car, dans mon esprit, je limitais les EPCI à ceux 
qui lèvent l'impôt en mettant dans une autre catégorie ceux n'ont pas de 
fiscalité votée en assemblée, c'est-à-dire ceux qui vivent de taxes 
paraficales et de redevances.
Les limites de ces EPCI de second niveau doivent être  mis dans des 
openlayers pour des besoins spécifiques, afin de créer des couches 
ayant des icônes et des polygones particuliers.
L'un des exemples les plus connus, basé sur une application avec une 
interface de saisie conviviale, est la Carte ouVerte de Rennes.

http://rennes.carte-ouverte.org/


qu'est-ce que tu entends par là _pour OSM_ ? qu'il faut s'occuper seulement des
"EPCI exclusifs", et ne pas chercher à faire un modèle générique ?


Oui, seulement des EPCI qui prennent des décisions politiques 
généralistes, comme les communautés de communes et assimilées, dont les 
conseils sont élus par des gens élus dans les communes.
Les autres EPCI, qui sont aussi élus au deuxième degré, ont en charge 
des politiques extrêmement limitées dans leur objet (maintien des 
ressources en eau, gestion d'incinérateurs, électrification, lutte 
contre les dangers naturels...) en opposition avec les compétences des 
CdC qui peuvent être l'économie, le tourisme, la voirie, parfois la 
jeunesse ou le culturel (plus les ordures ménagères qui sont obligatoires).
Il me semble que c'est aux gens intéressées par les politiques très 
spécifiques de créer ou faire créer les couches spécialisées.


Christian




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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 13:54, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 13:29 +0100, Vincent de Chateau-Thierry a ecrit :


Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases,
seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu
transposes ce damier en une comcom (une case = une commune), la
relation que tu souhaites aurait 64 membres, celle que je propose 29
(les 28 limites + un admin_centre), voire un peu plus que 29 car
certaines limites seraient scindées du fait des découpages des
communes hors comcom.


*beaucoup plus* que 29 : de nombreuses communes ont leurs limites scindées
en d'autres points qu'un changement de commune voisine :
souvent quand une limite entre communes change de "support"
(passe d'une route à une autre route, ou un cours d'eau, etc.).


Si tu traces en t'appuyant sur les routes et cours d'eau, en effet. De 
mon côté je trace toujours un way à part, quitte à reprendre des nodes 
utilisés par des routes ou rivières. D'où une plus faible inflation.





Concrètement, on a ce cas par exemple avec le département 86 : 281
communes, et seulement 178 membres dans la relation qui décrit le
contour de département.


Ton exemple est spécieux : j'ai bien expliqué ma position pour les EPCI,
pas pour les départements et régions.
Pour les départements (et encore plus les régions), les communes frontières
sont proportionnellement bien moins nombreuses que pour des EPCI.


Arf :-) Le but n'était pas de dévier, mais de montrer que la situation 
que je décrivais en théorie (le damier) se retrouve concrètement.





Donc aucune règle ne te dira combien de limites sont nécessaires en
fonction du nombre de surfaces considérées, l'argument de la
complexité d'édition ne tient pas.


D'une part, je pense qu'il tient, d'autre part dans la "complexité d'édition",
il n'y a pas que le nombre d'objets, mais aussi le fait que les objets soient
facilement compréhensibles par l'utilisateur.
Et un objet way 39078124 est largement moins facile à manipuler que
l'objet relation "MaCommune", donc plus sujet à erreurs.

Là dessus, je ne te rejoins pas. Manipuler des relations de relations, 
je trouve ça plus compliqué / plus abstrait que manipuler des relations 
de ways "bruts".




Tout comme un département, voire une région ou un pays. Tous ces
niveaux peuvent être définis par une accumulation de communes, ça
n'empêche pas le modèle actuel (par limites) de fonctionner.


Ah, on tourne en rond dans l'argumentation là.


:-)


Je ne dis pas que le modèle actuel ne fonctionne pas, au contraire.
Je dis que dans le cas des EPCI on peut trouver un meilleur modèle, plus 
"moderne"
et que ça vaut le coup d'essayer pour simplifier la tâche des utilisateurs
qui vont se charger de la saisie.


Ok, je comprends cette motivation (simplifier la tâche), en revanche je 
trouve plus compliqué ce que tu trouve plus simple (voir ci-dessus).



Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité
propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs
à la fois. Il n'y a pas, que je sache, d'opposition particulière à
mapper les autres EPCIs, il manque juste des "porteurs" pour le
sujet, bref avis aux motivés : imaginer le modèle géométrique, le
modèle de tags, discuter le tout... yapluka :-)


Ben voilà, on y est : la proposition de relation de relations-communes
(ou somme de surfaces) a le mérite d'avoir un seul modèle applicable à
tous les EPCI (donc à fiscalité propre ou pas).


Le modèle par limites est tout autant applicable. Ce débat sur le modèle 
géométrique, encore une fois, est récurrent, et les deux façons 
(surfaces vs limites) permettent grosso-modo d'arriver aux mêmes fins. 
Mon "yapluka" s'applique surtout au choix des tags pour décrire un SIVOM 
ou autre. Les tags existants suffisent-ils ? Les valeurs existantes ? 
Que faut-il créer comme nouveaux tags, nouvelles valeurs ? C'est à mon 
avis sur ce point que la discussion doit explorer.


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 13:29 +0100, Vincent de Chateau-Thierry a ecrit :
> 
> 
> Le 23/03/2011 10:47, Guillaume Allegre a écrit :
> >
> >Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :
> >>>L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> >>>facile de les éditer,
> >>>puisqu'elles regrouperaient :
> >>>- des objets moins nombreux et de plus haut niveau
> 
> Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases,
> seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu
> transposes ce damier en une comcom (une case = une commune), la
> relation que tu souhaites aurait 64 membres, celle que je propose 29
> (les 28 limites + un admin_centre), voire un peu plus que 29 car
> certaines limites seraient scindées du fait des découpages des
> communes hors comcom.

*beaucoup plus* que 29 : de nombreuses communes ont leurs limites scindées
en d'autres points qu'un changement de commune voisine :
souvent quand une limite entre communes change de "support"
(passe d'une route à une autre route, ou un cours d'eau, etc.).


> Concrètement, on a ce cas par exemple avec le département 86 : 281
> communes, et seulement 178 membres dans la relation qui décrit le
> contour de département.

Ton exemple est spécieux : j'ai bien expliqué ma position pour les EPCI,
pas pour les départements et régions.
Pour les départements (et encore plus les régions), les communes frontières
sont proportionnellement bien moins nombreuses que pour des EPCI.


> Donc aucune règle ne te dira combien de limites sont nécessaires en
> fonction du nombre de surfaces considérées, l'argument de la
> complexité d'édition ne tient pas.

D'une part, je pense qu'il tient, d'autre part dans la "complexité d'édition",
il n'y a pas que le nombre d'objets, mais aussi le fait que les objets soient
facilement compréhensibles par l'utilisateur.
Et un objet way 39078124 est largement moins facile à manipuler que 
l'objet relation "MaCommune", donc plus sujet à erreurs.




> >>>- les données "naturelles" dans ce contexte : une ComCom est toujours 
> >>>définie par la liste
> >>>des communes adhérentes, pas par ses limites
> 
> Tout comme un département, voire une région ou un pays. Tous ces
> niveaux peuvent être définis par une accumulation de communes, ça
> n'empêche pas le modèle actuel (par limites) de fonctionner.

Ah, on tourne en rond dans l'argumentation là.
Je ne dis pas que le modèle actuel ne fonctionne pas, au contraire.
Je dis que dans le cas des EPCI on peut trouver un meilleur modèle, plus 
"moderne"
et que ça vaut le coup d'essayer pour simplifier la tâche des utilisateurs
qui vont se charger de la saisie.


> >Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
> >englober des syndicats de communes, comme les syndicats de gestion des cours
> >d'eau, etc. qui ne sont pas exclusifs.
> >À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
> >exclusifs uniquement, mais je n'en ai pas le souvenir.
> >
> Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité
> propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs
> à la fois. Il n'y a pas, que je sache, d'opposition particulière à
> mapper les autres EPCIs, il manque juste des "porteurs" pour le
> sujet, bref avis aux motivés : imaginer le modèle géométrique, le
> modèle de tags, discuter le tout... yapluka :-)

Ben voilà, on y est : la proposition de relation de relations-communes
(ou somme de surfaces) a le mérite d'avoir un seul modèle applicable à
tous les EPCI (donc à fiscalité propre ou pas).



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 11:34, Christian Rogel a écrit :



Comme je l'ai déjà souligné, les structures administratives de la France
sont en plein bouleversement.
Une loi sur la fusion des postes de conseillers généraux et de
conseillers régionaux vient d'être votée et elle appelle d'autres
modifications comme la suppression des cantons et probablement celle des
arrondissements..
Les syndicats locaux d'électrification devraient être fusionnés en un
seul syndicat départemental.
La prochaine élection présidentielle peut apporter encore d'autres
changements.
Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce
dont il est amené à parler avec ses voisins et ses collègues.


Je refuse de recourir au "citoyen lambda" pour cautionner ce qui doit 
être mappé, et surtout ce qui ne doit pas l'être. En réduisant la base à 
un dénominateur commun des intérêts de tous, on n'aurait à peu près rien 
dans OSM ! On aurait, au mieux, le réseau routier, et encore.
Je vois OSM diamétralement à l'opposé de ta vision : comme la somme des 
intérêts / motivations individuel(le)s de chaque mappeur. A suivre ton 
raisonnement, on n'aurait pas d'objets avec un nom traduit en breton 
dans la base, j'en ai peur ;-)


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 10:47, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :

L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
facile de les éditer,
puisqu'elles regrouperaient :
- des objets moins nombreux et de plus haut niveau


Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases, 
seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu 
transposes ce damier en une comcom (une case = une commune), la relation 
que tu souhaites aurait 64 membres, celle que je propose 29 (les 28 
limites + un admin_centre), voire un peu plus que 29 car certaines 
limites seraient scindées du fait des découpages des communes hors comcom.
Concrètement, on a ce cas par exemple avec le département 86 : 281 
communes, et seulement 178 membres dans la relation qui décrit le 
contour de département.
Donc aucune règle ne te dira combien de limites sont nécessaires en 
fonction du nombre de surfaces considérées, l'argument de la complexité 
d'édition ne tient pas.



- les données "naturelles" dans ce contexte : une ComCom est toujours définie 
par la liste
des communes adhérentes, pas par ses limites


Tout comme un département, voire une région ou un pays. Tous ces niveaux 
peuvent être définis par une accumulation de communes, ça n'empêche pas 
le modèle actuel (par limites) de fonctionner.




Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
donnent pour chaque EPCI la liste de ses communes. En outre, les
relations de relation, c'est encore mal géré par les outils autour
d'OSM (mais bon, ça c'est un problème d'outil).


+1



Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.

Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité 
propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs à la 
fois. Il n'y a pas, que je sache, d'opposition particulière à mapper les 
autres EPCIs, il manque juste des "porteurs" pour le sujet, bref avis 
aux motivés : imaginer le modèle géométrique, le modèle de tags, 
discuter le tout... yapluka :-)


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Pieren]

2011/3/23 Christian Rogel 

> Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce dont
> il est amené à parler avec ses voisins et ses collègues.
> Les EPCI en font partie
>
>
Euh, on doit pas avoir la même idée du citoyen lambda alors. Même si tout le
monde a une vague idée de ce que veut dire 'communauté de
communes/agglomérations/urbaines', la plutpart ne savent pas que ça
s'appelle "EPCI" et quelles en sont les compétences.

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 11:34 +0100, Christian Rogel a ecrit :

> Donc :
> - Ne pas s'inquiéter de limites à vocation éphémère
> - Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire
> de ce dont il est amené à parler avec ses voisins et ses collègues.
> Les EPCI en font partie , car ils lèvent l'impôt et mettent des
> panneaux sur les routes.
> Les autres devraient être des couches distinctes.

OK, mais puisqu'on n'a pas de "couches" dans OSM, 
qu'est-ce que tu entends par là _pour OSM_ ? qu'il faut s'occuper seulement des 
"EPCI exclusifs", et ne pas chercher à faire un modèle générique ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 10:47, Guillaume Allegre a écrit :


Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.



Comme je l'ai déjà souligné, les structures administratives de la France 
sont en plein bouleversement.
Une loi sur la fusion des postes de conseillers généraux et de 
conseillers régionaux vient d'être votée et elle appelle d'autres 
modifications comme la suppression des cantons et probablement celle des 
arrondissements..
Les syndicats locaux d'électrification devraient être fusionnés en un 
seul syndicat départemental.
La prochaine élection présidentielle peut apporter encore d'autres 
changements.

Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce 
dont il est amené à parler avec ses voisins et ses collègues.
Les EPCI en font partie , car ils lèvent l'impôt et mettent des panneaux 
sur les routes.

Les autres devraient être des couches distinctes.

Christian





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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :
> > L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> > facile de les éditer,
> > puisqu'elles regrouperaient :
> > - des objets moins nombreux et de plus haut niveau
> > - les données "naturelles" dans ce contexte : une ComCom est toujours 
> > définie par la liste
> > des communes adhérentes, pas par ses limites
> 
> Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
> aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
> donnent pour chaque EPCI la liste de ses communes. En outre, les
> relations de relation, c'est encore mal géré par les outils autour
> d'OSM (mais bon, ça c'est un problème d'outil).

Ben ça c'est un argument qu'on pourrait appliquer à d'autres objets qui sont
déjà dans la base : repères géodésiques, CLC, etc.
La valeur ajoutée reste la même : faire apparaître les EPCIS dans le rendu OSM
(par limites ou par surfaces ;-)


> Autre argument : dans la page "Relations are not Categories" [1] on a
> la consigne suivante : "Les relations de groupement n'ont de sens que
> quand la relation n'est ni géographique, ni exclusive". Or dans ce
> cas, elle est exclusive (si on se limite aux EPCI à fiscalité propre).

Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> facile de les éditer,
> puisqu'elles regrouperaient :
> - des objets moins nombreux et de plus haut niveau
> - les données "naturelles" dans ce contexte : une ComCom est toujours définie 
> par la liste
> des communes adhérentes, pas par ses limites

Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
donnent pour chaque EPCI la liste de ses communes. En outre, les
relations de relation, c'est encore mal géré par les outils autour
d'OSM (mais bon, ça c'est un problème d'outil).

Autre argument : dans la page "Relations are not Categories" [1] on a
la consigne suivante : "Les relations de groupement n'ont de sens que
quand la relation n'est ni géographique, ni exclusive". Or dans ce
cas, elle est exclusive (si on se limite aux EPCI à fiscalité propre).
Donc il suffirait d'un tag epci=Communauté de communes de Parthenay
(ou epci=Parthenay ;-P ) pour pouvoir retrouver les communes de chaque
EPCI.

[1] http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le lun. 21 mars 2011 à 23:44 +0100, Vincent de Chateau-Thierry a ecrit :
> Bonsoir,
> - le modèle "somme de surface" et le modèle "somme de limites" ont
> chacun leurs avantages
> - le modèle que je pousse pour les EPCIs (somme de limites) permet
> de tracer les emprises d'EPCIs comme on trace aujourd'hui les
> emprises de communes, cantons [2], arrondissements, départements et
> régions : en regroupant dans une relation leurs limites pour former
> un contour fermé : ça donne une homogénéité à l'ensemble puisque ces
> différents découpages partent de la même unité : la commune. C'est
> pour moi le principal argument : la cohérence de modélisation des
> différents découpages,
> - le modèle par limites est déja utilisé pour les EPCIs qui
> recourent a tag admin_level=7 : la transition vers un nouveau modèle
> par limites est directe et simple
> - le modèle par limites permet de définir des zones sans forcément
> disposer de toutes les emprises qui les constituent, à l'inverse du
> modèle par surfaces, qui nécessite que toutes les surfaces (des
> communes) constituantes soient présentes, faute de quoi on forme des
> surfaces d'EPCIs trouées. En l'état de la couverture en limites
> communales (~70%) le modèle par somme de surfaces pénaliserait pas
> mal de territoires. Appliqué aux départements, voire (pire !) aux
> régions, il donnerait une France metropolitaine pleine de vide.

Je comprends bien les arguments que tu donnes, mais ils se résument à deux
objectifs :
- compatibilité avec la situation actuelle (admin_level = 7)
  et les conventions antérieures (modèle admin_level hiérarchique : 4, 6, 8)
- éviter des trous temporaires

Il me semble que l'idée des admin_level hiérarchiques dans OSM est antérieure à 
l'apparition
des relations, et que donc "on n'avait que ça" à l'époque.
À l'inverse, si on réfléchit pour le futur, on peut essayer de repartir sur des 
bases
différentes, puisque la solution "conservatrice" (admin_level=7) n'est 
clairement
pas satisfaisante.

L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
facile de les éditer,
puisqu'elles regrouperaient :
- des objets moins nombreux et de plus haut niveau
- les données "naturelles" dans ce contexte : une ComCom est toujours définie 
par la liste
des communes adhérentes, pas par ses limites

Je ne préconise pas de "faire la révolution" pour les départements et les 
régions en les 
passant à une relation de communes, mais plutôt de roder ce nouveau modèle 
uniquement pour 
les EPCIs dans un premier temps.



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent Pottier]

Le 23/03/2011 08:42, Damouns a écrit :

Je suis aussi d'avis de ne mettre le nom de l'arrondissement sans «
Arrondissement de » dans le tag name. Et idem pour les cantons. On le fait
déjà pour les communes et pourtant il y a bien une différence entre une
ville et sa commune. Mais les données permettent de savoir à quel type
d'objet on a affaire.

S'il y a une majorité pour, je suis prêt à m'incliner ! Y a-t-il
d'autres avis en faveur du nom avec "Arrondissement de " ? Apparemment
on n'est que 2 !

Damouns

+1
--
FrViPofm

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> Je suis aussi d'avis de ne mettre le nom de l'arrondissement sans «
> Arrondissement de » dans le tag name. Et idem pour les cantons. On le fait
> déjà pour les communes et pourtant il y a bien une différence entre une
> ville et sa commune. Mais les données permettent de savoir à quel type
> d'objet on a affaire.

S'il y a une majorité pour, je suis prêt à m'incliner ! Y a-t-il
d'autres avis en faveur du nom avec "Arrondissement de " ? Apparemment
on n'est que 2 !

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Thomas Petillon]

Le 22/03/2011 09:27, Vincent de Chateau-Thierry a écrit :

Le 22/03/2011 00:04, Thomas Petillon a écrit :

Donne-t-on un admin_centre aux arrondissement ? À première vue c'est un
élément important de leur définition. (Rien que par leur nom.) Ceci dit,
admin_centre est utilisé pour donner un point de centre aux relations
des communes ; pour les relations de plus haut niveau le centre est
lui-même une commune, donc c'est peut-être un autre tag qui
conviendrait. (Et rien n'a l'air d'être défini pour les niveaux
administratifs 6 et 4 jusqu'à présent.)

Je n'ai pas de chiffres, mais admin_centre est utilisé pour indiquer le
chef-lieu de plusieurs départements, par exemple Orléans pour le Loiret :
http://www.openstreetmap.org/browse/node/26686508

Je trouverais intéressant de propager (généraliser ?) l'usage du node avec
role admin_centre pour les chef-lieux de départements et régions.
Dans le même sens, les 3 arrondissements du 92 que j'ai modélisé ont chacun un 
node
admin_centre :
http://www.openstreetmap.org/browse/relation/1457524
http://www.openstreetmap.org/browse/relation/1457525
http://www.openstreetmap.org/browse/relation/1457526


Toujours à propos des arrondissements, on-t-ils un réel nom, outre le
fait d'être appelés par le nom de leur chef-lieu ?

J'ai vu quelques exceptions avec les noms d'arrondissements suivants :
Metz-Campagne
Thionville-Est
Thionville-Ouest
Metz-Ville
Château-Chinon (Ville)
Strasbourg-Campagne
Strasbourg-Ville

pour lesquel un tag name=* semble inévitable, on ne peut pas déduire le
nom de l'arrondissement du nom de son chef-lieu. Du coup par souci
d'homogénéité du modèle, peut-être faudrait-il propager l'usage du tag name
sur tous les arrondissements ? Par défaut, ce tag aurait le nom de l'emprise
admin_level=8 où se situe le node admin_centre (= le chef-lieu). Des avis ?

Pour Château-Chinon (Ville) ce n'est pas une exception, la commune porte 
le même nom. Pour les autres, issus des anciens Kreise, effectivement on 
est bien face à un vrai nom.
Je suis aussi d'avis de ne mettre le nom de l'arrondissement sans « 
Arrondissement de » dans le tag name. Et idem pour les cantons. On le 
fait déjà pour les communes et pourtant il y a bien une différence entre 
une ville et sa commune. Mais les données permettent de savoir à quel 
type d'objet on a affaire.
On est dans le même cas que pour les gares je pense : on dit souvent « 
gare de X », mais le « gare de » ne fait pas réellement partie du nom, 
et n'apparaît pas sur les panneaux en bord de voie par exemple.



Si tout le monde est d'accord, il ne manque plus qu'un rendu de la part
de Sylvain sur beta. ;)

Tu veux dire pour les EPCIs ? Je vote pour :-)
Oui, je parlais des EPCIs. Un joli rendu avec des couleurs différentes 
suivant le type d'EPCI ça serait pratique. :)


Thomas.

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

> De : "Damouns" 
> 
> @Vincent :
> > Avoir le nom séparé de son type permet de former un nom complet
> > en associant le nom propre ("Parthenay") à la traduction de "canton" ou 
"arrondissement"
> > dans la langue de présentation
> 
> Alors dans ce cas que proposez-vous pour les lycées par exemple ? De
> mettre juste name = Louis Pasteur ? L'usage a montré que les noms
> contiennent souvent le type de l'objet. Ce n'est pas tagguer pour le
> rendu, c'est tagguer pour montrer l'usage local, ce qui est "écrit sur
> le panneau". Si on veut, après l'auteur d'une application de rendu
> multilingue recherchera le terme Lycée et le remplacera par ce qu'il
> veut (bon courage !).

Oui, bon courage. Les succès d'OSM ne sont pas que dans le nombre de 
contributions,
ils se mesurent aussi au travers de l'usage de la base par tout un chacun. En 
compléxifiant l'usage avec ce genre de mélange, on n'encourage pas la 
réutilisation de la
base. Je trouverais ça dommage.

Tu choisis l'exemple des Lycées, qui n'a pas trop de rapport avec les 
arrondissements. 
Tu aurais pu choisir les musées, ou les bibliothèques, qui fonctionnent souvent 
pour leur
nom comme tu le décris, avec inclusion du nom commun dans le nom d'usage (même 
si on va
"au Louvre" au moins autant qu'au "Musée du Louvre"). Mais on pourrait aussi 
choisir
comme exemples les restaurants, où bien souvent les mots "restaurant", sans 
parler de
"fast-food", sont absents. Par exemple, si tu regardes les noms des restaurants 
& 
fast-foods par ici :
http://www.openstreetmap.org/?lat=48.84012&lon=2.2436&zoom=17&layers=M
tu verras rarement (voire jamais) le mot "restaurant", mais bien le mots 
"École" (à 
défaut de Lycée). 

Bref, ça n'est pas parce que les lycées ont "Lycée" dans leur nom propre que je 
mettrai
"arrondissement de" dans le nom propre d'un admin_level 7, les fonctionnements 
ne 
m’apparaissent pas corrélés. De plus, dans le cas des entités administratives 
en France,
on a la chance d'avoir un référentiel (le COG). C'est dommage de le contredire 
à ce 
point, je trouve, sur des aspects où il est sans ambiguïté. Après, qu'on ajoute 
un nom
d'usage dans un alt_name, avec "arrondissement de xxx", "canton de yyy", 
pourquoi pas.

> @Vlad :
> > En ce qui concerne les recherches, Nominatim (autre référence) affiche 
> > clairement le 
type de chaque résultat
> 
> Chez moi Nominatim indique "Parthenay, Deux-Sèvres, Poitou-Charentes,
> 79200, France (Administrative) (details)" pour le contour d'une
> relation administrative, donc je ne peux pas savoir s'il s'agit de la
> commune de Parthenay ou de l'arrondissement de Parthenay (en admettant
> que cantons et EPCI ne sont pas des relations administratives). Mais
> bon, j'admets que c'est un problème de l'outil.
> 

Un problème de l'outil (donc de rendu), là-dessus, on est d'accord :-)

vincent



Laposte.net, Messager Officiel du Rallye des Gazelles 2011, Pour suivre le 
Rallye Aicha des Gazelles et soutenir les participantes,
cliquez ici   http://www.laposte.net/rallye-des-gazelles


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mar. 22 mars 2011 à 12:52 +0100, Damouns a ecrit :

> Pour moi c'est nécessaire de préciser qu'il s'agit du "canton de
> Parthenay", de l'"arrondissement de Parthenay", de la "communauté de
> communes de Parthenay", parce que quand on parle de "Parthenay" dans
> le langage courant hors contexte il est évident qu'il s'agit de la
> commune (ou du bourg central de la commune). "J'habite à Parthenay".

+1


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

@Pieren :
> Alors tu as mis "Commune de.." dans les names de toutes tes relations
> admin_level 8 ?

Non, car comme je l'ai dit, selon moi dire le nom sans "Commune de"
dans le langage courant suffit pour comprendre qu'on parle de la
commune. Quand on parle de l'arrondissement, on sous-entend
"l'arrondissement *de la commune* de Parthenay".

@Vlad :
> Dites c'est pas cela que l'on désigne par tagguer pour le rendu ? ;)

@Vincent :
> Avoir le nom séparé de son type permet de former un nom complet
> en associant le nom propre ("Parthenay") à la traduction de "canton" ou 
> "arrondissement"
> dans la langue de présentation

Alors dans ce cas que proposez-vous pour les lycées par exemple ? De
mettre juste name = Louis Pasteur ? L'usage a montré que les noms
contiennent souvent le type de l'objet. Ce n'est pas tagguer pour le
rendu, c'est tagguer pour montrer l'usage local, ce qui est "écrit sur
le panneau". Si on veut, après l'auteur d'une application de rendu
multilingue recherchera le terme Lycée et le remplacera par ce qu'il
veut (bon courage !).

@Vlad :
> En ce qui concerne les recherches, Nominatim (autre référence) affiche 
> clairement le type de chaque résultat

Chez moi Nominatim indique "Parthenay, Deux-Sèvres, Poitou-Charentes,
79200, France (Administrative) (details)" pour le contour d'une
relation administrative, donc je ne peux pas savoir s'il s'agit de la
commune de Parthenay ou de l'arrondissement de Parthenay (en admettant
que cantons et EPCI ne sont pas des relations administratives). Mais
bon, j'admets que c'est un problème de l'outil.

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Pieren]

2011/3/22 Damouns 

>
> Indiquer ça dans le name permet de clarifier les choses lorsqu'on fait
> un recherche : on voir tout de suite que ce sont des choses
> différentes sans pour autant devoir aller dans les sous-tags comme
> l'admin_level.
>
>
>
Alors tu as mis "Commune de.." dans les names de toutes tes relations
admin_level 8 ?

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vladimir Vyskocil]

Le 22 mars 2011 à 12:52, Damouns  a écrit :

>>> Moi je mettrais plutôt "Arrondissement de ..." plutôt que juste le nom
>>> du node admin_centre. Comme pour les titre des articles wikipédia.
>>> Mais c'est peut-être ce que tu voulais dire.
>> 
>> Non, je parlais bien du seul nom, celui de la commune chef-lieu, sans 
>> précision de
>> la nature de la limite administrative. Comme référence ici, je regarde ce 
>> qui dit l'INSEE
>> dans le COG, par exemple ici pour le Loiret [1]. De la même manière, on ne 
>> met pas
>> "Ville de " devant les noms d'admin_level=8, je trouve ça cohérent. Comme je 
>> vois que tu
>> as appliqué "Canton de xxx" sur les noms de cantons du Doubs, eh bien... 
>> parlons-en :-)
> 
> Pour moi c'est nécessaire de préciser qu'il s'agit du "canton de
> Parthenay", de l'"arrondissement de Parthenay", de la "communauté de
> communes de Parthenay", parce que quand on parle de "Parthenay" dans
> le langage courant hors contexte il est évident qu'il s'agit de la
> commune (ou du bourg central de la commune). "J'habite à Parthenay".
> 
> Indiquer ça dans le name permet de clarifier les choses lorsqu'on fait
> un recherche : on voir tout de suite que ce sont des choses
> différentes sans pour autant devoir aller dans les sous-tags comme
> l'admin_level.
> 
> Damouns
> 

Dites c'est pas cela que l'on désigne par tagguer pour le rendu ? ;)
Bon c'est vrai que le rendu de "référence" ne facilite pas les choses, il en 
montre soit trop soit pas assez et il ne pourra pas convenir a tout le monde 
alors on s'adapte a lui...
En ce qui concerne les recherches, Nominatim (autre référence) affiche 
clairement le type de chaque résultat et on peut faire la différence entre une 
ville et une limite administrative par exemple, même si le nom est identique. 

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

> De : "Damouns" 
> 
> > Pour moi c'est nécessaire de préciser qu'il s'agit du "canton de
> > Parthenay", de l'"arrondissement de Parthenay", de la "communauté de
> > communes de Parthenay", parce que quand on parle de "Parthenay" dans
> > le langage courant hors contexte il est évident qu'il s'agit de la
> > commune (ou du bourg central de la commune). "J'habite à Parthenay".
> >
> > Indiquer ça dans le name permet de clarifier les choses lorsqu'on fait
> > un recherche : on voir tout de suite que ce sont des choses
> > différentes sans pour autant devoir aller dans les sous-tags comme
> > l'admin_level.
> 
> Pour en rajouter une couche, pour un lycée, en plus de amenity=school,
> school:FR=lycée, on ne met pas name=Louis Pasteur mais bien name=Lycée
> Louis Pasteur. C'est le nom utilisé pour désigner cet endroit dans le
> langage courant.
> 

Je distingue 2 choses. Pour restituer l'information, dans une application (une 
carte,
une appli de guidage, etc.), je suis d'accord avec toi, si on ne précise pas la 
nature de
l'emprise, on évoque implicitement, dans le langage courant, celle de la 
commune, et pas
celle du canton ou de l'arrondissement. Dans ce contexte, si on veut parler du 
canton ou
de l'arrondissement, il faut que l'application qui rend l'info associe le type 
(déduit de
la valeur d'admin_level) et le nom stocké dans name.

En revanche pour ce qui est du stockage de l'information dans OSM (= ce pour 
quoi on
discute ici), ça me semble important de dissocier type et nom. Si le nom du 
canton est
"Partenay", dixit le COG, je préfère connaître ce nom d'un côté, et le type de 
découpage
de l'autre. Libre à moi en tant qu'auteur d'une application de rendu de 
concaténer les
deux infos. 
Ça prend une dimension supplémentaire si tu penses à une application avec 
plusieurs
langues d'interface. Avoir le nom séparé de son type permet de former un nom 
complet 
en associant le nom propre ("Parthenay") à la traduction de "canton" ou 
"arrondissement"
dans la langue de présentation.

vincent

Laposte.net, Messager Officiel du Rallye des Gazelles 2011, Pour suivre le 
Rallye Aicha des Gazelles et soutenir les participantes,
cliquez ici   http://www.laposte.net/rallye-des-gazelles


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> Pour moi c'est nécessaire de préciser qu'il s'agit du "canton de
> Parthenay", de l'"arrondissement de Parthenay", de la "communauté de
> communes de Parthenay", parce que quand on parle de "Parthenay" dans
> le langage courant hors contexte il est évident qu'il s'agit de la
> commune (ou du bourg central de la commune). "J'habite à Parthenay".
>
> Indiquer ça dans le name permet de clarifier les choses lorsqu'on fait
> un recherche : on voir tout de suite que ce sont des choses
> différentes sans pour autant devoir aller dans les sous-tags comme
> l'admin_level.

Pour en rajouter une couche, pour un lycée, en plus de amenity=school,
school:FR=lycée, on ne met pas name=Louis Pasteur mais bien name=Lycée
Louis Pasteur. C'est le nom utilisé pour désigner cet endroit dans le
langage courant.

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

>> Moi je mettrais plutôt "Arrondissement de ..." plutôt que juste le nom
>> du node admin_centre. Comme pour les titre des articles wikipédia.
>> Mais c'est peut-être ce que tu voulais dire.
>
> Non, je parlais bien du seul nom, celui de la commune chef-lieu, sans 
> précision de
> la nature de la limite administrative. Comme référence ici, je regarde ce qui 
> dit l'INSEE
> dans le COG, par exemple ici pour le Loiret [1]. De la même manière, on ne 
> met pas
> "Ville de " devant les noms d'admin_level=8, je trouve ça cohérent. Comme je 
> vois que tu
> as appliqué "Canton de xxx" sur les noms de cantons du Doubs, eh bien... 
> parlons-en :-)

Pour moi c'est nécessaire de préciser qu'il s'agit du "canton de
Parthenay", de l'"arrondissement de Parthenay", de la "communauté de
communes de Parthenay", parce que quand on parle de "Parthenay" dans
le langage courant hors contexte il est évident qu'il s'agit de la
commune (ou du bourg central de la commune). "J'habite à Parthenay".

Indiquer ça dans le name permet de clarifier les choses lorsqu'on fait
un recherche : on voir tout de suite que ce sont des choses
différentes sans pour autant devoir aller dans les sous-tags comme
l'admin_level.

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

> De : "Damouns" 
> 
> > Par défaut, ce tag aurait le nom de l'emprise admin_level=8 où se situe
> > le node admin_centre (= le chef-lieu). Des avis ?
> 
> Moi je mettrais plutôt "Arrondissement de ..." plutôt que juste le nom
> du node admin_centre. Comme pour les titre des articles wikipédia.
> Mais c'est peut-être ce que tu voulais dire.
> 

Non, je parlais bien du seul nom, celui de la commune chef-lieu, sans précision 
de
la nature de la limite administrative. Comme référence ici, je regarde ce qui 
dit l'INSEE 
dans le COG, par exemple ici pour le Loiret [1]. De la même manière, on ne met 
pas 
"Ville de " devant les noms d'admin_level=8, je trouve ça cohérent. Comme je 
vois que tu 
as appliqué "Canton de xxx" sur les noms de cantons du Doubs, eh bien... 
parlons-en :-)

vincent

[1] : http://insee.fr/fr/methodes/nomenclatures/cog/arrdep.asp?codedep=45

Laposte.net, Messager Officiel du Rallye des Gazelles 2011, Pour suivre le 
Rallye Aicha des Gazelles et soutenir les participantes,
cliquez ici   http://www.laposte.net/rallye-des-gazelles


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> Par défaut, ce tag aurait le nom de l'emprise admin_level=8 où se situe
> le node admin_centre (= le chef-lieu). Des avis ?

Moi je mettrais plutôt "Arrondissement de ..." plutôt que juste le nom
du node admin_centre. Comme pour les titre des articles wikipédia.
Mais c'est peut-être ce que tu voulais dire.

A part ça je suis aussi partisan du modèle "frontière" plutôt que du
modèle "relation de relations commune" pour les entités constituées de
communes.

Damouns

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 22/03/2011 00:04, Thomas Petillon a écrit :
>
> Donne-t-on un admin_centre aux arrondissement ? À première vue c'est un
> élément important de leur définition. (Rien que par leur nom.) Ceci dit,
> admin_centre est utilisé pour donner un point de centre aux relations
> des communes ; pour les relations de plus haut niveau le centre est
> lui-même une commune, donc c'est peut-être un autre tag qui
> conviendrait. (Et rien n'a l'air d'être défini pour les niveaux
> administratifs 6 et 4 jusqu'à présent.)

Je n'ai pas de chiffres, mais admin_centre est utilisé pour indiquer le 
chef-lieu de plusieurs départements, par exemple Orléans pour le Loiret :
http://www.openstreetmap.org/browse/node/26686508

Je trouverais intéressant de propager (généraliser ?) l'usage du node avec
role admin_centre pour les chef-lieux de départements et régions.
Dans le même sens, les 3 arrondissements du 92 que j'ai modélisé ont chacun un 
node
admin_centre :
http://www.openstreetmap.org/browse/relation/1457524
http://www.openstreetmap.org/browse/relation/1457525
http://www.openstreetmap.org/browse/relation/1457526

> Toujours à propos des arrondissements, on-t-ils un réel nom, outre le
> fait d'être appelés par le nom de leur chef-lieu ?
J'ai vu quelques exceptions avec les noms d'arrondissements suivants :
Metz-Campagne
Thionville-Est
Thionville-Ouest
Metz-Ville
Château-Chinon (Ville)
Strasbourg-Campagne
Strasbourg-Ville

pour lesquel un tag name=* semble inévitable, on ne peut pas déduire le 
nom de l'arrondissement du nom de son chef-lieu. Du coup par souci 
d'homogénéité du modèle, peut-être faudrait-il propager l'usage du tag name
sur tous les arrondissements ? Par défaut, ce tag aurait le nom de l'emprise
admin_level=8 où se situe le node admin_centre (= le chef-lieu). Des avis ?

> Si tout le monde est d'accord, il ne manque plus qu'un rendu de la part
> de Sylvain sur beta. ;)
Tu veux dire pour les EPCIs ? Je vote pour :-)
Pour les arrondissements (rendu admin_level=7) le rendu montre déja la valeur 
du 
tag name=*, ce serait bien en bonus d'avoir l'affichage, comme pour les 
communes,
tag ref=* qui est le n° INSEE.

vincent


Laposte.net, Messager Officiel du Rallye des Gazelles 2011, Pour suivre le 
Rallye Aicha des Gazelles et soutenir les participantes,
cliquez ici   http://www.laposte.net/rallye-des-gazelles


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Thomas Petillon]

Le 20/03/2011 22:26, Vincent de Chateau-Thierry a écrit :

Bonsoir,
Pour faire suite aux échanges de janvier (voir ci-dessous) sur les 
EPCIs et les arrondissements départementaux, j'ai modifié la page de 
discussion du wiki [1] et rentré quelques relations mettant en 
application ce que j'y propose :


une Communauté Urbaine (Communauté Urbaine d'Alençon) à cheval sur 2 
régions :

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

des Communautés d'Agglomération :
- Communauté d'Agglomération Grand-Paris-Seine-Ouest :
http://www.openstreetmap.org/browse/relation/1467082
- Communauté d'Agglomération des Hauts de Bièvre, à cheval sur 2 
départements :

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

une Communauté de Communes (Communauté de Communes de Châtillon - 
Montrouge) :

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

et un Syndicat d'Agglomération Nouvelle (Syndicat d'Agglomération 
Nouvelle de Sénart Ville Nouvelle) :

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

Dans le même temps, comme les deux sujets sont liés, j'ai modélisé les 
3 arrondissements départementaux des Hauts-de-Seine en admin_level=7. 
Ils sont visibles ici :
http://beta.letuffe.org/?zoom=12&lat=48.83578&lon=2.23301&layers=BTF 



A l'exception de la CA GPSO (Boulogne et alentours, apparue en 2010), 
ma source pour la définition des EPCIs est le fichier de l'INSEE 
disponible ici :
http://insee.fr/fr/methodes/default.asp?page=zonages/liste-zonages.htm 
(rubrique Intercommunalité)

qui s'arrête à 2009.

S'il n'y a pas d'objections, la prochaine étape consistera à propager 
ces modélisations, tant pour les EPCIs (notamment en convertissant les 
actuels admin_level=7) que pour les arrondissements.


Merci pour vos retours,
vincent

[1] : 
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Arrondissements_d.C3.A9partementaux_.28sous-pr.C3.A9fectures.29




Bonsoir,

Ça m'a l'air de convenir tout à fait.

Donne-t-on un admin_centre aux arrondissement ? À première vue c'est un 
élément important de leur définition. (Rien que par leur nom.) Ceci dit, 
admin_centre est utilisé pour donner un point de centre aux relations 
des communes ; pour les relations de plus haut niveau le centre est 
lui-même une commune, donc c'est peut-être un autre tag qui 
conviendrait. (Et rien n'a l'air d'être défini pour les niveaux 
administratifs 6 et 4 jusqu'à présent.)


Toujours à propos des arrondissements, on-t-ils un réel nom, outre le 
fait d'être appelés par le nom de leur chef-lieu ?


Si tout le monde est d'accord, il ne manque plus qu'un rendu de la part 
de Sylvain sur beta. ;)


Thomas.

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Bonsoir,

Le 21/03/2011 23:14, Guillaume Allegre a écrit :


Je suis absolument d'accord pour remplacer les (horribles) admin_level=7
par des relations pour tout ce qui concerne les EPCIs, mais tant qu'à y être
pourquoi ne pas faire tout simplement des relations "haut niveau" regroupant les
_relations communes_ au lieu de relations "bas niveau" regroupant les _limites_.

J'imagine qu'en PostGis une opération : frontière ( union ( ... ) )
rèsoud le problème du calcul de frontières.
En tous les cas, ça me semble plus logique de stocker l'information de haut 
niveau.



Ta remarque me rappelle... ta remarque de janvier dernier :-) sur le fil 
"Référence INSEE" [1] puisque la question y était posée dans les mêmes 
termes. En résumé des éléments qui avaient suivi :
- le modèle "somme de surface" et le modèle "somme de limites" ont 
chacun leurs avantages
- le modèle que je pousse pour les EPCIs (somme de limites) permet de 
tracer les emprises d'EPCIs comme on trace aujourd'hui les emprises de 
communes, cantons [2], arrondissements, départements et régions : en 
regroupant dans une relation leurs limites pour former un contour fermé 
: ça donne une homogénéité à l'ensemble puisque ces différents 
découpages partent de la même unité : la commune. C'est pour moi le 
principal argument : la cohérence de modélisation des différents découpages,
- le modèle par limites est déja utilisé pour les EPCIs qui recourent a 
tag admin_level=7 : la transition vers un nouveau modèle par limites est 
directe et simple
- le modèle par limites permet de définir des zones sans forcément 
disposer de toutes les emprises qui les constituent, à l'inverse du 
modèle par surfaces, qui nécessite que toutes les surfaces (des 
communes) constituantes soient présentes, faute de quoi on forme des 
surfaces d'EPCIs trouées. En l'état de la couverture en limites 
communales (~70%) le modèle par somme de surfaces pénaliserait pas mal 
de territoires. Appliqué aux départements, voire (pire !) aux régions, 
il donnerait une France metropolitaine pleine de vide.


vincent

[1] : 
http://lists.openstreetmap.org/pipermail/talk-fr/2011-January/029909.html

[2] : http://www.openstreetmap.org/user/Damouns/diary/13364

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le dim. 20 mars 2011 à 22:26 +0100, Vincent de Chateau-Thierry a ecrit :
> Bonsoir,
> Pour faire suite aux échanges de janvier (voir ci-dessous) sur les
> EPCIs et les arrondissements départementaux, j'ai modifié la page de
> discussion du wiki [1] et rentré quelques relations mettant en
> application ce que j'y propose :
> 
> une Communauté Urbaine (Communauté Urbaine d'Alençon) à cheval sur 2
> régions :
> http://www.openstreetmap.org/browse/relation/1482552

[...]

> S'il n'y a pas d'objections, la prochaine étape consistera à
> propager ces modélisations, tant pour les EPCIs (notamment en
> convertissant les actuels admin_level=7) que pour les
> arrondissements.
> 
> Merci pour vos retours,
> vincent

Je suis absolument d'accord pour remplacer les (horribles) admin_level=7
par des relations pour tout ce qui concerne les EPCIs, mais tant qu'à y être
pourquoi ne pas faire tout simplement des relations "haut niveau" regroupant 
les 
_relations communes_ au lieu de relations "bas niveau" regroupant les 
_limites_. 

J'imagine qu'en PostGis une opération : frontière ( union ( ... ) ) 
rèsoud le problème du calcul de frontières.
En tous les cas, ça me semble plus logique de stocker l'information de haut 
niveau.



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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