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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
