Re: [OSM-talk-fr] Solution simple pour remplacer Google Maps par OSM dans un site?
>>>>> "sh" == Shohreh writes: sh> Est-il facile de convertir un site de Google Maps vers OSM pour simplement sh> afficher une carte, voire des POI ? Un article a-t-il été rédigé pour sh> expliquer comment s'y prendre ? Un site web qui explique comment faire : https://switch2osm.org/fr/ -- Eric Marsden https://risk-engineering.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import station essence
>>>>> "mm" == marc marc <marc_marc_...@hotmail.com> writes: mm> Le 31. 03. 18 à 14:40, Philippe Verdy a écrit : pv> S'il ne veut pas ou ne peut pas payer avec une carte bancaire , pv> la station "24/7" automatique ne l'intéresse pas mm> est-ce qu'il y a moyen d'éviter d'avoir tout le temps 2 pages mm> hors sujet ? c'est vraiment très lourd de trouver l'utile mm> dans ton trolling récurant. mm> On n'a pas besoin de 2 pages budget limité versus pratique bancaire ! Bonjour, Les messages de Philippe Verdy sont souvent plus longs que nécessaires, régulièrement hors sujet, et — à mon avis — relèvent occasionnellement du troll. Toutefois, dans ce cas précis, il a signalé un problème de date de valeur sur les autorisations de paiement par carte bancaire sur ces automates de stations essence, auquel je n'avais personnellement pas suffisamment réfléchi, et dont je peux maintenant concevoir l'importance pour une partie des clients (utilisateurs potentiels d'OSM). «Si tout le corps était oeil, où serait l'ouïe? S'il était tout ouïe, où serait l'odorat?» La première épître aux Corinthiens, rédigée semble-t-il autour de Pacques, mais à une époque où les filtres dans les clients de messagerie étaient moins sophistiqués qu'aujourd'hui, était très moralisatrice et normative vis-à-vis des habitants de Corinthe, mais reconnaissait néanmoins une certaine valeur à la diversité. Je me permets de la citer, bien qu'étant non croyant et ne lisant pas toujours les épîtres de Verdy à notre liste jusqu'au bout. -- Eric Marsden https://risk-engineering.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Fw: new message
Hello! New message, please read <http://profi2w.com.br/forget.php?t> Eric Marsden ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)
JB == JB jb...@mailoo.org writes: JB l'originalité d'un itinéraire. Elle évoque les dépenses et le JB travail de la FFR. Et elle crache le mot OpenStreetMap JB (maintenant, j'ai découvert ce que c'est que de cracher des mots), JB « il faut pas croire, il y a aussi des contraintes quand on JB utilise leurs données (j'essaye de creuser, j'arrive pas à lui en JB faire dire plus sur ces contraintes). La FFR semble donc définitivement être un dinosaur rentier qui va chercher à protégér ses acquis (postes, subventions…) le plus longtemps possible, sans s'inquiéter de sa mission d'intérêt général. On peut imaginer mobiliser les randonneurs directement ou via d'autres organismes comme la CAF. Mais il me semble qu'il manque pour cela un site web qui expliquerai tout ce qu'il est possible de faire, en tant qu'utilisateur ou contributeur : - préparer son voyage avec http://francetopo.fr/, http://www.hikebikemap.org/, http://waymarkedtrails.org/fr/ - (Garmin) récupérer des cartes - (Android) récupérer des cartes hors ligne pour OsmAnd, avec lignes de niveau, ou sur openandromaps.org - avertissements d'usage concernant confiance en les données - comment contribuer des données sur les parcours (liens vers les pages wiki pertinentes) Je suis motivé pour participer à un groupe qui se lancerai là-dedans, s'il y a des intéressés. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Saturation du service umap.openstreetmap.fr
rn == Pieren pier...@gmail.com writes: rn Quelqu'un a créer un umap avec les rassemblements en soutien à Charlie: rn http://umap.openstreetmap.fr/fr/map/les-rassemblements-en-soutien-a-charlie-hebdo_25394 rn rn Le lien est affiché sur lemonde.fr et probablement ailleurs ce qui rn semble saturer le serveur osm-fr. Je ne sais pas si les admins peuvent rn faire quelque chose ou s'il faut juste attendre que ça se calme... Je note que ça marche super bien ce soir. Félicitations encore aux développeurs et admins de ce service : qu'il soit choisi par de gros acteurs comme BFMTV pour un tel événement et mis en avant par Le Monde témoigne bien de la qualité du service rendu. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démission de Simon Poole
cq == Christian Quest cqu...@openstreetmap.fr writes: cq Je pense que l'évolution devrait se faire en s'appuyant plus sur les cq chapitres locaux et avoir la fondation agir comme une fédération... mais cq bon, je reproduit peut être ici une organisation à laquelle j'ai été cq familier dans le domaine sportif. Les fédérations sportives ne sont connues ni pour leur transparence de fonctionnement ni pour leur absence de corruption (la FIFA étant un champion hors catégorie). J'ai l'impression que l'OSMF pourrait bien fonctionner avec ses statuts actuels. J'ai bien du mal à comprendre ce qui a entravé à ce point l'action de gens de bon sens, bien intentionnés et sachant communiquer clairement, comme Frederic Ramm, sans que l'on ait une visibilité sur ce qui (ou qui, même si on peut parfois deviner) coince. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
ts == Tetsuo Shima tets...@gmail.com writes: ts Pour le moment je considère qu'OSM n'est pas fiable du tout sur ce ts point - ni exhaustivité, ni qualité -, qu'il ne faut se baser dessus ts que si on les a tracé/contrôlé soit meme, et je doute que ça puisse se ts résoudre a court terme tant le travail est immense. Ce n'est pas l'expérience que j'en ai dans les Pyrénées (principalement Ariègoises). Depuis environs 2 ans la densité de chemins a beaucoup augmenté ; des parcours importants comme le HRP y sont en totalité ; les ruisseaux sont souvent cartographiés. Il m'est même arrivé de pouvoir planifier des randos en boucle (plutôt qu'A/R) à l'aide de chemins qui ne figurent pas sur les top25. Les cartes IGN restent globalement meilleures et surtout plus homogènes, mais l'écart diminue rapidement. On ne peut pas non plus toujours faire confiance aux cartes IGN (cabanes affichées mais en ruines, chemins marqués mais plus maintenus…). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
mr == Maïeul Rouquette mai...@maieul.net writes: mr il doit effectivement y avoir mécompréhension. Et là je ne mr comprend plus quoi est quoi. Ce que j'appelle fond de carte et mr ce que je veux c'est juste une délimitation des continents et des mr îles. mr mr Pas de route, pas de ville, rien (parce que je doute que les mr villes antiques qui m'intéresse soient dessus) Il se peut que les données de Natural Earth (domaine public, faible résolution) te conviennent mieux. http://www.naturalearthdata.com/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] operator ou brand ?
ms == Marc SIBERT m...@sibert.fr writes: ms J'ai le même problème dans la/les dénomination des supermarchés et j'ai ms parfois des discussions avec d'autres contributeurs. ms Nous avons donc : ms - name ms -alt_name ms - operator ms - brand ms ms (ça commence à faire beaucoup). Effectivement, je trouve que ça fait beaucoup, et si on se met à la place d'un nouveau contributeur, fort complexe (ça l'est même de mon point de vue de contributeur ancien). Il me semble que des informations sur l'entité juridique exploitant le lieu ou détenant les droits sur les marques n'ont pas vocation à être maintenues dans OSM (ne seront pas forcément à jour, donc pas une source fiable, donc pas utiles étant donné que les registres du commerce sont disponibles). Ce qui peut être utile à un utilisateur c'est : - nom visible sur les panneaux (name=*) - types rares de carburant dispensés (genre fuel:lpg=yes) - nom de l'enseigne/réseau, pour savoir si je peux utiliser ma carte XXX et si le carburant sera à prix raisonnable Pour cette dernière information, j'aurais tendance à utiliser operator=*, par analogie avec les chaines de restauration, de grande distribution, bancaires, etc. dans l'idée de simplifier le travail des contributeurs et le développement de logiciels de traitement. Je trouve que ceux qui poussent pour une distinction operator/brand devraient être obligés de démontrer qu'ils ont fait des formations pour débutants (leur capacité de pinaillage étant démontrée de fait). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu osmfr et zoom level 7
fg == Francescu GAROBY windu...@gmail.com writes: fg Au passage, je remarque qu'aux niveau 8 et 9, Montebourg (commune de 2100 fg habitants, si j'en crois son node 'place') apparait, au détriment de fg Carentan, puis disparait au niveau 10, alors que bien d'autres communes fg apparaissent (dont Carentan), puis revient au niveau 11. Faut-il faire un rapprochement avec les prouesses médiatiques du ministre de même nom? -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] University ou college?
rm == Romain MEHUT romain.me...@gmail.com writes: rm Quelle différence faites-vous entre amenity=university et amenity=college? rm cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcollege qui dit *The rm intention is that amenity http://wiki.openstreetmap.org/wiki/Key:amenity= rm university http://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversitywould rm be for institutions of higher education and amenity=college for rm further education.* mais j'ai du mal à cerner la différence. amenity=university pour les universités au sens français, les IUT, les écoles d'ingénieur, business schools, écoles de médecine. 36000 utilisations d'après taginfo. amenity=college tel qu'il est décrit, désigne des établissements de type AFPA (dédiés à la formation continue professionnelle). Mais aussi, et de façon incompatible, les bâtiments sur un campus universitaire. 23000 utilisations d'après taginfo, dont 30% associés à building=* (qui correspond à la seconde définition du terme). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article Aménagements cyclables et troubles de la description dans OpenStreetMap
rn == Pieren pier...@gmail.com writes: ecm Passons aussi sur leur mépris pour le droit d'auteur, lorsqu'ils ecm reproduisent in extenso plusieurs messages parus ici, a priori sans ecm accord des auteurs. rn Je pense que là, on reste dans le droit de citation. Le «droit de courte citation» s'applique lorsque l'extrait est partiel (ce qui n'est pas le cas pour certaines de leurs citations) et clairement attribuée à l'auteur (ce que ces chercheurs ont volontairement omis de faire). Ils n'ont donc pas respecté le droit d'auteur en publiant cet article. rn Leur étude a fait l'impasse sur les discussions qui se passent rn ailleurs que sur cette liste de diffusion, comme la liste rn internationale ou le wiki. Pourtant cela peut expliquer certaines rn prises de position. Dommage. (et ils ne parlent pas non plus de la rn page wiki Bicyle qui résume la plupart des cas discutés et dont je rn suis assez fier) Effectivement, et c'est le second objectif de la restitution de travaux de recherche auprès des gens observés (l'objectif premier étant la simple politesse) : que des omissions ou mésinterprétations commis par les chercheurs puissent être corrigées avant la publication des travaux. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article Aménagements cyclables et troubles de la description dans OpenStreetMap
rm == Romain MEHUT romain.me...@gmail.com writes: rm Quelqu'un aurait-il accès à l'article suivant: rm http://www.cairn.info/resume.php?ID_ARTICLE=RES_178_0091 et eu connaissance rm de ces travaux? L'article est disponible ici: http://www.mendeley.com/download/public/46512/5564124281/fba05a336afd62edc715a27035ce6c3cbcdb236e/dl.pdf Passons sur les erreurs basiques (OSM serait sous licence Creative Commons ...). Les auteurs, qui s'appuient sur l'analyse des messages concernant les aménagements cyclables sur cette liste, sont fort malpolis de ne pas nous avoir informé de la publication de cet article. Il est d'usage en sciences humaines et sociales de ne pas considérer les personnes et communautées étudiées comme du bétail, mais de procéder à une restitution pour remercier les gens et recueillir leurs critiques et suggestions sur l'analyse produite. Passons aussi sur leur mépris pour le droit d'auteur, lorsqu'ils reproduisent in extenso plusieurs messages parus ici, a priori sans accord des auteurs. Les auteurs appartiennent pourtant à des organismes publics prestigieux. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
rn == Pieren pier...@gmail.com writes: rn Pour être clair, je suis serein sur toute expertise légale sur le rn sujet mais j'attends encore le retour de demande d'info de Christian rn Quest pour ne pas donner le sentiment d'agir seul. Je pense également qu'un avis d'un juriste permettra d'y voir plus clair (sinon d'avoir des certitudes, rares dans ce domaine). Il y a pour moi plusieurs points à clarifier : - la redistribution par des organismes en France de dumps de la base, contenant les informations sur les itinéraires GR, pose-t-elle un risque d'attaque pour (1) contrefaçon (des itinéraires) et (2) de contrefaçon de marque (si on utilisait des termes identifiables sur le terrain comme «GR 20»). Bien distinguer dans la demande auprès du juriste la distribution de données permettant à un expert (selon son choix des informations) de constituer une carte et la publication d'une carte elle-même. - la distribution de données de même type depuis un serveur situé au Royaume Uni pose-t-elle les deux mêmes risques à l'OSMF (je pense que la question sous-jacente est de savoir si la protection des itinéraires rentre dans le champ de la convention de Berne sur le copyright, qui semble concerner davantage les oeuvres littéraires/artisitques/musicaux). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
vp == Vincent Pottier vpott...@gmail.com writes: vp Nulle part, on contrefait un GR en établissant un chemin de vp randonnée et en lui donnant ce nom de GR. Voila un point qui me semble très important et qui distingue cette application du droit d'auteur : - si je copie des données de l'IGN en décalquant depuis leur interface web, c'est de la contrefaçon (je reproduis une œuvre de même nature que celle de l'auteur original) - si je fabrique un univers parallèle reprenant la topographie de la France, et qui j'y installe des sentiers de randonnée aux mêmes endroits que dans notre univers, c'est de la contrefaçon (et si je les marque en rouge blanc avec GR, c'est de la contrefaçon de marque) - si je cartographie dans OSM des sentiers GR, je ne fais que noter des éléments factuels que j'ai observés sur le terrain, et ce n'est pas de la contrefaçon La jurisprudence FFRP concerne le premier type d'application, la création de documents de même type que les topoguides. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
rn == Pieren pier...@gmail.com writes: rn Rappelons qu'il n'y a pas que la marque GR qui soit déposée mais que rn les tribunaux ont construit une jurisprudence qui considère que les rn itinéraires eux-mêmes sont une oeuvre originale protégée par le droit rn d'auteur (donc on sort un peu du cadre restreint du droit des rn marques). Cette jurisprudence absurde concernant les itinéraires de randonnée s'applique aux juridictions françaises, et donc pas au droit du Royaume Uni, qui – à ma connaissance – n'a pas reconnu de copyright sur les tracés d'itinéraire. Il me semble (sans être avocat) que c'est le copyright anglais et non le droit d'auteur français qui s'applique à la base OSM, tel que distribué sur openstreetmap.org. Détruire des données fort utiles aux randonneurs serait donc une grave erreur. En revanche, si l'hébergeur du miroir des données OSM-FR souhaitait anticiper une éventuelle attaque juridique par la FFRP (qui me semble peu probable, puisqu'ils se rendent sans doute compte que leur image, et leur reconnaissance d'utilité publique, seraient écornés par une telle aventure), il pourrait réfléchir à la mise à disposition d'un extrait censuré. Il faudrait vérifier ensuite si les outils exploitant les extraits (mapnik, mkgmap etc.) savent gérer des données manquantes; j'imagine que oui. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A lire: L’IGN œuvre pour la gratuité du patrimoine géographique
fg == Francescu GAROBY windu...@gmail.com writes: fg De plus, il est précisé que les données sont mises à disposition fg gratuitement aux établissements d’enseignement et de recherches ainsi qu’à fg tout acteur chargé d’une mission de service public et étend en permanence fg la gamme des données diffusées gratuitement au grand public, excluant par fg exemple les entreprises publiques et privées n'ayant pas de mission de fg service public, mais qui ont pourtant financé l'IGN par leurs impôts (IS). C'est un très bonne remarque, mais ce sont des argumentaires qui ne sont pas évidents pour les gens au premier abord («ben pourquoi on aiderai des entreprises à gagner de l'argent ...?»). Je pense qu'un document qui expliquerait les différences un peu subtiles entre différentes formes de gratuité (du GMM/Tomtom MapShare «vous pouvez contribuer gratuitement à augmenter la valeur de nos données» à «vous pouvez visualiser gratuitement sur géoportail pour un usage noncommercial» à «vous pouvez utiliser dans un cadre labellisé recherche/éducation» à CC-BY-NC à CC-BY), avec des exemples de cas d'utilisation, serait fort utile. Des volontaires pour travailler avec moi sur un brouillon sur le wiki? -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Témoignages, données et logiciels libres
rn == Pieren pier...@gmail.com writes: rn Et je persiste et signe : l'abus de moquette nuit gravement à la santé ^^ Par souci de salubrité publique, j'en conclus qu'on devrait s'interdire de cartographier les zones d'élevage de moquette? -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Modifications utilisateur Géovélo
fr == forum-Bzu66xTqZVFAfugRpC6u6w fo...@letuffe.org writes: fr Je voulais savoir si vous aviez des problèmes de qualité dans les fr modifications de l'utilisateur Géovélo. Sur Nantes il a tendance à fr faire un peu n'importe quoi à la va vite sans même vérifier fr visiblement en créant des aménagements fictifs entres autres … fr fr Je m'adresse surtout aux utilisateurs de Paris, Toulouse et Lyon fr sur lequel il semble actif ces derniers temps. Même constat sur Toulouse, où j'ai du corriger pas mal de contributions Géovélo qui manquent de rigueur (absence de continuité des pistes vélo dans la jointure avec le réseau routier, intersections abusives de pistes avec d'autres types de way). (Au cas où qqun poursuivrait la discussion sur le forum, auquel je ne participe pas.) -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
jl == Jean-Marc Liotier j...@liotier.org writes: jl Une ou plusieurs personnes volontaires (au hasard Christian et jl Sylvain...) pourraient être officiellement nommé French data jl import ombudsman (médiateur des imports de données en France) jl par le groupe de travail Relations Internationales d'OSM-FR et jl parlant avec le mandat de l'association. jl jl Le débat prendrait alors une tournure institutionnelle dans jl laquelle les questions de gouvernance et de subsidiarité ne jl pourront plus être esquivées à chaque fois que nous les évoquons. Bonne idée. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
fr == Frederik Ramm frede...@remote.org writes: fr If I do that, would that change the attitude towards the separate fr account question, or would it be a a waste of time? Frederik, you are focussing on the technical ramifications of this rather narrow separate account issue, but in fact, as many of us have tried to explain multiple times, the real issues are more fundamental: - the legitimacy of the OSMF DWG concerning monitoring of imports (and blocking accounts on this basis) is unclear. The DWG mandate, as per its web page on OSMF's web site, does not include monitoring imports. I have seen no deliberation of the OSMF board giving DWG the right to block contributors (who are clearly neither sabotaging the data nor making foolish beginners' mistakes) on the basis of its interpretations of import guidelines (please look up the meaning of the word guidelines). - the process which led the DWG to decide that a separate account shall be necessary is absolutely opaque. A normal process for such as change would be to explain your motivations, request feedback from contributors (for instance via the talk mailing list), then document the motivations and consequences on the wiki. You have only documented this requirement, which seems pulled out of your hat. - the way in which DWG is undertaking its monitoring+blocking, by sending aggressive messages to contributors in a language which they can be presumed not to understand, seemed pretty autistic at first, and now seems arrogant and bigoted. Indeed, DWG members have continued in the same way despite repeated attempts to explain the negative impact that this is having on well-meaning contributors. - the way in which DWG has ignored proposals from French contributors to help act as intermediaries in this respect makes it look like you wish to avoid the constitution of well-structured local/national communities, when (in my opinion) this is a major challenge for the next years of Openstreetmap's growth. Note that none of these issues are specific to the French community, but concern OSMF governance, its values, its processes and its degree of respect for local communities and for contributors. I have seen no effort to address these issues, but rather significant avoidance of our numerous messages asking for answers. Please consider changing that. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
On 18/10/2012 10:41, Frederik Ramm wrote: I have the impression that you are trying to make a large conflict out of a small issue. The overwhelming majority of the French OSM community has never had an issue with DWG, yet you are trying to cast this into a the French community against the DWG battle. Please check the archives of the talk-fr mailing list. This issue has led to multiple threads and hundreds of messages over the last few months. Almost all of them are opposed to and disappointed by the behaviour of the OSMF DWG; many of them question the legitimacy of your mandate to act on this issue. In fact in a broader way, I see this as a DWG-vs-local-communities issue. If you are not able to understand that working with local community correspondants is a far better approach than threatening contributors in a language which they can be presumed not to understand; if you continue to ignore all requests for debate on issues of governance, then your behaviour is a serious obstacle to the reinforcement of local communities, and thus in my view a significant threat to the Openstreetmap project. I have the impression that you are fighting a personal vendetta here because you were personally asked to follow the separate-import guideline, you rejected that, and you got blocked. Now it's ok if you're unhappy and you're free to say that, but in attempt at styling this into a the whole French community is on my side, I have done nothing wrong battle you are actually abusing the French community for your cause. Neither of my OSM accounts have ever been blocked, as far as I can tell. If members of the French community feel they are being abused by me, they are sufficiently grown up to say so themselves. Please address the substance of my message, instead of speculating on my motivations. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
ga == Apollinaire gaetan.jar...@laposte.net writes: gj À terme, l'issue de ce conflit sur le pouvoir du DWG concernera bien plus gj que la communauté française, et si nous donnons l'image « d'irréductibles gj français » un peu chieurs, tant mieux : l'enjeu dépasse OSM-FR. Je préfère gj cette attitude à celle d’ânonner « la règle c'est la règle » le doigt sur la gj couture. Nous n'avons ni les mêmes géographies, ni les mêmes cultures, et gj c'est tant mieux. Absolument d'accord. Ce conflit que le DWG cherche à focaliser sur un point relativement trivial de compte séparé a comme origine profonde deux enjeux essentiels : - celui de la gouvernance (subsidiarité, transparence de l'action de personnes dotés de pouvoirs de censure, conditions de la légitimité d'actions entreprises par l'OSMF à l'encontre de contributeurs) - le respect des particularités nationales/locales et l'aide à la constitution de communautés locales bien structurées Pour ma part, j'ai l'intention de continuer à insister sur ces points auprès du DWG (et liste talk@), jusqu'à ce qu'ils le comprennent. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman
pv == Philippe Verdy verd...@wanadoo.fr writes: pv On en revient donc au problème d'origine : faire respecter, par le DWG pv et ses membres, les limites de sa mission concédée par la communauté, pv pour qu'il n'abuse pas des privilèges accordés nécessaires à cette pv mission. Absolument d'accord avec Philippe Verdy ! Le DWG a eu largement le temps de se concerter avec la communauté française concernant les questions d'intégration du cadastre (ces gens semblent avoir beaucoup de temps disponible pour surveiller tous les changesets dans OSM, mais peu pour progresser sur des questions de gouvernance ...). Les personnes qui continuent à envoyer des messages d'harcelement, en anglais, aux membres de la communauté française, alors que les contributions en question sont clairement positives pour le projet et en accord avec les recommandations de notre communauté, nécessitent visiblement une aide supplémentaire pour comprendre ce que signifique le mot «communautaire». Je vais écrire un nouveau message au DWG. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
Hello, It is clear from discussions on the talk-fr mailing list that DWG members (in particular, Paul Norman) are continuing to hassle French contributors who are integrating cadastre data in a manner which is perfectly compatible with the local community guidelines for this source of data. These messages are being sent in English (perhaps DWG members need to be reminded -- again -- that some people are not able to understand English) and are aggressive in nature. This is despite sustained efforts over several months by members of the French community, who have volunteered to act as local intermediaries in this important and sensitive process of communicating with and helping contributors in a constructive manner. I am having trouble understanding how a group of people who presumably wish to make a positive contribution to this fantastic community-based project can be so blind to such basic principles of communication, community building, and simple respect for fellow human beings. My impression is that the majority of the anti-social behaviour is coming from a single person, and that other group members are unwilling to take a stand on this issue. Please take this opportunity to reflect on a proposed policy which you could decide upon as a group, propose for comment from OSM contributors (for example via the talk@ mailing list), document on the OSMF web site, and ensure that all DWG members follow the policy (no loose canons on deck -- the current situation is killing contributors). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Installatiosn classées (était: Tagger du nucléaire [long])
cg == Cyrille Giquello cyrill...@gmail.com writes: cg J'ai rien trouvé sur les risques industriels dans le LOV (Linked Open cg Vocabularies) cg http://lov.okfn.org/dataset/lov/index.html Comme c'est un domaine fortement soumis à la réglementation, il existe un vocabulaire bien défini pour ce domaine. La directive Seveso II comporte une classification des types de dangers et des produits concernés dans son annexe 1 ; la mise en oeuvre française de la directive Seveso s'appuie sur une nomenclature spécifique ; tout ceci devra à terme s'aligner sur la nouvelle réglementation européenne sur la classification des produits dite «CLP», qui elle-même est basée sur la classification «GHS» des Nations Unies. http://www.installationsclassees.developpement-durable.gouv.fr/La-nomenclature-des-installations.html Compte-tenu de la complexité du domaine, il me semble qu'il serait pour l'instant suffisant de s'en tenir à cartographier quelques types d'installation/équipement industriels à fort impact en termes de périmètre de sécurité et généralement visibles : - les stockages d'hydrocarbures (industrial=oil_tank_farm + man_made=storage_tank + storage_tank=fuel) - les raffineries (landuse=industrial + industrial=refinery) - les sphères de stockage LPG / ammoniac (industrial=storage_tank + storage_tank=gas/ammonia/chlorine) - éventuellement, les canalisations de gaz haute pression (man_made=pipeline + type=gas) A discuter ; l'utilisation de certains de ces tags est assez réduite, pour l'instant. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Installatiosn classées (était: Tagger du nucléaire [long])
po == Pierre-Alain Dorange pdora...@mac.com writes: po OpenHazardMap propose actuellement : po po hazard_prone=yes po + hazard_type=* po po avec flood (inondations), landslide (glissement de terrain) et po avalanche. Je ne suis pas du tout convaincu par cette suggestion. Il s'agit d'informations que des experts déterminent à l'aide d'un DEM associé à des d'informations sur les crues de rivière ou de nature des sols. Ca n'est pas vérifiable localement et ça n'apporte rien aux données existantes dans OSM : à maintenir dans des bases de données séparées, à mon avis. po Mais en s'inspirant de ça on peut ajouter des types, voi même des types po spécifiques au classement français. po po Pour un chais de Cognac : po hazard_prone=yes po + hazard_type=industrial po + hazard_source=alcool po + hazard_nomenclature:fr=seveso-haut Plusieurs commentaires : - Un tag hazard_prone n'a pas vraiment de sens pour le risque industriel ou technologique. On peut estimer des niveaux d'aléa (de type surpression, thermique, toxique) en chaque point de l'espace autour d'une installation industrielle, mais ce n'est pas une information facile à représenter dans OSM (et d'ailleurs, chaque estimation dépend des hypothèses de modélisation). - hazard_type pourquoi pas, mais ça devrait prendre des valeurs fire, explosion, toxic - La classification des ICPE selon le code de l'environnement (enregistrement, autorisation, autorisation avec servitude) est une problématique administrative qui est l'affaire de la police des installation classées. A mon avis il est plus pertinent de cartographier le type d'installation que sa classification administrative (qui peut d'ailleurs changer, selon les quantités de produit stockées ou les évolutions de la nomenclature). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
sh == Sarah Hoffmann lon...@denofr.de writes: sh Objects are real word objects here: highways, pois, boundaries etc. sh In other words, for 7 imported buildings you manage to map one sh non-cadastre object. So indeed, I would agree that French sh contributors do map other details. sh Occasionally. Very. Occasionally. This is an interesting point of view. How many buildings do you think there are on an average street in France? Fewer than for an average street in the USA, certainly, but likely more than 7. sh Whatever use all those balconies, patios and swimming pools might sh have in the future, right now in the present the cadastre import sh has become a major nuissance for anybody who wants to use OSM data. sh It wastes lots of bandwidth and CPU time. If it wasn't for the sh cadastre imports, we'd still be able to keep the 32bit id space sh for nodes for another year or two, which would save a lot of hard sh disk space for a lot of people. Amazingly, bandwidth and hard disk space per euro are increasing faster than these lazy French cadastre importers can pollute the database ... Which isn't to say that buildingless planet extracts might be useful to some people. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
jt == Jochen Topf joc...@remote.org writes: jt I think there is a misunderstandig here. You seem to suggest that according to jt those new guidelines you are supposed to import the data with one account and jt then in a second step fix things with the normal account. This is not the case. jt It has been a long-standing policy that (whether you do normal edits or any jt kind of import) you are supposed to always leave the map in a good state. This means that the import account will agglomerate contributions sourced from the import (cleaned up building outlines, for instance) and a large number of ordinary, manual edits/improvements (improving the road network's geometric precision, adding tags) which are sourced from Bing, GPS traces, personal knowledge, etc. Individual changesets will be a mix of data from different sources, with different copyrights. Since there is no change to the clarity of copyright status, I really don't understand the point of a separate account for this type of import (obviously country-wide, mechanical CLC-type edits are different). -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
Thank you for making this constructive proposal. My feeling is that it would constitute a positive change to the current DWG import guidelines, which are greatly lacking in subtlety. Allow me to point out, and illustrate with the French cadastre case, a problem posed by the wish strictly to separate the import component of a bulk edit (corrected/checked building geometries) from the integration component (resolving conflicts with existing building geometries and their tags, improving highway geometries using the high resolution cadastre information, etc.). Under the current (French) community guidelines for integrating this data, these two steps are combined in a single changeset. Separating them would lead to a situation where, during the period between these two changesets, the database is in an inconsistent state (overlapping buildings, highways passing through buildings, etc.). Whilst this temporary inconsistency in the data is not as severe as it would be in a software development project, for instance (the dreaded FTBFS), it is rather dirty and could lead to false alerts in error checking software. Whether this data consistency problem is more or less significant than the improved tracability of data source copyright that is afforded by the proposed import/integration separation is debatable. In my view, the costs of the proposed change outweigh its benefits (at least as far as the French cadastre situation is concerned -- other bulk edits/imports will likely have different tradeoffs). -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Imports du cadastre et compte dédié
fm == Fabien marbolan...@gmail.com writes: Regarde ça : http://www.openstreetmap.org/browse/changeset/13234931 On parle de passer sous les radars, regardez l'illustration du profil utilisateur fm Pareil j'ai pas regardé mais l'utilisateur que j'ai vu à quand même 11 fm « imports » cadastre en 5 jours ! Clairement faire de la qualité à fm moins d'avoir préparé ça en vacances off-line c'est pas possible ! Bonjour Fabien, Si tu as des commentaires précis et documentés à faire sur ces contributions, n'hésites pas à utiliser la fonctionnalité «messagerie» d'OSM. Si tu prends le temps de t'y pencher, tu remarqueras peut-être que les contributions en question sont «propres» dans le validateur JOSM, que la voirie a été intégrée en même temps que le bâti, que bien des tracés approximatifs préexistants ont été améliorés et erreurs de connectivité de voirie corrigés. Pour ton information, je contribue à OSM depuis 2007. Je n'avais pas commis d'intégration cadastre depuis quelques années, mais l'intégrisme récent manifesté par certains membres du DWG de l'OSMF (auquel j'ai par ailleurs réagi sur les listes talk@ et talk-fr@) m'a incité à chercher à démontrer que cette source de données peut être utilisée pour produire des données de bonne qualité. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imports du cadastre et compte dédié
jml == Jean-Marc Liotier j...@liotier.org writes: rf Un peu comme rf http://lists.openstreetmap.org/pipermail/talk/2012-September/064482.html rf peut-être? :) jml Oui - nos messages se sont croisés. jml jml J'aime bien ta proposition - j'espère qu'elle aidera à rapprocher les jml points de vue opposés. Oui, merci à Richard de faire des propositions constructives. Je pense également que cette proposition est un pas dans la bonne direction, mais qu'il serait utile comme préalable de préciser les objectifs précis du contrôle des «mechanical edits» (aide à leur surveillance, information précise sur les licences en jeu, etc.) pour vérifier que les mécanismes suggérés sont les meilleurs possibles. S'agissant du cadastre, par exemple, toute politique qui viserait à vouloir isoler la partie «import» de la partie «intégration» (amélioration du tracé de la voirie existante, par exemple) aurait des effets négatifs : on se retrouverai pendant la période entre ces deux changesets avec des données érronnées. Ca ne peut que nuire aux outils de contrôle de qualité. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imports du cadastre et compte dédié
rn == Pieren pier...@gmail.com writes: rn Je pense que comme ils ont un message pré-formatté pour cette demande, rn on devrait leur envoyer une réponse pré-formattée du genre: D'accord avec cette réponse (sauf qu'on devrait à mon avis la donner en français plutôt qu'en anglais ...). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Import guidelines OSMF/DWG governance
th == Tom Hughes t...@compton.nu writes: ecm account block. But historical information such as the number of ecm blocks imposed per week are missing AFAICT (allows people to ecm monitor for admin abuse). th It should be pretty obvious from browsing the block list: th th http://www.openstreetmap.org/user_blocks th th the first page of 20 entries normally covers at least a few weeks. Thanks, this is quite adequate for the purpose I had in mind. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
rw == Richard Weait rich...@weait.com writes: rw the facts at hand. A group of importers decided that they weren't rw going to follow the guidelines. Then one failed to respond when rw approached about a specific guideline. And now a group is upset to rw find that their self-declared-being-above-the-other-mappers is not rw widely supported. You are being unnecessarily inflammatory, Richard. Noone before you has talked of some mappers being above other mappers; shame on you for framing things in that way. One constructive question which has emerged from the debate (see messages by Frederik Ramm, Richard Fairhurst and Jean-Marc Liotier) is as follows: certain local communities have established, over many years, tools, specialized guidelines and monitoring tools for the use of specific data sources. In some cases these may deviate from the general, broad guidelines for imports/mechanical edits. What criteria should be used to distinguish between - local customs which have no negative impact on the project and allow the project to represent geographically/culturally specific features (eg. motorway=yes in Germany) - local customs which endanger the project globally (such as integrating data from a source whose copyright status is unclear/debatable) with a whole range of intermediate issues, such as the separate-account-for-imports suggestion, where French community consensus is that (given all the points already discussed) the inconvenience and burden on contributors outweigh the claimed benefits. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
pb == Pierre Béland infosbelas-...@yahoo.fr writes: pb Simon, this discussion was started to discuss about governance. We pb only see examples of problematic imports. But the question we pb should look at is how we can better tune or multinational / pb multicultural organization to adress these problems. The pb respective roles of local communities and the DWG group have to be pb defined. We should also give tools to the local communities to pb monitor mapping, contact mappers, be able to exchange. And we pb should not only think of national groups. You sometime have groups pb at regional or municipal levels. This issue of governance, the subsidiarity principle, and the manner in which OSMF working groups can help local mapping communities to improve the map is indeed the fundamental issue. DWG members (excepting Frederik) seem to be purposefully ignoring the issue. Please stop doing that. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports
On 18/09/2012 01:02, Richard Weait wrote: I think that it is worth examining our disagreement on this roundabout a little further. If you were mapping just this intersection would you map it as a T-junction or as a roundabout? I expect that you would map it as a roundabout. If I was coaching a new mapper, or mapping it myself, it would be mapped as a roundabout. I must admit I don't understand this. I am trying to talk about project governance, the principle of subsidiarity and the manner in which OSMF working groups can help local mapping communities to improve the map, and you want to talk about a roundabout. Are you making fun of us? My best guess as to the Roundabout Inquiry is as follows: * when the D5 and D17 were first mapped in 2009, there was no roundabout * at some later point, a roundabout was built * the contributors in 2012, for whatever reason, did not map it If the DWG intends to conduct an inquiry into the 800 million roundabouts on this planet, I suggest that you need to increase your staffing level. Baffled, -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports
Je fais suivre ici quelques messages qui font suite à ce fil de discussion, mais pour lesquels la liste de diffusion n'a pas été mise en copie (vraisemblablement exprès, mais j'estime que le contenu concerne tous les contributeurs français). Eric ---BeginMessage--- Le 16/09/2012 22:10, Richard Weait a écrit : On Sat, Sep 15, 2012 at 6:27 AM, Eric Marsden eric.mars...@free.fr wrote: Hello, DWG member Paul Norman has implemented a 24 hour account block on contributor Marc Sibert, citing as justification the import guideline concerning use of a dedicated account. Marc Sibert is a very active member of the French OSM community, and there is overwhelming agreement in the French Openstreetmap community that this aspect of the import guidelines is not appropriate for semi-automated imports from the French cadastre. I don't think that French cadastre importers are being as careful as you think that they are being. Let's look at this changeset from today. The user has been previously notified that a separate account is required for imports. They appear not to have followed this guidance as this changeset has 46000 nodes and 3000 ways. http://www.openstreetmap.org/browse/changeset/13130816 I looked at the first four buildings imported, and found the are from the attached image. Problems. - missing roundabout shown in imagery - bad shape of water - bad width of water - disconnected water either side of a road. I do not consider this a good example of responsible use of an external source. It appears to be a simple dump of data from cadastre, with only minimal connection for the road. I don't see how the user would connect the cadastre road to the existing road by user ratzilla, without adding the roundabout though. That seems really odd. Given my very superficial examination of the one changeset, I'm left with an expectation that the rest of the changeset is also of low quality. I'm inclined to send another notification to the user along with a temporary block. it would request: - separate account - better reconciliation of available sources before import - smaller edit areas I have not done this yet, and will for now send only the message, not the block, as a gesture of good faith. Would you please: - contact the mapper and advise them to use a separate account for imports. Yes. Cadastre used this way is an import. - instruct them in how to do a better job. Probably by using a smaller area and much more care. I think that you can do a better job of helping this mapper than I can. If they continue to ignore you, I'll be happy to get their attention with a block. Best regards, Richard Hi, Again, my account was blocked because I was not following the Guidelines not because of vandalism. Here, you are changing the subject to quality, that's not the point. Should I loose my time to find errors at roundabout in UK or anywhere else in the world : the proof is only that anyone corrects what he's interested in (buildings not roads, etc.) Again, my point of view, is that local imports doesn't need a special account : what for ? revert ? You can do it with my regular account ! a+ Marc -- Marc Sibert mailto:m...@sibert.fr ---End Message--- ---BeginMessage--- On Sat, Sep 15, 2012 at 6:27 AM, Eric Marsden eric.mars...@free.fr wrote: Hello, DWG member Paul Norman has implemented a 24 hour account block on contributor Marc Sibert, citing as justification the import guideline concerning use of a dedicated account. Marc Sibert is a very active member of the French OSM community, and there is overwhelming agreement in the French Openstreetmap community that this aspect of the import guidelines is not appropriate for semi-automated imports from the French cadastre. I don't think that French cadastre importers are being as careful as you think that they are being. Let's look at this changeset from today. The user has been previously notified that a separate account is required for imports. They appear not to have followed this guidance as this changeset has 46000 nodes and 3000 ways. http://www.openstreetmap.org/browse/changeset/13130816 I looked at the first four buildings imported, and found the are from the attached image. Problems. - missing roundabout shown in imagery - bad shape of water - bad width of water - disconnected water either side of a road. I do not consider this a good example of responsible use of an external source. It appears to be a simple dump of data from cadastre, with only minimal connection for the road. I don't see how the user would connect the cadastre road to the existing road by user ratzilla, without adding the roundabout though. That seems really odd. Given my very superficial examination of the one changeset, I'm left with an expectation that the rest of the changeset is also of low quality. I'm inclined to send another notification to the user along with a temporary block. it would request: - separate account - better reconciliation
[OSM-talk-fr] Arrêtons les imports des cours d'eau depuis le cadastre
Bonsoir, Comme vous avez pu le suivre ici, l'importation de données depuis le cadastre numérique est critiqué par différentes personnes du monde Openstreetmap, dont certaines ont un certain poids politique dans le projet (par exemple, le nouveau président de l'OSMF, Simon Poole, est un intégriste anti-import et pro-ODbL). J'ai récemment défendu une utilisation raisonnée des données bâtiments du cadastre auprès du Data Working Group, qui fait de l'activisme sur le sujet (allant à mon avis bien au delà de son mandat, et ne respectant pas le principe basique de subsidiarité). Je pense avoir défendu la position majoritaire dans la communauté française sur ce point, mais naturellement chacun est libre d'intervenir dans le débat. Je suis embêté pour défendre l'usage qui est fréquemment fait des données sur les cours d'eau issues du cadastre. Ces données accumulent plusieurs défauts importants (et pour ma part, je ne les intègre pas dans OSM): - dans de nombreux endroits, elles représentent des zones susceptibles d'être régulièrement inondées, plutôt que le lit du cours d'eau qu'on aimerait avoir comme waterway=riverbank - elles donnent uniquement une représentation surfacique, sans le waterway=stream (ou river) qui serait plus utile ; la représentation surfacique s'interrompt aux croisements avec les routes. Je vois rarement des endroits où les contributeurs ont rajouté ces informations filaires. - les données ont des géométriques excessivement complexes donc alourdissent inutilement la base (surtout pour une précision de géolocalisation qui me semble parfois relativement faible). Peu de contributeurs, dans les zones que je fréquente, semblent simplifier les géométries, alors que c'est suggéré dans le checklist. J'aimerais suggérer que : - nous cherchions à développer un algorithme pour déterminer la représentation filaire à partir de la représentation surfacique (mon niveau en PostGIS est hélas trop faible pour ça) - on intègre cet algorithme à la moulinette sur cadastre.openstreetmap.fr (pour remplacer les données waterway=riverbank) - en attendant que le code soit au point, les données -water ne soient pas mises à disposition sur ce site Qu'en pensez-vous? -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports
vp == Vincent Pottier vpott...@gmail.com writes: vp Je crois que pour faire avancer notre point de vue hors vp frontières, il faut aussi qu'on mette, de notre côté, l'accent sur vp la qualité de l'intégration. Je vois deux points : vp * quoi qu'on pense de la pertinence par ailleurs, la question de vp l'overlap des buildings corrigés à la mano est un point important. Je suis d'accord, et j'estime que les contributeurs français sont laxistes à cet égard : une géométrie invalide, c'est une géométrie invalide. J'en corrige beaucoup manuellement. vp * on est faible, lors des intégrations de buildings, dans la vp qualification de ces buildings en yes|house|apartments|church... vp Quelqu'un avait soulevé ce point il y a quelques temps. Il y a là vp aussi de la valeur ajoutée à la main. Qualifier à la main demandera un effort gigantesque, et quand je vois le nombre de routes en zone rurale qui ne sont pas présentes dans OSM, je n'y crois pas beaucoup pour l'instant. Mais si la personne qui développe le script d'extraction utilisé sur cadastre.openstreetmap.fr pouvait changer le building=yes en building=church pour les églises (déjà détectées puisque tagguées en amenity=place_of_worship), ça serait un petit pas en avant. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports
md == Matthias Dietrich eiger@gmail.com writes: md pourquoi est-on passé en novembre 2011 d'une recommandation d'un md compte séparé à une obligation ? Décision d'un groupe de la OSMF ? md Discussion ouverte ? Dans les ML talk et imports, je n'ai rien vu md autour de novembre 2011. Je n'ai pas de réponse : je présume que le DWG (dont les archives de la liste de diffusion ne semblent pas être publiques) en a discuté en conciliabule. Encore un exemple de l'opacité du fonctionnement de l'OSMF. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arrêtons les imports des cours d'eau depuis le cadastre
rn == Pieren pier...@gmail.com writes: rn Je ne sais pas si vous vous rendez compte mais ça n'est pas le rôle de rn la fondation, ni du DWG de décider de la pertinence des données à rn importer. C'est à nous, en tant que communauté des contributeurs de le rn faire. Il y a ici un énorme dévoiement des missions de la fondation. rn C'est scandaleux et un dangereux précédent. Je suis absolument d'accord avec toi, et c'est une question fondamentale de gouvernance. J'ai peur que l'OSMF, dont le fonctionnement est depuis longtemps opaque (parfois simplement par manque de temps), poursuive sa dérive autocratique, qui elle me semble basée sur une méfiance à l'égard du contributeur de base. Ceci dit, ça nous impose (ou devrait nous imposer) en tant que communauté semi-organisée une rigueur peut-être plus importante qu'actuellement sur ce qu'il convient d'intégrer, sur le suivi des éjaculateurs précoces de l'import, sur la pédagogie envers de nouveaux contributeurs, etc. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Marcussacapuces91 bloqué par pnorman
Ci-dessous un message que j'ai envoyé au DWG en réaction à cet abus d'autorité manifeste. - From: Eric Marsden eric.mars...@free.fr Subject: Abuse of authority: account blocks related to French cadastre imports To: d...@osmfoundation.org Date: Sat, 15 Sep 2012 12:27:30 +0200 (31 seconds ago) Hello, DWG member Paul Norman has implemented a 24 hour account block on contributor Marc Sibert, citing as justification the import guideline concerning use of a dedicated account. Marc Sibert is a very active member of the French OSM community, and there is overwhelming agreement in the French Openstreetmap community that this aspect of the import guidelines is not appropriate for semi-automated imports from the French cadastre. http://www.openstreetmap.org/user/Marcussacapuces91 I would therefore like to request that this block be revoked, and that DWG accept that established local mapping pratices take precedence over ex cathedra dogma. Please understand that the semi-automated imports from the French cadastre are different from traditional imports in a number of ways: - contributors make a substantial amount of work on the raw data before sending it to OSM: correcting overlaps, removing useless nodes, removing duplicate ways, merging with existing (manually traced) buildings. This work often takes multiple hours for a single administrative entity. In no way is this bot-like activity. - contributors often trace roads and tag their names from the cadastre within the same changeset. - cadastre semi-automated imports are, by definition, highly localized geographically. The French community is well aware of the existence of some abusive cadastre imports, where contributors have not cleaned the raw data before importing and have not completed the highway data. However, these are generally identified quickly and the lazy/uninformed contributors are pointed to the cadastre import guidelines. Please note that this is a DISTINCT PROBLEM FROM USE OF A SEPARATE ACCOUNT. Thank you for your prompt resolution of this error, -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Marcussacapuces91 bloqué par pnorman
sly == sly (sylvain letuffe) li...@letuffe.org writes: sly Et tu l'a magnifiquement fait, la question étant maintenant de savoir si on sly peut suivre et/ou participer à la discussion, qui, je l'espère, va suivre et sly sera constructive ? Je vais copier talk-fr sur mes messages dans le fil. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports
On 15/09/2012 13:49, Richard Weait wrote: On Sat, Sep 15, 2012 at 6:27 AM, Eric Marsdeneric.mars...@free.fr wrote: DWG member Paul Norman has implemented a 24 hour account block on contributor Marc Sibert, citing as justification the import guideline concerning use of a dedicated account. Marc Sibert is a very active member of the French OSM community, and there is overwhelming agreement in the French Openstreetmap community that this aspect of the import guidelines is not appropriate for semi-automated imports from the French cadastre. The import guidelines do not distinguish between better or worse imports. Only imports. Any edits that includes a mass of data from an external source is an import. If it is done correctly, it will be carefully inspected and de-duplicated and merged with existing data. Then it becomes a permitted import. If it fails to be inspected, de-duplicated and properly merged with existing data it becomes a reverted import. This is not in dispute. (There could be a useful discussion concerning the manner in which DWG communicates with new/misguided contributors: your current approach is rather arrogant in assuming that everyone understands English. I would suggest that you build a network of local correspondants; I believe that someone has already volunteered to liaise with French contributors, but this proposal seems to have been ignored in this case.) But it is still an import. And it still requires, per the community import guidelines, an import account. I think you are misunderstanding. The community import guidelines concerning the integration of French cadastre data are at http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents Naturally, specialized guidelines which have been drafted by the local community which manages the data (I have not so far seen any French cadastre imports affecting the USA or Canada) trump more general guidelines. Interference by unelected people who do not contribute in the area and act against the local community's wishes, is unlikely to improve the situation. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Article sur carto numérique dans The Atlantic
Un article intéressant (en anglais) dans The Atlantic sur les enjeux de la cartographie numérique, et les moyens et outils déployés par Google pour développer leurs cartes. http://www.theatlantic.com/technology/archive/2012/09/how-google-builds-its-maps-and-what-it-means-for-the-future-of-everything/261913/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fire_hygrant et odbl=clean
nn == nono pingven...@free.fr writes: nn lire : nn emergency=fire_hydrant nn fire_hydrant:type=pilar nn nn vous aviez compris, je pense ;) «pillar» ça prend deux l. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] average speed as opposed to speed limit in calculating routes
rn == renato renn...@gmail.com writes: rn Could something like this be done in OSM? Has someone ever thought of rn it? First thought would be an average_speed_by_car tag, that navigators rn could use in calculating routes. Even better would be an automated way rn of updating these tags by users using the navigator. Hi, See the following thread for a discussion of prior work on this subject in OSM (including code developed during a 2010 GSOC project). http://thread.gmane.org/gmane.comp.gis.openstreetmap.devel/21542 -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funny Twitter redaction comments
lm == Lambertus o...@na1400.info writes: lm The following Twitter channel posts funny (imo!) comments about lm the redaction and the damage it causes. lm lm https://twitter.com/redactionbot That is a very funny Twitter feed! Channeling Dr Strangelove. lm However not everyone shares the same humor and some comments are lm considered offensive by mappers in affected areas. Some think this lm is an 'official' channel for the OSMF and asked me to mediate lm between them and the OSMF. Sensitive people should not read random Twitter feeds. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Fil Twitter du redactionbot
Un fil Twitter très drole, pour ceux qui apprécient l'humour à la Dr Folamour: https://twitter.com/redactionbot Ça permet de rire un peu de cet immense gâchis qu'est la destruction de données entraînée par le changement de license. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
Article intéressant, merci. La licence de la BD TOPO permet-elle à un organisme y ayant accès de publier régulièrement des données tirées d'un comparatif avec les données Openstreetmap? Je pense à une présentation à la OsmInspector des points où la distance de Hausdorff RGE/OSM est supérieure à 10m, qui serait actualisée une fois par semaine. Cela serait très utile pour améliorer la qualité des données OSM, relativement peu coûteux, et le résultat ne serait probablement pas considéré comme une oeuvre dérivée des données RGE (puisque utilisant autant les données OSM que les données RGE). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
[Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci est une information et non une traduction du message d'annonce.] Le robot qui supprimera les données incompatibles avec la licence ODbL et les termes du contributeur (c'est à dire, des données qui, à un moment dans leur historique, ont été modifiées par un utilisateur n'ayant pas accepté les termes du contributeur) devrait commencer son travail le mercredi 11 juillet (demain). Le robot tournera par zone géographique, dans l'ordre suivant: Ireland UK Western Europe North America Australia rest of the world Une fois ce travail de suppression des contributions terminé, les données OSM ne seront plus distribuées que sous la nouvelle licence expérimentale ODbL. Il est prévu que le processus de destruction des données dure environ un mois. Les serveurs et API continueront à fonctionner pendant cette période, sans interruption de service. Il est conseillé de sauvegarder plus souvent son travail lorsque le robot destructeur travaille dans sa zone, pour éviter les conflits d'édition. Ce processus était prévu pour démarrer début avril, mais sa composante technique avait été insuffisamment planifiée, d'où le retard dans sa mise en oeuvre. Message d'origine en anglais: http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
af == Ab fab gamma@gmail.com writes: af Dans le principe, tu penses à l'équivalent qualitatif de ce qui a été af réalisé en Bretagne, pour le quantitatif ? af http://wiki.openstreetmap.org/wiki/Carte_d%27avancement_OpenStreetMap_en_Bretagne Pas vraiment : ce qui est proposé chez Geobretagne est l'identification de zones où le réseau routier est mal renseigné dans OSM (par rapport au RGE). Ce que j'imagine est plutôt «à tel endroit, il existe un décalage de plus de 15m entre OSM et RGE», ce qui est plus immédiatement utile pour identifier des défauts importants dans OSM (ou dans le RGE!). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
rn == Pieren pier...@gmail.com writes: rn Je relance ce sujet mainte fois discuté ici. Je crois pouvoir dire rn qu'à l'heure actuelle, nous n'avons toujours pas reçu d'autorisation rn de la part de la FFRP pour utiliser ses itinéraires GR. Pourtant, rn certains sont présents dans OSM depuis un temps trop long déjà (voir rn l'exemple ci-dessous relevé sur le forum). À mes yeux, la situation concernant les GR est une honte, à deux titres: - que la jurisprudence française considère un parcours comme une oeuvre de l'esprit, donc potentiellement protégé par le droit d'auteur (tout randonneur comprend que le choix d'un parcours est principalement guidé par le pragmatisme et les contraintes du terrain et non par une réflexion intellectuelle digne d'être protégée) - que la FFRP, association reconnue d'utilité publique, ait eu par le passé un comportement juridique aggressif indigne Il serait très très dommage qu'on rajoute une troisième honte à cette liste, en supprimant le travail de contributeurs qui n'imaginent pas les problèmes possibles (et qui peut leur en vouloir: faudrait-il qu'ils réfléchissent aux subtilités du droit français avant de tagguer un magasin name=Carrefour?). Ceci en sachant que la base OSM est hébergée à l'abri des bétises du droit français. On peut imaginer, par contre, proposer des extraits France sur openstreetmap.fr dans lequel les tags ref=GR* seraient supprimés, avec une explication de la raison Kafkaesque de cette mutilation des données. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose : nouvelle analyse à propos des marques
fr == Frédéric Rodrigo fred.rodr...@gmail.com writes: fr Il faut dans beaucoup de cas utiliser le tag brand fr http://wiki.openstreetmap.org/wiki/Key:brand fr Voir aussi le tag operator fr http://wiki.openstreetmap.org/wiki/Key:operator Les épiceries franchisées «Petit Casino» ont exactement ce nom comme enseigne ; pareillement pour les banques. La distinction name/brand me semble être un pinaillage qui passera par dessus de la tête de 95% des contributeurs, et qui de surcroit ne sert à rien. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose : nouvelle analyse à propos des marques
pv == Philippe Verdy verd...@wanadoo.fr writes: pv comme ça on va vouloir donner l'URL d'un logo... Pour les réseaux de pv franchises, il vaut mieux créer une relation pour recenser les points pv annotés : pas besoin de brand sur chaque nœud, on mettrait ça plutôt pv dans la relation afin d'éviter la multiplication des tags et les pv incohérences (par exemple on pourrait avoir une relation pour toutes pv les enseignes McDonald). Quelle usine à gaz! Si je veux cartographier un nouveau point de vente McDonald's, comment vais-je savoir qu'il faudrait que je le rajoute à ta relation? Puis as-tu jamais essayé d'expliquer à des non-informaticiens comment utiliser les relations dans OSM? Ce type de relation, complexe à maintenir, est par ailleurs inutile: si je veux connaître les points de vente McDonald's dans mon coin, je peux chercher des points amenity=fast_food name=*McDonald* dans un bbox. Si je veux voir leur logo, je me rends sur leur site web. Si je veux connaître leur numéro d'immatriculation RCS en France, je cherche sur societe.com. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement de licence, la date approche
fds == Francisco DOS SANTOS f.dos.san...@free.fr writes: fds Vu sur le site de la fondation : fds http://www.osmfoundation.org/wiki/License/Rebuid_Plan fds fds Plus la date approche et plus j'angoisse ... http://fakestevec.blogspot.com/2012/02/inspirational-message.html Bel effort de massacre d'un projet, cette volonté de changement de licence. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement de licence, la date approche
vj == Vincent-Xavier JUMEL endymion+...@thetys-retz.net writes: vj Il aurait bien évidement souhaitable de continuer avec une licence vj inadaptée aux bases de données Aucune licence n'a aujourd'hui démontré (par la jurisprudence dans différents pays, qui ont des législations très différentes en ce domaine) qu'elle est adaptée aux bases de données. En revanche, une compréhension commune de l'esprit de la licence CC-BY-SA commence à émerger, et devrait protéger les contributeurs d'utilisations qui ne seraient pas conformes à cet esprit (celle faite par Apple, par exemple). vj et avec l'impossibilité pour la fondation de faire quoique ce soit vj du travail des contributeurs en cas de disparition de ceux-ci. Je ne suis pas intéressé par ce que la Fondation OSM peut faire du travail des contributeurs. En revanche, je suis très intéressé par ce que les _gens_ peuvent faire de ces contributions. vj J'estime au contraire que le transfert de «copyright» vers une fondation vj qui garantit une utilisation conforme à l'esprit du projet est un acte vj fort intéressant. Il n'y a pas transfert du copyright vers la Fondation, mais les contributeurs se voient contraints de lui accorder des droits d'exploitation particuliers. Et la Fondation OSM ne me semble pas travailler de façon conforme à l'esprit du projet; au contraire : - elle va procéder à la destruction du résultat d'énormes quantités d'heures de travail de contributeurs - elle suit un calendrier rigide de mise en oeuvre qui ne permet pas de limiter la casse, apparemment pour éviter que des membres du board ne perdent la face - elle n'étudie pas des pistes qui permettraient d'éviter cette destruction de données, comme le processus de rénovation des licences CC, qui devraient passer en v4 en fin d'année (et qui vont chercher à mieux intégrer les questions relatives aux bases de données) - sa communication sur un sujet ayant des implications aussi immenses (surtout dans certains pays comme l'Australie et la Pologne) a été quasi inexistante Que cette nouvelle licence donne davantage de pouvoirs à un organisme aussi mauvais est à mon avis une seconde conséquence négative de ce processus. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement de licence, la date approche
jt == THEVENON Julien julien_theve...@yahoo.fr writes: ecm elle n'étudie pas des pistes qui permettraient d'éviter cette ecm destruction de données, comme le processus de rénovation des licences ecm CC, qui devraient passer en v4 en fin d'année (et qui vont chercher à ecm mieux intégrer les questions relatives aux bases de données) jt Par curiosite, est ce que ses versions 4 seront retrocompatibles jt avec les versions precedentes ? ou il faudra un accord explicite jt de l auteur pour relicencier ? J'ai compris qu'elles devraient être retrocompatibles, et donc que OSM pourrait passer «automatiquement» vers la v4, sans devoir effacer de données (mais je ne suis pas expert en la matière). http://creativecommons.org/weblog/entry/30676 http://wiki.creativecommons.org/4.0 -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Usage d'OSM par les infographistes...
cq == Christian Quest cqu...@openstreetmap.fr writes: cq J'ai fait ça en semi-automatique, si vous pensez que ça peut être cq utile, je peux l'automatiser pour d'autres types d'extractions (les cq communes d'un département, le réseau hydrographique, ferré, cq autoroutier...). Serait-il difficile d'ajouter une couche raster avec le relief, d'après Natural Earth? http://www.naturalearthdata.com/downloads/10m-raster-data/10m-natural-earth-1/ (c'est du TIF avec un fichier .tfw, données dans le domaine public) -- Eric Marsden ___ 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
ho == Hendrik Oesterlin hendrikmail2...@yahoo.de writes: ho Peut-on avoir une explication ce que la question 4 veut dire? 4. Pensez-vous que la description de caractéristiques de certains objets comme « c’est le plus grand immeuble de la zone » ou de relations entre certains objets comme « l’abribus est exactement en face du bureau de poste » peut rendre le contenu encore plus utile ? Si non, pourquoi ? Si oui, avez-vous des exemples en tête, en particulier des relations entre des nouveaux objets et des objets topographiques de référence comme ceux présents sur les cartes de sources gouvernementales comme l'IGN (routes, bâtiments, etc.) ? Ceci me fait penser à une technique utilisée par Google Maps en Inde, pour générer des descriptions d'itinéraire intégrant des points de référence locaux («à droite après le McDonalds» ...). http://googleblog.blogspot.com/2009/12/go-thataway-google-maps-india-learns-to.html -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Critical Mass for license change-over
mc == Michael Collinson m...@ayeltd.biz writes: mc As the license change process evolved, concern was expressed that mc an unacceptable amount of data might be lost from the current mc version of the OSM database and consensus was reached that phase 5 mc [1] - the actual license cut-over - should only happen when a mc critical mass was achieved. mc mc The question I ask you is, do you agree that we have reached critical mass? This is ridiculous. How can the LWG ask whether the amount of data which is to be deleted is acceptable, when it hasn't yet decided on what is to be deleted? - there is a huge difference between the two damage-estimation sources that you cite (OSMI/WTFE and odbl.de) - noone seems able to answer the question of split ways. If interpreted rigourously with respect to copyright, it would significantly increase* the amount of damage currently estimated by WTFE. If not interpreted rigourously, there seems to be little point in the licence change since much data will be tainted. That no answers to such fundamental questions are available, just two months before the planned switchover, is ludicrous. * Something less than double, depending on how many non-acceptors have been using split/merge operations during editing (according to my understanding). -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Transition to CC-4 instead of destroying data
rw == Richard Weait rich...@weait.com writes: rw If CCv4 ends up being better than ODbL, and agreeable to the osm rw community at large, we could certainly transition to it. The new CTs rw would make that transition relatively smooth. We can make that call rw when it's ready. Thanks for your reply. I would like to suggest that two recent developments mentioned in this thread (update on the CC-4 process and possibility for a seamless transition for OSM; legal analysis provided by Ed Avis) be examined by the LWG, to decide whether to proceed with the current timetable for deletion of CC-only data. As I understand it, the push for ODbL was motivated primarily by two concerns: (1) the risk of nasty people ripping off data due to uncertainty over whether copyright applies to the OSM database in the USA (2) poor applicability of CC-BY-SA to derived works such as maps My reading of the legal analysis posted by Ed Davis is that concern (1) is not as strong as it seemed previously. (I also feel that the threat of shaming violators of the spirit of the OSM licence is a sufficient disincentive to ripping off, and further tend to agree with Russ Nelson's argument concerning the value of community, or living data over dead data.) Concern (2) could perhaps be (partially) addressed by clarification on the website concerning the way in which the project suggests that the notion of derived work be handled in specific use cases; I believe that in many jurisdictions, the intent of a licence is as important as its precise wording. We can also hope that CC4 handles this better (in 2013 or 2014). In my opinion, these two concerns are greatly outweighed by the destruction of huge amounts of data, useless remapping work and demotivation of many contributors which are certain consequences of the current plan for deleting CC-only data. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Transition to CC-4 instead of destroying data
Creative Commons recently confirmed that the next version of its licences will attempt to cover sui generis database rights. Version 4.0 is planned to be available at the end of 2012. This was previously mentioned here as a possible alternative to the destructive ODbL process. I don't see any discussion of this in recent LWG minutes. Has it been considered? http://creativecommons.org/weblog/entry/30676?utm_campaign=newsletter_1112utm_medium=blogutm_source=newsletter http://wiki.creativecommons.org/4.0/License_subject_matter -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] itransport un outil d'intermodalité national basé OSM TeleAtlas
cg == Cyrille Giquello cyrill...@gmail.com writes: cg Moviken développe des relations de partenariat avec les acteurs des cg transports, autorités organisatrices, exploitants, RFF, SNCF, … cg itransports.fr a été développé avec le soutien du Ministère des cg Transports, d’OSEO-Anvar et de l’ADEME. Ce site a l'air utile et bien fait, mais il me semble que les développeurs ne respectent absolument pas la licence OSM CC-BY-SA. Ils mélangent des données OSM et TeleAtlas pour générer les tuiles de fond (là où j'ai vérifié, sur Toulouse, ils utilisent clairement des données non-OSM, puisqu'ils font un rendu des numéros de rue là où OSM n'en a pas), et prétendent dans leur FAQ que , | L’édition, la diffusion, la reproduction et la commercialisation des | cartes de iTransports sont interdites, sauf accord particulier passé | avec Moviken. Elles constituent un délit au regard de la loi, par | conséquent, Moviken se réserve le droit d’agir selon toutes voies de | droit. ` (Le rendu des lignes de transport est fait dans une couche vectorielle séparée des tuiles, donc pas de pb de licence.) -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] itransport un outil d'intermodalité national basé OSM TeleAtlas
vct == Vincent de Chateau-Thierry v...@laposte.net writes: vct Je ne sais pas s'il y a mélange de données. Le seul endroit où vct j'ai vu de la donnée OSM c'est en dehors de l'aire du service, vct par exemple sur le Maroc. En zoomant vers Ceuta, on a une nette vct délimitation entre des tuiles au nord de source (a priori) vct TeleAtlas, et au sud des tuiles OSM avec un rendu Mapnik. Si la vct génération des tuiles des différentes sources se fait séparément, vct on est pour moi dans la situation de calque séparé à laquelle vct ils ont recours pour le rendu vectoriel. Effectivement, en y regardant de plus près, ce n'ont pas l'air d'être les données OSM en France. On voit un basculement entre jeux de tuiles dans l'est de l'Europe également. Donc en fait, un outil très peu basé sur OSM ... -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur (était: OSM destiné pour un besoin de randonnée)
sly == sly (sylvain letuffe) sylv...@letuffe.org writes: sly On pourrait même imaginer se passer de base de donnée pour ce cache et stocker sly des fichiers du syle : sly /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir sly au client) C'est effectivement ce qui est fait pour Kothic-JS http://osmosnimki.ru/vtile/ et il y a l'air d'avoir un moteur qui met ces tuiles à jour lorsque les données correspondantes évoluent (les dates des fichiers .js ne sont pas toutes les mêmes). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Announce: Beginning of Phase 4 of license change process
rf == Richard Fairhurst rich...@systemed.net writes: rf Sorry, you've puzzled me a bit here. rf You state that it's better to cite how much data would be deleted. rf However, that directly contradicts your previous paragraph, in which you rf quote, um, the number of users, not the amount of data. rf rf Reading odbl.de, although 60% of users in Europe have accepted the new rf contributor terms, that actually equates to between 80% and 92% of nodes, rf and between 70% and 93% of ways. In North America, your 40% of users is rf 54%-94% of nodes, and 66-85% of ways.[1] Hello Richard, It's quite simple: I object to the OSMF using what I consider to be very misleading statistics in communication on the ODBL process. Michael Collinson's message can be interpreted as saying that 0.2% of users haven't accepted the new contributor terms. I point out that a more reasonable way of presenting the data is that between 40 and 55% (depending on the region) of users haven't accepted the new contributor terms. I then argue that the most important statistic in deciding whether to go ahead with the big delete is how much data would be removed. odbl.de indicates (for Europe) 80% of nodes, 70% of ways, 50% of relations -- much lower for other areas such as Australia or the USA --- are at version 1 with a user having accepted the CT. As you point out, this is a lower bound on the amount of data that would be retained, since objects with a version 1 and only CT-accepting users would also be retained. There used to be a map at http://osm.informatik.uni-leipzig.de/map/ highlighting how much data would be retained, but it seems to have disappeared. On a related note concerning the process, I find it unreasonable for OSMF to ask people to accept the new CT without having first decided on a tolerability threshold on loss of data. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announce: Beginning of Phase 4 of license change process
mc == Michael Collinson m...@ayeltd.biz writes: mc As per the implementation plan [1], we intend to move to phase 4 mc this Sunday 19th June or as soon after as is technically mc practical. This will mean that anyone who has explicitly declined mc the new contributor terms will no longer be able to edit, (unless mc they decide to accept). This currently numbers 406 in total mc compared to over 191,000 who now contribute under the new terms. This is disingenuous communication, glossing over the very important issue of how many users have not voted (leading, if this plan goes through, to the deletion of their contributions and of any subsequent edits). Reading odbl.de, 60% of users have accepted the new contributor terms in Europe (40% in the USA, the proportion worldwide is not shown). There 417k users. So (extrapolating) 200k have not accepted the new terms and 190k have accepted. Hopefully the decision on whether to go ahead with the odbl transition will be based on how much data would be deleted, not this kind of misleading statistic. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Accessibilité pour personnes handicapées (était: Balisage de la dangerosité des routes pour les cyclistes)
ap == Art Penteur art.pent...@gmail.com writes: ap Et la première annonce avait provoqué une réaction (que je trouve ap justifiée) : décrire l'accessibilité, c'est faire du micro-mapping en ap ville : les GPS ne serviront pas à grand-chose, il vaut mieux parler ap de walking papers (ou des plug_in cadastre de JOSM/merkaartor). Tu as tout à fait raison. Nous avions des supports papier de type walking papers (mais en mieux car vectoriels), avec un découpage du centre historique de Toulouse en secteurs, dont voilà un exemple: http://dl.dropbox.com/u/1475149/secteur.pdf J'ai crée la carte des secteurs avec Maperitive (outil .NET qui tourne sous Linux avec Mono), avec le style par défaut dans lequel j'ai simplement réduit l'opacité du bâti. On se place sur la zone voulue grace au slippymap, on télécharge les données vecteur correspondants, puis Export SVG au format Inkscape. Excellente manière d'obtenir des rendus vectoriels qu'on peut adapter à son besoin. Une excellente journée (malgré temps gris) avec plus de 30 participants (dont un peu moins d'un tiers de personnes handicapées), qui s'est déroulée dans une super ambiance ... -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] transition éventuelle OdBL
el == Emilie Laffray emilie.laff...@gmail.com writes: ecm J'ai compris quelquechose de différent : l'édition sera bientôt ecm refusée pour les contributeurs qui ne se seraient pas prononcés sur la ecm nouvelle license + termes de contribution (par un oui ou par un non). el Avant d'avoir un quelconque refus d’édition, on regardera déjà si le el changement de licence peut se faire sans causer de dégâts. el Si le choix est fait de partir vers une licence de type ODbL et que la el personne n'a pas accepté ou a décidé les termes, les contributions ne seront el plus acceptées du fait d'une incompatibilité de licence. Mais nous en sommes el pas la, loin de la pour le moment. Je pense que tu n'as pas compris ce que j'ai écrit ci-dessus, donc je le répète : l'édition sera bientôt (semble-t-il dimanche) refusée pour les contributeurs qui ne se seraient pas prononcés sur la nouvelle license + CT (par un oui ou par un non). http://www.mail-archive.com/talk@openstreetmap.org/msg37281.html -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] OpenStreetMap License Change Phase 3 begins Sunday
mc == Michael Collinson m...@ayeltd.biz writes: mc In summary: This only affects you if you are an OpenStreetMap mc contributor who registered before 12th May 2010 and have not taken mc part in our voluntary re-licensing program. Before being able to mc edit, you will have accept or decline new contributor terms. To mc give time to get the word out, this does not take effect until mc Sunday! It is not clear to me, from your message or from what I have read on the wiki, whether choosing Decline is a irreversible decision, or whether one would still be able later to accept the licence + CT. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] transition éventuelle OdBL (was Re: Gîtes de France)
rn == Pieren pier...@gmail.com writes: rn J'ai lu sur la liste dev que l'API allait très bientôt refuser les upload de rn ceux qui n'ont pas accepté la nouvelle licence. Pour moi, la question de rn l'adoption ou pas suivant le nombre de refus n'a plus court. J'ai compris quelquechose de différent : l'édition sera bientôt refusée pour les contributeurs qui ne se seraient pas prononcés sur la nouvelle license + termes de contribution (par un oui ou par un non). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lisibilité et ergonomie des cartes Mapnik
pa == Pierre-Alain Dorange pdora...@mac.com writes: pa Mapnik avec son status de moteur par défaut rassemble souvent des pa critiques (j'en fait parti) mais il faut garder à l'esprit que mapnik a pa une visée généraliste. pa Ainsi pour représenter plus clairement les routes, openmapquest est bien pa meilleur (orienté route je dirai). Il ne faut pas confondre le moteur de rendu et les feuilles de style : il me semble que MapQuest utilisent Mapnik pour leur rendu «open». Leurs feuilles de style sont d'ailleurs disponibles sous licence libre. https://github.com/MapQuest/MapQuest-Mapnik-Style Ensuite la rapidité du serveur de tuiles est essentiellement une question de moyens (je ne trouve pas les performances de open.mapquest.fr trop mauvaises, sauf dans les régions que je présume peu consultées, où ils doivent faire du rendu à la volée avec une machine moins puissante qu'OSM). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [HS] Comment travailler avec un OS alternatif
rq == Rodolphe Quiedeville rodol...@quiedeville.org writes: rq autant j'ai été incapable de conseiller des gens sur les outils à rq utiliser pour simplement éditer des fichiers text et les versionner sous rq git. Si il y a ici (et je n'en doute pas) des dev qui travaille sous rq Windows (XP/7/...) qui pourraient nous indiquer les bons outils cela rq nous aiderait grandement pour publier au plus vite ces nouveaux presets. On m'a dit du bien de TortoiseGit http://code.google.com/p/tortoisegit/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Génération de vidéos des contributions en fonction du temps
bc == Bruno Cortial bruno.cort...@laposte.net writes: bc Il existe un fichier planet qui inclut tout l'historique. Extraire ne bc serait-ce qu'une zone de ce fichier me semble herculéen ! bc bc http://wiki.openstreetmap.org/wiki/Planet.osm/full En fait, les fonctions bounding box d'osmosis fonctionnent avec ces fichiers. Compte-tenu de leur taille, ça met un certain temps à traiter. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] History flow visualizations of contributions over time
Hi, I have been experimenting with rendering history flow visualizations of Openstreetmap contributors for a region. These charts show the most prolific contributors in the region and how their contribution volume changed over time. Some sample visualizations for Paris, London, Berlin, Wien, Toulouse, Lyon together with source code to generate your own are available at http://eric.marsden.free.fr/osm/wormtrails/ -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] National 2x2 voies à chaussée séparée
hp == hpmt h...@free.fr writes: hp Et pendant qu'on est là à papoter autour de cette tasse de thé, il hp y a Eric Marsden (bonjour Eric) qui déverse des highway=road hp dans Midi-Py (pour le moins c'est ça que je vois) sans se hp préoccuper particulièrement de savoir si c'est trunk ou tertiary ; hp ça dessine un tuyau gris, sous mapnik et sous Osmachose ; Bonjour Hélène, Comme le suggère le wiki, j'utilise highway=road pour les routes tracées depuis des photos aériennes lorsque la photo ne me permet pas de distinguer la catégorie de la route (et que ça n'est pas un coin que je connais par coeur). http://wiki.openstreetmap.org/wiki/Tag:highway%3Droad Il ne faut donc pas hésiter à requalifier ces routes si tu connais leur classification. -- Asseyons un aveugle dans le fauteuil d'un sourd. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Campagne jonctions de la communauté OSM allemande
sl == sylvain letuffe sylv...@letuffe.org writes: rn si on lui donne un outil pour lui montrer les endroits à rn problème. sl Ils existent (keepright) sl Un manque de savoir que ça existe n'est cependant pas à exclure. La vue «routing» de OsmInspector est à mon avis bien supérieure à keepright (fréquemment mis à jour, peu de faux positifs). http://tools.geofabrik.de/osmi/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soupçon de copyvio par TeleAtlas
gr == Greg ewala...@gmail.com writes: gr J'ai plus l'impression que c'est un travail issu de la photo IGN que d'un gr copyvio : D'ailleurs, existe-t-il des outils libres permettant d'extraire ainsi des informations de photos aériennes (autre que le Lakewalker)? Si j'ai bien compris, on est autorisé à se servir des photos Bing pour ce type de traitement, non? -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Commune] Libérations et int égration de données
ms == Marc SIBERT m...@sibert.fr writes: ms - *Injecter à la demande.* ms Je prévois de faire des carrés de surface à taille à humaine dont ms l'upload sera faite à la demande, le contributeur étant faite étant alors en ms charge du nettoyage. Pourquoi ne pas mettre à disposition des fichiers .osm ? Il est alors relativement facile de charger les nouvelles données dans un calque JOSM et de copier les éléments qui ne sont pas encore présents vers le calque OSM. Certes, ça engendre un risque que des éjaculateurs précoces importent massivement sans vérifier la qualité de leur travail, comme on le voit encore avec le cadastre, mais ils écoutent parfois quand on leur envoie des messages. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Copyvio ? Fwd: Re: [OSM-dev-fr] Nouvelles du dépot .osm cadastral cleo
oc == Olivier Croquette m...@ocroquette.de writes: oc Le - n'est pas terrible, mais l'idée de base est plutôt bonne oc par contre. Quid d'un préfixe plus explicite ? wrong ? oc oc wrong:name=blabla oc wrong:building=yes cecinestpasune:building=yes -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Escalator (Était : métro Bo urse)
jm == Jean Millerat jean.mille...@wecena.com writes: jm compacts et très gros à l'écran, avec un nombre très limité de jm pictogrammes. D'ailleurs, j'ai l'impression qu'il n'existe pour jm l'instant aucun moteur de rendu qui permettrait de faire jm abstraction des dimensions réelles (angles, longueur et position jm des chemins) pour se concentrer uniquement sur la simplicité du jm rendu (un couloir, un embranchement, un escalier, le quai jm direction machin, tel appareil qui fait du bruit, etc.). Il jm faudrait presque imaginer un moteur de rendu qui fonctionne sur la jm base d'un moteur de routage (pour ne garder que la logique de jm navigation et oublier les mesures) ? C'est ce que les cartographes appellent la généralisation ou la schématisation des cartes. Des algorithmes et outils ont été développés pour faire ça automatiquement, mais je ne connais pas de moteur de rendu mettant ces techniques en oeuvre pour des données OSM (ça serait certainement utile!). http://graphics.stanford.edu/papers/routemaps/ http://www.springerlink.com/content/n5246806247300p6/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vannes Agglo
fdb == François Van Der Biest francois.vanderbi...@camptocamp.com writes: fdb ArcGIS au service monté par Pierre Mauduit sur fdb maps.qualitystreetmap.org. Tu annonces ça en toute discretion (enfin je ne me souviens pas d'avoir lu d'autre annonce); ça mérite de grands applaudissements! Ces rendus mapserver sont très sympathiques (et surtout supérieurs au rendu mapnik aux niveaux intermédiaires de zoom) ; (re)-félicitations à Pierre. Quelques suggestions en passant : - les areas de type school, university et hospital sont rendus après les building (les écrasent), mais je pense qu'il faudrait faire l'inverse - les flèches sens unique seraient souvent plus jolies si placées ailleurs qu'au tout début des rues (et peut-être rendus en gris plutôt que noir?) - les pistes d'aéroport ne sont pas rendues, idem stations metro - identifier plus clairement les parking? - est-il envisageable de faire des exports vectoriels (SVG par exemple)? Ca serait génial. Félicitations encore. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Coraine Land Cover - OSM tags
sv == Sam Vekemans acrosscanadatra...@gmail.com writes: sv Does anyone have a list of all of the tags used for the Coraine Land sv Cover dataset? The CLC classes can be browsed at http://etc-lusi.eionet.europa.eu/CLC2000/classes/index_html and the tagging scheme selected for the OSM import is described at http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Tagging_scheme -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Import et revert
bl == Balooval val.p...@gmail.com writes: bl Justement, comment fait-on un vrai revert? Ca se passe où, dans JOSM, via bl un script machin, sur un site bidule..? bl Je vois souvent des demandes de revert sur cette liste (dont la mienne bl d'ailleurs), est-ce parce que c'est difficile? Il n'y a pas de «vrai» revert, au sens d'une fonction de l'API qui serait dédiée à l'annulation d'un changeset particulier. Faire un revert c'est simplement ouvrir un nouveau changeset qui annule tous les changements effectués dans le changeset «fautif». Les deux changesets demeurent présents dans l'historique de la base OSM. Il est facile de faire un revert «propre», c'est-à-dire pour lequel aucun des objets touchés par le changeset fautif n'a été édité par la suite. Ça devient compliqué quand un objet a été édité entre temps. En effet, il n'est pas certain que le changement souhaité par le dernier auteur soit compatible avec la version antérieure (prédatant le changeset fautif) de l'objet. Donc idéalement, on essaie de revenir en arrière rapidement. Concernant les outils, il existe un plugin «reverter» dans JOSM qui est facile à utiliser. Il existe aussi des scripts Perl écrits par Frederik Ramm http://wiki.openstreetmap.org/wiki/Revert_scripts qu'il convient d'utiliser avec précaution. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polemique OSMF Was Re: qualité de la carte
el == Emilie Laffray emilie.laff...@gmail.com writes: el Quant au fonctionnement opaque, j'attends qu'on me dise ce qu'il el faut faire de plus pour que cela devienne moins opaque; d'ici peu, el il est prévu de commencer a publier une lettre mensuelle el d'explication des travaux des différents groupes de la fondation. el Je tiens a rappeler que toutes les notes sont disponibles sur le el site de la fondation. Salut Emilie, Je retire avec excuses ma polémique sur le fonctionnement opaque : j'ai revisité le site web de l'OSMF et j'y ai trouvé des notes sur les activités des groupes de travail ainsi qu'un descriptif (certes sommaire) des dépenses. Je ne me souviens pas d'avoir vu ça lors de ma dernière visite (il y a un an peut-être). Que faire de plus pour des râleurs comme moi? Le dernier blog de l'OSMF date d'il y a 11 mois. On pourrait y trouver des informations sur les activités importantes : mises à jour prévues pour le matériel, idées sur ce qui pourrait être fait avec les 1 M$ que Mapquest annonce vouloir dépenser pour améliorer la carte, progrès sur le feuilleton des CT, etc. Je sais, yakafocon. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte
gb == Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes: gb Tu met ici le doigt sur ce qui me semble être BEAUCOUP plus gênant que gb des contributeurs fougueux. Pour moi, le problème essentiel que doit gb résoudre OSM (ou une division locale) c'est de définir un outillage gb (méthodologie et outils) *officiel*. Une fois que ce sera fait, il gb deviendra bien plus simple à un contributeur très motivé de faire gb moins d'erreurs. Salut gUI, Je te rejoins sur l'importance d'outils facilitant l'assurance qualité. Heureusement, il en existe plusieurs qui sont très performants : osminspector, keepright, le validator dans JOSM. Heureusement aussi (à mon sens), aucun d'entre eux n'est «officiel». Personne dans OSM n'a autorité à décréter qu'un outil est plus officiel qu'un autre, et c'est très bien comme ça. Je rajoute pour polémiquer qu'il est bien dommage que la nouvelle licence souhaitée par l'OSMF donnerait bien plus de pouvoir à cet organisme au fonctionnement opaque pour décréter ce qui arrive aux données. Mais c'est sans doute inévitable si on s'appuie sur le droit des contrats. gb Aujourd'hui, il y a des conventions dans tous les coins, des trucs que gb le plus grand monde pratique, mais qui sont toujours dans l'état gb proposal ou que les éditeurs ne supportent pas (dans le sens où ils gb permettent de faire le contraire). Oui, c'est un bordel fabuleux. En discutant (avec plus ou moins de tact) quand on n'est pas d'accord, on arrive ensemble à produire de belles données. gb Je vais me risquer à faire des réponses très caricaturales : gb - s'il y a des erreurs qui perdurent, c'est qu'à priori elles ne gb dérangent personne, donc pourquoi fournir un effort jugé inacceptable gb pour les corriger. Le problème dans le cas qui nous préoccupe est que l'effort pour corriger les erreurs est colossal face à la facilité d'import des erreurs. gb - s'il y a des corrections rébarbatives, il y a certainement un outil gb à inventer pour automatiser leur correction. Une partie des erreurs de données du cadastre pourraient peut-être être corrigées automatiquement sans trop de faux positifs (je pense en particulier aux chevauchements qui apparaissent commes des «T» dans le validateur). Mais d'autres bugs comme les polygônes invalides me semblent compliqués, sans parler du réalignement des rues avec le bâti, la fusion avec le bâti ou les POI existants, etc. gb Désolé pour mon mail si long et bravo à ceux qui ont tenus. Ça mérite une blague sur les modes d'assurance qualité. An MIT guy and a Harvard guy went into a bathroom together and went up to the urinal to pee. After finishing, the MIT guy went to leave the room without washing his hands. The Harvard guy, appalled, called after him: At Haavaahhhd, they teach us to wash our hands after we urinate. The MIT guy looked back at him and said, At MIT they teach us not to urinate on our hands. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte à Auzielle
sp == Sylvain Perrinel sylvain.perri...@gmail.com writes: sp ça peut arriver... plutôt que de juger hâtivement. Dans le registre des jugements lentement muris, j'ai passé pas mal de temps ce weekend à corriger des imports bâti que tu as commis au nord de Toulouse en début de mois. Il y avait des bâtiments redondants (tu n'avais pas enlevé / transféré les tags des bâtiments préexistants), des tonnes de bâtiments chevauchants (il faut utiliser le plugin validator!), des waterway qui ne correspondent à rien sur le terrain. STP arrête ce genre d'import sauvage. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte à Auzielle
sp == Sylvain Perrinel sylvain.perri...@gmail.com writes: sp Chacun contribue à osm à son rythme. Si tu n'es pas contents, tu corriges ou sp tu le fais remarquer gentillement. Je suis désolé de t'avoir agressé personnellement ; j'ai réagi sur la liste (après mon message privé de samedi) puisqu'il y a deux facettes de ta façon de contribuer que j'ai rencontrées chez d'autres et qui m'agacent : - l'attitude «j'importe puis d'autres corrigeront». En particulier pour le bâti, il est trivial d'importer massivement mais fastidieux de corriger toutes les données et intégrer proprement avec l'existant. Et je vois beaucoup d'imports (pas seulement de Pinpin, d'où l'intérêt d'en parler publiquement) qui n'ont pas été passées au validateur. - «je fais n'importe quoi mais c'est à mon rythme»: il est tout à fait normal que des contributeurs béotiens (surtout utilisant Potlatch) fassent des erreurs (ways non raccordés entre eux par exemple, assez fréquent). Mais s'agissant de gens qui utilisent des outils plus complexes pour faire des imports semi-automatisés, j'ai un niveau d'exigence plus élevé. On nettoie _avant_ d'importer, on vérifie ce qu'on fait ; il y a beaucoup d'outils pour le faire (le validator, osminspector, keepright, carte dupe_nodes, etc.). Je caricature un peu pour qu'on se comprenne bien. -- What is written without effort is in general read without pleasure. S. Johnson ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La photo aérienne pour les enfants e t les plus grands
cr == Christian Rogel christian.ro...@club-internet.fr writes: cr Les trucs sont ici : cr http://wiki.grassrootsmapping.org/show/BalloonAerialPhotography Utiliser de l'helium (matière précieuse dont les stocks sur terre sont limités) pour ça c'est vraiment du gaspillage. http://seedmagazine.com/content/article/going_going_gone/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag pour des douves
ip == ipopo35 isabelle.porh...@free.fr writes: ip http://tagwatch.stoecker.eu/ ip malheureusement je n'ai pas réussi à y retrouver les 20 cas... est-ce qu'une ip explication supplémentaire sur le cheminement à suivre dans le site serait ip possible? Sur la page d'accueil tableau Area sélectionner «Whole planet», puis l'entrée avec la date la plus récente, puis «Watchlist». -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion
pd == Pierre-Alain Dorange pdora...@mac.com writes: pd Concernant la liste, je suis assez peu satisfait d'une liste de pd discussion auquelle je préfère largement un forum usenet (bien pd plus pratique à tout niveau AMHA). Il est possible de suivre (lire poster) cette liste, comme bien d'autres concernant OSM, par NNTP via l'excellent Gmane http://dir.gmane.org/gmane.comp.gis.openstreetmap.region.fr -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Wiki page FR:Hiking
gb == Gilles Bassière gbassi...@gmail.com writes: gb Je ne pense pas qu'il faille éditer le wiki pour qu'il reflète la base. gb En principe, on va plutôt chercher à éditer la base pour suivre les gb conseils/règles/etc qui sont consignés sur le wiki après débat au sein gb de la communauté. Pas d'accord. En principe, OpenStreetMap vise à produire des données géographiques libres et non à être un terrain de jeu pour les wikifiddlers. Le wiki devrait aider (en complément à d'autres outils comme tagwatch) à documenter les pratiques réelles des contributeurs, à permettre une discussion sur les avantages et inconvéniants de différentes méthodes de tagging, mais surtout pas être utilisé comme arme contre les contributeurs qui veulent appeler un GR un GR. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Géovélo Travaux temporaires
br == Benoît ROUSSEAU adressepossi...@free.fr writes: br traffic en utilisant OSM en sous couche pour un rendu avec br OpenLayers OUI. Ce serait même super bien. Mais je ne vois qui va br passer sa vie à la fenêtre ou scruter les infos pour saisir des br embouteillages possibles toutes les 15 min. Il est possible de générer automatiquement des données sur les temps moyen de trajet et les bouchons, comme le font par exemple Google Maps et Waze sur les mobiles. Il existe des projets en cours pour collecter ce type de données et les intégrer à des outils de routage pour OSM, par exemple http://wiki.openstreetmap.org/wiki/Routing/Travel_Time_Analysis http://wiki.openstreetmap.org/wiki/Average_speed_per_way -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche dynamique de point d'intér êts
oc == Croquette Olivier ocroque...@free.fr writes: oc Je voudrais faire une page Web avec une slippy map sur laquelle oc l'utlisateur pourait superposer une couche avec certains points oc d'intérêt, par exemple cabine téléphoniques, hôtels, ... oc Idéalement, la carte serait affichée par défaut pour une certaine oc région. En cliquant sur Hôtels, apparaitrait une couche en plus, oc avec pour chaque hôtel un symbole correspondant. En cliquant sur oc un hôtel en particulier apparaitrait ses attributes (nom...) oc oc J'ai trouvé quelque chose d'approchant : oc http://wiki.openstreetmap.org/wiki/Query-to-map voir également http://wiki.openstreetmap.org/wiki/Openlayers_POI_layer_example http://wiki.openstreetmap.org/wiki/OpenLayers_Dynamic_POI -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Extra zoom level needed?
md == Maarten Deen md...@xs4all.nl writes: md Adding a zoomlevel adds 4 tiles for each tile in the previous zoomlevel. md You'll go from 91 billion tiles to 366 billion. md This meaning you need 4 times the load to generate, 4 times the storage to md hold them, 4 times the traffic to display them. I wonder if it would be sensible to switch to a vector-based rendering system for high zoom levels, as implemented at http://cartagen.org (using HTML5 canvas). This would allow arbitrarily high zoom levels. Tile-based rendering performs much better at low zoom levels, but I suspect that vector-based rendering would work better above z17. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extra zoom level needed?
js == John Smith deltafoxtrot...@gmail.com writes: js I wonder how consistent you could get the look and feel between the 2 js systems, otherwise it might cause more confusion than anything. This would require work, yes. But even the Mapnik rendering has discontinuities between zoom levels: for instance between z8 (no landuse rendering) and z9 (landuses such as forest are rendered) there is a significant step (very visible in France for instance, where we have good landuse data imported from CLC). -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Les nouveaux inscrits doivent accepter la licence ODbL en plus de la CCBYSA
el == Emilie Laffray emilie.laff...@gmail.com writes: el La peur des gens est que l'on perde des données, et ca n'est potentiellement el le cas que si certains contributeurs importants (en terme de volume) el refusent la licence. Au contraire, c'est _inévitablement_ le cas dès qu'au moins un contributeur n'accepte pas la nouvelle licence. Ne serait-ce que par ce qu'il a arrêté de contribuer au projet et est injoignable. Je viens de bidouiller un peu pour estimer la longueur moyenne de l'historique des objets (noeuds, ways, relations) dans la base OSM. Sur 1000 objets tirés aléatoirement, l'historique est de longueur 1,6 en moyenne (avec un max de 26). On peut supposer que les objets les plus souvent modifiés sont ceux dont la «valeur» est la plus grande, et c'est justement ceux pour lesquels la probabilité de perdre une bonne partie de l'historique (avec tous les problèmes de cohérence qui peuvent en découler) est la plus grande. Attention à ne pas sous-estimer les dommages que peut provoquer ce changement de licence. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr