Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation
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
Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation
Le 26 juillet 2013 09:10, Christian Quest cqu...@openstreetmap.fr a écrit : 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. Méfie-toi du terme il suffit affirmé trop vite ici. Certes au plan logiciel on a ce qu'il faut mais le principal obstacle ce n'est pas le logiciel mais le serveur pour sa disponibilité et la basnde passante. Pour héberger un simple site statique tout le monde a accès à des sites persos. mais pour un serveur de rendu c'est bien plus compliqué (et plus cher car il faut un serveur dédié à ça, l'autre solution de l'hébergement à domicile ne tenant pas la route pour servir à plus d'une poignée de personnes). Ta solution github ne concerne que la partie logicielle. L'autre solution c'est l'hébergement mutualisé, mais pour un serveur de rendu les solutions LAMP classiques ne peuvent pas prendre en charge les outils demandés, ou alors il reste des services mutualisés comme uMap, masi on n'a plus du tout le moindre contrôle de la solution technique (TileMill sur github ne servira à rien du tout). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation
L'avantage d'avoir tout le soft disponible sous licence libre c'est qu'on peut si on a les compétence et l'infrastructure matérielle adaptée monter ses propres service en indépendance et autonomie de fonctionnement. Bien sûr que le projet github ne suffit pas, mais au moins la partie soft est disponible. Ensuite soit on se charge de dégoter la partie hard, soit on se contente de ce que d'autres ont mis en place, sans garantie de service, etc, etc. Github permet au moins de multiplier le soft à l'infini, pour le hard il faut encore attendre ;) Le 26 juillet 2013 19:27, Philippe Verdy verd...@wanadoo.fr a écrit : Le 26 juillet 2013 09:10, Christian Quest cqu...@openstreetmap.fr a écrit : 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. Méfie-toi du terme il suffit affirmé trop vite ici. Certes au plan logiciel on a ce qu'il faut mais le principal obstacle ce n'est pas le logiciel mais le serveur pour sa disponibilité et la basnde passante. Pour héberger un simple site statique tout le monde a accès à des sites persos. mais pour un serveur de rendu c'est bien plus compliqué (et plus cher car il faut un serveur dédié à ça, l'autre solution de l'hébergement à domicile ne tenant pas la route pour servir à plus d'une poignée de personnes). Ta solution github ne concerne que la partie logicielle. L'autre solution c'est l'hébergement mutualisé, mais pour un serveur de rendu les solutions LAMP classiques ne peuvent pas prendre en charge les outils demandés, ou alors il reste des services mutualisés comme uMap, masi on n'a plus du tout le moindre contrôle de la solution technique (TileMill sur github ne servira à rien du tout). ___ 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
Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation
Une des remarques faites est que les cartes d'OSM France affichent préférablement le français (donc Londres et pas London). 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). 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. 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). Le 26 juillet 2013 07:10, Ista Pouss ista...@gmail.com a écrit : Use of OpenStreetMap France in another country http://gis.stackexchange.com/questions/67013/use-of-openstreetmap-france-in-another-country Il s'agirait des zooms 19 et 20 qui seraient l'avantage concurentiel international... Peut être faudrait-il mettre en plus le 21 pour enfoncer d'éventuels challengers ? -- Les dérives de rue : Étude de main sur la terre artistique en pleine chaleurhttp://drivrsdu.fr/etude-de-main-sur-la-terre-artistique-en-pleine-chaleur/ http://drivrsdu.fr/profession-emotion/ ___ 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
