Non on ne parle pas de la même chose: les métatuiles ne sont pas celles servies aux clients (accès en lecture à la base du serveur de tuiles), mais celles servies par les moteurs de rendu, qui sont beaucoup plus grosses (et quand un serveur de rendu calcule une métatuile il va donc stocker simultanément, ou de façon quasi-séquentielle, plusieurs tuiles juxtaposées. La solution actuelle n'est pas optimale. Même si MBTtiles a été développé comme une solution simple permettant de gérer efficacement la concurrence d'accès en lecture, elle n'est pas efficace du côté de l'accès en écriture par les serveurs de rendus (qui en font un usage quasi-séquentiel). Je parlais bien d'un format de fichier de grosse image car c'est de ça dont il s'agit : même s'il y a une surcouche SQLLite, la base reste dans un gros fichier unique (avec des accès concurrents nombreux et aléatoires en lecture, mais séquentiels en écriture). Ce format n'est pas adapté à une utilisation sur autre chose qu'un serveur de tuiles avec de nombreux accès clients concurrents. Il n'est pas efficace sur une utilisation embarquée (où presque tous les accès seront quasi-séquentiels avec très peu ou pas de concurrence. Je dirais que MBTiles est une solution intérimaire en attendant de développer quelquechose de mieux. Mais il n'est même pas efficace non plus en terme d'espace de stockage (là encore un problème pour une solution embarquée comme un navigateur mobile avec GPS). il est également couteux en énergie (autonomie) et CPU (la surcouche SQLite, même si elle est plus légère qu'un serveur SQL de premier plan, a un coût aussi). Sincèrement je pense qu'on peut faire nettement mieux mais que la solution n'a pas encore été développée ni tunée comme il le devrait. En attendant MBTiles/SQLite n'est pas la panacée et ne répond pas à toute une série de demandes et n'exploite pas au mieux les ressources qu'on a. Même la partie HTTP du serveur de tuile n'est pas optimale (l'utilisation de domaines multiples, au lieu d'utiliser le pipelining HTTP, est coûteuse sur les caches HTTP en aval, cela limite les possibilités de déploiement par proxies, et cela impose alors des restrictions d'usage beaucoup plus strictes que ce qu'on pourrait faire). Au final, les serveurs de tuiles ne savent pas monter en échelonnabilité, les usages limités vont aussi limiter la valeur ajoutée apportées par ce service, ce qui a en fin de compte un effet pervers sur la facilité d'accroitre les ressources par l'obtention de nouveaux moyens. Victime du succès, le service sature, et finalement se fait déborder. Ces restrictions d'usage sont finalement nuisibles au long terme pour le projet qui doit pourtant continuer à croitre ou bien s'étendra de lui-même faute de moyens.
Le 18 août 2013 22:27, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 18 août 2013 21:53, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> D'ailleurs le serveur effectue déjà un traitement graphique (ave >> nécessité de recompresser l'image produite) pour retourner des tuiles >> unitaires qu'ils stocke sous forme de métatuiles plus grandes, et je ne >> vois même pas pourquoi il ne peut pas retourner directement une "métatuile" >> entière directement sans aucun calcul. >> > > Sais-tu au moins ce que contient une "métatuile" ? > As-tu regardé le code de mod_tile/renderd pour vérifier avant de poster > ton message ? > > Une métatuile c'est à peu de chose près équivalent à un MBtiles (SQlite > mis à part)... ça contient des tuiles PNG de 256x256 pixels ! > Et heureusement car sinon à chaque demande de tuile, il faudrait > décompresser la metatuile de 2048x2048 pour recompresser un extrait de > 256x256... > > Un peu de lecture pour le confirmer : > https://github.com/openstreetmap/mod_tile/blob/master/src/gen_tile.cpp#L227 > > CQFD > -- > Christian Quest - OpenStreetMap France > Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
