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

[Philippe Verdy]

Le 19 septembre 2013 17:42, V de Chateau-Thierry <vdct at 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...
> >
>
> 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.
>

C'est à que tu te trompes complètement car tu ne comptes pas tout ! Tu ne
regarde QUE la relation de l'Yonne et pas les relations des communes. et tu
oublies aussi qu'entre les deux il y a les arrondissements.

Pour l'Yonne cela ajouterait SEULEMENT les 3 ou 4 membres des
arrondissements et c'est tout (1 membre unique par arrondissement pour
toute la base de données), mais pas toutes les communes; dans chaque
arrondissement il y a aura uniquement la cinquantaine de communes. dans la
commune il n'y aura rien du tout (sauf si elle a un découpage administrarif
infracommunal au niveau 9 ou plus).

Total ajouté dans la base : jamais plus de membres ajoutés qu'il y a de
relations dans la base. Et il ne s'agit de remonter dans le parent qu'une
seule et unique donnée, mais aucun de ses autres attributs (on ne duplique
pas les noms, on ne duplique pas non plus la géométrie comme on l'a fait à
l'excès dans les listes de chemins membres "outer"/"inner" où il faut
souvent remonter plein de chemins de la relation fille vers la mère, dont
le volume explose : il suffit de regarder les relations du pays, des réions
et départements=et même des arrondissements).

Franchement fais tes calculs correctement et va voir réellement la
situation en Espagne et en Belgique et fait le compte : ces membres ajoutés
sont une partie INFIME des données en comparaison des membres
"inner"/"outer" des listes de chemins.

Pour toute la France et pour la totalité de sa structure adminsistrative de
niveau 2 à 8, il ne faudra pas plus de 40000 membres (répartis parmi les
40000 relations existantes, soit effectivement 1 seul membre ajouté en
moyenne par relation !). Alors qu'on a pas loin du million de chemins et
des dizaines de millions de noeuds à télécharger ou mettre à jour pour
seulement en déduire (par un calcul très compliqué et faux en permanence
car jamais les données ne sont complètes et cohérentes) sa structure
administative  !

Il n'y a pas photo, le modèle ensembliste est très largement gagnant et
assure à lui tout seul une totale absence de redondance, donc la solidité
et la cohérence d'ensemble. Les chemins ne sont réellement nécessaires
qu'au niveau le plus fin des relations (donc dans les feuilles au niveau 8
si c'et le niveau final) et TOUS les autres chemins sont des redondances.
De plus il y a une autre redondance par le fait que chaque chemin est
mentionné au moins deux fois (par les relations limitrophes qu'il
délimite), ce qui n'arrive pas non plus avec la définition ensembliste.

Bref reprend tes calculs et n'oublie rien : mais si tu ne veux pas regarder
le problème complet, tu vas tirer des conclusions fausses comme ci-dessus.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/c99299e3/attachment.htm>