[OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[sly (sylvain letuffe)]

On jeudi 30 juin 2011, Pieren wrote:
> 2011/6/30 sly (sylvain letuffe) <sylvain at 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