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

[Philippe Verdy]

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 <pieren3 at gmail.com> a écrit :

> 2013/9/19 Christian Quest <cquest at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/b6ead250/attachment.htm>