Le 26 juillet 2013 07:54, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Une des remarques faites est que les cartes d'OSM France affichent > préférablement le français (donc Londres et pas London). >
Le projet TileMill est disponible sur github, il suffit de repartir de là et de faire les adaptations locales. > Pour une utilisation internationale, il faudrait afficher de préférence la > langue locale (voire plusieurs), qui devrait être le nom par défaut sans > suffixe de code langue (et, si ce n'est pas une langue officielle, une > version romanisée entre parenthèses, en français sinon anglais lorsque les > noms en langue locale ne sont pas en caractères latins, mais par exemple en > écriture arabe, hebreu, cyrillique, grecque, sinographique, ou une des > écritures indo-brahmiques) > > En conséquence une version internationale afficherait les noms français en > France et au Québec et Afrique fracophone, anglais au Royaume-Uni, en > Irlande aux USA et le reste du Canada, espagnol en Espagne et la majeure > partie de l'Amerique centrale et du Sud, portugais au Portugal et au Brésil, > suédois en Suède, etc. En Russie on verrait le nom russe suivi du nom > anglais entre parenthèses, en Chine le nom chinois sinographique suivi du > nom anglais (sinon du nom en romanisation pinyin), etc. > > Noter que c'est ce que font déjà Google Maps/Earth, Bing Maps (même si > Google maintenant essaye de localiser les noms dans la langue du visiteur). > > L'idéal serait d'avoir une couche de libellé transparente séparée du reste > du rendu (bien que les étiquettes de numéros de référence des routes ou > numéros de bâtiments dans les rues ne soient pas dépendants de la langue, > ils interfèrent entre eux et devraient aller aussi dans cette couche > transparente). > C'est un peu plus complexe que ça. Il faudrait une couche où tout les éléments "placés" figurent, c'est à dire, les libellés et références de routes, mais aussi les symboles (icônes) qui jouent aussi sur le placement de texte. L'icône d'un symbole (par exemple le bretzel d'une boulangerie) va "prendre" la place et un texte ne pourra pas être placé au même endroit. On ne peut donc pas dissocier les uns des autres si on veut quelque chose de cohérent au final. Il y a du coup une couche de fond (occupation des sols, routes, etc) sans placement, où chaque élément est superposé, et une couche "placée". > L'ennui c'est que multiplier les couches c'est aussi augmenter la place > nécessaire pour le stockage Une place qui peut être considérablemetn réduite > en la fabriquant non pas au format bitmap mais au format vectoriel (quitte à > inclure sur le serveur un rendu bitmap instantané à partir d'un pavage > cectoriel précalculé, au moyen d'un serveur proxy cache annexe, pour > permettre la compatibilité avec des visualisations sur navigateurs non > pourvus en capacité de rendu vectoriel. Ce serveur proxy pourrait aussi > combiner plusieurs couches pour produire à la volée une couche bitmap > unique, sans avoir à cacher la totalité des niveaux, avec une place disque > énorme (ce serait seulement un cache FIFO pouvant tenir entièrement dans un > seul SSD à prix modique, avec la moitié du cache pour les pavés sources > téléchargés du serveur de rendu OSM France, l'autre moitié du cache pour le > pavage précombiné). > > On n'exploite pas encore assez la possibilité de mutusliser les rendus avec > des caches intermédiaires pour des rendus transparents superposables, > pourtant cela permettrait des économies de bande passante sur les serveurs > et permettrait de répartir la charge, tout en augmentant même la réactivité > à terme, puisque les couches transparentes plus simples seraient plus > rapides à calculer et demanderaient moins de données depuis la base OSM. > Encore actuellement toutes les couches Mapnik sont calculées successivement > sur le même serveur de rendu qui effectue toutes les compositions. > C'est un peu la voie que j'ai exploré sur les faibles zooms, en déconnectant la couche de fond de la couche de détail même si c'était dans un autre objectif. C'est sûr que le vectoriel va rebattre les cartes, mais ne va pas non plus être une solution miracle, surtout à ce niveau de zoom. Les quantités de données manipulées sont très importantes et posera de nouveaux problèmes de volumes de données à tranférer et à traiter où alors on devra rester dans un rendu léger, qui ne devra choisir qu'un faible nombre d'objets à rendre ou alors faire de gros pré-traitements. > Le système de distribution du pavage n'est pas optimal en terme de capacité > et répartition de charge, car chaque serveur de rendu veut faire la totalité > du rendu lui-même et aucun ne veut collaborer pour travailler à plusieurs > pour construire un rendu final (pour pouvoir le faire il faudrait disposer > d'outils de mesure de la réactivité et la fraicheur de chaque serveur > participant, et une gestion fine des dates de péremption des caches, adaptée > à la capacité locale de stockage, de calcul, et de bande passante montante > et descendante). > On pourrait aussi faire une répartition géographique des serveurs de rendu et avoir un cache intelligent qui demande les tuiles à tel ou tel générateur de tuiles. -- 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
