Le 19 septembre 2013 17:42, V de Chateau-Thierry <v...@laposte.net> a écrit :
> > > 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... > Oui, et tout les problèmes de mise à jour qui vont avec... info dupliquée = info pas synchronisée Si on a les mêmes tags, c'est bien qu'on parle de la même "chose". > > > > 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. > Tu aurais du prendre mieux... France (admin_level=2) et communes (admin_level=8)... ça ferait 36700 membres dans la relation "France" ;) L'idée est d'avoir une hiérarchie, donc dans admin_level=2 tu met les membres du niveau du dessous, soit les régions (4) dans les régions tu met les départements (6) et dans les départements les arrondissements (7) puis dans ceux-ci les communes (8). Le nombre de membres reste limité à chaque niveau. > Les relations actuelles se concentrent sur la géométrie d'un objet, et > rien d'autre. > Euh... alors on vire les admin_centre et les label ? > 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. > Oui, et la même relation peut servir aux deux sans que cela ne gêne. > 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. > > Tout dans la même relation ne gênera pas les consommateurs actuels... car c'est déjà le cas à plusieurs endroits (Espagne, Belgique) et que je sache osm2pgsql et consorts n'ont pas explosé en vol alors que ça fait un bout de temps que subarea est utilisé et décrit dans le wiki au sein d'une même relation. C'est toute la beauté du "role" dans les relations qui ne sont pas de simple collections d'objets. Il permet de regrouper des membres hétérogènes ensemble. Le rôle n'existerait pas, ça serait effectivement un gros bazar et je serai de ton avis. > > > 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. > > J'ai une approche moins géométrique et beaucoup SGBDR: un objet OSM (relation) pour une entité (ici un département) et au sein de la relation des membres qui peuvent décrire différents aspects de ce département, les way qui composent sa frontière (outer/inner), les autres objets OSM qui composent logique ce département (les subarea), un nœud pour placer un libellé, un autre pour définir la position du centre administratif, voire d'autres trucs futurs... Quant au ref:INSEE, il est trop incomplet pour décrire la hiérarchie, il ne donne qu'une info sur le département auquel appartient une commune, rien sur l'arrondissement/canton, la région et c'est un truc franco-français. J'ai joué avec ces problèmes ces derniers jours pour ressortir l'équivallent des is_in et c'est un prise de tête pays par pays car des tags nationaux ne peuvent permettre d'écrire du code générique bien que la logique soit souvent identique entre différents pays. L'usage plus systématique des codes NUTS/LAU, des codes ISO et FIPS seraient un sacré plus, mais c'est un tout autre sujet. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
