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] Orthophotos problème après màj JOSM
2009/7/17 Yann Coupin : démarré en Lambert (si un des auteurs du plugin me lis...). Yann Bon, il va falloir que je me réunisse avec moi-même pour faire un changement dans le plugin qui ne vérifiera la projection que lors d'une requête et plus au démarrage ;-) Pieren ___ 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] Orthophotos problème après màj JOSM
Ah c'est toi ! Je n'arrivais plus à retrouver (et encore moi me souvenir) à qui on devait le plugin. En fait il faudrait vérifier la projection au moment de dérouler le menu. Le reste marche bien. Yann Le 17 juil. 09 à 11:12, Pieren a écrit : > 2009/7/17 Yann Coupin : > démarré en Lambert (si un des auteurs du plugin me lis...). > Yann > > Bon, il va falloir que je me réunisse avec moi-même pour faire un > changement dans le plugin qui ne vérifiera la projection que lors > d'une requête et plus au démarrage ;-) ___ 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 - nou veau rendu
Hello ! Excellent, je voie que le travail avance ;-) J'ai juste une question d'ordre pratique au niveau des tags : Il me semble que pour le rendu de chemin pédestre tu n'utilise pas le tag sac_scale : http://beta.letuffe.org/?zoom=14&lat=46.35981&lon=7.16204&layers=0B000 Par contre ici je l'utilise : http://map.stephane-brunner.ch/?zoom=14&lat=46.35981&lon=7.16204&layers=B00TFTFFF0F Mais le problème est que normalement ce tag ne devrais être que sur les highway:path. Donc finalement ma question est comment mapper correctement un chemin pédestre baliser passant sur une route (situation relativement courante) et comment différencierai de manière correcte une chemin pédestre baliser d'une trace non balisée ? Merci d'avance Stéphane sly (sylvain letuffe)-2 (via Nabble) a écrit : > > > Pourquoi dire quelque chose quand il suffit de regarder : > http://beta.letuffe.org/?zoom=13&lat=45.44578&lon=5.926&layers=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 ;-) ) > -- View this message in context: http://n2.nabble.com/Gros-b%C3%A9ta-pour-les-randonneurs---nouveau-rendu-tp3272849p3274949.html Sent from the French OSM list mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osmose] est HS pour l'été
Salut, Le 17 juillet 2009 08:22, Vincent MEURISSE a écrit : > On Thursday 16 July 2009 23:41:42 Etienne Chové wrote: >> Il faudrait quelqu'un avec apache (+cgi), postgres et un tout petit peu >> de mémoire. Le front-end ne demande pas beaucoup de ressources. > Je peux fournir ça. Et comme j'ai pas de vacances je peux surveiller ça tout > l'été. Cool ! Il y a des docs quelque part qui expliquent comment mettre en place tout ça ? Amicalement, d. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotos problème après m àj JOSM
> > En fait il faudrait vérifier la projection au moment de dérouler le > menu. Le reste marche bien. > C'est une mauvaise idée de faire uniquement une vérification sur le déroulage du menu : que se passerait-il si on appuyait sur F11 (pas de menu!) ? ___ 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=14&lat=46.35981&lon=7.16204&layers=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 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=16&lat=45.44947&lon=5.92652&layers=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] [osmose] est HS pour l'été
On Friday 17 July 2009 01:57:10 pm David MENTRE wrote: > Il y a des docs quelque part qui expliquent comment mettre en place tout ça > ? Je suis en train de voir en privé avec Étienne. -- Vincent MEURISSE ___ 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) a écrit : > On vendredi 17 juillet 2009, Stéphane Brunner wrote: > > > > http://map.stephane-brunner.ch/?zoom=14&lat=46.35981&lon=7.16204&layers=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 > > 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=16&lat=45.44947&lon=5.92652&layers=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 - nouveau rendu
On vendredi 17 juillet 2009, OSM Léon wrote: > 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 On est d'accord, j'éssayerais de "pastéliser" mon relief dans la prochaine génération. Stéphane lui il triche ;-), il rajoute le layer mapnik d'osm.org par dessus avec une opacity ce qui fait que le rendu "beige" classique de osm.org du "quand il n'y a rien" rend le résultat plus clair, et finalement ça le fait ! > - idem pour les routes, c'est important en rando et là je les trouve trop > peu marquées problème de l'opacité appliqué à tout le rendu osm.org, alors qu'il faudrait appliquer un éclaircissement sur le relief uniquement. > - 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 J'ai peur que ça fasse guirlande de noël au niveau "beauté" > - 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é. chez moi ou chez lui ? 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" > - dommage que les cols ne soient pas rendus (ou alors le rendu/la bdd n'est > pas temps réel) chez moi ou chez lui ? > - même remarque pour les points de vue chez moi ou chez lui ? -- 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
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] Orthophotos problème après màj JOSM
Tu as raison il faudrait atrapper l'évènement de changement de proj dans le plugin pour décider à ce moment là si le plugin s'active... Yann Le 17 juil. 09 à 14:14, Julien D. a écrit : > En fait il faudrait vérifier la projection au moment de dérouler le > menu. Le reste marche bien. > > C'est une mauvaise idée de faire uniquement une vérification sur le > déroulage du menu : que se passerait-il si on appuyait sur F11 (pas > de menu!) ? > ___ > 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
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] Orthophotos problème après m àj JOSM
Ou mieux : activer la projection Lambert dès utilisation du cadastre et retour à la projection précédente juste après... C'est possible ? 2009/7/17 Yann Coupin > Tu as raison il faudrait atrapper l'évènement de changement de proj > dans le plugin pour décider à ce moment là si le plugin s'active... > > Le 17 juil. 09 à 14:14, Julien D. a écrit : > > En fait il faudrait vérifier la projection au moment de dérouler le > > menu. Le reste marche bien. > > > > C'est une mauvaise idée de faire uniquement une vérification sur le > > déroulage du menu : que se passerait-il si on appuyait sur F11 (pas > > de menu!) ? > ___ 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] Orthophotos problème après màj JOSM
2009/7/17 Julien D. > > Ou mieux : activer la projection Lambert dès utilisation du cadastre et > retour à la projection précédente juste après... > > C'est possible ? > +1 ou quelque chose du genre. J'utilise beaucoup Yahoo et le cadastre en même temps pour vérifier mes traces et jongler entre les deux coordonnées est tout simplement insérable. Est il possible que le plugin cadastre fasse lui même sa conversion en lambert quand on l'utilise sans changer le système de coordonnée de JOSM? Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotos problème après màj JOSM
On Friday 17 July 2009 11:41:32 am Yann Coupin wrote: > En fait il faudrait vérifier la projection au moment de dérouler le > menu. Le reste marche bien. C'est un coup à faire une crise de nerfs. Quand je clique sur un menu c'est pour le voir se dérouler, pas pour me prendre une popup dans la tronche. En plus la projection peut changer après avoir déroulé le menu. Il faut vérifier lors du rendu. C'est le seul moment où on peut être sur que la projection ne change plus (puisque une nouvelle projection provoquera un nouveau rendu). Sinon serai il possible que le plugin change lui même la projection ? Genre j'appuie sur , Josm passe automatiquement en Lambert. Je supprime le calque, je rajoute un calque Yahoo, Josm passe automatiquement en Mercator. Je ré appuie sur , Josm m'envoie balader en me disant que deux calques utilisent des projections incompatibles. -- Vincent MEURISSE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : SOTM dans le web de LIbéra tion
De : Eric Sibert C'est là: http://www.ecrans.fr/OpenStreetMap-les-routards-du-web,7695.html Dans les commentaires de l article quelqu un vient de poster cela "Une question comme ça: plutôt que de se faire chier à aller sur le terrain pour récupérer les informations, pourquoi ne pas simplement utiliser les données de google map par exemple? Je pense aux noms et numéros de rues, commerces, ... dans ces cas précis il est impossible pour google de savoir si ces infos viennent de leur base de données ou si elles ont effectivement été récupérées sur place." est ce que pieren ou promeneur qui ont deja cree un compte sur ce site pourraient lui repondre en expliquant le coup des erreurs volontaires tout ca. Julien / Q u i c k y ___ 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 - nou veau rendu
Hello, sly (sylvain letuffe)-2 (via Nabble) a écrit : > > > On vendredi 17 juillet 2009, Stéphane Brunner wrote: > http://map.stephane-brunner.ch/?zoom=14&lat=46.35981&lon=7.16204&layers=B00TFTFFF0F > > Whaou punaise, c'est carrément trop cool !! > Avec couverture du monde entier, s'il vous plait !! le monde entier mais seulement jusqu'au zoom 9 ! > > 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 ? ce qui n'est pas expliquer dans le lien en bas c'est que effectivement j'ai utiliser gdal_wrap pour rassembler différente images et ainsi créer des couches. un de ces 4 je vais compléter la doc mais, j'ai déga completer les différents scriptes que j'ai utilisé (j'espère que j'en ai pas oublier) http://www.stephane-brunner.ch/mediawiki/index.php/Map/Comment_est_g%C3%A9n%C3%A9r%C3%A9e_cette_carte#Fichiers_utilis.C3.A9 > > 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 > 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 ? Alors tu a du également mettre les path en rouge ce qui m'a perturbé ? > > 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. 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. > > 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=16&lat=45.44947&lon=5.92652&layers=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. Parfaitement d'accord. > - 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 c'est la que cela deviens scabreux car ce n'est pas une forcement route au sens des routes cycliste 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 ! > >> 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 > 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. bref je ne trouve pas satisfaisant :( En fouillant un peu j'ai trouver marked_trail mais qui est abandonné ! CU Stéphane -- View this message in context: http://n2.nabble.com/Gros-b%C3%A9ta-pour-les-randonneurs---nouveau-rendu-tp3272849p3275772.html Sent from the French OSM list mailing list archive at Nabble.com. ___ 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 - nou veau rendu
Hello ! OSM Léon (via Nabble) a écrit : > > > 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 C'est effectivement une bonne idée je vais regarder ça ;-) > > 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) a > écrit : > >> On vendredi 17 juillet 2009, Stéphane Brunner wrote: >> http://map.stephane-brunner.ch/?zoom=14&lat=46.35981&lon=7.16204&layers=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 >> >> 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=16&lat=45.44947&lon=5.92652&layers=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 > > > __ > View message @ > http://n2.nabble.com/Gros-b%C3%A9ta-pour-les-randonneurs---nouveau-rendu-tp3272849p3275264.html > > To unsubscribe from Gros béta pour les randonneurs - nouveau rendu, click > (link removed) == > -- View this message in context: http://n2.nabble.com/Gros-b%C3%A9ta-pour-les-randonneurs---nouveau-rendu-tp3272849p3275796.html Sent from the French OSM list mailing list archive at Nabble.com. ___ 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
[OSM-talk-fr] [tag] période historique
Bonjour, Pour éviter de créer une relation (qui ne doit pas être une catégorie ;-) pour le patrimoine historique quel tag utiliser, créer... Sur Besançon, on a cartographié des sites, bâtiments de la période romaine, de l'architecture militaire Vauban... Comment marquer ces éléments, (bâtits, ruines, remparts) au delà du tag historic:quelque-chose pour distinguer les périodes (romaines ou autre) les thèmes (architecture militaire...) Vincent ___ 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=17&lat=45.61271&lon=6.11817&layers=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
Re: [OSM-talk-fr] [résolu] Orthophotos problèm e après màj JOSM
Francois Van Der Biest a écrit : > Salut Frederic, > > Le document getCapabilities du serveur SITN annonce qu'il est capable > de servir en : > EPSG:21781 > EPSG:4326 > EPSG:54004 > EPSG:3785 > EPSG:9814 > Donc le problème ne vient pas du serveur, mais bien de JOSM ou du > plugin WMS, ou de sa configuration. > > Tu peux essayer de supprimer le paramètre SRS de l'URL du service dans > la conf du plugin : je crois qu'il l'ajoute automatiquement en > fonction de celle de JOSM. Oui c'est exact, mais ça ne fonctionne toujours pas... L'erreur n'est pas la même! Image couldn't be fetched: http://sitn.ne.ch/ogc-sitn-open/wms?version=1.1.1&request=GetMap&styles=&format=image/jpeg&layers=orthobbox=551700.0703110,215048.3071798,551908.6525682,215256.8894370&srs=EPSG:21781&width=499&height=499 http://schemas.opengis.net/wms/1.1.1/exception_1_1_1.dtd";> msWMSLoadGetMapParams(): WMS server error. Invalid layer(s) given in the LAYERS parameter. Mais j'y vois plus clair, le problème vient de l'url, il manque le "&" entre les paramètres layer et bbox. La version josm-tested 1788 à aussi ce comportement. Voici ma config cat ~/.josm/preferences | grep -b1 sitn 3099-wmsplugin.url.6.name=Ortho_NE_OK? 3133:wmsplugin.url.6.url=http://sitn.ne.ch/ogc-sitn-open/wms?version=1.1.1&request=GetMap&styles=&format=image/jpeg&layers=ortho Pour m'en sortir il suffit d'ajouter & à la fin de l'url Ce soir je n'ai pas le temps de finir les tests et de remonter le bug dans trac. Si qqun peut s'en charger ce serait sympa. Peut-être que c'est déjà fait... Bon WE > F. > > 2009/7/16 Frédéric Benninger : >> Bonsoir, >> >> J'ai un petit soucis avec JOSM, après une mise-à-jour vers la Révision >> 1797 je n'ai plus les même projection auparavant et du coups je n'arrive >> plus obtenir les données du wms. >> >> http://sitn.ne.ch/ogc-sitn-open/wms?FORMAT=image/jpeg&LAYERS=ortho&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326 >> >> J'ai vus que la grille suisse existe à présent dans JOSM, j'ai remplacé >> EPSG:4326 par EPSG:21781 de l'url ci-dessus mais ça ne fonctionne pas >> mieux. Voici un extrait de la console. >> >> [...] >> >> msWMSLoadGetMapParams(): WMS server error. Invalid SRS given : SRS must >> be valid for all requested layers. >> >> >> >> Image couldn't be fetched: >> http://sitn.ne.ch/ogc-sitn-open/wms?FORMAT=image/jpeg&LAYERS=ortho&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:21781bbox=552502.0095008,215693.5184874,552842.2200978,216033.7290844&width=499&height=499 >> >> [...] >> >> Help please >>Benni_75 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
