On jeudi 30 juin 2011, Pieren wrote: > 2011/6/30 sly (sylvain letuffe) <sylv...@letuffe.org> > > > Pour moi, il est clair que cette solution à vraiment un bel avenir > > > > > Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-)
Tant mieux ! ça ne serait pas drôle sinon, il faut bien confrontation pour avoir de nouvelles idées ou choses qu'on oublie. > optimisations possibles). Vous allez me dire "on s'en fout, c'est délocalisé > chez le client". on s'en fout, c'est délocalisé chez le client ;-) J'admet toutefois que sur un tel modèle, l'opération de rendu nécessite au final beaucoup plus de temps CPU total puisqu'en effet, elle est exécutée chez chaque client (navigateur) plutôt qu'une fois pour tous sur le serveur. Tout est question de comparer ce qu'il y a à gagner en fonctionnalité et ce qu'il y a à perdre en energie totale consommée > 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 Mmmm, je pense que tu perçois la requête comme une lourde tâche alors que ça n'est pas forcément le cas. Il est question ici de "tuiles vectorielles" c'est à dire de l'ensemble des données vecteurs (utile au niveau de zoom demandé) présentes sur un carré fixe, défini à l'avance, pas un truc genre WMS ou les données sont construites à la volée. Il est envisageable, je pense, d'en garder une version "en cache" de la même manière que les serveurs de tuiles gardent une version image en cache et de la servir au navigateur. On pourrait même imaginer se passer de base de donnée pour ce cache et stocker des fichiers du syle : /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir au client) > On va me dire : "oui mais on peut mettre tout ça en cache". C'est vrai. Oups, ça m'apprendra à lire le mail dans son entier, avant ;-) > 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). Pas forcément, voir plus haut le modèle auquel je pense. Qui, bien sûr, présente des défauts par rapport à la requête où on demande ce qu'on veut comme on veut sur une zone arbitraire. Cas typique du client qui ne veut afficher que les cours d'eau alors que la tuile contient forêt, cours d'eau, route, amenity, c'est à dire trop de données par rapport à l'affichage final souhaité -- sly qui suis-je : http://sly.letuffe.org _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
