[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[V de Chateau-Thierry]

> 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