Le 25 janvier 2012 10:19, Pieren <[email protected]> a écrit : > 2012/1/25 Philippe Verdy <[email protected]>: >> 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...). > > Dans ce cas, il suffit d'ajouter les îles manquantes dans la relation > et attendre que nominatim se remette à jour. Avec des subarea, on > aurait aussi ce genre de problème. Si une relation est incomplète, on > ne peut pas espérer que les logiciels ne fassent pas d'erreurs.
Non, avec les subareas, ce problème disparaitrait complètement: elles sont simples à définir, très stables, indépendantes de la précision des tracés ou de leur complétude, ne grossiront pas même si on améliore la précision, elles soulagent énormément les requêtes. Et une fois complètes (ce qui est facile à faire en peu de temps), elles permettront de regénérer entièrement toutes les frontières de niveaux supérieur, par récursion, afin que les cartes dessinées se mettent à jour. Elles seront très utiles pout finalement aboutir à une cohérence complète: plutôt que de perdre du temps à corriger les frontières oubliées ou à la remettre en ordre pour les fermer et vérifier qu'elles sont bien fermées, on ne travaille plus que sur les frontières des zones les plus petites, ces zones (définies comme relations de type boundary) qu'ont inclue ensuite comme relations membres d'une zone plus grande avec un rôle "subarea". La frontière de la zone de niveau supérieur, une fois que toutes les subareas ont été incluses pour former une partition complète, peut être regénérée automatiquement, et les boundary segments peuvent être définis aussi automatiquement (plus tard) pour les frontières communes des sous-zones. L'automatisation évitera toutes ces erreurs car on commet nettement moins d'erreurs en travaillant au niveau le plus fin de la carte: plus besoin de corriger les frontières des zones de niveau supérieur, cela se fera par un bot, qui pourra le faire si une zone contient des subareas, et si la zone mère est marquée comme listant exhaustivement ses sous-zones (par exemple un attribut de la relation "partitions"="subarea" indique que les membres de type "subarea" forment une partition, et que donc ses frontières peuvent être déduites, mises à jour automatiquement, des frontières de ses sous-zones de rôle "subarea". Rien donc n'est à changer aux outils qui dessinent les tuiles: ils peuvent continuer à ignorer les membres de rôle subarea (ou tout autre rôle si on désire faire plusieurs partitions différentes d'une zone, ou faire des sous-zones formant une partition incomplète, ce rôle restant alors non listé dans l'attribut "partitions"="subarea"). Je ne dis pas qu'il faut remplacer les frontières (boundaries, voire boundary_segments) par des subareas, mais que les deux peuvent énormément faciliter le travail: on travaille localement sur la carte, qui se remet alors à jour de façon automatisable sur les zones de niveau supérieur. Au final, on charge moins le serveur car la plupart des éditions successives se fera au niveau local, ce qui affectera beaucoup moins de tuiles, et demandera aux cartographes moins de travail pour fouiller la carte, localiser les chemins et noeuds puisqu'on peut naviguer facilement de façon récursive. Et avec moins d'erreurs (grace au travail des bots), on pourra en in corriger ce que Nominatim n'arrive pas à calculer correctement. Les bots qui importent aussi des métadonnées n'auront plus besoin de charger sans arrêt les noeuds et chemins: ils auront juste à parcourir les relations, ce qui sera bien plus facile, plus rapide, plus efficace, et produira des données de bien meilleure qualité que la seule recherche géométrique qui est trop lourde. Tu saisis l'intérêt ? _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
