Je maintiens entièrement ce que j'ai écrit. Et je connaissiasi déjà le sujet, pas la peine de me renvoyer à cette page.
MBTiles est bien un format d'image même s'il contient en interne des sous-images, son but est de stocker une image plus grande afin de pouvoir la servir facilement par morceaux sans avoir à faire des calculs compliqués. Mais c'est un format spécifique qui ne se justifie plus du tout. Bref tu me fais penser à ces journalistes qui ne lisent pas les sujets écrits par d'autres, juste pour en comprendre le principe de base et écrivent de belles critiques en prétendant que l'autre ne connait rien et n'a rien lu de sa part. C'est juste insultant, et je te renvoie l'insulte. Et oui cela a aussi bien à voir avec l'affichage progressif (note bien que je n'en ai parlé QUE dans le contexte du sockage de niveaux de zooms multiples). Dans les rendus 3D on utilise des formats progressifs pour les textures, ou des formats utilisant des textures mutliples avec des techniques dites de "mipmapping" avec ou sans stockage différentiel, avec ou sans interpolation et on parle bien du même sujet là aussi même si les techniques son différentes. Je renvient donc à la solution proposée par Mapquest qui s'avère efficace et peu couteuse sur le serveur surtout pour retourner des bandes verticales de tuiles plus grosses qu'une seule tuile unitaire, car il est possible de le faire sans aucune transformation compliquée et au fil de l'eau, et sans avoir à faire de nombreuses requêtes HTTP. Mapquest le propose pour composer des images de taille arbitraire (mais dans une limite de taille raisonnable). Il permet donc de réduire considérablement le nombre de requêtes : tout serveur devrait être capable de composer à la demande des images de taille plus importante que 256x256, et on devrait pouvoir lui demander aussi 1024x1024 et diviser le nombre de requêtes par 16. 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. Le 18 août 2013 21:31, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 18 août 2013 20:18, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> >> MBTile ne m'a jamais bien convaincu, face aux formats de compression >> d'image d'aujourd'hui. >> >> > ... pour la simple et bonne raison que MBtile n'est pas un format de > compression d'image, mais simplement un moyen de stocker des images (JPEG, > PNG, etc) dans un seul fichier (SQlite), de façon plus économe en espace > disque que sur les filesystem courants. La seule "compression" > additionnelle se fait sur les images absolument identiques (le bleu uni de > la mer par exemple). > > Il suffit de lire ne serait-ce que l'intro sur > http://www.mapbox.com/developers/mbtiles/ pour comprendre de quoi il > s'agit exactement, car ça n'a aucun rapport avec ce que tu écris comme les > compressions en mode progressif ou les palettes de couleur. > > C'est marrant, en te lisant ça me fait penser aux articles de journalistes > qui ne connaissent pas un sujet, mais qui écrivent de beaux articles. > > -- > 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
