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

[Vincent de Château-Thierry]

Le 19/09/2013 18:02, Philippe Verdy a écrit :

>
> 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).

Tu as raison, le niveau des arrondissements change les chiffres, en 
s'intercalant. Mais ça ne change rien au principe : ce que je décrivais 
pour une relation de département s'applique à une relation d'arrdt, en 
divisant (en moyenne par 3 ou 4) la liste des références de communes.

> 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 !).
Sûrement pas : la répartition se fera surtout parmi les relations au 
dessus des communes, donc il faut enlever un bon 36000 à ton 2e 40000.

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.

Je n'ai rien contre le modèle ensembliste, comme tu l'appelles. Je lui 
trouve un véritable intérêt pour sa capacité à décrire, autrement que 
par inclusion spatiale, des relations entre objets. Et je m'en sers au 
quotidien, donc je suis d'avance convaincu. Je pense que décrire ces 
relations dans OSM apporterait une vraie plus-value. Je parle ici en 
pensant aux usages, aux consommateurs. La demande initiale de Fionn est 
un cas d'usage, concret. Il y en aura d'autres à l'avenir, enfin on ne 
peut que l'espérer !
Là où, définitivement, j'ai un souci, c'est avec la volonté de tout 
ranger dans un même sac : géométrie et relations hiérarchiques. En 
pensant aussi bien à la maintenance qu'à la réutilisation, je ne suis 
pas convaincu par la pertinence. Mais bon, je radote.

vincent