Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On jeudi 16 juillet 2009, Pieren wrote: Dommage que le relief ne couvre pas le massif vosgien (juste un ptit bout au sud). Mon but premier c'était la couverture alpes françaises/italiennes, puis pyrénéés. Dans le cadre de mon site http://www.refuges.info/nav/massif/56/vosges/ les vosges sont couvertes depuis quelques temps et j'aurais bien aimé... la prochaine fois, j'étendrais peut-être à toute l'europe, mais il faut faire quelques compromis. C'est déjà un peu plus typé rando, non ? Oui tout à fait, et ça semble un super coin ! PS: d'où viennent les contours ? Ce sont les données aster : http://asterweb.jpl.nasa.gov/gdem.asp Plus précises, mais également plus grosses encore que l'ancien SRTM que j'utilisais (pixel de 30m qui remplace un pixel de 90m) Bilan, je travail avec des fichiers géoTIFF de 3Go découpés en bandes, (là j'ai deux bandes) et il me manque un peu de RAM pour les traiter correctement (et surtout rapidement !) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Je dis ça, je dis rien, mais il y a de super lib en java pour bosser avec de super grosses images. Ça gère par exemple le fait de ne charger les images qu'au fur et à mesure et par morceaux. Pour faire ton traitement ça pourrait peut-être être utile. https://jai-imageio.dev.java.net/ Yann Le 17 juil. 09 à 11:08, sly (sylvain letuffe) a écrit : On jeudi 16 juillet 2009, Pieren wrote: PS: d'où viennent les contours ? Ce sont les données aster : http://asterweb.jpl.nasa.gov/gdem.asp Plus précises, mais également plus grosses encore que l'ancien SRTM que j'utilisais (pixel de 30m qui remplace un pixel de 90m) Bilan, je travail avec des fichiers géoTIFF de 3Go découpés en bandes, (là j'ai deux bandes) et il me manque un peu de RAM pour les traiter correctement (et surtout rapidement !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On vendredi 17 juillet 2009, Yann Coupin wrote: Je dis ça, je dis rien, mais il y a de super lib en java pour bosser avec de super grosses images. Ça gère par exemple le fait de ne charger les images qu'au fur et à mesure et par morceaux. Pour faire ton traitement ça pourrait peut-être être utile. Merci pour le lien, je pense (mais qu'en sais-je finalement ?) que j'utilise des outils relativement adaptés que sont les gdal tools, le plugin gdal de mapnik et l'outil de stéphane pour colorer et faire de l'ombre sur tout ça (utilisant la lib gdal toujours) Il faudrait que je script un peu tout ça, génère la section de style mapnik automatiquement et étende la zone. Le principal problème que je rencontre en traitant des images énormes, c'est, au delà des outils, le format même de l'image. Des images compressées style png et dans une moindre mesure jpeg ont un problème d'index interne. Mon image de travail fait 51950 x 20307, si je ne veux qu'un % de ça (selon la zone à afficher) il me faut un format d'image indexé, car la décompression total est impossible. Le format géotiff permet ça, pour la simple raison qu'il n'est en fait pas compressé : un pixel = 16 bits quoi qu'il arrive. La solution que m'avais conseillé stéphane et quelqu'un de la liste anglaise serait de faire une découpe moi même en plein de fichiers jpeg petits et de leur donner un index pour les géoréférencer dans le système mercator. C'est une de mes prochaines voies de recherches. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On s'est mal compris, je croyais que tu rencontrais des limitations techniques pour faire l'ombrage. Les deux solutions que tu évoque ont chacune leur avantage/ désavantage. Si le facteur limitant c'est les lectures depuis le disque alors la solution d'une myriade de petits JPEG est bonne, si c'est le CPU qui morfle alors le gros TIFF peut êre plus adapté. Enfin pour limiter l'usage du CPU et des IO, il peut-être interessant de stocker en TIFF/JPEG des images déjà redimentionnées au bon zoom. Il ne reste plus qu'à découper et tu ne lis plus depuis le disque 4x ou 8x le volume de données dont tu as vraiment besoin. Tout ça c'est pour rappel ; j'ai l'impression que je n'ai rien à t'apprendre et pourtant je me permet de te donner des conseils... Yann Le 17 juil. 09 à 12:04, sly (sylvain letuffe) a écrit : On vendredi 17 juillet 2009, Yann Coupin wrote: Je dis ça, je dis rien, mais il y a de super lib en java pour bosser avec de super grosses images. Ça gère par exemple le fait de ne charger les images qu'au fur et à mesure et par morceaux. Pour faire ton traitement ça pourrait peut-être être utile. Merci pour le lien, je pense (mais qu'en sais-je finalement ?) que j'utilise des outils relativement adaptés que sont les gdal tools, le plugin gdal de mapnik et l'outil de stéphane pour colorer et faire de l'ombre sur tout ça (utilisant la lib gdal toujours) Il faudrait que je script un peu tout ça, génère la section de style mapnik automatiquement et étende la zone. Le principal problème que je rencontre en traitant des images énormes, c'est, au delà des outils, le format même de l'image. Des images compressées style png et dans une moindre mesure jpeg ont un problème d'index interne. Mon image de travail fait 51950 x 20307, si je ne veux qu'un % de ça (selon la zone à afficher) il me faut un format d'image indexé, car la décompression total est impossible. Le format géotiff permet ça, pour la simple raison qu'il n'est en fait pas compressé : un pixel = 16 bits quoi qu'il arrive. La solution que m'avais conseillé stéphane et quelqu'un de la liste anglaise serait de faire une découpe moi même en plein de fichiers jpeg petits et de leur donner un index pour les géoréférencer dans le système mercator. C'est une de mes prochaines voies de recherches. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Les deux solutions que tu évoque ont chacune leur avantage/ désavantage. Si le facteur limitant c'est les lectures depuis le disque alors la solution d'une myriade de petits JPEG est bonne Ce sont des disques classiques donc ce qui est vachement limitant c'est l'accès à des petits fichiers ou des zones non contigu (problème de temps d'accès), pour des gros trucs ça va plutôt bien (genre 180Mo/s) Je le vois surtout au niveau de l'accès à la base de donnée où je tombe à ~2Mo/s c'est le CPU qui morfle alors le gros TIFF peut êre plus adapté. Pour en avoir le coeur net, il faudrait que je tente les deux. pour limiter l'usage du CPU et des IO, il peut-être interessant de stocker en TIFF/JPEG des images déjà redimentionnées au bon zoom. Yes ! c'est ce que j'ai commencé à faire. N'ayant pas trouvé l'option pyramidal des géotiff pour que tout ça soit automatique : http://iipimage.sourceforge.net/images.shtml Ben, je le fais à la main, dans le style mapnik, j'indique d'utiliser une de mes 3 images (qui sont toutes des versions rétrécies de la plus grosse) selon le zoom. Et ça éviter le chargement de 3Go d'image quand on est en zoom 0 pour n'afficher au final qu'un pauvre truc de 100 pixel (je dois tomber à 4 méga il me semble) Tout ça c'est pour rappel ; j'ai l'impression que je n'ai rien à t'apprendre et pourtant je me permet de te donner des conseils... Pas du tout, pas du tout ! Je suis très preneur de conseils, il y a certainement plein de trucs auxquels je n'ai pas pensé ou de manière différente de faire qui ne m'ont même pas traversé l'esprit. Comme dirait morphéus : Free your mind Et la confrontation d'idées me semble super bénéfique. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On vendredi 17 juillet 2009, Stéphane Brunner wrote: http://map.stephane-brunner.ch/?zoom=14lat=46.35981lon=7.16204layers=B00TFTFFF0F Whaou punaise, c'est carrément trop cool !! Avec couverture du monde entier, s'il vous plait !! Je ne savais pas que tu avais avancé à ce point, petit cachotier ;-) Sly le voleur d'idées : Je me dis qu'en plus clair c'est d'ailleurs moins agressif, tu pourrais me donner la ligne de commande utilisé pour color-shader les dem (à moins que ce soit une version plus récente de ton color-shade.cpp ? On ne voit aucun pixel, tu as fais des interpolations de fou avec gdal_wrap ? l'alti des courbes de niveau est un peu plus difficilement lisible, mais moins agressive que la mienne Finalement tu as fais un gros fichier mapnik xml avec plein plein de layer ou tu as regroupé ça dans un énorme géotiff ? tu peux me filer une copie du xml ? Excellent, je voie que le travail avance ;-) Je te retourne le compliment multiplié par 10 !! Il me semble que pour le rendu de chemin pédestre tu n'utilise pas le tag sac_scale : argh, me dis pas ça ;-) normalement si je l'utilise, aurais-je merdé sur mon style ? A ok, pigé, en fait, le chemin est taggué en sac_scale=mountain_hiking, et je ne représente pas les 6 niveaux de sac_scale, mais juste 3. J'ai considéré que rien, hiking, et mountain_hiking ne présentait pas suffisamment de difficulté/dangerosité technique pour mériter une représentation différente et sont donc représentés en trait plein. J'utilise ensuite deux échelles donc au total 3 représentations : T0/T1/T2 ou T3/T4 ou T5/76 : http://beta.letuffe.org/?zoom=16lat=45.44947lon=5.92652layers=0B000 correctement un chemin pédestre baliser passant sur une route (situation relativement courante) Je vois deux solutions : - Si le path est séparé de la route (quelques mètres) on fait deux ways séparés. - si le path est sur la route, alors ce n'est plus un path justement, et là, il faut ajouter ce morceau de route à une relation plus général type=route qui représentera par exemple chemin de X à Y et comment différencierai de manière correcte une chemin pédestre baliser d'une trace non balisée ? trail_visibility est fait pour ça, sauf que tu as raison, il ne s'applique par à une route, car une route ne semble pas difficile à suivre ;-) L'option serait d'étendre trail_visibility aux routes (pour la notion de marqueurs) ou de l'étendre aux relations de type route ou d'inventer un nouveau tag -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Sly le voleur d'idées : Oups, pas la peine de me répondre, j'avais loupé le petit info tout en bas que je suis en train de lire et qui semble bien complet -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
La vache, c'est excellent ! Je me permets quelques suggestions : - effectivement le relief en pastel je trouve ça mieux que sur la carte de Sly - par contre j'aimerai bien que les altitudes ressortent mieux - idem pour les routes, c'est important en rando et là je les trouve trop peu marquées - est-ce qu'il ne serait pas astucieux d'utiliser le code couleur des pistes de ski pour rendre compte de la difficulté des chemins ? + 2 types de pointillés noir pour les chemins qui sont à la limite de l'escalade - concernant les tracks, elles sont souvent utilisées en randonnée, serait-il possible de les rendre un peu plus larges que les paths ? Ca gagnerait en lisibilité. - dommage que les cols ne soient pas rendus (ou alors le rendu/la bdd n'est pas temps réel) - même remarque pour les points de vue En tout cas, encore bravo. D'ici quelques années on aura des cartes OSM de rando vraiment exploitables. Le 17 juillet 2009 14:34, sly (sylvain letuffe) sylv...@letuffe.org a écrit : On vendredi 17 juillet 2009, Stéphane Brunner wrote: http://map.stephane-brunner.ch/?zoom=14lat=46.35981lon=7.16204layers=B00TFTFFF0F Whaou punaise, c'est carrément trop cool !! Avec couverture du monde entier, s'il vous plait !! Je ne savais pas que tu avais avancé à ce point, petit cachotier ;-) Sly le voleur d'idées : Je me dis qu'en plus clair c'est d'ailleurs moins agressif, tu pourrais me donner la ligne de commande utilisé pour color-shader les dem (à moins que ce soit une version plus récente de ton color-shade.cpp ? On ne voit aucun pixel, tu as fais des interpolations de fou avec gdal_wrap ? l'alti des courbes de niveau est un peu plus difficilement lisible, mais moins agressive que la mienne Finalement tu as fais un gros fichier mapnik xml avec plein plein de layer ou tu as regroupé ça dans un énorme géotiff ? tu peux me filer une copie du xml ? Excellent, je voie que le travail avance ;-) Je te retourne le compliment multiplié par 10 !! Il me semble que pour le rendu de chemin pédestre tu n'utilise pas le tag sac_scale : argh, me dis pas ça ;-) normalement si je l'utilise, aurais-je merdé sur mon style ? A ok, pigé, en fait, le chemin est taggué en sac_scale=mountain_hiking, et je ne représente pas les 6 niveaux de sac_scale, mais juste 3. J'ai considéré que rien, hiking, et mountain_hiking ne présentait pas suffisamment de difficulté/dangerosité technique pour mériter une représentation différente et sont donc représentés en trait plein. J'utilise ensuite deux échelles donc au total 3 représentations : T0/T1/T2 ou T3/T4 ou T5/76 : http://beta.letuffe.org/?zoom=16lat=45.44947lon=5.92652layers=0B000 correctement un chemin pédestre baliser passant sur une route (situation relativement courante) Je vois deux solutions : - Si le path est séparé de la route (quelques mètres) on fait deux ways séparés. - si le path est sur la route, alors ce n'est plus un path justement, et là, il faut ajouter ce morceau de route à une relation plus général type=route qui représentera par exemple chemin de X à Y et comment différencierai de manière correcte une chemin pédestre baliser d'une trace non balisée ? trail_visibility est fait pour ça, sauf que tu as raison, il ne s'applique par à une route, car une route ne semble pas difficile à suivre ;-) L'option serait d'étendre trail_visibility aux routes (pour la notion de marqueurs) ou de l'étendre aux relations de type route ou d'inventer un nouveau tag -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ 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
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Un patch pour quoi faire ? Fait un bitmap avec des traces de pneu et utilise ça : http://trac.mapnik.org/wiki/LinePatternSymbolizer Yann Le 17 juil. 09 à 15:23, sly (sylvain letuffe) a écrit : Moi j'ai augmenté un peu l'épaisseur des tracks par rapport à mapnik bon d'accord 3 pixels au lieu de 2, je passerais peut-être à 4 ou 5, mais j'attends toujours la réalisation d'un patch pour mapnik afin d'obtenir un rendu style : = et = = = = = et : : : : : genre marques de pneu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Sauf que le TIFF n'est jamais lu en entier et donc il aura du seek aussi. Mais le volume total de données lues sera bien moindre. Yann Le 17 juil. 09 à 12:40, sly (sylvain letuffe) a écrit : Les deux solutions que tu évoque ont chacune leur avantage/ désavantage. Si le facteur limitant c'est les lectures depuis le disque alors la solution d'une myriade de petits JPEG est bonne Ce sont des disques classiques donc ce qui est vachement limitant c'est l'accès à des petits fichiers ou des zones non contigu (problème de temps d'accès), pour des gros trucs ça va plutôt bien (genre 180Mo/s) Je le vois surtout au niveau de l'accès à la base de donnée où je tombe à ~2Mo/s ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On vendredi 17 juillet 2009, Yann Coupin wrote: Sauf que le TIFF n'est jamais lu en entier et donc il aura du seek aussi. C'est vrai, mais j'utilise un mode du géoTiff qui s'appel TILED, et si j'ai bien compris (en tout cas je l'espère !) l'intérieur du Tiff est découpé en tuiles et si j'ai toujours bien compris, l'accès à une zone arbitraire ne devrait nécessiter qu'un nombre de seek très réduit pour choper les tuiles de la zone d'affichage. Contrairement à un Tiff classique sans l'option ou on trouve des rangées de pixels à la suite des autres. Mais le volume total de données lues sera bien moindre. Yann Le 17 juil. 09 à 12:40, sly (sylvain letuffe) a écrit : Les deux solutions que tu évoque ont chacune leur avantage/ désavantage. Si le facteur limitant c'est les lectures depuis le disque alors la solution d'une myriade de petits JPEG est bonne Ce sont des disques classiques donc ce qui est vachement limitant c'est l'accès à des petits fichiers ou des zones non contigu (problème de temps d'accès), pour des gros trucs ça va plutôt bien (genre 180Mo/s) Je le vois surtout au niveau de l'accès à la base de donnée où je tombe à ~2Mo/s ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On vendredi 17 juillet 2009, Yann Coupin wrote: Un patch pour quoi faire ? ça : http://trac.mapnik.org/ticket/180 et pouvoir dessiner deux lignes de 1 pixel de large décallées de chaque coté du centre de la route Fait un bitmap avec des traces de pneu et utilise ça : http://trac.mapnik.org/wiki/LinePatternSymbolizer Ho p, mais c'est pas con ça !! Je vais tenter le coup -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Alors tu a du également mettre les path en rouge ce qui m'a perturbé ? oui Personnellement j'ai rendu les sac_scales T1 à T3 en rouge, les T4 à T6 en bleu, T1 et T4 en trais continu, T2 et T5 en traitiller, T3 et T6 en traitiller plus long. Il me semble que c'est plus ou moins la norme de représentation habituelle. Si je me trompe dite le mois je ne suis pas douer en très haute montagne. Les cartes IGN utilisent le bleu pour les itinéraires de ski de randonnée et c'est la que cela deviens scabreux car ce n'est pas une forcement route au sens des routes cycliste Quand je lis le wiki, je comprends que type=route n'est pas dédié au cyclisme type=route + route=road / bicycle / foot / hiking / bus / ferry / canal /pilgrimage / detour / railway / tram / trolleybus / mtb (mountainbike) / roller_skate / running / horse / ... Y'a le choix ! numérotée mais un chemin qui viens de plusieurs endroit différents pour aller à plusieurs endroits différents qui passe à un moment donner par une route ! Alors je pense que je renseignerais autant de type=route + route=hiking qu'il y a de chemins virtuels qui passent, à la manière des lignes de bus. Mais c'est bien la que j'ai un problème c'est que ces tags sont penser en tant que route mais généralement les chemins pédestre sont penser en tant que réseau. En france on a un peu cette notion de réseau, mais ce que je ferais alors c'est d'ajouter un tag network=diablerets et de tager mes chemins dans le coins en : type=route + route=hiking + network=diablerets + name=Ascension du Wildhorn bref je ne trouve pas satisfaisant :( Je ne le suis pas non plus, ma solution en ajoutant trail_visibility ne fonctionne pas car le fait que ce morceau de rue (je dis rue car le français est merdique à confondre route et route) soit bien indiqué est local à ce morceau de rue, pas à toute la hiking route. Je flaire que étendre trail_visibility aux rues est le moins pire. Mais on perd la possibilité d'indiquer que telle hiking route est mal marqué sur ce tronçon de rue, alors qu'une autre hiking route est bien indiqué Ou alors, il faut sortir l'artillerie lourde et placer une relation appartenant à la hiking route, qui regroupe les morceaux de rues qu'elle emprunte et lui attribuer le tag trail_visibility pas simple -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
On vendredi 17 juillet 2009, Yann Coupin wrote: Un patch pour quoi faire ? Fait un bitmap avec des traces de pneu et utilise ça : http://trac.mapnik.org/wiki/LinePatternSymbolizer Nikel, ça le fait. La distorsion du png et la perte de l'antialiasing sont un peu dommage, mais ça reste très très correct. (Les intersections sont parfois un peu étranges, mais je me doute que mapnik ne sait pas comment j'ai fais mon image) http://beta.letuffe.org/?zoom=17lat=45.61271lon=6.11817layers=0B000 -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
Pourquoi dire quelque chose quand il suffit de regarder : http://beta.letuffe.org/?zoom=13lat=45.44578lon=5.926layers=0B000 Aller, si : ASTER : Nouveaux contours, nouveau ombrages, nouvelles données. La licence n'est donc pas l'habituelle NC-BY-SA, car leur utilisation est restreinte. OSM : style complété, qui affiche bien sûr le tag smoothness, les tags rando, des cols, des sources, des points d'eau, des altitudes, etc. * WARNING ** Bon, mollo tout de même sur les mouvements de cartes, la zone alpes Nord est à peu prêt dans le cache pour les zooms moyens, mais si ça commence à ramer à l'affichage, on calme le jeu et on revient plus tard car vous êtes sur une zone hors cache. Ou peinard on attend demain pour la répartition dans le temps (et les autres seront passés pour générer le cache pour vous ;-) ) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
sly (sylvain letuffe) wrote: Pourquoi dire quelque chose quand il suffit de regarder : http://beta.letuffe.org/?zoom=13lat=45.44578lon=5.926layers=0B000 Aller, si : ASTER : Nouveaux contours, nouveau ombrages, nouvelles données. La licence n'est donc pas l'habituelle NC-BY-SA, car leur utilisation est restreinte. OSM : style complété, qui affiche bien sûr le tag smoothness, les tags rando, des cols, des sources, des points d'eau, des altitudes, etc. * WARNING ** Bon, mollo tout de même sur les mouvements de cartes, la zone alpes Nord est à peu prêt dans le cache pour les zooms moyens, mais si ça commence à ramer à l'affichage, on calme le jeu et on revient plus tard car vous êtes sur une zone hors cache. Ou peinard on attend demain pour la répartition dans le temps (et les autres seront passés pour générer le cache pour vous ;-) ) J'ai fait un peu mumuse sur la zone Orleans et j'avais l'impression que c'etait bien plus rapide. Ais je encore des restes de Amsterdam dans le sang? Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros béta pour les randonneurs - n ouveau rendu
2009/7/16 sly (sylvain letuffe) sylv...@letuffe.org: Ouille ouille ouille ;-) C'est pas trop une zone typé rando, donc il ne doit pas y avoir des masses de tuiles en cache par là... Dommage que le relief ne couvre pas le massif vosgien (juste un ptit bout au sud). C'est déjà un peu plus typé rando, non ? Pieren PS: d'où viennent les contours ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
