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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-fr
