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

Répondre à