Le 26 janvier 2012 23:49, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > > > Le 26/01/2012 23:08, Philippe Verdy a écrit : > > >> >> JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes >> laissées (j'ai fait un seul test uniquement du boundary_segment sur la >> côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car >> il y avait déjà des boundary_segments incohérents et très difficiles à >> mettre à jour, pour la frontière française, que le serveur peine >> énormément à gérer et que chaque édition locale sur la côte nécessite >> un chargement énorme de données et de pénibles synchonisations de >> dizaines de milliers de noeuds: les boundary_segments de la France >> sont trop acutellement beaucoup longs, et même si on décide de garder >> les ways pour les côtes de l'Ille-et-Vilaine, les segments de >> frontière frontçaise par départements sont à privilégier au niveau de >> la zone France, afin de soulager le travail: c'est un redécoupage plus >> fin qui ne change pas le modèle actuel pour la France; mais il reste >> que le problème est aussi ardu pour la Bretagne). > > > Le fait de splitter les limites côtières (et uniquement elles) françaises en > relations "boundary_segment" à raison d'une relation par département, a déjà > été discuté ici et admis. J'avais proposé de m'en occuper et je ne l'ai pas > fait : > http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/037663.html > Tu peux prendre le relais. > À noter qu'il existe déjà un boundary_segment pour les Côtes d'Armor : > http://www.openstreetmap.org/browse/relation/1846740 > créé de mon côté en guise de test, > et un autre créé par toi pour l'Ille-et-Vilaine, et auquel je n'ai pas > touché en "réparant" le contour de ce département hier : > http://www.openstreetmap.org/browse/relation/1979939 > > Donc pour la Bretagne, on ne part pas de rien.
OK, donc je vais continuer à ajouter les splits départementaux, pour qu'enfin on puisse remplacer les segments trop grands de la frontière française (pour l'instant ils restent là), par les segments départementaux. Mais que faire alors de la frontière de la région Bretagne elle-même (très compliqué ?) peut-on la splitter en utilisant alors les segments départementaux qu'on aura créés ?? Dernier point: je ne suis pas le seul à vouloir utiliser les subareas (même si on n'en a pas besoin pour dessiner une surface): regardez par exemple la Belgique et l'Espagne, qui les utilisent comme métadonnées intégrées directement dans les mêmes relations de frontières (et PAS dans des relations différentes). Je n'ai jamais nié l'intérêt de la définition par frontières (quoique l'absence de support partout des boundary_segments pose encore problème). Je ne l'ai jamais remise en cause, pas même lors de mon essai d'utiliser le boundary_segment de la côte nord l'Ille-et-Vilaine, au lieu de dupliquer les ways comme on ne fait encore, avec toutes les incohérences que cela génère quand les différents niveaux ne sont pas mis en jour en même temps, ce qui n'est franchement pas facile à faire pour les hauts niveaux qui contiennent des centaines de ways désordonnées et anonymes, raison pour laquelle je me bat en permanence pour essayer de les faire apparaitre comme formant des boucles complètes, afin d'identifier les ways à ajouter ou supprimer de la relation mère !) On est pas les seuls en France à avoir ces incohérences (les Allemands se plaignent, et les Anglais aussi surement, mais je n'ai pas regardé si eux aussi utilisaient les subareas pour faciliter la maintenance des ways de toutes les relations de niveau inférieur quand une petite zone locale a été modifié...). Les Belges utilisent les subareas avec un outil qui se charge tout seul de reconstruire les frontières de niveau inférieur, lorsqu'une plus petite zone de niveau supérieure est modifiée: pas d'incohérence (sauf temporairement: le robot fait le travail bien mieux qu'un humain, sans erreur). Ils l'utilisent aussi pour faciliter l'import de données externes (depuis des bases de données qui n'ont strictement AUCUNE définition géolocalisée permettant la recherche des sous-zones). Cette automatisation des "remontées" de frontières automatisées est justement possible dès qu'une zone est entièrement partitionnée en zones filles. S'il manque des tracés, ce n'est pas du tout un problème: la zone est marquée comme non encore partitionnée ou contient des "FIXME" pour les zones manquantes (que strictement rien n'empêche de créer immédiatement même sans encore aucune frontière définie, afin de permettre justement des imports externes des données géolocalisées qui manquent: on crée la zone sans frontières, ou avec une frontière incomplète pas encore fermée, on la référence avec un "subarea", et on avance...). Ceux qui travaillent sur le dessin d'un niveau (et ont un accès direct à des bases OpenData ou qui aiment dessiner des frontières précises verront ces manques de frontières suffisantes (qui sont signalés par nos outils). Notez que la définition des hiérarchique des "subareas" est extrêmement stable en comparaison des données de frontières (qui sont sujètes à des tas de corrections ou remise à jour par des relevés plus précis sur le terrain par les géomètres des collectivités ou autres). Les GPS qu'on utilise de façon populaire pour les routes sont souvent assez imprécis (décalage de plusieurs mètres, qui peuvent placer des objets du mauvais côté d'un autre, ou créer des intersections inexistantes, des demi-tours, des zigzags sur des routes droites: l'exploitation de leurs tracés tient plus au "feeling" du cartographe que par un relevé très précis, et malgré cela, il reste aussi les anomalies provenant de la synchronisation imparfaite ou de l'imprécision des projections de photos aériennes: il y a des décalages par exemple entre la géolocalisation WGS84 de Bing, celle de Google Maps, selon les sources utilisées et les dates des photos utilisées, ou la source réelle de ces photos). De plus des relevés de position précise des repères géodésiques conduit à réajuster plus tard la position des photos, indépendamment du géoïde qui a été utilisé au départ pour positionner ces photos. Dans OSM, on utilise abondamment les photos aériennes dans lesquelles on a inclus des points géodésiques qu'on ne doit pas toucher (contrairement à tout le reste, qu'on pourra ensuite réajuster de façon automatique pour réaligner les points physiques cartographiés sur les photos avec les points géodésiques. On a aussi des évolutions dans la précision des modèles de projection utilisés dans les différents outils. Tout cela amènera à améliorer les frontières et les remettre à jour un peu partout, pour arriver à une précision de l'ordre de 0.5 mètres (nécessaire pour le tracé des rues et positionner les bâtiments dans les villes, puis pour fournir des adresses pour les "POI"): plus les frontières sont précises, plus le travail sur les frontières des zones mères (afin d'obtenir leur adhérence) devient pénible. A terme même, je pense que les frontières mères ne pourront plus être mises à jour du tout pour fournir une adhérence totale, mais juste approximées sur une précision plus faible et dans ce cas le test d'inclusion d'une zone fille dans la zone mère (par une recherche spaciale) ne pourra plus fonctionner du tout (c'est déjà le cas actuellement): et seules les relations de type "subarea" dans les zones mères (moins précises) partitionnées en sous-zones (plus précises), fourniront une réponse fiable. SAUF si on hiérarchise aussi les boundary_segments (qui tôt ou tard devront venir si on ne veut plus dupliquer les "ways") comme le suggère le nom de votre modèle "pyramidal" (votre pyramide ne concerne que les contours mais uniquement aux noeuds d'intersection des frontières entre elles). Car dans ce cas il est possible de conserver l'adhérence (puisqu'il n'y a plus du tout duplication des ways dans les différentes relations définissant une zone, les données des ways ne figurent alors que dans 1 et 1 seul boundary_segment, ceux-ci se combinant entre eux par des relations récursives, ce qui aboutit à ce moment-là à un modèle réellement dual du modèle par surface, que peuvent représenter les "subareas"). Je le répète donc: les frontières (faites de ways actuelles qu'on duplique dans les relations) n'est pas du tout topologiquement équivalent au modèle par surface: il est nettement plus coûteux en données à stocker et mettre à jour de façon constante (la mise à jour doit se faire simultanément entre les zones mitoyennes d'un même niveau ET dans toutes les zones mères quand elles en définissent le contour externe : cela ne serait plus nécessaire du tout avec des frontières hiérarchisées, ce qu'on n'a pas encore et qu'on est très loin d'avoir dans OSM et ses outils). Le modèle actuel, à frontières simples fermées (entièrement définies par les ways tous dans la seule relation definissant le contour d'une zone) a pu marcher jusqu'à présent,pour débuter, tant que la cartographie était peu avancée, mais c'est de plus en plus lourd et de moins en moins gérable. On devra passer au modèle par segments (eux-mêmes hiérarchisés par définition récursive), car le modèle actuel produit trop d'erreurs à cause de remontées qu'on a de plus en plus de mal à faire vers les zones mères (qui du coup sont "oubliées" dans les mises à jour). Les requêtes spaciales sont aussi de plus en plus lourdes sur le serveur (qui ne sait plus répondre: volume de données trop grand) pour de simples tests d'inclusion d'une zone donnée dans une zone mère. Et on le voit bien: même en ajoutant de nouveaux serveurs, ils ont du mal à suivre (aussi bien la base principale que les serveurs de rendus de tuiles qui prennent de plus en plus de retard...) Ce n'est pas un problème de ressources, on peut avoir les serveurs nécessaires, mais on utilise mal ces serveurs en les gavant de données qu'ils doivent sans arrêt ingurgiter de façon répétés même si une part infime de ces données a été réellement modifiée, alors qu'on peut grandement leur faciliter le travail. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
