<div class="gmail_quote">2011/6/30 sly (sylvain letuffe) <span dir="ltr"><<a href="mailto:sylvain@letuffe.org">sylvain@letuffe.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Pour moi, il est clair que cette solution à vraiment un bel avenir<br><br></blockquote><div><br>Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-)<br><br>Cette solution ne marche que pour de l'expérimental, à faible échelle et à faible nombre de clients. Parce qu'au lieu de calculer le rendu une fois pour toutes, on le fait pour chaque client et à chaque visite (il y a des optimisations possibles). Vous allez me dire "on s'en fout, c'est délocalisé chez le client". Oui, mais le client va faire une requête bdd pour chaque tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la demande de requêtes, celles-ci augmentant proportionnellement avec le nombre de clients. Alors que la solution classique avec tuiles ne nécessite cet effort (requête vers la base) qu'une seule fois (à part les actualisations fréquentes de données qui sont un problème spécifique à OSM).<br>
On va me dire : "oui mais on peut mettre tout ça en cache". C'est vrai. Mais il est plus facile et rapide de faire du cache d'images fixes (tuiles) que de données dont les requêtes (et les résultats) changent en permanence (niveau de zoom, type de rendu, position).<br>
<br>Pieren<br></div></div>