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
<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...
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
<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 ?>
En modélisant le contour plutôt que la surface, je proposais hier
boundary=local_authority,
J'ai raté ça... Pourquoi pas pas suffisamment
anglophone pour juger.
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.
Pour moi : limites OK. Vocabulaire anglais je
vous suis.
A vous lire,
vincent
Benoît R.
|
