[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Vincent de Château-Thierry
vdct at laposte.net
Jeu 19 Sep 16:30:59 UTC 2013
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
Plus d'informations sur la liste de diffusion Talk-fr