Quel que soit la méthode de parcours des tuiles à rafraichir (pour les zooms faibles), il y aura toujours un décalage dans le temps quelquepart. On peut toutefois concevoir un parcours tel que le décala dans le temps soit maximale uniquement dans les zones à faible risque de changement : le centre des océans, ce qui placerait le point centraau milieu de l'Atlantique, en évitant de couper le Groenland et surtout l'Islande, et un peu plus haut que l'équateur pour couper autour du canal de Panama.
Ensuite le parcours idéal est non pas un parcours en bandes parallèles, mais en fractale type S (prenez un S dessiné à angles droits sur les bords d'un grille de 2x2 carrés, centré sur le point choisi; décomposez ensuite chaque segment bordant une case en redessinant un S réduit à 50% à la place de chaque segment, avec les rotations à 0°, 90°, 180° ou 270° appropriées, et récursivement de façon fractale). Là où la fractale sort du cadre maximum, éliminez les segments en trop et joignez ceux qui restent dans le cadre. Arrêtez la décomposition fractale quand vous atteignez la longueur minimale des côtés de carreaux voulus pour chacune des métatuiles de la liste à raffraichir. Cela ne change rien à la durée totale de parcours de toutes les tuiles, mais les rafraichissements sont alors groupés dans le temps par zone avec moins de risque de désynchronisation entre les données lues pour tracer l'une ou l'autre. On peut optimiser davantage en commençant par créer un parcours prédéfini pour chaque continent (puis en comblant les océans restants, avant d'y faire les zigzags de parcours en fractale S sur la totalité de ce parcours.... Encore mieux en tenant compte de la densité des données dans chaque "super-métatuile" à parcourir par métatuiles (en Europe la France très dense serait parcourue en entier avant de passer à l'Allemagne, la Belgique, les Pays-Bas, la Pologne, l'Espagne, l'Italie, la République tchèque...) Le serveur peut décider aussi sur les tuiles très denses de les repasser plussouvent : à mi parcours avant de faire la suite, il reprend à nouveau la France qui est parcourue deux fois plus souvent, ou bien seulement les tuiles les plus denses couvrant Paris, Lille, Marseille. Cependant cela ne sera jamais assez optimal tant qu'on utilise pas une autre stratégie : le parcours à plusieurs couches distinctes (le fond coloré mais vierge de segments et de libellés bougeant assez peu, il devrait être gardé en cache à plus long terme. Un autre cache stocke uniquement les dessins (sur fond transparent) des ways à moyen terme. Un autre ne stocke que les libellés et icônes. Pour le rendu final on combine les 3 couches rapidement sans avoir à charger et traiter beaucoup de données. Chaque couche ayant son propre parcours indépendant des métatuiles à couvrir. Dans le cache de la couche des métatuiles de libellés, on peut y stocker une table des tous les libellés candidats avec une note d'évaluation de sa priorité en cas de collisions et leur taille calculée en fonction du style de police et de l'orientation souhaitée du libellé. Avec cette méthode il est plus facile de parcourir plus souvent la surcouche des libellés et de les parcourir tous assez vite. Il est possible de répartir le travail sur plusieurs serveurs gérant chaque couche, et de les laisser alors faire les parcours à leur rithme, sans s'occuper de ce qui ne les concerne pas: chacun aura moins de données à charger et combiner. Un autre serveur surveilles les métatuiles de chaque surcouche pour former les combinaisons superposées. Ce serveur peut ausis utiliser le parcours prédéfini ou simpelment un parcours à file LRU. Chaque "serveur" peut n'être aussi qu'un processus séparé sur la même machine. Si plusieurs machines sont utilisées, elles se répartissent le travail en prenant des jetons d'accès à la file de parcours, avec une limite de temps imposée pour terminer la sous-tâche prise en jeton, (sinon la sou-tâche repasse en tête de file d'attente (le parcours idéal étant hors file d'attente, la file toute entière étant toujours en dernière position de la file d'attente. Le 2 mars 2015 11:28, Otourly Wiki <otou...@yahoo.fr> a écrit : > Le rendu Mapquest est aussi impacté par le phénomène le prolongement de > l'A89 vers Tarare n'apparait pas dans les zoom les plus faibles. ça saute > au yeux... > > Florian > > > Le Lundi 2 mars 2015 11h22, erwan salomon <r...@gmx.fr> a écrit : > > > ok tout s'explique > 2 mois pour refaire les tuiles du niveau 7 ? > à noter que le même phénomène ce produit pour le rendu FR et le rendu HOT > (niveau 9 du côté de London), rien de spécifique donc > les tuiles sont recalculées à partir du méridien 0° en faisant le tour ou > c'est plus aléatoire ? > si oui et si c'est paramétrable on pourrait choisir un autre méridien de > départ qui comporterait moins de détails susceptible d'être coupé pendant 2 > mois (aux alentour de -30° par exemple) > > Le 2 mars 2015 à 11:03, Philippe Verdy a écrit : > > On a demandé de relever les anos qu'on voit... > Le niveau 7 de toute façon est très en retard et pas du tout synchrone : > les tuiles ouest du méridien 0 datent de mi-décembre, celles de l''est date > du 20 février il y a une semaine (avant le changement de style) bref elles > sont toutes à recalculer mais pas encore faites. > > Le 2 mars 2015 11:00, JB <jb...@mailoo.org> a écrit : > > 14 courriels aujourd'hui et il est pas encore 11h (du matin) ? > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
