Le 19 septembre 2013 18:30, Vincent de Château-Thierry <v...@laposte.net> a écrit :
> 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. > Surement si ! les 36000 restent dans le total général (note bien que j'ai pris la structure administrative dans sa totalité, autrement dit tous les niveaux) ! Ce qui donne bel et bien une moyenne de 1 membre par relation. Si tu enlèves 36000 cela veut dire que tu as supprimé les 36000 membres représentant les communes dans les départements, uniquement parce que tu ne les veux pas comme membres dans les départements, mais tu les voudras dans les arrondissements départementaux, et les arrondissements départementaux seront membres des départements et entreront dans le compte général des relations pruses en compte et celui des membres qu'on leur ajoute. Il reste maintenant à savoir 3 choses (du plus simple au plus compliqué à analyser et décider) : (1) quel rôle utiliser pour ces membres : jusqu'à présent on n'a jamais prévu QUE le rôle "subarea" alors qu'en fin de compte on est dans une logique ensembliste indépendante de la géométrie. Je pencherai pour un rôle synonyme (mais plus clair) "include" (ce pourrait même être le rôle vide par défaut s'il n'y a pas d'ambiguité en regardant juste le type d'objet, mais on a déjà des membres qui sont des relations destinées à contenir des fragments de frontières, sous forme de multi-polylignes non nécessairement toutes fermées en anneaux). (2) à quel niveau placer le membre ajouté pour cet ensemble : la relation parente ou la relation fille. En terme de stockage physique de la base de données cela ne change rien puisque dans les deux cas les membres de relations sont stockés dans un tableau à double entrée (avec une orientation non inversible) qui peut être indexé dans un sens ou dans l'autre et qui contient les références aux deux objets, ainsi qu'un attribut pour cette paire, le "rôle". Cependant en terme physique il reste plus efficace pour gérer les deux index d'en faire un lié directement à la structure de stockage du tableau à double entrée, trié dans l'ordre de la première colonne comme clé primaire et la seconde colonne comme clé secondaire, sans avoir besoin de stocker des références indirectes (comme un rowid"), et l'autre contenant uniquement un index pour la direction opposée, et qui contiendra donc la seconde colonne la plus unique et la référence à la première table d'index. Comme la première table-index dot avoir comme première colonne clé primaire la moins unique, cette table-index sera comme clé plutôt celle contenant une relation mère, la seconde sera pour la relation fille. A ce moment là la seconde table devient quasi-isomorphe de la table concernant la relation fille seule et elle en suit le tri. ce qui fait que la référence à la relation mère devient un attribut (0,1) de la "relation OSM" fille, tandis que que la première table-index est stockée à part de la "relation OSM" mère dans l'ordre de son index qui stocke alors physiquement: - type OSM de la relation OSM mère - id OSM de la relation OSM mère - type OSM de la relation OSM fille - id OSM de la relation OSM fllle - nom du rôle (ou hashvalue du rôle si on a une table à part des rôles utilisés pour économiser de la place) - rowid de la relation OSM mère - rowid de la relation OSM fille La table-index stockant alors les relations OSM (filles) devient: - id OSM de la relation OSM - attribut (0,1) du rowid de la relation OSM mère (non renseigné et reste NULL si elle n'a pas de mère) - autres attrbuts et tags Cependant cela n'est possible que si le rôle est figé; comme le nombre de rôles n'est pas fini (plusieurs hiérarchies possibles) et rien dans le schéma n'oblige à assurer une distibution de volumétrie aussi déséquilibrée qu'une structure hiérarchique pure (on a des exceptions) cette solution est moins avantageuse que de stocker plutôt des listes de membres dans la relation mère plutôt que la fille (car de toute façon on ne peut pas échapper à un stockage physique dans au moins 2 tables-index (ou 3 si on stocke les rôles uniques remplacé par un rowid unique vers une table-index de hachage des rôles). Même en terme de volume d'échange au format XML ou GeoJSON, c'est sous forme de listes de membres stockés dans la relation OSM mère que c'est le plus compact. Et c'est le plus naturel car la topologie du schéma suit la dénomination aussi utilisée "sur le terrain" pour décrire les membres d'une héirarchie adminsitrative. (3) doit-on avoir un autre rôle pour les exclusions ? Autrement dit les listes de membres doivent elles nécessairement être uniquement inclusives et sans superposition (purement hiérarchiques, mais éventuellement avec des trous), comme c'est le cas des rôles "subarea" ou admettre des exceptions ? PAr prudence, mais aussi comme c'est la réalité observée dans toute géographie humaine, il faut admettre des exceptions un peu partout sur les prétendues hiérarchies administratives. Dans ce cas on a besoin de deux rôles pour la représentation "ensembliste" du cas le plus général : un rôle "include" (correspond à l'actuel rôle 'subarea") et un rôle "exclude" (pour gérer les exceptions qui permettent à une relation fille d'être attachée à deux mères). Cela marchera par exemple dès que la hiérarchie ne fonctionne plus, et cela permet aussi d'unifier de façon plus systématique ce qu'on a arbitrairement défini par une division hiérarchique des territoires en feignant de croire que ces cas de superposition partielle des filles n'existe pas; le rôle exclude pemettant d'inclure une fille seulement en partie en en retirant un fragment (qui n'a pourtant pas d'autonomie en tant qu'entité administrative par elle-même). Cela permet par exemple de gérer nos fractions cantonales, les fractions de secteur postaux d'une commune desservis par un bureau d'une autre commune, etc. Cela marche auss idans le cas des revendications politiques multiples et d'un même territoire (que ces revendications soient conflictuelles, ou bien régies en partage, paritaire ou en alternance, par un statut particulier du territoire). Ceci fait, on est capable de savoir immédiaement qui fait partit de quoi ou pas uniquement sur une vision ensembliste des choses. La géométrie de terrain reste indispensable au niveau le plus fin (celui dont la liste des membres de rôle "include"/"subarea" ou "exclude" est vide), mais toute relation ayant des membres de rôle "include" (et d'éventuels "exclude" qui ne peuvent jamais exister seuls) n'a plus besoin de frontières "inner"/"outer" (on peut en mettre mais c'est une redondance obtenue par dénormalisation, et elle ne fait plus référence dès qu'il y a au moins un seul membre de rôle "include"/"subarea"), et ces frontières dénormalisées peuvent être si nécessaires générées automatiquement par bot ou vérifiées automatiquement. Si la dénormalisation en improte trop, autant ne pas les mettre, car il n'y a plus aucun bénéfice, il vaut mieux descendre la hiérarchie ensembliste des rôles "include"/"subarea" et "exclude".
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
