Justement c''est le modèle purement géométrique qui a une quantité ENORME de redondance en lui-même. beaucoup plus que le modèle ensembliste.
Et je suis en vieux routier des BDD, je sais aussi de quoi je parle. Et ceux qui parlent de mettre le modèle ensembliste dans des relations séparées à part des relations géométriques militent en fait pour un redondance enorome de données (deux objets séparés avec duplication intégrale des attributs juste pour gérer des listes de membres différentes, alors qu'on a déjà la notion de "rôle" pour distinguer les listes de membres sans rien dupliquer du tout). Le modèle ensembliste pourtant est beaucoup plus efficace que d'ajouter aussi des tags "is_in" : là oui ces derniers sont des redondances très lourdes, très volumineuses, et difficiles à maintenir (mais la seule chose qu'on a pu faire pour tenter de garder une trace des morceaux de géométries cassées...). Rien que "is_in:country=*" génère des millions de copies de l'attribut pour un pays comme la France. En comparaison le modèle ensembliste générera ***1 et 1 seul*** membre par commune (preuve qu'il n'a pas de redondance en lui-même) quel que soit le nombre de niveaux administratifs gérés, et le modèle géométrique à frontières génère 6 à 12 membres par commune, chaque chemin membre étant inclus presque toujours au moins deux fois (et souvent plus pour les niveaux adminsitratifs muttiples), ce qui montre une redondance intrinsèque du modèle géométrique à lui tout seul (et qui pourtant n'arrive pas à se stabiliser et qu'il est difficile de vérifier et parcourir, et qui rend toute rechercher ultra compliquée et lourde à faire si c'est le seul moyen). Si tu commence à parler d'éviter les redondances, alors clairement c'est le modèle géométrique actuel (chemins frontières ou surfaces, même chose) qui a perdu depuis toujours quand les données sont à la base essentiellement hiérarchiques (et donc mieux représentés par un modèle ensembliste, avec comme membres des régions filles sans aucune petite fille) Le 19 septembre 2013 15:54, Pieren <pier...@gmail.com> a écrit : > 2013/9/19 Christian Quest <cqu...@openstreetmap.fr>: > > > J'aime aussi cet ajout de redondance qui permet de détecter les > > incohérences. > > > Nooooooooonnnnn (snip) Il faut écouter les vieux routiers des bdd : la > redondance ne détecte pas les incohérences, elle les créer ! Encore > plus dans un projet comme OSM où chaque entité peut être modifiée > séparément et sans contrôle. > Les relations boundary sont déjà très difficiles à maintenir. Vous > allez doubler le travail sur 36000 communes, 100 départements et 22 > régions, doublez le nombre de relations (ou leur taille); tout ça pour > éviter que quelques personnes remplissent une base spatiale avec > osm2pgsql... > > Pieren > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
