[OSM-talk-fr] Prochaine réunion des contributeurs des Pyrénées-Orientales
La prochaine réunion des contributeurs des P.O. aura lieu le mercredi 24 avril 2013 de 18h à 20h à la Cyber Bodega, 26 rue de l'Avenir, 66000 Perpignan. Principales sujets : - organisation d'une cartopartie en mai/juin. - nos demandes de mise à disposition de données par la ville et l'agglo. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Philippe Verdy avait énoncé : Le 20 avril 2013 22:41, Plop76 vaujani...@free.fr a écrit : Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à utiliser le New tagging du wiki riverbank et à retirer le waterway=riverbank quand une partie n'est pas un vrai riverbank... Pourquoi la boucle Nord de la Sein qui traverse le centre de Royen ne serait pas un vrai riverbank ? Parce que si on garde le riverbank en chemin fermé, il y a une partie de riverbank qui coupe la Seine, pour faire la jonction avec les autres morceaux de la Seine. En quoi tu veux lui appliquer une autre politique par rapport au bras plus court et plus direct qui passe au Sud ? Je ne veux pas lui appliquer une autre politique :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Le 21 avril 2013 09:44, Plop76 vaujani...@free.fr a écrit : Philippe Verdy avait énoncé : Le 20 avril 2013 22:41, Plop76 vaujani...@free.fr a écrit : Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à utiliser le New tagging du wiki riverbank et à retirer le waterway=riverbank quand une partie n'est pas un vrai riverbank... Pourquoi la boucle Nord de la Sein qui traverse le centre de Royen ne serait pas un vrai riverbank ? Parce que si on garde le riverbank en chemin fermé, il y a une partie de riverbank qui coupe la Seine, pour faire la jonction avec les autres morceaux de la Seine. Et alors ? Ce cas est très fréquent sur de nombreux fleuves possédant des bras secondaires qui parfois forment des îles, même si le statut d'île ne te semble pas évident ici, à cause de la taille. La Seine dans ses méandres a beaucoup bougé dans son histoire (avec d'anciens lits aujourd'hui complètement disparus, naturellement ou comblés et occupés par l'homme). D'anciens lits principaux de la Seine sont aussi considérés aujourd'hui comme des lits principaux des affluents. Cela ne change pas les choses. Il y a des lits multiples, cela n'empêche pas que ce soit des riverbanks quand même, même si ce n'est pas évident de définir un sens d'écoulement (d'autant plus que la relative proximité de la Manche donne aussi une influence des marées avec des hauteurs et débits d'eau changeant 2 fois par jour, même si on ne voit pas d'eau de mer arriver jusque là ce sont les eaux de la Seine qui s'accumulent à marée haute, et se purgent à marée basse, plus ou moins sensiblement selon le régime total de la Seine en amont et l'importance des indices de marée en aval, et selon la régulation des débits créée par les écluses et barrages et le réglage des seuils et vannes sur les affluents du bassin versant et les canaux navigables qui traversent le tout en passant d'un bassin à l'autre). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag pour un toit en terrasse
2013/4/20 Agnès Rambaud agnesramb...@free.fr Comment peut-on indiquer un toit (de quelque chose, comme une habitation ou un garage) qui est aussi une terrasse ? Je ne trouve pas d'info particulière nulle part à ce sujet. On est au niveau du micro-mapping, peu courant dans OSM (surtout que la plupart des contributions sur le bâti vient d'images aériennes en dehors de la France). Dans l'import cadastral, ce genre de structure devrait porter les tags building=yes + wall=no. On pourrait les remplacer par building=roof: http://wiki.openstreetmap.org/wiki/Key:building Mais ce tag concerne des structures entières alors que je ne sais pas si tu parles juste d'un appendice (apparement oui d'après la question). Pour des appendices non fermés et rattachés à un bâtiment plus grand, il n'existe pas encore de consensus clair au niveau international. On pourrait imaginer un building=patio ou building=yes + patio=yes ou building:part=patio avec covered=yes (très peu d'exemples dans taginfo). Attention à ne pas utiliser le faux-ami building=terrace qui désigne les rangées de maisons comme on en voit dans certains quartiers ouvriers: http://wiki.openstreetmap.org/wiki/File:Terraced_housing.png Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Je doute que les marées de la Manche expliquent pourquoi ce label se balade totalement hors de la zone... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compte bloqué : je fais quoi ?
2013/4/20 Vincent Pottier vpott...@gmail.com Bonjour, Je ne peux toujours pas uploader des modifications : création de changeset impossible sur mon compte, modification impossible des informations sur ma page user... J'ai déjà ré-ouvert deux fois le ticket 4540 : https://trac.openstreetmap.**org/ticket/4540https://trac.openstreetmap.org/ticket/4540 Comme le suggère TomH à la fin, tu devrais ouvrir ton propre ticket, dire que ça se passe avec josm ou potlach avec des petits edits et expliquer que le problème ne date pas des dernières 24h (durée maximale d'ouverture d'un changeset). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Philippe Verdy a exposé le 21/04/2013 : Le 21 avril 2013 09:44, Plop76 vaujani...@free.fr a écrit : Philippe Verdy avait énoncé : Le 20 avril 2013 22:41, Plop76 vaujani...@free.fr a écrit : Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à utiliser le New tagging du wiki riverbank et à retirer le waterway=riverbank quand une partie n'est pas un vrai riverbank... Pourquoi la boucle Nord de la Sein qui traverse le centre de Royen ne serait pas un vrai riverbank ? Parce que si on garde le riverbank en chemin fermé, il y a une partie de riverbank qui coupe la Seine, pour faire la jonction avec les autres morceaux de la Seine. Et alors ? Et alors un riverbank là où dans la réalité il n'y a que de l'eau, je trouve pas ça logique. Je vois que dans le wiki qu'il y a une nouvelle façon de tagguer le lit des rivières sans utiliser waterway=riverbank en tant que surface : j'applique :) Ce cas est très fréquent sur de nombreux fleuves possédant des bras secondaires qui parfois forment des îles, même si le statut d'île ne te semble pas évident ici, à cause de la taille. On ne doit pas parler de la même chose, car le cas dont je parle est systématique lorsqu'il s'agit d'une étendue d'eau non fermée. À un moment il y a un bout de riverbank dans l'eau. Je parle du cas du chemin 4 ici : http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank#River_junctions Ça arrive à la jonction de rivières ou à la jonction de morceaux de rivières. J'ai rien contre mettre waterway=riverbank sur les chemins 3, 5, 6, 7 et 8, mais vu que le wiki dit de se méfier de l'utilisation de waterway=riverbank comme chemin non fermé, je ne rajoute pas ce tag sur les berges (et de toute façon ça n'aurait rien changé au bug :)) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réf.: Re: Réf.: Re: Réf.: Re: Liens de et vers OSM...
Bonjour, Quelqu'un (pas moi) peut-il faire un résumé de la situation ? Qu'est-ce qui est acté ou pas ou en débat ? Et par exemple (à vrai dire en toute sincérité ce qui m'intéresse) si ça vaut le coup que je présente ma proposition sur la page wiki ou si elle a été rejetée pour cause de trop vague, incompréhensible, implémentée trop vite et propriétaire ? Merci à elle/lui. Le 19 avril 2013 22:31, Emilie Laffray emilie.laff...@gmail.com a écrit : Le problème des geohash est un problème de précision et d'acceptation des limites du geohash. Car les geohash tels qu'ils existent actuellement sont extrêmement limités par le franchissement de la limite de précision. Autrement dit tu pourrais déplacer un point d'un mètre avec un geohash d'une précision de 1km et passer à quelque chose de complètement différent. Les geohash tels qu'ils existent actuellement ne sont pas vraiment utiles à mes yeux. Ils peuvent être utiles dans certains cas mais c'est limité par l'incapacité de créer un 'gradient' utile. Je trouve l'approche que tu proposes comme un bon début mais extrêmement limité. L'approche uuid mentionnée par Pieren et auquel j'ai participé était intéressante mais limitée sur d'autres points notamment les éditeurs. Tony a de bons points sur le fait qu'il faudrait savoir quel paramètres qualifier ce futur osmhash (dibs sur le trademark :) ). Je l'ai évoqué initialement sur le déplacement d'une entreprise et certains ont évoqués le changement de propriétaire. Un osmhash doit tenir compte de ça. Commençons par qualifier l'unicité d'un poi et penser à une composante geospatiale plus flou. L'intervention de Gael montre bien l'intérêt commercial d'un tel système ainsi que l'intérêt de Tony. Moi même à mapquest j'ai travaillé sur cette problématique afin de travailler sur la réconciliation de plusieurs sources (voir le commentaire de Marc sur le sujet et son expérience). Je ne dis pas que c'est impossible au contraire même mais sans poser certaines bases d'accord et des use cases on va tourner en rond. La communauté a les moyens d'être créative mais structurons un peu le propos pour gagner en clarté et voir les solutions non orthodoxes gagnées car les bases auront été jetées D'un point de vue commercial si un tel système se mettait en place ça aurait une très grosse valeur. Émilie laffray On 17 Apr 2013 18:07, Christian Quest cqu...@openstreetmap.fr wrote: #a4u2k9 dans mon exemple est un geohash... il correspond à une bbox qui est de plus en plus petite lorsque le geohash est long (et inversement). C'est un truc existant qui est même supporté en interne par postgis (ST_GeoHash). Pour ceux qui ne connaissent pas voir: http://fr.wikipedia.org/wiki/Geohash En y repensant avec un ID comme Croustillette.bakery.shop@#a4u2k9 permet de facilement faire du matching partiel... bakery.shop@#a4u2k une boulangerie dans une zone un peu plus grande, shop@#a4u2 correspond juste à une boutique dans une zone encore plus grande, etc... et une simple recherche textuelle en contient fait l'affaire ;) On peut aussi déterminer le niveau de similitude entre 2 ID assez facilement (longueur de la partie commune gauche, droite ou combinée). Tout ça se calcule facile sans faire appel à des API car le principe est universel et pas spécifiquement liée à OSM. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ 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 -- Les dérives de rue : Profession émotion http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
Je suis moi-même daltonien comme on dit, le terme plus exact étant deutéranope mineur? Ce cas n'est pas exceptionnel puisque les différences de vision des couleurs touchent 10 à 15% des hommes (plus d'ailleurs chez les Caucasiens autrement dit les personnes d'origine européenne, et plus les hommes que les femmes). Contrairement à ce qui est écrit un peu partout, le daltonisme ne crée que très rarement une vision bichromatique, et on conserve une palete de vision trichromatique différente du modèle chromatique standard qui n'est qu'une moyenne. La plupart du temps il n'y a pas absence d'un type de pigment chromatique mais seulement des déficits et surplus de certains types de pigments dans certains types de cônes ou battonets de a rétine, avec des taux de concentration surfacique différents. Bien des tests de daltonismes (les images de points colorés faisant apparaître ou pas des chiffres) donnent des résultats faux si on les interprète isolément. Tout à pour dire que malgré mon handicap (qui n'en est pas un puisqu'en revanche je dispose d'une différenciation chromatique plus importante pour d'autres couleurs), la différence de rendu est tout de même bien visible sur la carte notamment grâce à: - des différences de tonalité dans les couleurs de remplissage - des différences de contraste par le choix de la luminosité - une différenciation accentuée par le tracé de fins liserés plus sombres de part et d'autre du trait Là où c'est moins évident c'est quand les traits sont moins épais de sorte qu'on ne voit plus les liserés (moins d'1 pixel, ils se fondent dans le trait central en réduisant la différence de contraste. Malgré tout la couleur principal du trait forme un contraste suffisant par rapport aux forêts et vignes alentours. Certes il est difficile de savoir quelle est la couleur du trait, mais on voit qu'il contraste avec le fond dont on reconnait bien la couleur. Plus un tracé est fin, moins on perçoit les différences de couleur et plus on perçoit les différences de contraste. Cela veut dire que les fins détails ne devraient utiliser que des couleurs très sombres ou noirs sur un fond de couleur claire, ou très claires sur un fond sombre. Un autre phénomène est que la différenciation des couleurs à luminosité égale est plus accentuée entre deux couleurs claires qu'entre deux couleurs sombres : - Cela voudrait dire que les fins détails où la couleur revêt une importance, cas des routes, devraient être tracés en couleurs très claires, nettement plus claires que les aplats de couleur des terres (comme le fait Google Maps). - Là où la couleur a moins d'importance, cas des libellés, on prend le choix inverse et on les trace en couleur sombre sur les fonds moyens comme sur les tracés clairs des traits des routes, ce qui accentue leur lisibilité. Si la couleur des fonds n'est pas assez différencié en contraste avec celle du texte, on améliore la lisibilité du texte en l'affichant dans un halo semi-transparent plus clair (qui n'a pas besoin d'être lui-même plus important en épaisseur que la taille des détails des caractères, sinon ce halo risque de masquer trop de chose de l'arrière-plan : pour une taille de police de 9 à 12 points, un halo clair de 1 point suffit à rendre ce texte sombre très lisible). Si on respecte cette différenciation des contrastes par les méthodes de tracés améliorées (y compris par l'utilisation de techniques d'anticrénelage dans un modèle colorimétrique RGBA et non RGB seulement -- même sans utiliser le suréchantillonnage énormément plus coûteux en calcul et espace mémoire, le passage de RGB à RGBA ne coûtant que 33% de plus en espace et environ 50% de plus en complexité de calcul, contre 300% de plus à la fois en espace et en calcul pour un simple suréchantillonnage 2x2 qui ne parvient pourtant pas à des résultats aussi excellent !), on peut ensuite ajuster plus finement les palettes de couleur pour les aplats de fond. La tonalité des couleurs joue alors bien un rôle secondaire loin derrière une bonne gestion des contrastes sur ce qui est important de montrer dans une carte. Le 20 avril 2013 18:07, Pierre-Alain Dorange pdora...@mac.com a écrit : Christian Quest cqu...@openstreetmap.fr wrote: J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour permettre d'identifier le rendu FR comme provenant d'OSM. J'ai déjà modifié la couleur verte des trunks pour qu'elles soient plus contrastées sur les landuse de couleur proche mais ça peut sûrement encore s'affiner sans changer complètement le jeu de couleur. Je comprend, mais a mon avis, les trunks ne sont toujours pas du tout assez visible... Ils disparaissent litéralement, tout les autres axes routiers sont beaucoup plus visible, c'est un soucis de hiérarchisation amha. Sur l'exemple cité, on voit bien que la structure routière la ville de Saintes forme un arc sud clair, sur toutes les cartes... Sauf celle d'OSM ou il manque un bout qui est un trunk. Je dois être daltonien et le seul
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Pour Aydat, c'est fait ! S'il reste des trous identifiés -- View this message in context: http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.html Sent from the France 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] Source d'un label
Oui mais ce n'est pas le propos de ma réponse. (la cause était qu'un morceau de surface couverte d'eau n'était pas tracé, mais cela n'indique pas comment taguer ce morceau de surface couverte d'eau et pourquoi on doit ou pas le différencier). Le 21 avril 2013 10:35, Christian Quest cqu...@openstreetmap.fr a écrit : Je doute que les marées de la Manche expliquent pourquoi ce label se balade totalement hors de la zone... ___ 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] Source d'un label
Le 21 avril 2013 10:37, Plop76 vaujani...@free.fr a écrit : Ce cas est très fréquent sur de nombreux fleuves possédant des bras secondaires qui parfois forment des îles, même si le statut d'île ne te semble pas évident ici, à cause de la taille. On ne doit pas parler de la même chose, car le cas dont je parle est systématique lorsqu'il s'agit d'une étendue d'eau non fermée. À un moment il y a un bout de riverbank dans l'eau. Une étendue d'eau non fermée ça n'existe pas ! Même si pour le fermer il faut ajouter un segment virtuel (qui n'est pas une rive en français, car les riverbank ne désignent pas les rives mais seulement les limites d'une étendue d'eau, certaines étant des rives et d'autre non), et même si ce segment virtuel sera repris dans la définition d'une autre étendue d'eau mitoyenne pour la fermer elle aussi. Je parle du cas du chemin 4 ici : http://wiki.openstreetmap.org/** wiki/Tag:waterway%3Driverbank#**River_junctionshttp://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank#River_junctions Ça arrive à la jonction de rivières ou à la jonction de morceaux de rivières. J'ai rien contre mettre waterway=riverbank sur les chemins 3, 5, 6, 7 et 8, mais vu que le wiki dit de se méfier de l'utilisation de waterway=riverbank comme chemin non fermé, je ne rajoute pas ce tag sur les berges (et de toute façon ça n'aurait rien changé au bug :)) Effectivement mais cela ne change rien au fait que les riverbank dans la base OSM ne désignent des rives (définition normale du mot français) et qu'on ne doit les utiliser QUE pour désigner des surfaces fermées, donc: - soit un chemin fermé tagué en riverbank, - soit une relation multipolygone dont les chemins membres ne DOIVENT PAS eux-mêmes être des riverbank ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Philippe Verdy a exposé le 21/04/2013 : la cause était qu'un morceau de surface couverte d'eau n'était pas tracé C'est pas ce que j'ai compris... Quel morceau ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Le 21 avril 2013 11:44, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a exposé le 21/04/2013 : la cause était qu'un morceau de surface couverte d'eau n'était pas tracé C'est pas ce que j'ai compris... Quel morceau ? Le morceau de surface qui était tagué en natural=water+water=* (ce qui est totalement équivalent à un tag natural=riverbank, le changement de tag ne changeant strictement rien au problème et n'apportant strictement aucune amélioration), et qui en plus ne formait pas un polygone ou multipolygone fermé, ce qui ne permet effectivement pas de remplir la surface en bleu. Note qu'on a les même cas aux embouchures : la surface étendue d'eau (douce) devient mitoyenne de la surface étendue d'eau de mer : là encore ce n'est pas évident mais il existe bien un multipolygone pour la mer, même si on ne définit pas de relation pour elle, mais qu'on se contente de joindre les traits de coastline qui doivent avoir une orientation précise (pour ne pas avoir à chercher le côté interne ou externe en parcourant tous les chemins sur une bonne partie de la planète). Le dernier (multi)polygone natural=riverbank (ou natural=water+water=* ce qui ne change rien) de l'embouchure doit lui aussi se fermer mais en utilisant un trait tagué en coastline alors que ce trait n'est pas non plus une vraie ligne de côte ! Pour savoir si in a une vraie rive, il faut regarder quel type de polygone il y a de l'autre côté du trait de délimitation, vers l'extérieur du polygone. Ce n'est alors ni une rive ni une ligne de côte si de l'autre côté on a un autre natural=riverbank (ou natural=water+water=*), ou si on a de la mer (trait avec natural=coastline orienté dans le bon sens). Mais pour le tagging dans OSM cela ne change rien : ce qu'on tague réellement ce sont les surfaces qu'on DOIT fermer d'une façon ou d'une autre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Ce qui n'a plus rien à voir avec la question d'origine de ce fil de discussion... Le 21 avril 2013 11:26, Philippe Verdy verd...@wanadoo.fr a écrit : Oui mais ce n'est pas le propos de ma réponse. (la cause était qu'un morceau de surface couverte d'eau n'était pas tracé, mais cela n'indique pas comment taguer ce morceau de surface couverte d'eau et pourquoi on doit ou pas le différencier). Le 21 avril 2013 10:35, Christian Quest cqu...@openstreetmap.fr a écrit : Je doute que les marées de la Manche expliquent pourquoi ce label se balade totalement hors de la zone... -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Philippe Verdy avait énoncé : Le 21 avril 2013 11:44, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a exposé le 21/04/2013 : la cause était qu'un morceau de surface couverte d'eau n'était pas tracé C'est pas ce que j'ai compris... Quel morceau ? Le morceau de surface qui était tagué en natural=water+water=* (ce qui est totalement équivalent à un tag natural=riverbank, le changement de tag ne changeant strictement rien au problème et n'apportant strictement aucune amélioration), et qui en plus ne formait pas un polygone ou multipolygone fermé, ce qui ne permet effectivement pas de remplir la surface en bleu. http://www.openstreetmap.org/browse/relation/13820 ? Elle est fermée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Je ne suis pas convaincu que c'était cette relation. Vu la position du libellé qui est bien plus au nord, je pense qu'il y a un autre objet (non fermé lui donc invisible) dont le libellé apparaît là (position d'un centroïde calculé très probablement). Cet objet ne semble pas avoir été identifié. La discussion a démarré avant moi en disant que c'était cet objet uniquement parce qu'il utilisait un tagging comme natural=water+water=* au lieu de natural=riverbank, ce changement malgré tout n'est pas la cause du problème et n'apportant rien de plus par lui-même en terme de rendu attendu. Mais cet objet est trop loin de la position qui a été mentionnée au début. D'ailleurs je cherche toujours à voir où le libellé La Seine apparaît au milieu de nulle part, car pour l'instant je ne l'ai pas vu ! S'il n'est plus là, c'est qu'une correction a été faite (probablement sur un riverbank non fermé d'un affluent) Le 21 avril 2013 12:05, Plop76 vaujani...@free.fr a écrit : Le morceau de surface qui était tagué en natural=water+water=* (ce qui est totalement équivalent à un tag natural=riverbank, le changement de tag ne changeant strictement rien au problème et n'apportant strictement aucune amélioration), et qui en plus ne formait pas un polygone ou multipolygone fermé, ce qui ne permet effectivement pas de remplir la surface en bleu. http://www.openstreetmap.org/**browse/relation/13820http://www.openstreetmap.org/browse/relation/13820? Elle est fermée. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Source d'un label
Le 21 avril 2013 12:22, Philippe Verdy verd...@wanadoo.fr a écrit : D'ailleurs je cherche toujours à voir où le libellé La Seine apparaît au milieu de nulle part, car pour l'instant je ne l'ai pas vu ! S'il n'est plus là, c'est qu'une correction a été faite (probablement sur un riverbank non fermé d'un affluent) Autre cause possible : un segment de la Seine qui a été au début dupliqué par erreur sans que son auteur s'en aperçoive tout de suite (utilisation dans JOSM de CTRL+D au lieu de CTRL+ALT+D par exemple pour charger les relations dépendantes d'un chemin sélectionné), mais qui a depuis été supprimé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
C'est sûr que passer autant de temps à écrire n'en laisse pas beaucoup pour lire... Le voici le label étrange: http://www.openstreetmap.org/?mlat=49.4737mlon=1.131zoom=15layers=M Et tu peux douter qu'il provienne de la relation 13820 mais c'est un fait établi, vérifié... besoin d'une copie d'écran du rendu où l'id OSM remplace le name=* qui m'a servi à retrouver l'objet fautif ? Quelle étonnante capacité à écrire en avançant autant d'hypothèses sans rien vérifier. Il y a 2 bugs dans le rendu: - un bug dans la feuille de style OSM qui ne prend pas en compte les natural=water+ water=* qui du coup font apparaitre des labels indésirables, - un bug Mapnik sur le calcul de la position où placer le label dans le cas de multipolygones biscornus comme celui-là. En attendant la marée suivante... -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Il y a des endroits particuliers à faire pour aider ? Ou alors c'est pour le plaisir d'indiquer les villes importées ? ;) -- Jean-Baptiste Holcroft 2013/4/21 PhQ pierre.que...@sfr.fr Pour Aydat, c'est fait ! S'il reste des trous identifiés -- View this message in context: http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.html Sent from the France mailing list archive at Nabble.com. ___ 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] Rendu OSM-FR : couleurs highway
Philippe Verdy verd...@wanadoo.fr wrote: Je suis moi-même daltonien comme on dit, le terme plus exact étant deutéranope mineur [...] Je précise que ma remarque sur le daltonisme était une boutade, tout ce que tu écris est fort intéressant mais sans rapport aucun avec le sujet du forum, je zappe donc cette introduction... [...] Malgré tout la couleur principal du trait forme un contraste suffisant par rapport aux forêts et vignes alentours. Certes il est difficile de savoir quelle est la couleur du trait, mais on voit qu'il contraste avec le fond dont on reconnait bien la couleur. OK, je suis donc bien pas normal car sur l'exemple ci-dessous je vois par émerger naturellement et facilement la structure du réseau routier qui forme un anneau au sud de la ville. Pour moi le vert du trunk est tellement peu évident que je ne vois plus que (du premier abord) que l'axe nord-sud. https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf Là par exemple : http://osm.org/go/eqr4qlc- Je trouve pas du tout assez visible la N10 qui traverse du nord-est au sud-ouest que les axes secondaires (D731, D674) J'en conclus que je dois donc être une exception. Désolé de tout ce bruit pour rien. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
Je rejoins Pierre-Alain, tout particulièrement avec son dernier exemple : les routes vertes ressortent beaucoup moins bien que les autres ! Même les oranges ressortent mieux, alors qu'elles sont moins importantes... Francescu Le 21 avril 2013 13:34, Pierre-Alain Dorange pdora...@mac.com a écrit : Philippe Verdy verd...@wanadoo.fr wrote: Je suis moi-même daltonien comme on dit, le terme plus exact étant deutéranope mineur [...] Je précise que ma remarque sur le daltonisme était une boutade, tout ce que tu écris est fort intéressant mais sans rapport aucun avec le sujet du forum, je zappe donc cette introduction... [...] Malgré tout la couleur principal du trait forme un contraste suffisant par rapport aux forêts et vignes alentours. Certes il est difficile de savoir quelle est la couleur du trait, mais on voit qu'il contraste avec le fond dont on reconnait bien la couleur. OK, je suis donc bien pas normal car sur l'exemple ci-dessous je vois par émerger naturellement et facilement la structure du réseau routier qui forme un anneau au sud de la ville. Pour moi le vert du trunk est tellement peu évident que je ne vois plus que (du premier abord) que l'axe nord-sud. https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf Là par exemple : http://osm.org/go/eqr4qlc- Je trouve pas du tout assez visible la N10 qui traverse du nord-est au sud-ouest que les axes secondaires (D731, D674) J'en conclus que je dois donc être une exception. Désolé de tout ce bruit pour rien. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
J'avais parfaitement lu mais je ne le voyais **pas du tout** à cet endroit. Merci de montrer qu'il est bien encore là. Quelle étonnante capacité à chercher la polémique sans d'abord expliquer ce qui n'était pas clair. Le 21 avril 2013 12:36, Christian Quest cqu...@openstreetmap.fr a écrit : C'est sûr que passer autant de temps à écrire n'en laisse pas beaucoup pour lire... Le voici le label étrange: http://www.openstreetmap.org/?mlat=49.4737mlon=1.131zoom=15layers=M Et tu peux douter qu'il provienne de la relation 13820 mais c'est un fait établi, vérifié... besoin d'une copie d'écran du rendu où l'id OSM remplace le name=* qui m'a servi à retrouver l'objet fautif ? Quelle étonnante capacité à écrire en avançant autant d'hypothèses sans rien vérifier. Il y a 2 bugs dans le rendu: - un bug dans la feuille de style OSM qui ne prend pas en compte les natural=water+ water=* qui du coup font apparaitre des labels indésirables, - un bug Mapnik sur le calcul de la position où placer le label dans le cas de multipolygones biscornus comme celui-là. En attendant la marée suivante... -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ 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] Source d'un label
Et je sais pourquoi je ne le voyais pas, me^me en vérifiant: le label n'apparait qu'à un seul niveau de zoom et il m'a fallu raffraichir le tuile pour le voir, en vidant d'abord le cache de mon navigateur. Le label n'apparait pas quand on zoom plus avant. Alors je veux bien qu'il y ait un ou deux bogues mais il va falloir se demander pourquoi cela affecte ce niveau de zoom précisément, et pas plus avant car la position géographique calculée (avant projection dans les coordonnées en pixels de la tuile) est normalement la même. Aussi un niveau de zoom arrière, on voit le label mais dans une style différent, qui n'est plus celui d'une rivière ou d'un fleuve mais celui d'un lieu-dit. C'est ce qui me convint encore qu'il y a une autre anomalie dans les tags ou dans leur traitement, que tu n'as pas vu. Celle sur les natural=water+water=* au lieu de natural=riverbank n'a rien à voir puisque les deux sont déjà rendus de façon identifique (au moins aux niveaux de zoom élevés). L'anomalie semble spécifique de ces 2 niveaux de zoom qui ont des styles appliqués différents et des méthodes de rendu différentes pour les libellés. De toute façon c'est sur le rendu des libellés (leur sélection, leur positionnement optimal, leur dimensionnement, les styles de polices ou d'interlettrage, leur graisse et leur transparence pour ceux apparaissant en très gros, voire aussi le placement non nécessairement horizontal mais sur des diagonales ou courbes) qu'OSM, dans ses rendus Mapnik ou autres, doit faire encore beaucoup de progrès pour approcher un peu ce que savent faire à la perfection Michelin ou l'IGN ou les instituts cartographiques nationaux qui affinent les cartes patiemment à la main depuis des décennies, ou même (moins bien mais toujours mieux qu'OSM) Google Map et Bing Map. Souvent aussi MapQuest (et maintenant aussi uMap) fait mieux qu'OSM avec son rendu Mapnik sur ce point, à partir pourtant des mêmes données de base OSM. Michelin vient aussi de démontrer aussi qu'il savait le faire avec des données OSM; bref la compétence et le savoir-faire carto**graphique**, issu de longues traditions et du travail réalisé par des humains (qu'on peut qualifier d'artistes tellement les cartes obtenues sont belles tout en restant précises à leur échelle) et pas seulement par des heuristiques programmées encore balbutiantes, n'est pas du tout la même que la compétence et le savoir-faire en terme de collecte, de codification, de classement, de vérification et de mise à jour des données ; elle ne dépend pas non plus du soin apporté par ceux qui passent du temps à patiemment travailler le contenu de la base de données avec les outils d'édition ; comme dans OSM on dit qu'on ne tague pas pour le rendu, la tâche restant à faire derrière est immense. Un progrès significatif a été fait pour les libellés le long des frontières en les plaçant du bon côté et non par dessus. Mais pas pour les libellés des noeuds. Et pas plus dans la sélection des libellés à garder contre d'autres à masquer (notamment les noms de villes, villages et lieux-dits). L'essai en cours pour les libellés des noms de rue demande à être affiné, c'est parfois trop ambigu. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Le dimanche 21 avril 2013 à 13:05 +0200, Jean-Baptiste Holcroft a écrit : Il y a des endroits particuliers à faire pour aider ? peut etre les villes qui sont partiellement importées ? ou pas ? ( comme nimes ou pessac de souvenir d'un post recent) Ou alors c'est pour le plaisir d'indiquer les villes importées ? ;) L 1 n'empeche pas l'autre ;) didier -- Jean-Baptiste Holcroft 2013/4/21 PhQ pierre.que...@sfr.fr Pour Aydat, c'est fait ! S'il reste des trous identifiés -- View this message in context: http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.html Sent from the France mailing list archive at Nabble.com. ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
bonjour, personnellement, j'ai toujours trouv que c'tait le plus gros dfaut du rendu mapnik +1 donc un bleu/vert ? (vert canard fonc) djo_man Le 21/04/2013 13:44, Francescu GAROBY a crit: Je rejoins Pierre-Alain, tout particulirement avec son dernier exemple : les routes vertes ressortent beaucoup moins bien que les autres ! Mme les oranges ressortent mieux, alors qu'elles sont moins importantes... Francescu Le 21 avril 2013 13:34, Pierre-Alain Dorange pdora...@mac.com a crit : Philippe Verdy verd...@wanadoo.fr wrote: Je suis moi-mme "daltonien" comme on dit, le terme plus exact tant "deutranope mineur" [...] Je prcise que ma remarque sur le "daltonisme" tait une boutade, tout ce que tu cris est fort intressant mais sans rapport aucun avec le sujet du forum, je zappe donc cette introduction... [...] Malgr tout la couleur principal du trait forme un contraste suffisant par rapport aux forts et vignes alentours. Certes il est difficile de savoir quelle est la couleur du trait, mais on voit qu'il contraste avec le fond dont on reconnait bien la couleur. OK, je suis donc bien pas normal car sur l'exemple ci-dessous je vois par merger "naturellement" et "facilement" la structure du rseau routier qui forme un anneau au sud de la ville. Pour moi le vert du trunk est tellement peu vident que je ne vois plus que (du premier abord) que l'axe nord-sud. https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf L par exemple : http://osm.org/go/eqr4qlc- Je trouve pas du tout assez visible la N10 qui traverse du nord-est au sud-ouest que les axes secondaires (D731, D674) J'en conclus que je dois donc tre une exception. Dsol de tout ce bruit pour rien. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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] Rendu OSM-FR : couleurs highway
Le 21 avril 2013 13:34, Pierre-Alain Dorange pdora...@mac.com a écrit : Philippe Verdy verd...@wanadoo.fr wrote: Je suis moi-même daltonien comme on dit, le terme plus exact étant deutéranope mineur [...] Je précise que ma remarque sur le daltonisme était une boutade, tout ce que tu écris est fort intéressant mais sans rapport aucun avec le sujet du forum, je zappe donc cette introduction... Elle est totalement en rapport avec ton sujet qui est le choix des couleurs dans un rendu, lequel est TRES dépendant de la perception humaine des couleurs, beaucoup plus compliquée que ce qu'on croit. Le daltonisme trop souvent mal compris est pourtant très courant mais il ne se réduit pas aux descriptions faites dans Wikipédia ou même dans de soit-disant tests scientifiques qui donnent de faux résultats (si je prend l'article de Wikipédia qui donne des exemples de planches avec les points de couleur, ils sont TOUS faux dans leurs conclusion, même sur les planches d'origine. De même que les prétendus rendus de simulation de ce que perçoivent les daltoniens à partir d'une photo transformée. Il n'y a qu'une seule planche qui soit correcte dans l'article Wikipédia. Tout bonnement parce que les algorithmes de simulation pour tenter de reproduire les couleurs sur ordinateur sont carrément... complètement faux et ignorent aussi les bases de la colorimétrie ou les profils de calibration, et que nos écrans (ou ceux utilisés par les auteurs de ces simulations) sont, pour la plupart, non calibrés. (Et moi même je suis loin de tout savoir ou comprendre sur le sujet, n'étant pas affecté par toutes ses diverses formes, même si j'en ai la forme la plus commune. Ce qui n'est pas un handicap du tout mais me donne une vision juste originale un peu différente, me permettant de voir aussi des nuances bien réelles, confirmées par des tests, là où beaucoup d'autres n'en voient aucune, notamment dans les noirs et d'une façon générale en vision nocturne ou je perçois de mes yeux certains infrarouges et les champs électriques assez forts) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag pour un toit en terrasse
Le 21/04/2013 10:31, Pieren a écrit : 2013/4/20 Agnès Rambaud agnesramb...@free.fr mailto:agnesramb...@free.fr Comment peut-on indiquer un toit (de quelque chose, comme une habitation ou un garage) qui est aussi une terrasse ? Je ne trouve pas d'info particulière nulle part à ce sujet. On est au niveau du micro-mapping, peu courant dans OSM (surtout que la plupart des contributions sur le bâti vient d'images aériennes en dehors de la France). Dans l'import cadastral, ce genre de structure devrait porter les tags building=yes + wall=no. On pourrait les remplacer par building=roof: http://wiki.openstreetmap.org/wiki/Key:building Mais ce tag concerne des structures entières alors que je ne sais pas si tu parles juste d'un appendice (apparement oui d'après la question). building=roof c'est pour les toits sans murs, donc une structure ouverte. Ce n'est pas le cas ici : typiquement, un garage d'habitation (qui lui est bien fermé), attenant au bâtiment, et dont le toit plat fait office de terrasse pour l'appartement à l'étage. Ou encore, un toit d'immeuble (donc avec appartement dessous) qui est plat et est utilisé comme terrasse. Le building=roof ne convient pas du tout. Par contre j'ai trouvé roof:shapehttp://wiki.openstreetmap.org/wiki/Key:roof:shape=flat ici : http://wiki.openstreetmap.org/wiki/Simple_3D_Buildingspour caractériser le type de toit. D'après mon dico, on peut l'utiliser pour un toit en terrasse. Mais est-ce le sens indiqué dans ce cas ? (ou plutôt le fait que ce soit plat ?) Pour des appendices non fermés et rattachés à un bâtiment plus grand, il n'existe pas encore de consensus clair au niveau international. On pourrait imaginer un building=patio ou building=yes + patio=yes ou building:part=patio avec covered=yes (très peu d'exemples dans taginfo). Attention à ne pas utiliser le faux-ami building=terrace qui désigne les rangées de maisons comme on en voit dans certains quartiers ouvriers: http://wiki.openstreetmap.org/wiki/File:Terraced_housing.png Ok, et il est bien explicité dans le wiki. Pieren ___ 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] Source d'un label
Le 21 avril 2013 15:03, Philippe Verdy verd...@wanadoo.fr a écrit : Et je sais pourquoi je ne le voyais pas, me^me en vérifiant: le label n'apparait qu'à un seul niveau de zoom et il m'a fallu raffraichir le tuile pour le voir, en vidant d'abord le cache de mon navigateur. Le label n'apparait pas quand on zoom plus avant. Alors je veux bien qu'il y ait un ou deux bogues mais il va falloir se demander pourquoi cela affecte ce niveau de zoom précisément, et pas plus avant car la position géographique calculée (avant projection dans les coordonnées en pixels de la tuile) est normalement la même. Ce qui rentre en ligne de compte pour que cela affecte ou non un niveau de zoom donné : - la taille des metatuiles (8x8 tuiles, soit 2048x2048 pixels): est-ce que l'objet intersecte ou pas cette metatuile, donc aux zooms supérieurs à 15 le polygone n'intersecte plus la bbox de la metatuile et donc le label n'est plus là. - la feuille de style et ses règles de rendu.. et là il suffit d'aller lui rendre visite sur https://trac.openstreetmap.org/browser/subversion/applications/rendering/mapnik/osm.xml Que trouve-t-on ligne 4036 ? and (waterway is null or waterway != 'riverbank') un test spécifique sur riverbank... pour éviter de dessiner un label pour les riverbank, mais ce test ne tient pas compte des natural=water + water=river qui sont un équivalent récent de waterway=riverbank (voir le wiki: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank new tagging). C'est l'origine de l'apparition du label en zoom 14 sur le layer area-text... qui en plus dépend de la taille du polygone et du niveau de zoom (voir lignes 212-227)... sans oublier l'ordre de placement des textes car si la place est déjà prise, le label n'est pas rendu. Voilà pourqu'oi il n'apparait pas à tout plus de niveaux de zoom. Ensuite zoom 15... là c'est le layer text avec sa règle de rendu en bleu, taille 10 qui est ligne 350... et qui s'appuie sur la requête postgis qui est en ligne 4019 qui cherche entre autre des natural is not null... zoom 16 et suivant on est hors de la metatuile... C'est bon, assez détaillé comme explication du fonctionnement de la feuille de style XML ? C'est vrai que c'est pas super facile à comprendre. Il y a bien un problème avec la feuille de style OSM qui ne prend pas bien en compte les natural=water + water=river, mais uniquement les waterway=riverbank... qu'il est donc préférable de laisser en doublon (mais ça n'éliminera qu'un des deux labels indésirables, celui du zoom 14). Ca c'est pour le bug de la feuille de style OSM (et OSM-FR jusqu'à ce que j'en corrige une partie, je vais faire la deuxième maintenant). Le deuxième bug, je n'ai pas réussit à le cerner... c'est dans Mapnik que ça se passe et que le centroid calculé par mapnik pour le multipolygone retourné par postgis est complètement farfelu et que du coup ce label apparait très loin du multipolygone dont il est issu. Aussi un niveau de zoom arrière, on voit le label mais dans une style différent, qui n'est plus celui d'une rivière ou d'un fleuve mais celui d'un lieu-dit. C'est ce qui me convint encore qu'il y a une autre anomalie dans les tags ou dans leur traitement, que tu n'as pas vu. C'est le layer area-text ligne 214 + 4036 pour le zoom 14. Je l'ai bien vu, merci. Celle sur les natural=water+water=* au lieu de natural=riverbank n'a rien à voir puisque les deux sont déjà rendus de façon identifique (au moins aux niveaux de zoom élevés). L'anomalie semble spécifique de ces 2 niveaux de zoom qui ont des styles appliqués différents et des méthodes de rendu différentes pour les libellés. Rien compris. De toute façon c'est sur le rendu des libellés (leur sélection, leur positionnement optimal, leur dimensionnement, les styles de polices ou d'interlettrage, leur graisse et leur transparence pour ceux apparaissant en très gros, voire aussi le placement non nécessairement horizontal mais sur des diagonales ou courbes) qu'OSM, dans ses rendus Mapnik ou autres, doit faire encore beaucoup de progrès pour approcher un peu ce que savent faire à la perfection Michelin ou l'IGN ou les instituts cartographiques nationaux qui affinent les cartes patiemment à la main depuis des décennies, ou même (moins bien mais toujours mieux qu'OSM) Google Map et Bing Map. Souvent aussi MapQuest (et maintenant aussi uMap) fait mieux qu'OSM avec son rendu Mapnik sur ce point, à partir pourtant des mêmes données de base OSM. Oh ? uMap a sont propre rendu maintenant ? Tu as un lien pour qu'on puisse le voir ? Tout ce travail c'est la généralisation cartographique... comment partant d'une masse de données détaillées sélectionner les objets les plus utiles et faire le choix graphique approprié pour une carte dense en info mais lisible... Michelin vient aussi de démontrer aussi qu'il savait le faire avec des données OSM; bref la compétence et le savoir-faire carto**graphique**, issu de longues traditions et du travail
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
Le 21 avril 2013 15:21, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui n'est pas un handicap du tout mais me donne une vision juste originale un peu différente, me permettant de voir aussi des nuances bien réelles, confirmées par des tests, là où beaucoup d'autres n'en voient aucune, notamment dans les noirs et d'une façon générale en vision nocturne ou je perçois de mes yeux certains infrarouges et les champs électriques assez forts) C'est donc pour ça que tu vois tant de choses que le commun des mappeurs ne voit pas. Tout s'explique. Pour recentrer un peu le sujet, je suis d'accord avec Pierre-Alain, ce vert terne n'est vraiment pas très lisible. Une autre couleur ou une teinte plus flashy serait la bienvenue. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
Philippe Verdy verd...@wanadoo.fr wrote: [...] Elle est totalement en rapport avec ton sujet [...] Excuse moi mais non. Je répète, ma remarque daltonisme était une boutade (une blague), en aucun un sujet de discussion... Aussi intéressant soit-il. [...] Il n'y a qu'une seule planche qui soit correcte dans l'article Wikipédia. !? -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cadastre dans l'Yonne
Boujour à tous, J'aimerais savoir où en est la communauté de l'import du cadastre dans l'Yonne. Il reste des communes pour lesquelles le bâti n'a pas été importer et j'aimerais pouvoir contribuer dans le coin, notamment vers Vaudeurs. Vu que je ne maîtrise pas le plug-in d'import, je préfère m'en remettre aux spécialistes. Merci de me tenir au courant dès que vous avez des nouvelles. -- View this message in context: http://gis.19327.n5.nabble.com/Cadastre-dans-l-Yonne-tp5757967.html Sent from the France 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] Cadastre dans l'Yonne
Il y a relativement peu de communes avec un cadastre vectoriel dans l'Yonne :( J'en ai importé une partie en mappant le coin (c'est mon axe habituel... 94 - 77 - 89). Je m'en occupe... Le 21 avril 2013 18:05, Tony Emery tony.em...@yahoo.fr a écrit : Boujour à tous, J'aimerais savoir où en est la communauté de l'import du cadastre dans l'Yonne. Il reste des communes pour lesquelles le bâti n'a pas été importer et j'aimerais pouvoir contribuer dans le coin, notamment vers Vaudeurs. Vu que je ne maîtrise pas le plug-in d'import, je préfère m'en remettre aux spécialistes. Merci de me tenir au courant dès que vous avez des nouvelles. -- View this message in context: http://gis.19327.n5.nabble.com/Cadastre-dans-l-Yonne-tp5757967.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochaine réunion des contributeurs des Pyrénées-Orientales
Malheureusement je travail sur Durban et je n'aurai pas pas de moyen de locomotion, j'aurai aimé vous rencontrer mais ce n'est que partie remise. Je serait sur Durban pendant 2 semaines, j'en ai déjà profité pour apporter quelques amélioration sur la commune d'après ce que j'ai visuellement constaté sur place et je compte profiter de mon séjour pour améliorer cette zone rarement mise à jour. A défaut d'avoir un bâtit importable, je dessinerai approximativement les bâtiments public, commerce de proximité autre bâtiments recevant du public. Le 21 avril 2013 08:36, RainerU ra...@sfr.fr a écrit : La prochaine réunion des contributeurs des P.O. aura lieu le mercredi 24 avril 2013 de 18h à 20h à la Cyber Bodega, 26 rue de l'Avenir, 66000 Perpignan. Principales sujets : - organisation d'une cartopartie en mai/juin. - nos demandes de mise à disposition de données par la ville et l'agglo. ___ 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
[OSM-talk-fr] Rendu tile.openstreetmap.fr et nom dans relation multipolygone
Salut, Le Centre hospitalier de Cayenne n'est pas marqué par un H sur fond bleu dans le rendu FR (comme dans Mapnik d'ailleurs) tandis que les cliniques apparaissent. http://tile.openstreetmap.fr/?zoom=16lat=4.92122lon=-52.31659layers=B0F Mapquest affiche bien une image mais pas pour les cliniques. 2u affiche pour les deux. En fait l'étiquette (amenity=hospital) est dans une relation mulipolygone : 2 669 321. Bref, y aurait-il moyen de moyenner ? Faut-il que je crée un ticket ? @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
