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 <adressepossi...@free.fr
<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 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...
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
<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
