J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent être générées selon une "stratégie" optimisée en fonction de la demande pour les zones géographiques données. Bref ce que l'on demande à des "machins" (*) qui répondent au doux nom de Renderd ou Tirex pour des tuiles image.
Je suis d'ailleurs curieux de savoir dans quelle mesure ces outils pourraient gérer ce genre d'objets. C'est peut être assez transparent puisque les tuiles image suivent le même arrangement géographique que les tuiles images. (*) dénomination adaptée à mes connaissances en la matière Le 30 juin 2011 14:49, sly (sylvain letuffe) <sylv...@letuffe.org> a écrit : > On jeudi 30 juin 2011, Pieren wrote: > > 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) > > -- > ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab> > "Il n'y a pas de pas perdus" >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
