Il y a une autre solution, déjà proposée par Mapquest, qui consiste à retourner à la demande en en une seule requête un assemblage de tuiles précalculées.
Cela génère une image unique directement, sans avoir besoin d'un format "exotique" comme MBTile (qui est un format d'image sauf qu'il est plus gourmand encore car l'image est décomposée en série de tuiles et contient un index; MBTile est économique surtout pour les carte maritimes ou déseriques où de nombreuses tuiles élémentaire seraient totalement identiques entre elles (uniformément unicolores), mais le format PNG (et même le format JPEG) inclue déjà une compression interne qui compresse déjà très bien ces zones formées de bandes de tuiles identiques. MBTile n'est intéressant en fait que pour le stockage de plusieurs niveaux de zoom avec de grandes similitudes entre les niveaux, si les niveaux sont compressés de façon différentielle (et à condition qu'il n'y ait pas trop de libellés car les tailles de polices des libellés ne suivent pas la règle de proportionnalité, et pas trop de routes non plus car elles aussi ont des largeurs de traits non proportionnelles). Il marcherait bien pour le stockage d'orthophotographie aérienne ou satellitaire, mais là encore JPEG et PNG incluent un support pour une compression en mode "progressif". Certes cela demande un peu de ressources sur le serveur qui doit réaliser l'assemblage (mais l'assemblage en bandes verticales est trivial et très peu coûteux, ce n'est pratiquement qu'une concaténation sans avoir à traiter les images sources ligne par ligne; à condition que les images sources utilisent les mêmes paramètres de compression (pas garanti avec JPEG où les tables de codage Huffman son différentes) et de palettes si ce n'est pas un stockage où les pixels codent directement la couleur (pas garanti avec PNG si il utilise une compression des couleurs par indirection via une palette spécifique à chaque image). MBTile ne m'a jamais bien convaincu, face aux formats de compression d'image d'aujourd'hui. Le 18 août 2013 16:53, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Aspirer les tuiles une à une est très peu efficace. Beaucoup de ressources > gâchées par des millions de requêtes HTTP pour récupérer à chaque fois > quelques dizaines de Ko. > > Il faudrait voir si on peut mettre à dispo un accès aux tuiles > précalculées dans des formats comme le MBtile (une base SQlite qui contient > les tuiles), voire une synchro des metatiles par sync. > > Le top de l'autonomie c'est bien sûr de mettre en place en local votre > propre serveur de tuiles... et sur une zone limitée (comme là où opère un > SAMU), ça ne nécessite pas d'énormes ressources. > > > Le 18 août 2013 15:28, HParv <talk-fr....@rramuhn.org> a écrit : > >> ici : http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png >> [image: http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png] >> >> >> A présent une question : j'ai noté que http://tile.openstreetmap.fr/était >> hébergé par Free (trop cool Free) sur des machines présentées en lien. >> >> Y-a-t-il des restrictions à prévoir en matière d'aspiration des tuiles ? >> Il s'agit de pouvoir assurer une autarcie de fonctionnement pour le système >> cartographique de plusieurs SAMU (aspiration centralisée et redistribuée >> par le système d'information multirégional). >> >> OSM , l'initiative qui réconcilie avec le genre humain ! >> >> >> *Bien cordialement,* >> -- >> Hugues P. GCS RRAMUHN >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > -- > 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
