Le 26 janvier 2012 14:30, Hélène PETIT <h...@free.fr> a écrit : > Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : >> >> Tentons de rester objectif, et de mettre des "peut-être" quand ça reste >> une >> supposition plutôt que les superlatifs récemment lu du genre : >> C'est 10000 fois plus rapide. > > > Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait > ce pour quoi il a été conçu au départ ; comme je préfère cartographier que > mettre la main dans le code (pour l'instant) je n'ai pas pris le temps > d'aller lire la descro du schéma de la base et de ses abatis. > Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? > AC) pas particulièrement référence au schéma actuel de la base, je me > demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à > vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre > le système de catégories utilisé par le wiki :>( > > Pendant que j'y suis : > À quoi pourrait bien servir le tag "label" dans une relation "frontière > administrative" de niveau 8 ?
Pour une commune dont la forme fait que son centroïde calculé tombe en dehors de ses frontières et le label par défaut semble indiquer le nom d'une autre commune. Regarde les boucles de la Seine dans le 92 pour comprendre... > À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée > boundary=administrative, vu que de toutes façons, c'est la relation boundary > qui dira le admin_level ? Non ! L'admin_level de la polyligne peut être de niveau inférieur au niveau 8 de la relation communale. Regarde donc les communes en frontière d'arrondissement, de département, de région ou de pays: les polylignes des contours sont de niveau différents. L'admin_level de la polyligne indique aussi au moteur de rendu des tuiles comment dessiner (quel style de ligne, quelle épaisseur, quelle couleur) sur ce contour partiel. Un moteur de rendu de tuile ne charge pas nécessairement la totalité de la commune ou des communes environnantes, ni toutes les relations de niveau inférieur qui contiennent cette polyligne. Il se contente de regarder l'admin_level qu'on lui a assigné localement, et ça suffit car il ne voudra pas charger tous les noeuds et toutes les polylignes de la relation parente qui sortent de son rectangle de tracé, cela prendrait trop de temps et trop de données. Il demande au serveur les objets contenus dans un rectangle et le serveur ne lui retourne que les noeuds dans ce rectangle, les polylignes qui ont une intersection dans ce rectangle. En fait parfois il en oublie si la polyligne n'a pour seule interection qu'un seule segment de droite entre deux noeuds qui ne sont pas dans le rectangle d'intérêt, ce qui parfois aboutit à des morceaux oubliés de lignes dessinées d'une tuile à l'autre; pour régler cela, si plus tard une autre tuile est analysée contenant un noeud dont un trait sort du cadre, il marque les tuiles extérieures comme étant à revisiter plus tard en tenant compte de nœuds trouvés dans une autre tuile; de ce fait il peut aussi "oublier" des relations contenant des polylignes avec ces segments oubliés; je pense, sans l'affirmer, que cela marche avec des listes d'attentes marquant chaque tuile à redessiner avec les numéros de tuiles voisines contenant des noeuds de la base ou des noeuds calculés sur des rendus de lignes épaisses, mais dont les données ont été mises à jour et sont à charger depuis la base OSM en plus de celles des noeuds tombant dans la tuile à redessiner, afin d'avoir des données suffisantes pour ne rien oublier). En conséquence, les tuiles se mettent à jour avec des décalages dans le temps, en plusieurs passes successives selon la longueur des files d'attentes de tuiles à redessiner. Mais on doit encore lui mâcher le travail trait par trait, pour minimiser le nombre de ces "oublis". _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
