> De : "Christian Quest" > Il ne faut pas prendre "boundary" au pied de la lettre...
Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme n'est pas choisi au hasard, non ? > Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui va avec). La recopie de tags, c'est 3 clic dans JOSM 1er : 3e bouton en partant de la gauche dans le panneau des relations => ouvre une nouvelle relation copiée sur celle sélectionnée initialement 2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation pour sélectionner tous les membres 3e : bouton 'Poubelle' juste au dessus du précédent et voilà une relation toute neuve, avec tous les tags, et vide de membres. Donc bon... > En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ? Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) ) Actuellement, la relation [1] a 259 membres : 258 ways et un node. En ajoutant les 455 références des 455 communes, on triple presque le nombre de membres, mais surtout on mélange 2 styles de références, on va vers des objets un peu monstrueux je trouve. Les relations actuelles se concentrent sur la géométrie d'un objet, et rien d'autre. Celles dont on parle avec les subarea ne décrivent pas de géométrie, mais des relations d'inclusion via la sémantique : un arbre, qui irait de la racine (le pays) aux communes voire aux quartiers, via des branches : les régions, les depts, etc. Tout dans la même relation, je trouve ça à la fois moins lisible, moins évident à comprendre car hétéroclite, accessoirement plus lourd à manipuler. Bref, je ne vois pas d'avantages, plutôt (que) des inconvénients. En modélisant ça à part, on assure, mine de rien, une compatibilité pour les usages actuels des "boundary" : leurs consommateurs n'y verraient que du feu. Mais les nouvelles relations, hiérarchiques, seraient simples à combiner aux boundaries, avec une clé ultra simple pour ce qui concerne nos découpages admin : le ref:INSEE et rien que lui. > Je préfère un seul objet OSM pour représenter une unique entité sur le terrain (la région machinchose, le département trucmuche). Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet représentant en même temps une surface et un linéaire ? ;) Va savoir :-) Mais moi aussi je préfère un seul objet par entité. Mais ici j'estime qu'on représente 2 notions distinctes : d'un côté des emprises géométriques, indépendantes les unes des autres (ce qui est le problème à l'origine de ce fil) et de l'autre un arbre, ici administratif mais on pourrait appliquer ça à d'autres cas. vincent [1] : http://www.openstreetmap.org/browse/relation/7392 Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
