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
<mavie>
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
standard en important plus d'adresses que tous les autres sur un
schéma perso, soit j'attends un consensus. J'opte pour le second
choix.
</mavie>
Je reviens au sujet... Pour les limites, au delà du schéma général,
je pense que l'on est confronter au même type de pb qui fait que
beaucoup laissent tomber ou qu'on en arrive a entrer les cantons en
limites administratives parce que l'un dans l'autre on s'comprends
et le schéma existe. Sans croire à un afflux massif de contributeurs
sur les limites administratives, je pense qu'un meilleur schéma,
clair et un nettoyage du wiki sur le sujet, permettrai une
contribution plus rapide et par ricoché plus de contributions.
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 :-)
Ne suis pas contre node "place=*", au contraire et pour les m^me
raisons que toi. Mais je ne voudrais pas que cet élément laisse
pensé que le travail est fait une fois qu'il est en place et et ne
devienne une "excuse" pour ne pas tracer les limites par la suite.
vincent
Benoit R.
|
