Je sais parfaitement pourquoi l'Ille-et-Vilaine n'est pas classée en Bretagne par Nominatim: la requête spaciale échoue, car l'Ille-et-Vilaine n'est pas entièrement incluse dans la Bretagne (ce sont les îles oubliées...).
Nominatim tente alors une recherche approximative basée sur la plus courte distance entre centroïdes et en déduit que le centroïde de l'Ille-et-Vilaine est plus proche de celui des pays de la Loire que de celui de la Bretagne (il ne sait pas encore utiliser les subareas, c'est vrai, mais il pourrait le faire pour régler définitivemlent le problème de façon simple au lieu de s'appuyer sur les définitions spaciales de frontières). Nominatim se plante car justement c'est un ordinateur. Il dépend de règles algorithmiques qui ont des failles: ce n'est pas un algorithme qu'il emploie mais un heuristique. Avec ses failles. Un humain ne ferait pas cette erreur et ignorerait de lui-même les petites imperfections frontralières entre la définition des zones de niveaux différents. Il n'y a actuelelment AUCUN contrôle de cohérence de la base entre les niveaux administratifs différents. Uniquement entre zones de même niveau. Et c'est une lacune grave de la base OSM, que les subareas vont permettre de régler. La stabilité et l'exactitude de la base de données milite fortement pour l'utilisation des subareas, et permet de palier justement très facilement à ces imperfections, permet de les détecter, et de les corriger facilement. Je peux donner de nombreux exemples de ces problèmes, et le modèle que j'ai cité en exemple pour les 20 arrondissements communaux de Paris et les 3 arrondissements départementaux du Val-de-Marne montrent qu'il n'y a aucune anomalie, aucune ambiguïté, et une modélisation simple et lisible, à la fois pour un humain ET pour un ordinateur. Et cela n'entraine aucune anomalie non plus pour les logiciels de rendus ou d'analyse et d'exploitation des cartes. Cette double modélisation (spaciale et relationelle) n'est pas un luxe, elles se complètent. Tu as raison de dire qu'avec une modélisation relationelle (subareas) il faudrait faire des requêtes récursives pour chercher les zones parentes. Mais même dans ce cas, les requêtes à la base OSM bien qu'un peu plus nombreuses (pour une zone seule), fourniront en fait des résultats beaucoup moins massifs et demanderont beaucoup moins de travail au serveur: le volume des valeurs retournées dans un modèle relationnel est plusieurs milleurs de fois inférieur: au lieu d'un seule énorme resultset, on obtient une poignée de tous petits resultsets, très faciles et rapides à traiter. De fait: essaye dans JOSM, en partant d'un claque vide, de chercher et charger tous les arrondissements de Paris: avec une requête spaciale, cela demande des requêtes volumineuses. C'est encore pire pour le découpage de zones plus grandes (les régions ou tout le pays: de nombreuses régions ne parviennent pas à se charger dans JOSM, le serveur retourne une erreur à cause du volume de données à charger, même en ne demandant à charger que les "membres incomplets", ou alors il faut choisir une heure de basse charge du serveur pour parvenir à charger ces relations). Il faut des heures ou des jours pour charger la frontière de la France... C'est intenable. On a donc besoin des deux: modélisation relationelle (pour l'exploitation des cartes et le travail dessus, ou pour enrichir les cartes de données tierces, par exempel statistiques ou métadonnées), et modélisation spaciale (uniquement pour le rendu des cartes sur les tuiles afin de les dessiner). Ce sont deux travaux indépendants, mais qui se complètent l'un l'autre. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
