<div dir="ltr">Le 19 août 2013 10:56, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span> a écrit :<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2013/8/18 Philippe Verdy <<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>>:<br>
<div class="im"><span style="color:rgb(34,34,34)">Dire que c'est un format d'image, c'est comme dire que</span><br></div>
.zip ou .tar sont des formats d'image.<br></blockquote><div><br></div><div>Non car MBTiles ne stocke que de l'image et pas des données quelconques. Ce n'est pas juste un fichier conteneur de base de données SQLLite, car il a un schéma imposé qui est *entièrment* basé sur le stockage d'image.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Franchement, il faut être un crack pour prédire à l'avance lequel des<br>
deux systèmes est le plus performant. Il y a aussi l'interaction avec<br>
le cache ram des tuiles qui atténue sensiblement les questions d'accès<br>
concurentiels en lecture.<br>
<br>
Pour en revenir à la question initiale, MBTiles est un format bien<br>
pratique pour échanger un ensemble de tuiles dans un seul fichier.<br>
Mais il l'est surtout si le destinataire peut directement s'en servir.<br></blockquote><div><br></div><div>Non. Ce n'est pas du tout un schéma adapté à l'échange. Il n'est adapté QUE dans le cas d'une utilisation concurrentielle avec à la fois de nombreux accès aléatoires en concurrents en lecture, et des accès concurrents aussi en écriture (mise à jour partielle facilitée). Bref uniquement pour un serveur de tuile destiné à une publication sur Internet avec de nombreux clients.</div>

<div><br></div><div>Ce format est totalement inadapté à une utilisation locale et pas efficace pour l'échange de fichiers. Il est très mauvais pour une utilisation embarquée (avec essentiellement un seul utilisateur, aucun accès concurrent, et même aucune mise à jour). Il est encore trop gourman en espace, comme en ressources de calcul. Ce format n'a pas été fait pour ça, et pour moi ce n'est qu'un tuning particulier, un format "rustine" pour résoudre, temporairement mais facilement, un problème de fond qui n'a pas été traité de façon optimale. La "rustine" est fortement liée à un certin type d'accès pour lesquels les systèmes de fichiers courants ne sont, actuellement, pas assez efficaces.</div>

<div><br></div><div>Pourtant le problème de fond est là et il est tout à fait possible de concevoir un format d'image efficace, sans cette solution "rustine" de contournement, et avec une bien meilleure densité d'informations, une meilleure prise en compte des flux d'accès (en lecture comme en écriture), une synchronisation possible (peu coûteuse en I/O et peu gourmande en verrous exclusifs), un mode transactionnel "optimiste" (et non pessimiste comme avec SQLite).</div>

<div><br></div><div>Rien que la couche SQLite nécessaire le rend inadapté à l'usage embarqué et l'échange. Il ne permet pas non plus la synchronisation en continu pour un déploiement en étoile (on y viendra : il y a un problème non résolu de prise en charge des caches vers l'aval, et c'est un problème d'échelonnabilité).</div>

<div><br></div><div>Je ne dis pas que MBTiles est une mauvais solution mais il faut le placer dans son usage actuel pour lequel il a été créé rapidement. Mais ce n'est pas la panacée et son utilisation hors d'un serveur de tuiles, installé sur un OS Linux ou Windows avec ses systèmes de fichiers standards qui ne savent pas gérer efficacement des dossiers *triés* par noms de façon hiérarchique (alors que les données sont organisées en deux dimensions non hiérarchisées, et même 3 dimensions si on considère le zoom, et avec de très fortes corrélations sur la troisième dimension).</div>

<div><br></div><div>Alors oui MBTiles ne me convainc pas, c'est juste une bonne solution actuelle qui marche à l'échelle actuelle du projet, et dans son mode de déploiement actuel (un déploiement pas optimal du tout, trop centralisé, avec un fort goulet d'étranglement qui ne permet pas une collaboration efficace et une réduction des coûts d'exploitation ou mise en oeuvre).</div>

<div><br></div><div>Pour moi le format d'échange idéal doit pouvoir utiliser directement un processus de type rsync, mais utiliser HTTP en mode pipeline, avec une seule session par utilisateur (et non 4 comme actuellement), et permettre de maximiser l'utilisation des proxies. MBTiles n'est pas du tout nécessaire sur cette architecture, quand on peut aussi bien utiliser les formats d'image standard (et se débarasser aussi des tuiles à taille unique, avec un protocole de requêtes permettant de réduire le nombre de transactions, en travaillant avec des "bandes" multiples et listes, et permettre aux serveurs et proxies de répondre dans le désordre et se répartir la charge entre eux).</div>

<div><br></div><div>Pour le transport des images retournées par les requêtes, PNG et JPEG fonctionnent très bien, mais il manque une phase de préparation d'images diférentielles. C'est une chaine de traitement graphique, utilisant des codecs adaptés à l'entrée et la sortie des interfaces de requêtes HTTP. Pour le stockage local et la mise en cache, MBTiles n'est pas bien adapté (et en fait, même si on l'utilise cela doit être invisible au niveau des interfaces d'échange, qui ne devraient même plus avoir à imposer aucune tailles de tuiles : on demande une zone au serveur, celui-ci doit pouvoir y répondre avec des images de taille quelconque couvrant la zone demandée, avec un débordement possible, en un ou plusieurs morceaux, en une ou plusieurs passes progressives, au choix du serveur, le client doit lui prendre en charge sa synchronisation, et même les serveurs entre eux pourraient s'épauler et être à la fois clients et serveurs des images qu'ils redistribuent).</div>

<div><br></div><div>Note que je découple dans cette vue totalement ce qui est l'interface d'échange (HTTP) de l'interface de sctockage pour les caches locaux.</div><div><br></div><div>Enfin je maintiens que les tuiiles actuelles telles que fabriquées par Mapnik ne sont pas efficaces : le système devrait générer deux couches séparées au minimum : une couche non redimensionnable (pour les fonds à couleur unie, le texturage final étant à la charge du client), et une couche nonredimensionnable si elle est en format bitmap (traits, libellés et icones).</div>

<div><br></div><div>- La première couche DOIT supporter un stockage, un transport, et un rendu progressifs (on inclura dedans les fonds d'imagerie photographiques)</div><div>- La seconde couche devra passer au mode vectoriel ; elle sera aussi scindée en deux entre une partie internationalisable (libellés et icones) et une qui ne l'est pas (ou ne dépend que de préférences de style) pour les traits ou les icones non dépendantes de l'utilisateur.</div>

<div><br></div><div>Dans ce schéma, MBTiles ne fonctionnera pas.</div><div><br></div><div><br></div></div></div></div>