Re: [OSM-talk-fr] Taguer les terrains vagues
Sur un thème voisin : les coupes rases (totales) de forêts privées dont on ne sait pas si les propriétaires vont les reboiser, les laisser à l'abandon ou les dessoucher pour un retour au pastoralisme voire à la culture.. Pour ma part je tague par .. une absence de tag, c'est à dire que je désaffecte la zone. Bien sur au bout d'un certain temps, on peut constater le retour de la végétation naturelle, rejet, broussaille. -- natural=heath Et suivant l'évolution naturelle (20 30 ans plus tard) --- natural=wood. Si le terrain bénéficie d'une replantation (ça peut prendre un ou deux ans), on reste dans le landuse=forest. -- View this message in context: http://gis.19327.n5.nabble.com/Taguer-les-terrains-vagues-tp5484076p5485285.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] Taguer les terrains vagues
Bonjour, C'est d'ailleurs dommage de ne pas pouvoir faire de distinction entre plantations forestières alignées (type peupleraies ou autres) et forêts gérées par des coupes mais sans plantation particulière : landuse = forest for all ! Samy le 15/02/2012 09:49, PhQ a écrit: Sur un thème voisin : les coupes rases (totales) de forêts privées dont on ne sait pas si les propriétaires vont les reboiser, les laisser à l'abandon ou les dessoucher pour un retour au pastoralisme voire à la culture.. Pour ma part je tague par .. une absence de tag, c'est à dire que je désaffecte la zone. Bien sur au bout d'un certain temps, on peut constater le retour de la végétation naturelle, rejet, broussaille. -- natural=heath Et suivant l'évolution naturelle (20 30 ans plus tard) --- natural=wood. Si le terrain bénéficie d'une replantation (ça peut prendre un ou deux ans), on reste dans le landuse=forest. -- View this message in context: http://gis.19327.n5.nabble.com/Taguer-les-terrains-vagues-tp5484076p5485285.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] Taguer les terrains vagues
Bonjour, Wikipedia (fr) propose friche industrielle, pour la traduction de brownfield. A la lecture de l'article brownfield land en anglais, une friche industrielle correspond à l'usage américain du terme. En anglais UK, il semble avoir un sens beaucoup plus générique qui pourrait justement se traduire par terrain vague Pour le projet OSM, c'est l'anglais UK qui prévaut, en cas de nuance linguistique US / UK. la balise landuse = brownfield me semble donc bien adaptée pour parler d'un terrain vague Extrait de http://en.wikipedia.org/wiki/Brownfield_land *In the United States http://en.wikipedia.org/wiki/United_States urban planning http://en.wikipedia.org/wiki/Urban_planning jargon, a brownfield site (or simply a brownfield) is landhttp://en.wikipedia.org/wiki/Real_property previously used for industrial http://en.wikipedia.org/wiki/Industry purposes or certain commercial uses. The land may be contaminated by low concentrations of hazardous waste http://en.wikipedia.org/wiki/Hazardous_waste or pollution http://en.wikipedia.org/wiki/Pollution, and has the potential to be reused once it is cleaned up. * *(...)* *In the United Kingdom http://en.wikipedia.org/wiki/United_Kingdom and Australia http://en.wikipedia.org/wiki/Australia, the term applies more generally to previously used land.* précise, mais pas trop ! Le 15 février 2012 00:15, Philippe Verdy verd...@wanadoo.fr a écrit : Plutôt wasteland en anglais. Mais on en parle dans le wiki sur Tag:landuse=brownfield et dans Tag:landuse=construction. Pour moi les browfields sont des zones laissées à l'abandon, autrefois occupées, souvent avec des ruines. Un vrai terrain vague est resté une zone naturelle, autrefois peut-être une terre agricole qui s'est retrouvée enfermée dans un paysage urbanisé, mais qu'on a décidé de laisser à l'état vert, sans forcément l'aménager comme un vrai parc. Leur avenir est incertain tant la pression urbaine voudrait les lotir. Mis certaines communes ont pris les devants pour justement ne pas y autoriser la construction, et au moins les protéger pour éviter qu'elles se transforment en décharges (ce que pourrait évoquer le terme anglais wasteland). Difficile à mapper. Car s'il y a une vraie protection, les communes préfèrent en faire de vrais parcs nettoyés, et pas squattés, même si les cultures restent encore assez sauvages (hautes herbes, arbres désordonnés, talus, ronces... car ce sont des terres intéressantes surtout en zone humide pour la nidification, et les petites espèces de rongeurs que pourtant on supporte mal dans nos villes, alors que ce sont de grands nettoyeurs !) Le 14 février 2012 23:38, Pieren pier...@gmail.com a écrit : 2012/2/14 Séverin MENARD severin.men...@gmail.com: Jee n'ai pas trouvé dans les map features un tag pour les terrains vagues en milieu urbain. landuse=brownfield/greenfield ? 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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osm et le Geocaching
Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ -- View this message in context: http://gis.19327.n5.nabble.com/Osm-et-le-Geocaching-tp5485363p5485363.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] Osm et le Geocaching
Le 15 février 2012 10:19, PhQ pierre.que...@sfr.fr a écrit : Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ Il y a 2-3 specimens qui valent le détour, d'autant que le choix par défaut n'est pas OSM (qui était déjà dispo en option) mais MapQuest. Cela dit, je ne pense pas que mettre ainsi en avant OSM pour un service mondial soit une très bonne idée à l'heure actuelle, tant la couverture est encore inégale, surtout dans les zones rurales. Fanny ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Et dans les commentaires, Robby est bien le plus croquignolet des trolls que j'ai pu observer en liberté. Blague à part, il a une approche d'utilisateur final qu'on retrouve fréquemment quand OSM est mentionné sur des sites de technophiles (Clubic, Journal du geek ...). Sur certaines zones pauvres en contributions, cela peut être douloureux d'annoncer à quelqu'un qu'il va devoir mettre la main à la pâte pour arriver au même niveau de détails que ce qu'il avait tout cru sous la main grâce à Google Maps. Mais dans l'histoire, c'est surtout auprès de Google qu'il devrait se plaindre Le 15 février 2012 10:19, PhQ pierre.que...@sfr.fr a écrit : Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ -- View this message in context: http://gis.19327.n5.nabble.com/Osm-et-le-Geocaching-tp5485363p5485363.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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ Il y a 2-3 specimens qui valent le détour, d'autant que le choix par défaut n'est pas OSM (qui était déjà dispo en option) mais MapQuest. Cela dit, je ne pense pas que mettre ainsi en avant OSM pour un service mondial soit une très bonne idée à l'heure actuelle, tant la couverture est encore inégale, surtout dans les zones rurales. au contraire, c'est un gisement de fourmi qui battent déjà la campagne pour le plaisir. ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Bonjour, De : Fanny Schertzer Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ Il y a 2-3 specimens qui valent le détour, d'autant que le choix par défaut n'est pas OSM (qui était déjà dispo en option) mais MapQuest. Cela dit, je ne pense pas que mettre ainsi en avant OSM pour un service mondial soit une très bonne idée à l'heure actuelle, tant la couverture est encore inégale, surtout dans les zones rurales. Je trouve au contraire que c'est une bonne idée, même si sur certains territoires un peu vides c'est une idée, disons... courageuse. Même si la motivation de départ semble être économique (le nouveau modèle de tarifs de Google) le fait est que geocacching.com assume le passage à OSM. Et vu le public, on peut attendre quelques nouveaux contributeurs avisés. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Le 15 février 2012 10:27, Fanny Schertzer fanny.schert...@gmail.com a écrit : Le 15 février 2012 10:19, PhQ pierre.que...@sfr.fr a écrit : Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ Il y a 2-3 specimens qui valent le détour, d'autant que le choix par défaut n'est pas OSM (qui était déjà dispo en option) mais MapQuest. Mapquest c'est un moteur de rendu de la base de données OSM... CQFD. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
De : Philippe Verdy Mapquest c'est un moteur de rendu de la base de données OSM... CQFD. Mapquest s'appuie selon le cas sur des données OSM (open.mapquest) ou Navteq (www.mapquest). Dans le cas présent geocaching.com prend les tuiles Mapquest basées sur OSM, mais ne crédite pas les contributeurs OSM lorsque le style de rendu est celui de Mapquest. Il faut basculer sur les styles qu'ils appellent OpenStreetMap, CloudMade ou OpenCycleMap pour voir le crédit OSM sur les données. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Taguer les terrains vagues
2012/2/15 Ab_fab gamma@gmail.com: Bonjour, Wikipedia (fr) propose friche industrielle, pour la traduction de brownfield. A la lecture de l'article brownfield land en anglais, une friche industrielle correspond à l'usage américain du terme. En anglais UK, il semble avoir un sens beaucoup plus générique qui pourrait justement se traduire par terrain vague D'après taginfo, il y aurait dans les 60 landuse=wasteland (1). A comparer avec les 10.000 et des poussières landuse=brownfield (2) Pieren (1) http://taginfo.openstreetmap.org/tags/?key=landusevalue=wasteland (2) http://taginfo.openstreetmap.org/tags/?key=landusevalue=brownfield ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Le mercredi 15 février 2012 à 10:43 +0100, Philippe Verdy a écrit : Le 15 février 2012 10:27, Fanny Schertzer fanny.schert...@gmail.com a écrit : Le 15 février 2012 10:19, PhQ pierre.que...@sfr.fr a écrit : Pour ceux qui parlent l'anglais, les réactions au passage de Google à OSM sont croquignollettes. http://blog.geocaching.com/2012/02/new-geocaching-com-maps/ Il y a 2-3 specimens qui valent le détour, d'autant que le choix par défaut n'est pas OSM (qui était déjà dispo en option) mais MapQuest. Mapquest c'est un moteur de rendu de la base de données OSM... CQFD. Incroyable !! Tu es donc capable de rédiger des mails succincts \o/ Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Oui mais le site en question est destiné à l'activité de loisir de géocaching, une bonne occasion de faire des balades dans des coins malconnus ou qui mériteraient plus. Et de faire de la publicité pour ces endroits car on y trouve plein de visites intéressantes. Malgré tout, le principe du géocaching c'est tout de même de chercher, même avec des infos incomplètes. Et le site Géoaching ne peut pas payer les 3 millions de dollar par ans (estimés) que demanderait Google pour l'utilisation excessive de son API Google Maps. Bref Geocaching n'a pas le choix, mais je ne vois pas en quoi le passage va gêner les passionnés du Géocaching (Et ils peuvent aussi continuer toutefois à utiliser individuellement Google Maps s'ils ne souhaitent sur leur GPS ou leur smartphone ou tablette, pendant leurs balades). Cela ne les empêche en rien d'utiliser le site Geocaching pour organiser de nouvelles caches avec des descriptifs de balades, ou de chercher d'y chercher de nouvelles balades à faire, car la carte Google Maps n'y est pas indispensable pour ce type de recherche et une carte Mapquest (basée sur OSM) suffit très bien pour l'immense majorité des balades référencées. En plus, les contributeurs de balades ou de nouvelles caches peuvent aussi contribuer à améliorer OSM. Si réellement le site a 2 millions de hits sur son site, ça fait des tas de nouveaux contributeurs potentiels pour OSM :-), justement dans des endroits malconnus et dans le monde rural où les caches sont plus difficiles, résisteront mieux à la sagacité des baladeurs, et où les baladeurs aimeront aller chercher leurs petits trésors ou remplacer un trésor par un autre pour les baladeurs suivants... Franchement j'adore le concept du Geocaching : ces balades sont quasi gratuites, souvent très proches de chez soi (pas besoin de longue route, et de pleins d'essence), et nous font sortir de la télé ou de la tentation des loisirs chers. Ils font découvrir ce qui nous entoure, et en tout cas de l'ennui de ne connaitre qu'une poignée de lieux, et c'est aussi du sport très bon pour le physique, le moral et la santé, dans un loisir qu'on peut aussi partager entre amis et en famille, toujours disponible n'importe quel jour et à n'importe quelle heure. Faites donc tous du géocaching, en emportant vos GPS ou smartphones avec vous, pour comparer à ce qui est dans OSM. Une fois chez vous rapportez les erreurs ou omissions constatées sur votre chemin. Car ces balades motivent bien pour voir des tas de choses qu'on n'aurait même pas soupçonnées (même quand on vit à côté) et qu'on ne verra nulle part sur une imagerie satellite. En plus c'est aussi l'occasion de rencontres avec ceux qui vivent ou travaillent dans les lieux visités (qui sont souvent les promoteurs ayant référencé la balade à faire), et l'occasion de trouver des produits régionaux et bonnes affaires originales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 08:05, Philippe Verdy verd...@wanadoo.fr a écrit : C'est à chaque moteur de rendu de définir le nombre de couches indépendantes de tuiles qu'il va générer, et dans quelle couche il va placer les éléments qu'il trouve. C'est le genre de choix pour lequel je considère que l'humain possède un discernement plus efficace que la machine. - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant que les textes d'un layer donné ? Je penche plutôt pour la séparation complète (dans un même moteur de rendu) des libellés, notamment pour permettre de choisir dans quelle langue les afficher, ou même choisir de ne pas les afficher tout en affichant le reste. Déjà fait ! http://toolserver.org/~osm/locale/__all.html Autre exemple réussi, mais là avec des fonds et des calques : http://francetopo.fr/ C'est pas mal, mais en regardant de près il y a des télescopages possibles entre le texte et les éléments de la carte. Ils restent limités quand le rendu de toutes ces couches est fait par la même machine. - Comment assurer que deux textes ne vont pas se superposer si les calculs des tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte toutes les données affichables (càd le maximum de tuiles superposées)... Là encore, si les tuiles sont servies par des moteurs dont le développement est séparé, il est impossible de s'assurer que ces textes ne se superposeront pas. Cependant, comme ces tuiles seront servies dans des couches séparées, on peut encore disposer d'une interface permettant de sélectionner laquelle de ces couches afficher. francetopo.fr est le meilleur exemple. Cependant, si on trouve des réponses pratiques à toutes ces questions, les moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :) Je le pense aussi, car cela simplifierait énormément l'utilisation des cartes et le travail de modification ou création de données (vers quelquechose de bien plus utilisable que le bordel qu'on voit dans JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier des choses à créer ou corriger), Si tu veux filtrer / atténuer / occulter des éléments de la base osm perturbateurs pour ta contribution, il existe un super outil de filtrage pour JOSM. Côté rendu, JOSM fonctionne avec une feuille de style au format mapcss. Rien ne t'empêche de l'ajuster pour que l'affichage colle mieux à ton profil de contribution tout en assurant une bien meilleure cohérence des données stockées dans la base (en permettant à chaque couche modifiable dans l'interface de restreindre le jeu de tags et de valeurs utilisables ou acceptables). Le mode de stockage des données dans la base principale OSM suit une logique qui parait bordélique, mais qui vise surtout à arriver à un haut niveau de robustesse. Restreindre le jeu de tags et de valeurs ? Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à Wikipedia ? D'ailleurs on s'en rends compte puisque justement Osmose sert aussi à offrir des vues séparées de plusieurs couches d'erreurs qu'il détecte. Là je ne comprends pas bien où tu veux en venir. Si on a pu développer Osmose pour générer des couches séparées, on doit aussi pouvoir faire la même chose pour créer des couches destinées cette fois au rendu correct et utilisable des cartes, destinées cette fois non plus seulement aux contributeurs cartographes, mais à fournir un résultat clair montrant ce que l'auteur d'une carte veut réellement montrer (ce qui n'exclue pas pour autant que cette carte affiché ne puisse pas être modifiée dans la même interface sans avoir à charger toutes les autres données stockées dans la base OSM. Et j'imagine que si le développement de JOSM doit continuer, dans la mesure où il dispose DÉJÀ d'un mécanisme de gestion de calques, mais qu'il sous-utilise cette fonctionnalité : je suggérerais aux auteurs de JOSM de commencer à réfléchir à leur utilisation beaucoup plus systématique où les données chargées le seraient dans des sous-calques (même si ces sous-calques sont enregistrés ensemble dans un même fichier OSM et soumis ensembles à la base de données), classant automatiquement ces données dans les bons sous-calques. Dans certains cas (pas si rares en fait), il y aura des liaisons entre les sous-calques, notamment concernant la position de certains noeuds partagés qui doivent permettre de fixer des calques sur des positions qui devraient être identiques (voire même le seront de façon systématique avec le modèle de données actuelles) : * Par exemple, une couche frontières administratives, elle-même découpée en plusieurs sous-couches pour chaque niveau différent, devrait pouvoir partager les positions des noeuds entre ces sous-couches. * De même avec une couche routière, les routes désignées comme voies communales devraient être découpées là où passe
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 11:28, Ab_fab gamma@gmail.com a écrit : Le 15 février 2012 08:05, Philippe Verdy verd...@wanadoo.fr a écrit : C'est à chaque moteur de rendu de définir le nombre de couches indépendantes de tuiles qu'il va générer, et dans quelle couche il va placer les éléments qu'il trouve. C'est le genre de choix pour lequel je considère que l'humain possède un discernement plus efficace que la machine. - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant que les textes d'un layer donné ? Je penche plutôt pour la séparation complète (dans un même moteur de rendu) des libellés, notamment pour permettre de choisir dans quelle langue les afficher, ou même choisir de ne pas les afficher tout en affichant le reste. Déjà fait ! http://toolserver.org/~osm/locale/__all.html Autre exemple réussi, mais là avec des fonds et des calques : http://francetopo.fr/ C'est pas mal, mais en regardant de près il y a des télescopages possibles entre le texte et les éléments de la carte. Ils restent limités quand le rendu de toutes ces couches est fait par la même machine. - Comment assurer que deux textes ne vont pas se superposer si les calculs des tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte toutes les données affichables (càd le maximum de tuiles superposées)... Là encore, si les tuiles sont servies par des moteurs dont le développement est séparé, il est impossible de s'assurer que ces textes ne se superposeront pas. Cependant, comme ces tuiles seront servies dans des couches séparées, on peut encore disposer d'une interface permettant de sélectionner laquelle de ces couches afficher. francetopo.fr est le meilleur exemple. Cependant, si on trouve des réponses pratiques à toutes ces questions, les moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :) Je le pense aussi, car cela simplifierait énormément l'utilisation des cartes et le travail de modification ou création de données (vers quelquechose de bien plus utilisable que le bordel qu'on voit dans JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier des choses à créer ou corriger), Si tu veux filtrer / atténuer / occulter des éléments de la base osm perturbateurs pour ta contribution, il existe un super outil de filtrage pour JOSM. Côté rendu, JOSM fonctionne avec une feuille de style au format mapcss. Rien ne t'empêche de l'ajuster pour que l'affichage colle mieux à ton profil de contribution tout en assurant une bien meilleure cohérence des données stockées dans la base (en permettant à chaque couche modifiable dans l'interface de restreindre le jeu de tags et de valeurs utilisables ou acceptables). Le mode de stockage des données dans la base principale OSM suit une logique qui parait bordélique, mais qui vise surtout à arriver à un haut niveau de robustesse. Restreindre le jeu de tags et de valeurs ? Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à Wikipedia ? Justement je n'ai pas dit ça. Tu commence à comprendre à l'envers... Je n'ai pas dit de restreindre ces valeurs, mais justement pouvoir taguer avec des valeurs dont on sait qu'elles sont reconnues correctement et supportées (en cas d'évolution des recommandations), en évitant des tas d'erreurs communes commises dans un éditeur qui permet de saisir absolument n'importe quoi n'importe quand, presque sans rien signaler du tout (ou si peu, et souvent après coup sur d'autres outils). Quand je vois le nombre de tags très ambigus (ou redondants sans raison) dans la base dont on ne sait pas trop comment les interpréter, même quand on est humain, un peu de cohérence de nuit pas. Et ce sera plus facile à assurer si une couche est développée pour afficher des classes d'objets plus uniformes dans leur définition, puisque chacune peut offrir des raccourcis utiles à cette couche d'informations qui accélère le travail de contribution en évitant aussi d'autres problèmes: sur cette couche spécialisée des tas d'actions de modifications peuvent être semi-automatisées pour taguer correctement sans erreur, et cette couche spécialisée peut aussi offrir un accès facile à des tags plus précis que ce que chacun croit connaître. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Je connaissais vaguement le principe du géocaching. C'est vraiment le pendant naturel au projet OpenStreetMap, et au delà des soucis de couverture d'OSM, de nombreux amateurs de cette activité seront sans doute intéressés à rejoindre notre communauté. Maintenant je sais où aller poser des flyers OSM http://www.geocaching.com/map/default.aspx?ll=47.11574,-2.09945 A+ BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
De : Philippe Verdy Justement je n'ai pas dit ça. Tu commence à comprendre à l'envers... une manie :-) Je n'ai pas dit de restreindre ces valeurs, mais justement pouvoir taguer avec des valeurs dont on sait qu'elles sont reconnues correctement et supportées (en cas d'évolution des recommandations), en évitant des tas d'erreurs communes commises dans un éditeur qui permet de saisir absolument n'importe quoi n'importe quand, presque sans rien signaler du tout (ou si peu, et souvent après coup sur d'autres outils). Pas besoin de ré-inventer la roue : pour une saisie d'attributs cadrée, qui justement limite les erreurs, voir le menu déroulant Attributs de JOSM. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 11:28, Ab_fab gamma@gmail.com a écrit : Le 15 février 2012 08:05, Philippe Verdy verd...@wanadoo.fr a écrit : C'est à chaque moteur de rendu de définir le nombre de couches indépendantes de tuiles qu'il va générer, et dans quelle couche il va placer les éléments qu'il trouve. C'est le genre de choix pour lequel je considère que l'humain possède un discernement plus efficace que la machine. - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant que les textes d'un layer donné ? Je penche plutôt pour la séparation complète (dans un même moteur de rendu) des libellés, notamment pour permettre de choisir dans quelle langue les afficher, ou même choisir de ne pas les afficher tout en affichant le reste. Déjà fait ! http://toolserver.org/~osm/locale/__all.html Autre exemple réussi, mais là avec des fonds et des calques : http://francetopo.fr/ C'est pas mal, mais en regardant de près il y a des télescopages possibles entre le texte et les éléments de la carte. Ils restent limités quand le rendu de toutes ces couches est fait par la même machine. - Comment assurer que deux textes ne vont pas se superposer si les calculs des tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte toutes les données affichables (càd le maximum de tuiles superposées)... Là encore, si les tuiles sont servies par des moteurs dont le développement est séparé, il est impossible de s'assurer que ces textes ne se superposeront pas. Cependant, comme ces tuiles seront servies dans des couches séparées, on peut encore disposer d'une interface permettant de sélectionner laquelle de ces couches afficher. francetopo.fr est le meilleur exemple. Cependant, si on trouve des réponses pratiques à toutes ces questions, les moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :) Je le pense aussi, car cela simplifierait énormément l'utilisation des cartes et le travail de modification ou création de données (vers quelquechose de bien plus utilisable que le bordel qu'on voit dans JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier des choses à créer ou corriger), Si tu veux filtrer / atténuer / occulter des éléments de la base osm perturbateurs pour ta contribution, il existe un super outil de filtrage pour JOSM. Côté rendu, JOSM fonctionne avec une feuille de style au format mapcss. Rien ne t'empêche de l'ajuster pour que l'affichage colle mieux à ton profil de contribution tout en assurant une bien meilleure cohérence des données stockées dans la base (en permettant à chaque couche modifiable dans l'interface de restreindre le jeu de tags et de valeurs utilisables ou acceptables). Le mode de stockage des données dans la base principale OSM suit une logique qui parait bordélique, mais qui vise surtout à arriver à un haut niveau de robustesse. Restreindre le jeu de tags et de valeurs ? Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à Wikipedia ? D'ailleurs on s'en rends compte puisque justement Osmose sert aussi à offrir des vues séparées de plusieurs couches d'erreurs qu'il détecte. Là je ne comprends pas bien où tu veux en venir. Si on a pu développer Osmose pour générer des couches séparées, on doit aussi pouvoir faire la même chose pour créer des couches destinées cette fois au rendu correct et utilisable des cartes, destinées cette fois non plus seulement aux contributeurs cartographes, mais à fournir un résultat clair montrant ce que l'auteur d'une carte veut réellement montrer (ce qui n'exclue pas pour autant que cette carte affiché ne puisse pas être modifiée dans la même interface sans avoir à charger toutes les autres données stockées dans la base OSM. Et j'imagine que si le développement de JOSM doit continuer, dans la mesure où il dispose DÉJÀ d'un mécanisme de gestion de calques, mais qu'il sous-utilise cette fonctionnalité : je suggérerais aux auteurs de JOSM de commencer à réfléchir à leur utilisation beaucoup plus systématique où les données chargées le seraient dans des sous-calques (même si ces sous-calques sont enregistrés ensemble dans un même fichier OSM et soumis ensembles à la base de données), classant automatiquement ces données dans les bons sous-calques. Dans certains cas (pas si rares en fait), il y aura des liaisons entre les sous-calques, notamment concernant la position de certains noeuds partagés qui doivent permettre de fixer des calques sur des positions qui devraient être identiques (voire même le seront de façon systématique avec le modèle de données actuelles) : * Par exemple, une couche frontières administratives, elle-même découpée en plusieurs sous-couches pour chaque niveau différent, devrait pouvoir partager les positions des noeuds entre ces sous-couches. * De même avec une
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 11:49, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pas besoin de ré-inventer la roue : pour une saisie d'attributs cadrée, qui justement limite les erreurs, voir le menu déroulant Attributs de JOSM. FAUX ! Cette liste de valeurs possibles contient en fait une énumération de toutes les valeurs possibles déjà présentes, même celles en erreurs (avec toutefois une indication du nombre de fois où une même valeur est utilisée dans les données chargées, ce qui n'est pas forcément non plus un indicateur que la valeur la plus utilisée est la bonne ou est celle recommandée). Quant aux menus déroulants, ils sont très incomplets et pas pratiques du tout quand il faut dérouler des sous-menus et encore ensuite se prendre un autre dialogue, alors qu'on n'a qu'une valeur à saisir. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Justement je n'ai pas dit ça. Tu commence à comprendre à l'envers... Flûte ... Je n'ai pas dit de restreindre ces valeurs, mais justement pouvoir taguer avec des valeurs dont on sait qu'elles sont reconnues correctement et supportées (en cas d'évolution des recommandations), en évitant des tas d'erreurs communes commises dans un éditeur qui permet de saisir absolument n'importe quoi n'importe quand, presque sans rien signaler du tout (ou si peu, et souvent après coup sur d'autres outils). C'est peut être les menus de balises présélectionnées qu'il faut améliorer dans JOSM et Potlatch ? Le substrat est là : les deux outils sont hautement configurables pour améliorer les choix proposés C'est probablement le temps disponible multiplié par le nombre de bonnes volontés qui fait le plus défaut. Un bon brainstorming permettrait d'arriver à quelque chose de plus étoffé, de mieux traduit, de moins ambigu. Quand je vois le nombre de tags très ambigus (ou redondants sans raison) dans la base dont on ne sait pas trop comment les interpréter, même quand on est humain, un peu de cohérence de nuit pas. Et ce sera plus facile à assurer si une couche est développée pour afficher des classes d'objets plus uniformes dans leur définition, puisque chacune peut offrir des raccourcis utiles à cette couche d'informations qui accélère le travail de contribution en évitant aussi d'autres problèmes: sur cette couche spécialisée des tas d'actions de modifications peuvent être semi-automatisées pour taguer correctement sans erreur, et cette couche spécialisée peut aussi offrir un accès facile à des tags plus précis que ce que chacun croit connaître. Oui, le constat est valide. Améliorer les outils de contributions pour éviter aux gens de sortir des clous est quelque chose qui mérite l'attention pour éviter les ennuis à la source ... mais qui demande du temps. - Voir la possibilité de se faire un Potlatch 2 customisé pour ne permettre qu'un type particulier de contribution - Voir un site comme http://wheelmap.org/ qui suit la même logique Les outils comme Taginfo, Osmose sont justement là pour mettre certaines choses en valeur et donc faciliter la correction. Pour ces corrections, encore des lapalissades la solution manuelle est fastidieuse (suffit de regarder l'ensemble des erreurs remontées par Osmose, le boulot est colossal) La solution automatisée est possible, mais casse-gueule. -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 11:56, Ab_fab gamma@gmail.com a écrit : choses en valeur et donc faciliter la correction. Osmose marche bien pour signaler les anomalies portant sur un noeud, mais pas du tout concernant les relations et les chemins, car il signale une position arbitraire sur un seul noeud, ce qui ne permet pas d'identifier précisément l'objet en conflit. Si on veut corriger avec rawedit de tels objets signalés qui ne sont pas des noeuds, c'est impossible quand l'erreur touche à la géométrie elle-même et parfois ce n'est pas l'objet signalé qu'il faut corriger, mais l'objet voisin. Si on veut corriger avec josm_zone on se retrouve souvent avec beaucoup trop de données chargées autour de la zone donnée sans AUCUN filtre. Pour ces corrections, encore des lapalissades Une lapalissade veut dire qu'on a expliqué une chose en rapportant un autre fait évident qui découle du premier (comme dire monter en haut, sortir dehors, une jolie beauté, il fait noir la nuit, un chat est un chat, juste avant de mourir, il était encore vivant, certains sont gentils, d'autres pas, Quand il était à Poitiers, il n'était pas à Nantes). Les lapalissades (apparentées aux tautologies, bien qu'une tautologie soit moins grave et a le mérite de servir à rappeler une démonstration causale valide, même si elle semble évidente) sont souvent utilisées avec l'apparence d'une explication ou pour servir de justification à un fait affirmé (en confondant élément causal et conséquence), ou en disant une chose et son contraire pour faire croire qu'on est complet sur un sujet sans oser affirmer une prise de position. C'était le cas ? la solution manuelle est fastidieuse (suffit de regarder l'ensemble des erreurs remontées par Osmose, le boulot est colossal) La solution automatisée est possible, mais casse-gueule. Je ne dis pas le contraire, mais même la solution humaine n'est pas facilitée du tout. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Un joli coin que Pornic, que je connais assez bien, mais certainement pas assez ! L'occasion aussi pour nos propres membres d'aller proposer des balades à faire en organisant des caches référencées sur ce site (sans oublier de parler d'OSM car les géocacheurs se baladent presque tous avec leur GPS ou un smartphone avec une appli de traçage GPS). Les autres géocacheurs qui viendront par d'autes chemins complèteront les alentours... Et puis c'est plus motivant que de simplement aller faire une visite systématique de certains lieux, sans but précis sur ce qu'il faudrait chercher ou repérer, et ensuite, pour les zones qu'il n'a pas eu le temps de faire, de créer une nouvelle cache à proximité avec un objet symbolique à trouver, comme une marque de son passage (l'objet peut être une suite de points de passages, avec un message inclus contenant des instructions de données à compléter sur OSM...). Le 15 février 2012 11:40, Bruno Cortial bruno.cort...@laposte.net a écrit : Je connaissais vaguement le principe du géocaching. C'est vraiment le pendant naturel au projet OpenStreetMap, et au delà des soucis de couverture d'OSM, de nombreux amateurs de cette activité seront sans doute intéressés à rejoindre notre communauté. Maintenant je sais où aller poser des flyers OSM http://www.geocaching.com/map/default.aspx?ll=47.11574,-2.09945 A+ BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Pour n'utiliser que des tags connus dans JOSM, c'est quand même facile: - menu Attributs et en particulier Recherche d'attributs disponible via F3 - les icônes d'accès rapide aux principaux attributs Bien sûr, si on utilise le panneau Attributs à droite, on travaille sans filet, mais c'est un choix. Dans Potlatch 2 il faut passer en mode advanced pour accéder aux attributs bruts. Là aussi je pense que le garde-fou est quand même bien présent pour éviter la saisie d'attributs erronés. Passer en advanced est là aussi un choix. Osmose... Rawedit est pratique pour faire une petite correction, comme une faute d'orthographe ou de frappe. Pour le reste, c'est sans filet là aussi et souvent sans intérêt. Pour le lien josm_zone, le chargement peut être lourd autour de l'objet en question, mais cela a l'avantage de le remettre dans son contexte ce qui n'est pas plus mal. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sondage sur le travail collaboratif de saisie de données pour un contributeur expérimenté OSM
Bonjour à tous ! J’ai enfin fini de lire toutes vos réponses aux 58 sondages remplis, merci de votre participation, j’ai lu des réponses superbes ! Désolé de ne pas avoir répondu ultérieurement, je vais enfin réagir à vos commentaires. Je voudrais dire que mon travail de thèse au laboratoire COGIT n’a pas un lien direct avec le service de production de l’IGN. Comme vous, je sais que l’IGN prévoit d’ouvrir le RGE et d’autres données sous licence libre, mais je n’ai pas d’autres connaissances sur l’avancement de ce projet ou d’autres projets similaires. Dans vos discussions, j’ai vu passer des avis intéressants sur le rôle de l’IGN que j’ai déjà passés à ma directrice de thèse. Je voudrais aussi dire que je me suis personnellement intéressée à OSM parce que c’est, comme Wikipédia, un projet que j’aime bien. J’ai rencontré des contributeurs OSM au long de conférences et je me suis bien entendue avec eux. J’ai beaucoup de respect pour les contributeurs qui utilisent leur temps libre pour faire vivre ces projets communautaires. Néanmoins, je voudrais clarifier que l’objectif de ma thèse n’est pas de donner des solutions aux problèmes spécifiques d’OSM, ceci est le rôle des contributeurs parce que c’est vous qui connaissez bien le projet comme personne d’autre. D’ailleurs, j’ai su que le Centre for Geospatial Science à l’Université de Nottingham a embauché un nouveau post-doc qui va travailler particulièrement sur OSM dans le cadre du projet OSM-GB ( http://www.osmgb.org.uk/), apparemment il vient de démarrer ! (ah la la, j’aurais beaucoup aimé postuler sur ce poste-là mais d’abord il faut que je finisse la thèse :-|). Mon travail de thèse porte sur l’édition collaborative d’un contenu géographique, en particulier sur la gestion de la cohérence d’un tel contenu pour améliorer son utilisabilité (« fitness for use »). Évidement, l’utilisabilité des données est liée à un thème spécifique. Par exemple, vous avez tous pensé aux points de repères pour améliorer les applications de routage, ceci pourrait me servir à définir un cas d’étude intéressant ! Merci particulièrement à @Eric Marsden, @Sylvain Letuffe, @Julien Thenevon, @Guillaume Allegre, @Yves, @Simon, @Philippe Verdy, @Gilles Bassière, @Christian Quest, @Nicolas Dumoulin de vos discussions et les bons exemples sur les points de repères, les exemples du MacMachin et de la maison bleue adossée à la colline, et aussi pour le « score de remarquabilité ». Le sujet de l’utilisabilité des données sur un thème spécifique m’a fait penser à l’exemple de Wikipédia où il y a des portails dédiés aux thèmes spécialisés comme l’histoire, la démographie, les transports en commun ( http://fr.wikipedia.org/wiki/Portail:Transports_en_commun), etc. J’imagine un jour dans OSM, la possibilité de saisir des données qui seront organisées par thèmes (ex : données historiques, données démographiques, etc.). Je reviens au sujet de ma thèse, à mon avis, l’explicitation de propriétés et de relations des objets peut être utile à quelqu’un qui ne veut pas forcement saisir la géométrie de l’objet mais décrire l’espace géographique locale en utilisant un objet de référence (ex : éventuellement le RGE). Personnellement, je me souviens si un MacMachin est à côté de l’épicerie chinoise pas loin de chez moi, et pas forcement son emplacement géographique. De plus, comme certain de vous ont dit dans les sondages, c’est une approche qui pourrait être aussi intéressante pour signaler un manque d’information. D’ailleurs, comme certains de vous ont signalé, les relations peuvent aussi être dérivées des géométries. Un catalogue d’algorithmes en analyse spatiale pourrait être disponible pour évaluer chaque type de relation sur des objets. Pour faciliter la saisie des données, si un objet « pont » est décalé, le serveur devrait savoir que la relation avec un objet « fleuve » est importante, il devrait donc essayer de préserver la relation entre ces deux objets, et ceci pourrait éviter d’introduire un conflit. Bon allez, je vais avancer avec les sondages, n’hésitez pas à me signaler plus d’information que vous avez oublié de rajouter dans le sondage ! Cordialement, Carmen. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15/02/2012 11:56, Ab_fab a écrit : C'est peut être les menus de balises présélectionnées qu'il faut améliorer dans JOSM et Potlatch ? Le substrat est là : les deux outils sont hautement configurables pour améliorer les choix proposés Oui, je viens découvrir qu'il est possible de rajouter ses propres attributs préconfigurés dans la liste déroulante. C'est pratique j'en ai fait un pour la relation frontière administrative d'une commune c'est bien pratique, et pas diffiile ; juste je m'enbête avec les accents, je ne sais pas comment paramétrer l'unicode, ni où le faire (dans l'éditeur de texte ? c'est expliqué là : http://josm.openstreetmap.de/wiki/TaggingPresets Je l'ai mis dans la barre de menus, ça me fait gagner au moins 5 clics par commune. cool. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Dans JOSM, c'est normal que tu n'aies rien à paramétrer, puisque l'outil écrit en Java prends en charge directement Unicode et travaille dans ce mode. Dans Potlatch, (ou rawedit), c'est une affaire car il faut que ton navigateur soit à jour et correctement paramétré pour gérer l'Unicode correctement, détecter les bons jeux de caractères lors des échanges avec le serveur, et lors de la saisie: le réglage du navigateur intervient, de même que l'installation des polices (c'est encore plus critique sur certaines distributions simplifiées Linux ou de vieilles version de Windows (avant Windows XP et sans noyau NT ou avant Windows 2000 : Windows 95/98/ME, ou NT4), et de vieux navigateurs bogués (y compris notamment IE6 et versions d'avant, ou Netscape avant Mozilla Firefox), ou encore les version de Mac OS avant OS X. Malheureusement les sites frontend et backend d'Osmose ne détectent pas ces vieilles versions et cela peut entraîner des corruptions de données uniquement par des confusion sur les jeux de caractères utilisés ou détectés par ces navigateurs (qui avaient une facheuse tendance à toujours vouloir prendre de l'ISO 8859 ou une page Windows 125x, ou encore des codages asiatiques comme SJIS, voir aussi du MacRoman sur les versions de Mac OS avant OS X, variable selon les versions nationales du système hôte du navigateur client), lorsque ceux-ci soumettront les données de formulaires au serveur backend. Le 15 février 2012 18:01, Hélène PETIT h...@free.fr a écrit : Le 15/02/2012 11:56, Ab_fab a écrit : C'est peut être les menus de balises présélectionnées qu'il faut améliorer dans JOSM et Potlatch ? Le substrat est là : les deux outils sont hautement configurables pour améliorer les choix proposés Oui, je viens découvrir qu'il est possible de rajouter ses propres attributs préconfigurés dans la liste déroulante. C'est pratique j'en ai fait un pour la relation frontière administrative d'une commune c'est bien pratique, et pas diffiile ; juste je m'enbête avec les accents, je ne sais pas comment paramétrer l'unicode, ni où le faire (dans l'éditeur de texte ? c'est expliqué là : http://josm.openstreetmap.de/wiki/TaggingPresets Je l'ai mis dans la barre de menus, ça me fait gagner au moins 5 clics par commune. cool. Parle pour toi : je trouve ces menus pas pratiques du tout, on peut trop facilement taper à côté de la bonne option, et avoir à relire le contenu des menus pour retrouver la bonne option est une perte de temps incroyable (et c'est pas très accessible non plus quand on doit cliquer au milieu d'un menu qui se referme de façon intempestive parce qu'on a cliqué 3 pixels à côté, et qui provoque alors des placements ou sélections d'objets différents sur la carte située juste sous la zone du menu qui vient de se fermer). Je hais les menus quand c'est la seule interface d'une application, qui plus est sans raccourci clavier (je fais plus confiance à la frappe d'une touche sur le clavier qu'à un clic souris trop sensible à un déplacement microscopique de la main) ! Une interface bien fichue à la souris doit être capable de déterminer les options réellement utiles selon la sélection à laquelle s'appliquera une action, et être entièrement navigable aussi au clavier sans avoir à presser de touches exotiques ou multiples (OK pour les flèches de direction et entrée, ou pour la frappe d'une lettre initiale). C'est OK en revanche de travailler à la souris quand on place géométriquement des objets sur la carte. Mais pour mettre ou corriger des tags, ce n'est franchement pas idéal, car on passe son temps à passer de la souris au clavier (pour frapper du texte j'ai besoin de lâcher la souris, car je ne sais pas frapper avec un doigt : c'est un mouvement incessant de main entre les deux périphériques pas pratique du tout et qui prend du temps et est aussi source d'erreurs de saisies ou de clics au mauvais endroit, dont on ne s'aperçoit pas toujours, justement lors de ces changements). C'est comme les formulaires web (écrits en Flash souvent, quand est-ce que les webadmins vont abandonner ce truc propriétaire et plein de rustines mal collées sur les failles de sécurité) ou les applications qui ne veulent pas qu'on utilise TAB ou MAJ+TAB pour passer d'un champ à l'autre et qui exigent qu'on clique dans chaque zone à remplir, ou qui ne supportent pas la sélection de texte au clavier avec MAJ+les flèches, ni les raccourcis clavier usuels pour copier/coller (et veulent qu'on passe par le menu éditer ou qu'on aille cliquer un bouton à côté du texte saisi, ou parfois même dans une barre d'outils éloignée de la zone de saisie). De fait, je ne me sers que très exceptionnellement des menus de JOSM (sauf parfois pour me rappeler quel était le nom d'un tag que je vais ensuite taper directement avec les premières lettres et la complétion automatique des champs) ; mais la plupart du temps je n'y trouve pas ce que je cherche et j'ai plus vite fait d'utiliser la fonction de recherche du wiki OSM, qui en
Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...
Le 14 février 2012 09:18, Emilie Laffray emilie.laff...@gmail.com a écrit : Euh appeler un virus de l'amour AIDS est d'un mauvais goût le plus complet vu que c'est l'acronyme du SIDA en anglais. Justement, absolument tout entre les lignes (et pas seulement ce seul acronyme) indiquait la relation à ce sujet (y compris dès le premier message parlant du virus de l'amour)... Ca semblait évident, mais bon, malgré le nombre d'indices laissés, on voit ceux qui comprennent tout de suite... et les autres qui ne pigent pas le second degré. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...
Le 14 février 2012 09:18, Emilie Laffray emilie.laff...@gmail.com a écrit : Euh appeler un virus de l'amour AIDS est d'un mauvais goût le plus complet vu que c'est l'acronyme du SIDA en anglais. Au fait, tu as vu l'allusion dans « Haute Intelligence des Volontaires » ? Visiblement tu ne l'as pas remarqué non plus. Je te laisse chercher... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...
Le 14 février 2012 11:50, Vincent Pottier vpott...@gmail.com a écrit : Y en a qui n'ont pas fumé que la moquette, là Tu voudrais que je fume quoi d'autre (de long et dur...) concernant ces messages vecteurs du « virus de l'amour » ? Si pour répondre t'as l'info, cite « t'es fort ». Ah, Saint-Drôme, quand on parle d'amour tu nous réserves tes surprises ! Bon OK, je me retire : j'suis pas couvert sur ce terrain-là... Allez draguer qui vous voulez sur Internet avec cette propagande, c'est votre choix et à vous de supporter les conséquences, tant que vous ne chargez pas les autres à ce sujet. Moi j'ai déjà ma dose. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk-fr-bzh] Litto3D : les fonds marins côtiers à 40 cm près
Le 14 février 2012 18:01, Steven Le Roux ste...@le-roux.info a écrit : SHOM + IGN, on n'est pas près de voir un import de ces nouvelles côtes... on aura peut être un WMS avec un peu de chance :) A mon avis on aura avant une appli Flash propriétaire pour visualiser le rendu 3D, façon Google Earth... Mais avant que ça devienne de l'OpenData (ou même seulement de l'imagerie 2D WMS) les promoteurs chercheront d'abord à assurer le financement et la rentabilité du projet jusqu'à son terme Parce que faire naviguer des bateaux équipés pendant des mois sur les côtes, avec un personnel, la location des navires, leur fourniture en carburant, une couverture des risques de navigation, ça a un coût que même les financeurs voudront à terme qu'il soit rentabilisé ou au moins que son financement serve à quelque chose d'exploitable en termes d'applications dérivées pour être mené à son terme. Les premiers financeurs pouvant être les câblo-opérateurs sous-marins, les sociétés de pêche industrielle, armateurs, sociétés d'exploration gazière ou pétrolière, sociétés d'assurance maritime, voire instituts de recherche sur la santé (espèces de planctons), groupes agroalimentaires, ou producteurs d'énergie qui cherchent des sites d'implantation ou d'expérimentaton d'éoliennes ou de systèmes de captation de l'énergie des courants, marées et vagues, voire quelques ministères publics pour des études de prévention de risques naturels ou industriels lié à l'activité qui naîtrait dans ces zones cartographiées plus précisément, et des gouvernements prêts à réclamer un droit territorial sur cette exploitation, mais pire encore des sociétés financières de capital-risque qui exigeront des garanties minimales de rentabilité. Bien avant les pauvres sociétés de protection de l'environnement, qui n'ont rien d'autre à vendre que leur message socio-politique (on sait combien les traités environnementaux sont difficiles à faire appliquer et qu'ils ont pris maintenant un retard considérable, la crise excusant tout), et quelques images, un peu du merchandising de soutien à leur action et quelques conférences. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15/02/2012 19:38, Philippe Verdy a écrit : Dans JOSM, c'est normal que tu n'aies rien à paramétrer, puisque l'outil écrit en Java prends en charge directement Unicode et travaille dans ce mode. potlatch, je sais pas, je n'utilise pas. et je viens juste de dire que c'est dans josm, justement, que les accents sont recrachés. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm et le Geocaching
Le 15/02/2012 10:19, PhQ a écrit : Alors ça ! c'est vraiment chouette, je ne m'y attendait pas ! j'adore les géocaches, j'en pose et j'en trouve avec ma petite famille. Voir mes géocaches sur les fonds de cartes que j'ai cartographié, tout ça visible depuis la corée ou l'espagne, c'est régal. Vive le libre, vive le crowdsourcing. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Le 15 février 2012 20:28, Hélène PETIT h...@free.fr a écrit : Le 15/02/2012 19:38, Philippe Verdy a écrit : Dans JOSM, c'est normal que tu n'aies rien à paramétrer, puisque l'outil écrit en Java prends en charge directement Unicode et travaille dans ce mode. potlatch, je sais pas, je n'utilise pas. et je viens juste de dire que c'est dans josm, justement, que les accents sont recrachés. A quel endroit tu as vu des accents que JOSM ne savait pas afficher, entrer ou enregistrer correctement ? Je n'en vois pas. Au contraire des données qui ont été créées ou modifiées et réenregistrées (y compris celles supposées non modifiées) dans rawedit sur Osmose ou dans Potlatch, des données parfois corrompues maintenant dans la base à cause de mauvais codages en HTML et/ou javascript, et/ou requêtes XMLHttpRequest par un navigateur connu comme ayant des problèmes de compatibilités non détectés par les solutions en ligne. Même si une installation de Java n'a pas la possibilité d'afficher un caractère Unicode, faute de police installée pour les supporter, au moins JOSM affichera des carrés et préservera l'identité des caractères Unicode qui sont dans les données textuelles non modifiées. Maintenant on ne peut pas se prémunir contre des effacements volontaires de données par les contributeurs (qui pourraient croire de bonne foi que ces textes mal affichés ou qu'ils ne peuvent pas lire du tout sont incorrects). Mais le support des principales écritures du monde (latin, grec, cyrillique, arabe, hébreu, devanagari, tamoul, hangeul, katakana, hiragana, et sinographique dans le plan multilingue de base, ainsi que de nombreux chiffres, symboles et signes de ponctuation courants) fonctionne sans problème dans Java (et depuis très longtemps, même avant Java 4 alors que JOSM demande Java 6). On ne peut pas en dire autant des applis .Net coté client, ou même Python, PHP et MySQL du côté des serveurs frontend et backend (mais Perl en revanche est quasi irréprochable aussi depuis longtemps). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MAIA : aires marines protégées
Le 14/02/2012 05:55, Philippe Verdy a écrit : Note: MAIA sera présent demain à Brest lors d'une conférence : 15 février 2012, 08:00 pm Restaurant Le M (22 Rue du Commandant Drogou) Brest, France Une occasion pour nos amis brestois de leur rendre visite ! Pas le budget désolé ;-) http://le-m.fr/cuisine/la-carte-les-menus.html a+ stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MAIA : aires marines protégées
Parce qu'il faut nécessairement payer le restau pour assister à la conférence ? C'est marqué nulle part qu'il faut réserver sur leur flyer publié en ligne ! Et n'allez pas croire qu'ils font ça pour rester devant leur assiette, ils ont réservé la salle, c'est déjà payé, la salle réservée ne sera pas pour accueillir les clients habituels, le service n'y sera éventuellement servi que pendant une courte durée (et je vois plutôt un simple buffet et non un service à table). Il ne manque plus qu'à y aller si vous êtes à côté (je ne peux pas c'est trop loin pour moi). Y viennent ceux que ça intéresse, ne serait-ce que 10 minutes pour savoir comment ça se passe. Toute conférence finit aussi par une présentation suivie de questions (pas toujours évident de pouvoir prendre la parole, mais après ça il y a tout de même des tas de discussions informelles et certainement des gens intéressants à rencontrer parmi les autres participants. Le 15 février 2012 21:21, Stéphane Le Bourdon stephane.lebour...@free.fr a écrit : Le 14/02/2012 05:55, Philippe Verdy a écrit : Note: MAIA sera présent demain à Brest lors d'une conférence : 15 février 2012, 08:00 pm Restaurant Le M (22 Rue du Commandant Drogou) Brest, France Une occasion pour nos amis brestois de leur rendre visite ! Pas le budget désolé ;-) http://le-m.fr/cuisine/la-carte-les-menus.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] frontière bizarre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bonsoir en traînant un peu ce soir sur geofabrik je suis tombé sur ce qui me semble être une frontière de la russie à ambérieu en bugey :) http://tools.geofabrik.de/osmi/?view=multipolygonlon=5.38286lat=45.95406zoom=14opacity=0.59overlays=multipolygons_type_is_boundary,type_is_boundary voir la relation #60189 je dois être fatigué ... bonne nuit jean navarro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk88MsEACgkQirIRKX59UEkfKQCgtqNxQ0aI2YabhxpwEFzXd3AU OAwAnRMJzYPuvxOTThfsL1g4JJwA4BQs =cNl1 -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
Bonjour, Le 15/02/2012 18:01, Hélène PETIT a écrit : Le 15/02/2012 11:56, Ab_fab a écrit : C'est peut être les menus de balises présélectionnées qu'il faut améliorer dans JOSM et Potlatch ? Le substrat est là : les deux outils sont hautement configurables pour améliorer les choix proposés Oui, je viens découvrir qu'il est possible de rajouter ses propres attributs préconfigurés dans la liste déroulante. C'est pratique j'en ai fait un pour la relation frontière administrative d'une commune c'est bien pratique, et pas diffiile ; juste je m'enbête avec les accents, je ne sais pas comment paramétrer l'unicode, ni où le faire (dans l'éditeur de texte ? c'est expliqué là : http://josm.openstreetmap.de/wiki/TaggingPresets Je l'ai mis dans la barre de menus, ça me fait gagner au moins 5 clics par commune. cool. Les accents qui t'embêtent sont où : dans le XML des Presets ? Dans les champs de saisie ? Propose ton fichier en test au cas où. Pour les relations, il existe une autre manière que je trouve rapide : le bouton Copier et modifier la relation, bouton du milieu (avec la flèche bleue) dans le panneau de droite Relations. Quand on a déjà une relation présente avec les bons tags, pas ex. une relation admin de commune : - copie avec ce bouton, la nouvelle relation s'ouvre dans l'éditeur - un clic sur le bouton AZ à gauche, théoriquement pour trier les membres, mais ici juste pour les sélectionner - un clic sur la poubelle - et voilà, on a une relation vide de membres, avec les bons tags, où les valeurs restent à changer bien sûr : name, ref:INSEE, etc. Ne pas oublier de rajouter les nouveaux ways comme membres :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
