Re: [OSM-talk] New OSM Carto: White Roads & Road Widths
On Tue, Nov 3, 2015 at 5:58 PM, Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > tertiaries are still rendered, they just don't have a different colour than > other roads (but they are thicker). In German we say: remain on the carpet ;-) Well, I would say in English "you play with words". It's not visible as a specific class. And for the minority who will see it's thicker, they will think it's based on a physical attribute (width or lanes), not on its importance. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Carto: White Roads & Road Widths
On Tue, Nov 3, 2015 at 3:39 PM, Christoph Hormann <chris_horm...@gmx.de> wrote: > Also not correct, various alternatives were tested, samples were shown, > areas where problems occur were mentioned, advantages and disadvantages > of various options mentioned, you can hardly cover this more in depth > than this. > > Note ultimately design decisions are always subjective. If at the end > of a long process a decision is made without once more listing in depth > all arguments for and against it this does not mean the decision is > arbitrary. I didn't express myself since a long time on this list. I just discovered the new style and wanted to undestand how it was possible to kill the tertiary road type in OSM. Because it must be clear : if a road class is not rendered, it will be ignored by most of the contributors in the future. That's it. And after reading the thread on github, I'm surprised to see how easy the warnings have been ignored. Maybe because the style developers underestimated its importance (only 4 millions ways) ? This is not a message to minimize the huge efforts and positive improvements about this change. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On Thu, Aug 20, 2015 at 7:12 AM, Russ Nelson nel...@crynwr.com wrote: Frederik Ramm writes: The trouble is that I'm being threatened with having my contributions deleted! DELETED! Why incentive do I have to correctly tag, when people are saying Go ahead, I'm just going to delete it anyway and I'm going to encourage other people to do the same thing. Russ, seriously. Many people already told you that if it is removed physically, then we remove it in OSM as well. Even if you use a tag dismantled, the point isn't changing : we don't keep removed features in OSM. We map the present (and basically, I'm also if favour to delete the future, like the planned stuff when it's not 100% sure). There is a large consensus on that in the community. Why are you insisting ? If you like, check the OHM project which is dedicated for historical maps. I got some examples from the net: [1] https://commons.wikimedia.org/wiki/File:Dunstable,_Dismantled_railway_and_National_Cycle_Network_Route_6_-_geograph.org.uk_-_146322.jpg where is the railway here ? were are the rails ? why should we keep any mention about rails when it's a cycleway now ? map what we see, the path or track and the cuttings/embankments. [2] http://ukbeach.guide/photos/uk-photos.php?photo=15295 [3] http://www.geograph.org.uk/photo/2496379 disused is fine here. [4] https://outoftheloopdotcom.files.wordpress.com/2012/06/p6090099.jpg Who knows that this track was a railway from 1881 to 1961 ? why should we keep any railway tag here ? Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
2015-01-24 10:18 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: C'est la géométrie qu'on ne peut pas reprendre en tant que telle des PDF car elle s'appuie sur une base IGN non libre. Vu qu'on ne la reprend pas, je ne vois pas où serait le problème. Je ne sais pas si ça a déjà été relevé sur cette liste mais la base IRIS est maintenant libérée en LO/OL par l'IGN: http://professionnels.ign.fr/contoursiris (merci à http://ecrans.liberation.fr/ecrans/2015/04/28/un-decoupage-plus-precis-des-communes-en-licence-libre_1273735) Pieren PS: notez que je suis aussi contre leur import dans OSM mais que ça peut servir à contrôler certaines de nos limites communales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Prochaine révision des cantons, à vos souris
Quand je disais il y a quelques années, ici, sur cette liste, que les cantons changaient tout le temps et qu'il ne fallait pas les mettre dans OSM... Pour ceux qui en douteraient encore, voici, déjà planifiée, la prochaine révision: http://www.leparisien.fr/politique/ump-sarkozy-promet-de-redecouper-les-cantons-08-04-2015-4675181.php Et si c'est pas à la prochaine élection, ça sera à la suivante, le redécoupage des cantons étant un sport prisé par les élus nationaux depuis très, très longtemps (et au grè des résultats de la précédente élection), l'impact étant quasiment nul pour les citoyens lambda. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ?
Les parcelles sont des limites administratives. Elles ne forment pas les limites physiques d'une forêt, ne tient pas compte des clairières, ni des prairies, ni des forêts privées adjacentes, etc. L'idée du tag landuse est très mauvaise, incohérente et ne passerait pas la barre de la liste import. Et non, cela ne va pas simplifier l'édition de la carte mais la compliquer puisque ces polygones vont s'entrelacer avec le reste. Ce sont les mêmes raisons qui font qu'on refuse les parcelles privées, même lorsqu'elles sont à disposition pour import. Voir le résumé des discussions ici: https://wiki.openstreetmap.org/wiki/Parcel Ensuite, petit rappel : les forêt gérées par l'ONF, celles qui ont leurs numéros parcellaires visibles sur le terrain, c'est 4,7 millions d'hectares (état+départements+communes). Cela fera donc plusieurs dizaines de milliers de parcelles au minimum (dont une partie seulement est visible des chemins) et ça n'a donc rien d'anodin comme décision. @Jérôme: j'en ai beaucoup plus à foutre que toi, je pense. Je sais ce que ça veut dire d'aller en forêt, et pas pour la balade, et je n'ai jamais eu besoin de ces numéros de parcelles pour me repérer. J'aime bien tous ceux ici qui trouveraient ces repères bien pratiques alors qu'ils ont un GPS à la main... Et je connais très bien les gens de l'ONF. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
2015-04-02 11:13 GMT+02:00 Vincent Frison vincent.fri...@gmail.com: Personnellement j'aimerais bien qu'on prenne également la tranche des 80%-90% car il faut bien voir que le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes. Si on se dit que ma zone de test dans le 12e arrondissement est assez représentative (on aura à peu près les mêmes pourcentages sur l'ensemble de Paris) et qu'on accepte cette tranche de 80%-90% cela permettrait de mettre à jour plus de la moitié des immeubles parisiens (39 + 13 = 52%). Mais je comprends tout à fait que cela puisse vous gêner et que vous préfériez ne rien mettre à jour plutôt que de mettre à jour des données fausses (même si pour moi elles ne sont pas fausses mais juste légèrement simplistes en raison des données existantes ;p). Le surfacique des building viennent du cadastre. Mais on sait tous que le cadastre a son propre découpage qui contient souvent des artifices/erreurs/fantaisies avec des polygones séparés qui ne sont pas des bâtiments séparés mais au mieux des pièces ou pire, des balcons ou des cheminées (pour les plus petites). C'est pourquoi après l'import du bâti sur Paris, j'ai fusionné de nombreux polygones pour que le tag building s'applique vraiment à la surface du building et non à une partie seule (mais pas dans tous les arrondissements). De plus, de nombreuses cours intérieures ont souvent manqué pendant l'import (qui n'est pas de mon fait), ce qui peut aussi expliquer les différences avec les données de la ville. Voila j'attends vos retours avant de me lancer mon programme sur le serveur live. Avant de passer au vrai import de masse, il faut créer une page wiki décrivant le processus, résumer l'action dans un mail envoyé à la liste impo...@osm.org avec si possible un échantillon de fichier xml pour que les autres puissent juger de ce qui sera modifié. Il faut chercher imports dans le wiki pour trouver la procédure à suivre. Le risque sinon est d'avoir un revert automatique du DWG si tu passes dans leur radar. Sinon, tu pourrait commencer plus petit, avec un quartier assez caractéristique des problèmes rencontrés. Plus besoin de passer par la procédure officielle. Et d'avantage de gens pourront juger du résultat. De plus, il serait intéressant de publier ton script pour que d'autres puissent réitérer l'opération plus tard, sur la même zone ou ailleurs. Celui-ci devrait aussi d'ailleurs signaler les cas qui ont un écart trop grand entre les données de Paris et les valeurs déjà dans OSM (quand c'est le cas). Là aussi, dans l'optique de vérifier l'existant manuellement (les anciennes contributions peuvent être fausses, altérées ou obsolètes) et d'exécutions du même script plus-tard avec des données plus fraiches. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ?
Alors tagguez les pannonceaux. C'est eux que vous voyez sur le terrain, pas les limites de parcelles. Il me semble qu'il existe déjà des tags pour ça, peut-être à adapter pour ce cas particulier. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
Je sens une pointe de sarcasme dans certaines réponses... sauf Philippe qui a bien compris (et qui nous fait des poissons d'avril toute l'année, sacré farceur). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nice, rajouter une place
Atention, un polygone avec un highway + area=yes a une signification particulière : la circulation y est libre dans toutes les directions à l'intérieur du polygone ! Pour les piétons, la question ne se pose pas (c'est évidemment possible). Mais pour un highway=residential ou service, ça ne peut correspondre qu'à une place ouverte dont les voitures peuvent circuler en tout sens. Et je doute que ce soit le cas de cette place. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boulet, que faire?
2015-04-01 16:28 GMT+02:00 Eric Sibert courr...@eric.sibert.fr: Que faire??? Soit attendre : c'est un suisse, y a pas le feu au lac ! Soit (re)contacter le DWG et attendre aussi, bien qu'aucun membre du DWG ne soit suisse ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 1 jour 1 carpe...
Je doute que rue Saint-Pierre parlait du poisson... ... et il manque le département du Lotte. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
2015-03-31 9:38 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: En général dans OSM on décrit plutôt la finalité (le nom d'une rue sur le tronçon de la rue ou le fait qu'elle soit en sens unique) que le panneau lui même (qui mappe les plaques de rue ou les panneaux de sens unique ?). Pourtant, un traffic_sign=FR:B1 est beaucoup plus clair qu'un oneway=yes... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
2015-03-28 20:34 GMT+01:00 Eric SIBERT courr...@eric.sibert.fr: Donc on espère surtout que ça va harmoniser dans le bon sens au niveau européen :-p Même si ça aboutissait (ce dont je doute), il est peu probable que cela soit rétroactif. @ceux qui lisent Philippe : il nous explique qu'on peut contourner le droit des marques en renommant les itinéraires. Je lui répond que c'est la présence même de l'itinéraire qui pose problème. Changer le nom d'une oeuvre (c.a.d création originale protégée par le droit d'auteur) n'empêche pas la contrefaçon en donnant un exemple en littérature. Donc oui, il y a bien problème, quelles que soient ses dénégations. Même s'il met en doute personnellement la légitimité de la FFRP, seul un juge pourrait trancher la question, un risque que la fondation OSM a toujours refusé d'endosser en refusant ou supprimant systématiquement les données revendiquées par des ayants-droits extérieurs. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
2015-03-29 16:12 GMT+02:00 Christian Rogel christian.ro...@club-internet.fr: A noter : la propriété intellectuelle n’est pas cessible ?? Tu dois confondre droit moral et droit patrimonial. Le premier n'est pas cessible, effectivement. Mais le second peut l'être. On peut même le céder pour rien : c'est ce qu'on fait avec les CT's d'OSM... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
2015-03-27 6:36 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: Aucun probleme si on cartographie ces itiinéraires sans y mettre la labellisation GR ou Grande Randonnée (marques de la FRPP dont on n'a pas besoin). Appelons-les Circuits Nationaux de Randonnée et abrégeons en CNR ou NR (comme aussi nouvelle randonnée). On pourra même reprendre leur numéro : le GR20 devient NR20... Bien sûr qu'il y a un problème. Il ne faut pas mélanger deux choses : d'une part, le droit des marques, l'usage du GR; d'autre part, la propriété intellectuelle sur l'itinéraire. Le deuxième cas est plus compliqué parce que la FFRP devra justifier du caractère original de la création devant un tribunal. Hors, on sait que ça serait difficile dans certains cas (chemins de Stevenson, Compostelle, etc). Ce qui ne veut pas dire que le risque juridique n'existe pas et que la création est vraiment l'oeuvre de la FFRP (de ses affiliés en fait) pour la majorité des itinéraires. Il faudrait donc qu'un tribunal tranche au cas par cas, avec des preuves à fournir (et à chercher) sur le caractère historique d'un itinéraire (il y a des affaires assez similaires concernant les droits de passage). Il ne faut donc pas s'imaginer qu'en renommant les itinéraires, on s'exclut des obligations liées aux droits d'auteurs. C'est comme si je proposais de recopier et publier les livres de Harry Potter sans l'accord des ayant-droits mais en changeant simplement le titre. Ca reste de la contrefaçon. Mais j'ai comme l'impression que cette discussion s'est déjà produite ici par le passé avec les mêmes approximations ... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée 44 et l'open data
2015-03-26 18:33 GMT+01:00 Antoine Riche antoine.ri...@ymail.com: Et si on ajoutait ces itinéraires dans OSM en les taggant name=GR3® et source=Département de Loire-Atlantique ? On pourrait ensuite l'annoncer au CG44 et voir ce qui se passe ... Le CG n'est pas le propriétaire de la marque. Reste à savoir s'ils ont libéré ces données avec l'accord de la FFRP (ce qui est tout à fait plausible). Si oui, alors leur utilisation est possible pour OSM. Si non, alors le CG a fait une erreur et ça ne serait pas le premier dans le mouvement opendata ! (cf les archives de cette liste). Dans ce cas, il ne faut pas importer. OSM n'a pas les moyens de se payer un avocat (alors que le CG44, si). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ?
2015-03-26 15:05 GMT+01:00 Romain MEHUT romain.me...@gmail.com: Et je connais 2 contributeurs (dont l'un d'eux qui est agent technique forestier) qui ajoutent de telles parcelles dans OSM ex: http://www.openstreetmap.org/relation/4469183 Celui qui est agent technique forestier le fait dans le cadre de son travail et les données ainsi saisies lui sont utiles pour se repérer via le GPS. Un agent technique peut très bien créer sa propre couche technique. Si on laisse passer ça, on ne pourra pas ensuite empêcher quelques géomètres ou autres d'entrer des parcelles cadastrales dans OSM. Il y aura toujours une ou deux personnes qui y trouveront leur intérêt. Mais ça ne sera pas celui du plus grand nombre. Mais la conséquence est que le tag ref n'est pas rendu par défaut et ce n'est pas donné à tout le monde de générer son propre rendu avec les tags désirés... La définition même du fameux tagguer pour le rendu, c.à.d utiliser un mauvais tag pour obtenir un bon rendu. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée 44 et l'open data
2015-03-26 14:38 GMT+01:00 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: Ça veut dire quoi utiliser ? Ça veut dire ne pas peindre ces marques ailleurs pour baliser un nouveau sentier ? Ou bien ce que tu proposes Pierre, de s'appuyer sur le marquage présent ? C'est pénible ces textes juridique qui sont volontairement flou. Le droit de citation est bien encadré avec une grosse jurisprudence. Tu peux citer une marque mais tu ne peux pas en abuser par la fréquence d'utilisation ou la mise en avant pour abuser le client (usurpation) ou t'en servir dans le même domaine d'activité. Par exemple, tu ne pourrais pas faire un livre qui s'appellerait mon guide topo à moi des GR. Ou ouvrir un resto qui s'appellerait le ptit macdo .Ca entre trop en conflit avec le propriétaire de la marque. Tu peux parler d'un GR dans un roman policier (pub dans un autre domaine= FFRP content). Mais tu ne pourra pas éditer des cartes représentant les GR sans leur autorisation (concurrent dans le même domaine = FFRP pas content). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
2015-03-25 14:57 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr: J'adhère sans réserve à l'analyse de Vincent ! En version raccourcie on dit +1, mais j'aime bien faire long ! ;-) Le 25/03/2015 14:41, Vincent Pottier a écrit : La FFRP étant informée de notre intention pourra tout au plus, passé ce délais permettant raisonnablement une réponse, faire cesser la carto dans osm et retirer les GR saisis, mais ne pourra pas se prévaloir d'un préjudice en disant qu'elle ne savait pas. Elle ne pourra que s'en prendre à elle-même de n'avoir pas répondu aux multiples démarches. Bon alors, je vais le redire : en droit privé, une absence de réponse ne vaut pas accord (même pour les services publics, bien qu'il soit prévu que la loi change dans ce domaine). Par contre, il est vrai que en cas de procès, ça peut fortement atténuer nos responsabilités et fortement incriminer celles de la FFRP. Mais ça n'a rien de garantie. Il y a un autre principe qui dit que nul n'est sensé ignorer la loi, donc la ffrp pourrait avancer que nous sommes parfaitement au courant de son droit d'auteur et que, même en l'absence de réponse, nous enfreignons ce droit en toute connaissance de cause. D'ailleurs, ils pourraient aussi bien donner copie des archives de cette liste de diffusion comme preuve contre nous ! Après, c'est la loterie et un juge pourrait décider qu'on était de bonne foi (ou naifs) et relaxer; ou bien décider qu'on a sciemment violer leur droit d'auteur et sévir. Mais au delà de ce point, il faut redire que la réponse peut varier d'un itinéraire à l'autre. Et ça sera à la charge de la FFRP de prouver le caractère original de chaque itinéraire copié dans OSM; une tâche titanesque, surtout quand ça implique les asso et/ou les collectivités locales. Un sacré pataquès. La ffrp peut aussi la jouer plus vicieux en n'attaquant pas OSM directement - trop impopulaire - mais en attaquant les applis commerciales qui utiliseraient les GR tirés d'OSM. C'est plus facile à faire passer pour l'image (c'est un vilain concurrent commercial contre une asso d'utilité publique qui ne que ça pour vivre) et en plus, c'est plus facile à identifier que les contributeurs OSM ou leur fondation (qui devrait passer par une action juridique en Angleterre dans les 2 cas). Reste un point pas abordé dans votre discussion : la position de l'OSM foundation. Elle a la responsabilité légale de la base de données et elle a toujours refuser de prendre un quelconque risque juridique sur des données externes. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment on taggue ce genre de panneau d'interdiction ?
Lire l'article du Parisien: http://www.leparisien.fr/espace-premium/paris-75/sous-la-gare-du-nord-urinez-vous-etes-filme-25-03-2015-4634619.php Quelqu'un pourrait aller Rue de Maubeuge (Xe) pour prendre une photo en cc-by-sa qu'on puisse la mettre dans le wiki ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ?
2015-03-24 9:56 GMT+01:00 Romain MEHUT romain.me...@gmail.com: Bonjour, Le 23 mars 2015 18:08, Jérôme Amagat jerome.ama...@gmail.com a écrit : Ce que je veux dire c'est qu'il peut il y avoir des clairières, des zones plus ou moins grandes sans arbre à l'intérieur de l'emprise de la forêt communale. Avec landuse= forest ça voudrait dire qu'il y a des arbres partout. C'est pourquoi il existe les relations de type multipolygone qui permettent de dessiner les représenter les clairières tout en les excluant de l'emprise forestière cf. http://wiki.openstreetmap.org/wiki/FR:Relation:multipolygon#Un_anneau_externe_et_un_anneau_interne Non, non. Ce que Jérôme cherche, c'est à représenter la limite administrative de la forêt domaniale, pas physique, un peu comme les limites parcellaires du privé. Et pour les mêmes raisons que pour les parcelles, ma réponse serait de dire que ça n'a pas sa place dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Entités urbaines de plus de 100 000 habitants
On Mon, Mar 2, 2015 at 8:05 PM, desgranges.p...@neuf.fr wrote: Serait il alors possible d'envisager cette solution : * boundary=urban * urban_type=FR:urban_unit (unités urbaines de l'Insee) * urban_type=FR:urban_unit_10 (unités urbaines de + de 10 habitants de l'Insee) * urban_type=FR:urban_unit_80 (unités urbaines de +de 80 habitants de l'Insee) * urban_type=FR:urban_area (aires urbaines de l'Insee). Attention, pour l'instant, sur cette question, il n'y a que 2 opinions exprimées seulement, dont celle de Philippe qui a été blacklisté par beaucoup d'abonnés de la liste. Donc, sans exprimer d'opinion personnelle sur le sujet, je veux souligner que c'est très fagile comme consensus pour l'instant. Et surtout, qu'il ne faut pas prendre ce que dit Philippe comme significativement représentatif de la communauté OSM France... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quai Gallieni ou Quai du Général Gallieni ?
2015-03-02 10:39 GMT+01:00 Jean-Marc Liotier j...@liotier.org: Ou sinon, si vous pouvez m'éclairer sur la manière de répondre à ce problème... Perso, je pense que les tags alt_name ou short_name ne devraient être utilisés que si on trouve des versions alternatives ou courtes sur le terrain (panneau) ou dans la documentation officielle. Pour les raccourcis de langage (comme rue de Gaulle), il faudrait plutôt chercher à améliorer les logiciels de recherche de nom au lieu d'envisager de tagguer toutes les façon possibles et imaginables de citer le nom d'une rue. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
2015-02-28 5:30 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: [citation] pourrait avoir un impact sur la répartition de la fraction « bourg-centre » de la DSR. [/citation] Franchement, je ne vois pas là un argument suffisant pour garder les anciennes limites dans OSM (mais maintenant, je reste ouvert si on m'en avance un plus convainquant). De toute façon, quand on supprime quelque chose, il en reste toujours une trace. Il suffit d'écrire sur le wiki quel fichier planet contient encore les anciennes limites puis d'effacer. Ceux que ça intéresse pourront toujours se lancer dans l'archéologie OSM ;-) Il faut lutter contre cette tentation rampante, poussée par une infime minorité, de conserver des données obsolètes dans OSM. Wikipedia ne garde pas ses anciennes versions de texte dans la page article, même sous forme de commentaire, mais uniquement dans l'historique. Quand on édite la page, on ne trouve pas trace des anciennes contributions disparues. C'est le même esprit qui doit prévaloir dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
2015-02-27 10:16 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr: avoir directement les informations attributaires provenant des tags OSM, c'est quand même beaucoup plus exploitable que de devoir aller récupérer des données annexes dans une base externe et les joindre plus ou moins proprement avec les données provenant d'OSM. Avoir à faire ce genre de manipulations peut même être un frein à l'utilisation des données OSM. Mais comme les données dans OSM sont modifiables par n'importe quel gugus, on est de toute façon obligé de les croiser/comparer/vérifier avant une exploitation sérieuse. Ou alors, vous dites que certains attributs ne doivent pas être modifiables... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Je prolonge la discussion sur la liste talk-fr parce qu'elle concerne tout le monde et que le contenu d'OSM ne relève pas de l'association: 2015-02-26 21:31 GMT+01:00 DH dhel...@free.fr: N'est-ce pas là le fond du problème ? Faire un référentiel géographique mutualisé multi-domaines (on balaie large de l'occupation du sol, aux services publics en passant par l'adresse sans oublier les PEI et les limites en tous genres) sans tenir compte des nécessaires connexions avec les réutilisateurs/producteurs. Ces primary key sont nécessaires tant qu'une solution plus durable (uuid géographisée déjà évoquée sur cette liste) n'émerge et fasse consensus. : Il ne faut pas se méprendre sur la chaine de valeur de l'information. Comme l'a justement rappelé Tony, la commune est TITULAIRE de la dénomination de la voirie. Le FANTOIR, certes national -merci Napoléon-, n'intervient qu'en 2ème rang avec toutes les erreurs de transcription de graphies, d'homophonies, etc. 2015-02-26 23:22 GMT+01:00 Guillaume Allegre allegre.guilla...@free.fr: MAIS je ne parlais pas de la donnée adresse et voirie (objet succinct du paragraphe suivant), mais des autres objets C'est bien de le préciser ;-) Ca soulève du coup d'autres questions (utilisation du même tag pour des objets totalement différents, quid de la doc, etc) mais bon. Pour revenir au code ref:FR:commune sur les voies, limité à Orange et son interco pour l'instant, personne ne répond à une de mes questions : si on laisse se propager plusieurs codes uniques pour chaque voie, qui pourra dire stop à la prolifération de ces refs externes ? Ceux qui sont abonnés à la liste import savent à quel point le principe même de ref externe pour le croisement de données est mal accepté, voir refusé au moment des imports. Même le code fantoir doit encore justifier de sa légitimité à l'extérieur de la France. Au moment de sa création, on nous a expliqué en long et en large que le cadastre n'étant pas suffisament fiable avec les dénominations, le code FANTOIR servirait à croiser les données OSM avec le cadastre avec succès dans tous les cas. Dont acte. Un argument que je suis aussi prêt à défendre à l'international car c'est une solution incontournable en France. Mais si maintenant, chacun vient avec son propre code interne, c'est plus difficile à admettre, surtout lorsqu'on sait que l'utilisateur a aussi le code fantoir en local, donc que le croisement automatique reste possible moyennant un petit effort au départ dans la mise en place des outils. Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du point de vue d'OSM, il n'y a pas de rang ni de priorité dans les consommateurs de nos données. Il peut y avoir des producteurs de code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur priorité. A la limite, moi, je n'ai rien contre la généralisation des codes ref:FR:commune mais alors on supprime les codes FANTOIR. Mais on sait tous que les communes peuvent croiser leurs codes avec ceux du cadastre mais que l'inverse n'est pas vrai et que c'est ingérable en dehors de la sphère commune/interco. Il faut rester pragmatique et ne laisser que le seul code fantoir, le seul qui soit ensuite réutilisable pour croiser les fichiers de toutes les communes par tout les consomateurs de données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry osm.v...@free.fr: Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. La discussion ne concerne que les voies qui ont déjà un code FANTOIR. Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà répondu par ailleurs que le tag ref:FR:commune était compréhensible, faute de mieux. si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas mortel) et où tu va avoir beaucoup de mal à convaincre le reste des contributeurs. Multiplier les tags ref montre certes une belle dynamique de réutilisation mais elle rend surtout l'interprétation des données plus difficile par les humains... et inutile. Ce sont d'abord les humains qui maintiennent et maintiendront la voirie OSM dans le futur, pas des programmes de synchronisation avec des référentiels externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous avons tout à gagner à utiliser un uuid (identifiant unique). Comme cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le code FANTOIR et s'en contenter (et le ref:FR:commune là où il n'y en a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public, présent et cohérent sur l'ensemble du territoire, our toutes les communes, ce qui n'est pas le cas d'un ref:FR:commune. Concernant la prolifération de tags abscons, lorsqu'il y a des discussions sur les listes de diffusion internationales et qu'il faut choisir entre le confort des contributeur et celui des consommateurs (souvent pour éviter de faire un petit effort de programmation d'ailleurs), c'est toujours celui des contributeurs qui est au final privilégié car c'est le contributeur lambda, celui qui est près du terrain, qui fait la force du projet. La liste imports est remplie d'exemples de refs externes remis en question ou même finalement rejetés pour un import de nouveaux objets dans OSM. Alors en mettre 5 ou 10... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
En disant ça, je pense aux relativement récents place=neighbourhood ou place=quarter qui ont avantageusement remplacé certains landuse=residential. Le tag place n'a jamais été limité à un noeud mais c'est plus facile à utiliser avec des ptits polygones. Pour place=town, on comprend que c'est plus facile de le mettre sur un noeud que sur un immense multipolygon difficile à maintenir et aux contours flous. La différence entre highway et place n'est pas très flagrante à cette échelle et je n'ai pas de préférence. Les deux sont utilisés pour les adresses (pensez à place=hamlet) par exemple. Mais pas les landuse. @Stephane, highway=pedestrian + area=yes, c'est aussi du surfacique. Il n'y a donc pas de règle d'or, malheureusement ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
2015-02-25 15:58 GMT+01:00 MASSIOT Dominique dominique.mass...@sdis29.fr: A l'instar de Yann (que je remercie pour ce gros travail de fond sur le sujet), je suis administrateur des données cartographiques d'un SDIS (Finistère). J'ai le sentiment qu'une exclusion des champs métiers constituerait un frein dans la démarche d'ouverture de ces données métiers par les SDIS... Une fois versées dans OSM, ces données peuvent être modifiées par n'importe qui. Alors comment, moi, simple contributeur, je pourrais vérifier une valeur de pression modifiée par un tiers ? Ou alors, vous considérez vous comme les seuls autorisés à modifier ces valeurs ? Si c'était le cas, il faudrait alors revoir votre modèle de contribution à OSM. Les informations et améliorations (en particulier de positionnement) peuvent parfaitement fonctionner dans les deux sens mais vous devrez de toute façon garder votre jeu de données originales de votre côté (comme référenctiel) et ne partager que ce qui peux être modifiable/améliorable par le public. Ensuite, vous devrez mettre en place un processus de consultation qui soit combine le meilleur des deux sources, soit prend en compte en local ce qui change dans OSM mais uniquement après vérification. A vous de voir. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
2015-02-25 11:46 GMT+01:00 Stéphane Péneau Pour plus de détails, je te renvoie vers la discussion citée plus précédemment. Stf Aujourd'hui, je pencherais plutôt pour un nouveau tag, du genre highway=plaza ou place=plaza (avec un ou deux 'z' au choix), à mettre sur un polygone fermé ou un multipolygon. Ca reflète mieux le caractère mixte des usages. Et surtout, on reste dans une logique de highway ou de place=* pour nommer un lieu, ce qui est beaucoup plus cohérent qu'un landuse pour les toponymes/odonymes déjà présents dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
2015-02-25 7:33 GMT+01:00 Stéphane Péneau stephane.pen...@wanadoo.fr: Salut, Je confirme qu'en attendant de trouver mieux j'utilise landuse=plaza D'après taginfo, il y a 225 landuse=plaza dans OSM. En regardant sa répartition géographique avec overpass-turbo, on voit que l'essentiel se trouve concentré sur la région nantaise (~150 uniquement en France): http://overpass-turbo.eu/s/7S8 On peut en conclure que ce tag est une impasse ^^ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte avec les panneaux autoroutiers / Destination Sign ?
2015-02-24 8:17 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com: Il me semble qu'une société de logiciels de routage avait fait une saisie importante aux USA et avaient fourni un lien. La société, c'est Telenav qui a racheté Skobbler qui s'appelle maintenant Scout et qui a payé des gens pour remplir ces info sur les USA: http://blog.openstreetmap.de/blog/2014/07/wochennotiz-nr-210/ Quelqu'un se souvient du lien ? Ca ne me dit rien, par contre. Désolé. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aide correction d'une note de carte
2015-02-18 0:42 GMT+01:00 Félix Marty felixma...@outlook.com: Du coup pour moi les tags ont l'air bon, je ne vois pas de raison de les changer pour le rendu (qui semble ici être lui-même à l'origine du problème). Les seuls tags importants pour le rendu dans ce cas précis sont tunnel=yes et layer=-1, donc les tags sont corrects. Les autres tags comme usage ont sans doute un intérêt pour quelqu'un mais pas pour le rendu. Ce qui se passe ici, c'est juste que le rendu n'est pas actualisé très rapidement en ce moment. Les délais anormalement longs arrivent surtout lorsque la feuille de style est modifiée, ce qui a été le cas je crois récemment-. (ou ça peut être un problème de serveur plus simplement) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
2015-02-17 17:21 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Comment comptes-tu traiter l'existant dans OSM (PEI déjà présents dans l'Essonne) ? Outre ce point, j'ai deux remarques: - il faudra publier quelque part la license des données dans une forme compatible ODbL - un critère important dans OSM est la vérifiabilité ([1]). J'ai peur que à part ref, fire_hydrant:type et éventuellement fire_hydrant:diameter, les autres informations comme le débit, la pression ou l'opérateur ne soient invériables et devraient donc rester dans la base du SDIS. Sinon, merci pour cette volonté d'ouverture et de partage, Pieren [1] http://wiki.openstreetmap.org/wiki/FR:Verifiability ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] calcul d'itinéraires sur osm.org
2015-02-17 8:02 GMT+01:00 Francescu GAROBY windu...@gmail.com: Après un rapide essai, c'est pas mal (et rapide). Mais ça n'est (pour le moment ?) qu'un itinéraire A - B : pas moyen de faire un itinéraire A - B via C Francescu Il n'y a pas encore eu d'annonce officielle mais c'était dans les rails depuis longtemps. Comme tous les autres services offerts par osm.org (le serveur de tuiles ou nominatim), le calcul d'itinéraire n'a pas vocation à faire concurrence à Google maps, ni à offrir plein d'options, mais surtout à valider les contributions. C'est donc principalement à destination des contributeurs et accessoirement un outil de promotion. Les possibles gros consommateurs de ce genre de services devront comme pour le reste, contacter des fournisseurs tiers ou mettre en place leurs propres serveurs (pour ceux qui veulent développer des applications et rester indépendants par exemple). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer un centre de formation AFPA
Notez que vous pouvez lancer vous-même des recherches dans les archives de la liste de diffusion de plusieurs manières. L'une d'entre-elles est de taper afpa sur le Nabble de talk-fr: http://gis.19327.n5.nabble.com/France-f5380434.html On peut y voir ma réponse à cette même question en 2012. Aujourd'hui, je ne pense toujours pas que les centres de formation pour adultes doivent utiliser un tag amenity=* existant. Ca n'est pas une école classique, ça n'est pas universitaire non plus, ça n'est pas le même public ni les mêmes enseignants, ça n'est pas non plus géré par les mêmes administrations ni les mêmes ministères/budgets. Donc amha toutes les bonnes raisons pour créer un tag spécifique, distinct des amenity=school (et donc qui ne justifierait plus l'usage de school:FR) même si un sous-tag pourrait préciser les secteurs professionnels concernés. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-12 23:01 GMT+01:00 Tony Emery tony.em...@yahoo.fr: Tu rigoles des genoux ? Tiens, comme je ne connaissais pas cette expression, j'ai essayé divers postures mais n'y suis pas arrivé. Quelqu'un a un mode d'emploi ? Sinon, Tony, laisse tomber les remarques de Philippe. Je préfère de loin, comme d'autres intervenants, le tag ref:FR:commune qui aura la même clé pour toutes les communes. Par contre, je reste sur ma position de ne l'utiliser qu'en l'absence de code FANTOIR pour éviter d'alourdire inutilement les objets dans OSM. Il faut aussi penser aux autres contributeurs. Pour ton travail local, il reste facile de retrouver le code unique local si le code FANTOIR est connu, à la condition que les codes correspondent géographiquement à 100%. Est-ce bien le cas ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article - La Voix du Nord
On Fri, Feb 13, 2015 at 2:17 PM, J.-Lys jacq...@famille-lys.com wrote: Bonjour, Pour info et pour répondre au challenge du journaliste de la VDN, j'ai ajouté le parking silo en question, ainsi que l'hyper Leclerc qui justifie l'existence de ce parking à Aulnoye-Aymeries. https://www.openstreetmap.org/#map=18/50.19913/3.84259 Génial. Merci pour ce travail d'actualisation. J'avais vu que le cadastre était à jour mais pas l'imagerie Bing. L'article de presse mentionnait une voie piétonne qui traverse le parking pour joindre deux rues. Ca serait bien que ça soit ajouté aussi dans OSM (par quelqu'un qui connait son tracé). Surtout que maintenant, cette zone est surveillée de près par un journaliste ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] guide to vandalism” in OSM?
On Fri, Feb 13, 2015 at 3:50 PM, JB jb...@mailoo.org wrote: Still wondering about this « presume good faith » thing. If every note should be resurveyed on the ground, why not just replace the creator text with « please come survey here » ? I'm not saying it has to be necessarily resurveyed on the ground. The information can be verified first by other sources. For the two examples, the bank and the bakery, it' easy to go on the bank web site and check if the branch exists in that town. And for the bakery, you can check if google - for instance - indexed any local press article or website talking about this shop. A no-result should raise an internal alarm and a comment on the note (like plz someone to survey on the ground because I find nothing about this bakery in the web). Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Article - La Voix du Nord
Sinon, il y a quand même un problème plus général avec ces éléments en statut proposed. J'ai vu sur un autre fil une discussion autour d'une proposition de route vieille de 15 ou 20 ans, jamais réalisée mais héritée d'un import. Je pense qu'OSM devrait être plus strict sur ce sujet et ne pas tolérer des objets qui n'ont aucune certitude d'exister dans le futur (de même qu'on devrait l'être inversement sur ceux qui n'existent plus, cf une autre discussion sur le forum.osm.fr). J'ai moi même effacé un tracé de contournement de Strasbourg il y a quelques temps. Ca fait des années qu'on en parle, avec x variantes, et rien n'est acquis tant les oppositions (et les problèmes de financement) sont importants. Tant qu'on est au stade du projet virtuel avec aucune certitude de réalisation, OSM ne devrait pas servir de bac à sable ou de feuille de brouillon, même avec les bons tags ... surtout que maintenant il y a d'autres outils pour faire ça comme umap. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-12 13:44 GMT+01:00 Tony Emery tony.em...@yahoo.fr: Effectivement, les toutes petites intercos n'ont pas plus les moyens. Après, je ne suis pas d'accord avec toi. Il faut des structures de taille suffisante si on veut qu'elles soient efficaces et qu'elles aient les moyens de faire quelque chose. Sinon, autant laisser les communes ! Ça n'a rien de technocrate, c'est juste logique. Si on parle de logique, le simple citoyen que je suis ne comprends pas que deux entités administratives créent et gèrent deux identifiants uniques pour chaque voie. Ca fait sans doute partie de la simplification administrative annoncée ... Plus sérieusement, il suffirait que la DGFiP délivre des identifiants immédiatement aux communes qui le demande, éventuellement avec un statut temporaire et jusqu'à validation définitive par le cadastre. Mais ça doit être trop simple pour nos technocrates ... D'un autre côté, quand on voit les millions dépensés depuis des décennies à gérer deux registres parcellaires en parallèle, plus rien ne m'étonne (et ne parlons pas des base adresses). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] guide to vandalism” in OSM?
FYI, after reading this thread in the forum, I sent a message to the registred user who converted the notes into POIs in OSM that he should always verify first from a 2nd source what is reported by the note, whatever the author is anonymous or not. The argument about most of the notes are correct is not good enough. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] guide to vandalism” in OSM?
On Thu, Feb 12, 2015 at 3:46 PM, Michał Brzozowski www.ha...@gmail.com wrote: Therefore sometimes I simply assume good faith which in my opinion *is* sensible. That's where I disagree. If some registred user creates fake POI's directly, he should be banned (first temporarily, with warnings etc) once we notice the vandalism. The same rule should apply for registred users copying easter eggs based on copyrighted maps or fake POI's based on notes. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] guide to vandalism” in OSM?
On Thu, Feb 12, 2015 at 4:29 PM, Michał Brzozowski www.ha...@gmail.com wrote: @Pieren: You switch topics so easily that I'm not sure what are you talking about precisely. Is your stance Someone showed that it is easy to add fake notes, therefore we must assume that every single POI added from notes is fake unless we prove it 100%? I'm just saying that a note is not good enough as a single source for contribution. Especially when it is easy to verify like in the two reported examples (a bank and a bakery). And in case of doubt, you just leave the note open for others instead of compulsive close notes contributions. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Osmose
2015-01-29 12:50 GMT+01:00 Éric Gillet gill3t.3ric+...@gmail.com: Dans l'idée je pense, car ça permet une homogénéité des vitesses, et permet une mise-à-jour instantanée des vitesses en cas de changement de législation (potentiellement bientôt d'ailleurs). Le soucis c'est que les limites risquent de rester inchangées pendant un moment sur le terrain malgré un changement de législation. Le dernier changement en masse fête ses 25 ans (le 50 en ville)... et depuis, il y a eu la multiplication des zones 70, 30 ou 20 en zones urbaines. On est donc très loin d'un système homogène. Et un changement légal demanderait du temps, beaucoup de temps et de l'argent pour remplacer les centaines de millliers de panneaux (qui seuls font foi durant la période de transition). Pour résumer, ce tag est superfétatoire si ce n'est pour expliquer dans certains endroits l'origine de la limitation lorsque les panneaux sont absents. En cas de changement, il faudrait de toute façon mettre en place pour OSM un process de suivi de mise à jour des sections tagguées avec l'ancienne vitesse, genre avec un tag à vérifier, qui serait éliminé au fur et à mesure des progrès sur le terrain. De toute façon, vu les freins financiers et politiques actuels (le dernier exemple du 80 généralisé ayant fait pchitt), un tel changement est peu probable. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de vitesses urbaines, rurales et autres... (était : Osmose)
2015-01-29 10:12 GMT+01:00 Eric Sibert courr...@eric.sibert.fr: Rien pour les routes pour automobile à chaussées séparées (maxspeed=110) Zut alors. Sans compter les voies à 50 en dehors des agglo et tous les autres cas spéciaux... Plus sérieusement, le tag source:maxspeed a été inventé dans un seul but : faciliter le changement au cas où la vitesse limite serait changée par la loi, c.à.d quelque chose qui n'arrive qu'une fois tous les 50 ans... et si ça arrive, il faut de toute façon vérifier (les panneaux ne sont pas tous changés simultanément). Autant ajouter un tag maxspeed à vérifer sur tous les ways concernés lorsque ça arrivera. Je préfère voir le tag maxspeed partout plutot que ce tag source:maxspeed (que certains voudraient même substituer au premier) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-05 13:17 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: +1 Tony, keep going. François Lacombe Non, c'est trop facile. Il faut d'abord examiner ce qui se passe avant de donner un blanc-seing aussi rapidement (même si le message suivant commence à poser les bonnes questions). Le problème principal tourne autour de cette référence ref:FR:commune. Il y a déjà en France un code unique pour les rues, celui de la dgfip ref:FR:FANTOIR. L'explication donnée par Tony: Vous faites ce que vous voulez avec les codes Fantoir, nous gérons nos identifiants internes n'est en aucun cas satisfaisante, pas seulement parce que le tag n'est documenté nul part (alors qu'il est utilisé depuis 2 ans déjà) mais surtout parce qu'il est d'un usage interne ! OSM ne peut être le réceptacle de données à usage interne, inexploitables par les autres utilisateurs et incompréhensibles par les autres contributeurs. C'est une règle fondamentale dans ce type de projet. D'autant plus que des solutions techniques (externes à OSM) sont faciles à mettre en place si un code unique, celui du fantoir, est correctement mis en place. Notez que ça n'est pas la première fois que les expérimentations faites sur Orange posent questions. C'était déjà le cas en 2013 avec les mêmes personnes et le ref:FR:commune s'appelait à l'époque ref:orange: https://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056807.html mais qu'à l'époque, le ref:FR:fantoir n'existait pas et l'excuse de l'expérimentation était encore acceptable. Concernant les autres points (limites communales), il ne s'agit apparement que de maladresses. Inutile donc d'y revenir. Sinon, concernant les échanges épistolaires de Philippe, on le connait ici très bien et il sait déjà qu'il gagnerait beaucoup à être moins agressif dans le choix de ses expressions mais qu'il ne changera jamais de ce côté là. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-05 14:41 GMT+01:00 Tony Emery tony.em...@yahoo.fr: Le code Fantoir est généré par la DGFiP a posteriori de la création ou dénomination de la voie faite par les communes. Du coup, les communes qui gèrent une base de données voirie en interne attendent entre 1 et 3 ans avant de récupérer ce code, ce qui n’est pas du tout satisfaisant. Okay pour ce cas. Mais uniquement pour ce cas où la voirie n'a pas encore de code fantoir. On peut parfaitement tolérer ce ref:FR:commune comme une solution transitoire pour satisfaire tout le monde. Mais en aucun cas, on ne devrait le généraliser à toutes les voies. Et ça n'exonère pas de le documenter dans le wiki... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr: Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le supprimer derrière. L'intérêt est que l'usage de ce code resterait très limité (par exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec les autres communes françaises. J'ai commencé ici : http://wiki.openstreetmap.org/wiki/Vaucluse/voirie http://wiki.openstreetmap.org/wiki/Vaucluse/voirie Il faudrait aussi voir ici: http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-05 16:56 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Est-ce vraiment une référence qu'on peut qualifier de nationale ? Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur l'ensemble du territoire français et il n'existe pas de répertoire officiel géré par un organisme qui en a la charge. A priori, rien n'empêche d'utiliser ce tag dans d'autres communes. Mais je suis d'accord, le titre du wiki est maladroit. On devrait dire liste des tags ref spécifiques à la France Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [tag] musée d'art
2015-01-15 17:17 GMT+01:00 althio althio althio.fo...@gmail.com:
La définition actuelle dans le wiki anglais est confuse et
partiellement fausse. En particulier, l'idée qu'un espace affichant de
l'art uniquement serait une gallerie d'art et que le concept de
musée serait réservé aux sciences et à l'histoire... En fait, la
différence entre galerie d'art et musée est la même en anglais et en
français.
Tandis qu'est réservé aux musées sur d'autres sujets ('scientific,
historical, cultural') le tag:
tourism=museum [2]
Si on devait toujours croire ce qui est écrit dans le wiki... (art
gallery)An institution holding art exhibitions (even if they have
museum in the name)
Donc un musée ne serait pas un musée, même si c'est dans son nom ! Le
cartographe OSM aurait donc la science suffisamment infuse pour dire
que des musées se trompent et usurpent leur titre.
Mais la documentation en français n'existe pas [1,2] ou donne beaucoup
moins de détails que la version anglaise. [3,4]
Simplement parce qu'elle n'évolue pas à la même vitesse (ce qui a
parfois du bon, comme ici)
Et nous avons quelques musées qui ne respectent pas le schéma
proposé... En fait, tous ceux que j'ai regardé parmi les plus connus à
Paris...
Alors quoi ? On boycotte le tag tourism=gallery ? On rectifie ? Osmose ?
Plus simplement, on devra adapter le wiki pour que le tag art
gallery soit utilisé pour les espaces que se déclarent comme
galleries d'art et comme museum les espaces qui se déclarent comme
des musées.
name=Jeu de Paume [5]
tourism=museum
centre d'art d'après wikipedia (art contemporain, photo). -arts_centre
http://fr.wikipedia.org/wiki/Jeu_de_Paume_%28centre_d%27art%29
amenity=arts_centre [6]
name=Centre Pompidou
tourism=attraction
L'ensemble mérite le qualificatif de centre d'arts. Mais il faut
affiner dans la cartographie indoor et identifier à l'intérieur les
parties muséals et les galleries séparément comme ci-dessous:
name=Musée national d'art moderne [7]
tourism=museum
alt_name=Musée du Louvre [8]
historic=castle
name=Le Louvre
tourism=attraction
Corrigé
name=Musée d'Orsay [9]
tourism=museum
name=Musée Rodin [10]
tourism=museum
Appliquez la règle du duck tagging ([1]) : si ça ressemble à un
musée, si ça s'appelle un musée, alors tagguez-le comme un musée.
Pieren
[1] http://wiki.openstreetmap.org/wiki/Duck_tagging
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations
Je dois dire qu'en suivant de loin cette conversation, je bois du petit lait. J'avais à plusieurs reprises par le passé signaler ici que ces relations étaient loin de faire l'unanimité. Le fait même que 50% de ces relations soient concentrées dans un seul pays, la France, est en soit une anomalie. Le syndrome du village gaulois sans doute. Je ne vais pas revenir sur les avantages et inconvénients de chacune des méthodes. Mais je voudrais encore une fois insister sur le fait qu'aucun logiciel d'aide à l'import ne devrait favoriser une méthode en particulier en laissant le libre choix aux participants. Et aussi, j'aimerais que certains évitent de passer d'un modèle à l'autre en masse sur de grandes villes comme j'ai déjà pu malheureusement le constater. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour du bâti sur une commune
2015-01-16 15:24 GMT+01:00 jean navarro jean.nava...@laposte.net: en travaillant pour BANO, je suis tombé sur une commune dont le tracé bâti semble plus que folklorique... Je ne peux pas comparer là tout de suite. Mais est-ce que le cadastre actuel est vraiment mieux ? (l'import date de mars 2012) Il y a beaucoup de villages comme ça dans le cadastre, avec un bâti souvent, disons, approximatif. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer les Départements français et admin_level=6
2015-01-14 16:18 GMT+01:00 sly (sylvain letuffe) lis...@letuffe.org: Les cas cités sont des cas particuliers créés par la loi. Pour la NC, on pourrait admettre que le niveau 6 correspond aux provinces mais leurs compétences correspondent d'avantages à un mix entre régions et départements de la métropole. C'est donc très, très difficile d'établir une correspondance et je reste dubitatif. Peut-être faudrait-il un 3e tag, nouveau, qui distinguerait la structure administrive de la métropole et des outres-mers tout en gardant l'admin_level pour converser la hiérarchie entre niveaux, quitte à ce que les level ne correspondent pas tout à fait. Sinon, l'autre solution serait d'inventer des admin_level=3,5 ou que sais-je qui n'auraient pas beaucoup de sens. Pour Lyon, on en a un peu parlé sur un autre fil. J'y ai encore repensé et bien que la métropole ait récupéré les compétences du département sur sa zone, celui-ci existe encore, bien que largement vidé de sa substance. Je trouve donc abusif de coller le niveau département à cette métropole contrairement aux autres métropoles, surtout qu'officiellement ni le nombre ni la forme des départements n'a été modifié en France. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Guidage OsmAnd
2014-12-30 16:18 GMT+01:00 le nash nashou...@gmail.com: Ce qui, entre les route unclassified, residential peux poser probleme, car les mappeurs ne font parfois pas de différence. (unclassified est + rapide que résidentiel) Non, rien ne dit que unclassified est + rapide que residential. C'est juste une présomption. Certains, comme moi, ne font pas de hiérarchie entre ces deux classes de routes. Il y en a une qui traverse une zone résidentiel alors que l'autre peut traverser, par exemple, une zone industrielle. Rien ne dit que la deuxième sera plus rapide que la première. Mais les cyclistes par exemple peuvent présumer qu'une zone résidentielle est plus calme qu'une zone industrielle (moins d'utilitaires, etc). La solution que j'utilise depuis quelque temps est de systématiquement indiquer la limitation de vitesse, et le cas échéant de réviser la hiérarchie des voies dans la partie qui pose probleme. C'est très bien de mettre les limitations mais réviser la hiéarchie des routes pour satisfaire un résultat dans OSMAnd est une grosse erreur. On peut certes se poser des questions sur la validité de certaines contributions mais, on le voit ici, les logiciels de routages contiennent eux-aussi leurs propres erreurs ou manquement et comme il ne faut pas tagguer pour le rendu, il ne faut pas tagguer pour le routage. Étant donné que la hiérarchie des route ne doit pas être calquée sur leur référence administrative, mais sur leur utilisation réelle, cela me semble pas erroné. Les deux sont heureusement souvent corrélés. Créer une différence dans OSM entre réel et administratif doit se justifier uniquement du point de vue du réel (traffic, limitations et accessibilité) et pas sur un avis trop subjectif (genre, c'est mon raccourci préféré pour aller au boulot). A mon avis Eric, si OSMand te fait passer par la N563, c'est a cause des limitations de vitesse, qui font que OSMand a plus confiance dans cet itinéraire, que dans l'autre ou il n'y en a pas. Ca, c'est clairement un bug osmand qui estime mal les portions sans maxspeed. Il a fallut que je mette des interdictions de tourner qui n’était visiblement pas implicite. (en fait, il faudrait que OSMand comprenne que l'angle entre la voie d'accès et la route est tellement important que l'interdiction de tourner est implicite) Heu, attention, attention. Les interdictions de tourner à mettre dans OSM ne doivent être que celles qui sont légales (comme tous les tags access d'ailleurs), c.a.d. basé sur un panneau de signalisation. La limitation peut être implicite (rond-point ou sens unique) mais c'est encore une fois aux logiciels d'en tenir compte suivant les règles de circulation dans les pays concernés. Si l'angle est fermé mais tourner n'est pas interdit, il n'y a aucune raison d'ajouter une restriction dans OSM. Ca n'est pas forcément impossible pour tous les types de véhicules (penser vélo, moto, etc). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer des magasins ayant une démarche écologique
2015-01-13 9:58 GMT+01:00 althio althio althio.fo...@gmail.com: Si ce tag est taggable (pas trop subjectif, avec un label clair dans au moins quelques pays)... Alors là, bon courage. Des labels, il y en a des centaines dans chaque pays... S'il faut attendre qu'il n'y en ai qu'un seul et international en plus, on est tranquille pour un bout de temps ;-) Je n'ai rien trouvé d'équivalent dans mes archives ni sur le wiki. Peut-être faudrait-il lancer une proposition de genre certification_mark=le nom du label. Mais je suis d'accord sur le fait qu'il faille un label (ou tout autre forme de certification) et pas simplement un commerçant qui met une affiche sur sa devanture (on n'est pas obligé de le croire, même si sa démarche est sincère). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Commerces ethniques
2015-01-02 16:41 GMT+01:00 Eric SIBERT courr...@eric.sibert.fr: Je cherche un moyen de coder les commerces avec une dominante ethnique. Je pense aux épiceries (portugaises, italiennes, chinoises...), coiffeurs (afro...), vêtements (indien, africain...)... Pour la nourriture, on a déjà cuisine=*. Des idées pour le reste? La même question a été posée ici pour les épiceries: https://help.openstreetmap.org/questions/23811/correct-tags-for-ethnic-grocery-shops Apparemment, ils sont d'accord pour réutiliser le tag cuisine, ce qui peut se comprendre pour une épicerie. Mais je ne suis pas convaincu que la même réutilisation soit possible pour un coiffeur ou des fringues... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne année
2015-01-01 17:51 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Quel bazar ! C'est sans doute ce que nos gouvernants appellent le choc de simplification. Pour l'instant, on a le choc, la simplification viendra plus-tard... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orne - communes nouvelles
2015-01-07 0:28 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: On en avait discuté ici, il n'y a aucune confusion possible entre les arrondissements municipaux de PLM et les communes associées partout ailleurs. Ben, c'est les mêmes tags, donc il y a bien confusion. En plus, si c'était validé, pourquoi est-ce que le wiki n'en parle pas ? D'ailleurs administrativement c'est vraiment très proche; Proche mais pas la même chose. On pourrait imaginer un cas (très théorique) où une ville à arrondissements s'associe avec des communes voisines. C'est peu probable mais c'est juste pour montrer que dans ce cas, il n'y aurait aucun tag qui distinguerait arrondissements et communes associées... A noter que quelqu'un a utilisé le niveau 9 pour des sous-ensembles de la métropole de Nantes: http://layers.openstreetmap.fr/?zoom=10lat=47.20573lon=-1.35742layers=BFFTFFF Le niveau choisi est certainement incorrect mais on peut même se demander si ce découpage a un intérêt pour OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orne - communes nouvelles
2015-01-07 15:33 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: Mettre les communes associées en niveau 10 est donc complètement stupide. Ca n'est pas moi qui parle d'utiliser le niveau 10. Il faudrait relire les anciens messages pour trouver qui est a eu cette idée stupide J'insiste il n'y a aucune confusion possible entre arrondissements et communes associées, il n'y a aucun conflit à les mêler au même niveau OSM Ben, si tu les mélanges dans OSM, il y a bien confusion. Et s'il fait un tag supplémentaire pour les pointilleux qui voient mal le mélange entre arrondissements et communes associées, c'est un tag supplémentaire pour la poignée d'arrondissements, et par défaut de ce tag considérer le niveau 9 pour toutes les communes associées (il y en a plus de 700, leur nombre est à nouveau en hausse rapide après des années de relative stagnation). Le niveau 9 pour les arrondissements, c'est assez ancien. On ne peut pas changer les admin_level comme ça, d'un claquement de doigts. Il y a probablement des applications, des gens qui utilisent ces données avec ces tags régulièrement. La distinction entre arrondissements et communes associées n'est pas un gadget pour les pointilleux. C'est un minimum de pouvoir extraire ces deux types de limites administratives par des requêtes simples, de type overpass-api, sans avoir à filtrer ensuite les résultats en cherchant des id ou des name particuliers. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Saturation du service umap.openstreetmap.fr
Quelqu'un a créer un umap avec les rassemblements en soutien à Charlie: http://umap.openstreetmap.fr/fr/map/les-rassemblements-en-soutien-a-charlie-hebdo_25394 Le lien est affiché sur lemonde.fr et probablement ailleurs ce qui semble saturer le serveur osm-fr. Je ne sais pas si les admins peuvent faire quelque chose ou s'il faut juste attendre que ça se calme... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orne - communes nouvelles
2014-12-22 21:34 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: Attention ce sont des communes associées : les 4 communes ne disparaissent pas elles passent au niveau 9; c'est une 5e commune qui est créée au niveau 8. Euh, je n'ai pas souvenir qu'on est atteint un consensus sur ce sujet. Le level 9 correspond à un niveau administratif très précis : les arrondissements des grandes communes Paris, Lyon, Marseille. Utiliser le même tag pour une autre entité administrative n'est pas une bonne chose. Il faudra bien pouvoir distinguer arrondissements et communes associées d'une manière ou d'une autre. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changements massif sur les noms génériques de shop et amenity
Après lecture et mûre reflexion, je crois qu'il faut redire quelques points ici: - d'abord, éviter de faire des changements globaux sans en parler avant à la communauté (comme le rappelle fort justement sky). Même si cela ne concerne que quelques centaines d'objets, cela concerne le travail de plusieurs dizaines de contributeurs et une personne seule ne peut imposer ses vues aux autres sous prétexte qu'elle maitrise mieux les outils pour le faire. - je connais plein de boulangeries qui ont une façade avec uniquement marqué Boulangerie. D'autres sont marquées Boulangerie pâtisserie. Même si le vrai nom est Boulangerie Tartampion, l'information n'est pas toujours disponible immédiatement. Et il se trouve aussi que comment tagguer patisserie et/ou boulangerie/patisserie, dépôt de pain, etc est une question récurrente dans OSM chez les nouveaux (et les autres). Même chose pour les parkings ou les églises ou que sais-je avec le cas particulier que certains parking n'ont vraiment pas de noms (comme certaines routes d'ailleurs). - OSM fonctionne par itération. Mettre un tag name sur une boulangerie n'est pas faux. Mettre un tag name=Boulangerie au lieu de name=Boulangerie Tartampion n'est pas faux mais incomplet. Si c'était name=Boulangerie en face de la boucherie ou name=La boulangerie avec les meilleurs croissants, là ça serait une erreur. Si vous tombez sur une boulangerie tagguée name=Boulangerie, cherchez son nom complet plutôt que de revenir en arrière. Si c'est juste que ça vous irrite et que vous n'avez pas envie de chercher le nom complet, respirez un bon coup et passez à autre chose, il y a assez à faire ailleurs (utilisez osmose si les idées vous manquent). Pour les parkings, c'est pareil. Un changement de masse ne peut pas déterminer si name=parking est incomplet ou incorrect (qu'il n'a vraiment pas de nom). - OSM est une communauté dont seule une infime partie participe aux discussions. Ca ne me gêne pas trop de voir des reverts massifs si ça permet de rectifier l'action d'une ou deux personnes prolifiques qui tentent d'imposer leur point de vue par la quantité. Par contre, annuler des choses faites par des dizaines ou centaines de contributeurs différents (ce qui est le cas ici) me pose d'avantage de problème. La question devient en quoi mon opinion est-elle plus valable que la leur ?, pourquoi sont-ils si nombreux à ne pas penser comme moi ? Après ça, je ne peux pas dire que ces changesets soient finalement une bonne idée. Cette polémique me rappelle celle des oneway=no qui seraient inutiles sur les highway puisque implicite. Mais ca sert quand même dans les villes qui ont plein de sens uniques (pour dire que celle-là a bien été vérifiée et est bien à double sens). Ca n'est pas parce qu'une information est implicite qu'elle n'est pas utile à certains. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
2015-01-02 15:45 GMT+01:00 Art Penteur art.pent...@gmail.com: J'en profite pour adresser mes remerciements aux auteurs de feu le bulletin OSM-fr, qui était une source d'information variée et dense. Tu peux dire à l'auteur unique qui a arrêté, faute d'avoir obtenu un meilleur accès au serveur. (et qui a fait du weeklyOSM bien avant weeklyOSM ;-) @Manfred, je suis prêt à reprendre le flambeau sur votre site, contacte moi directement, même si je trouve dommage d'éparpiller nos infos sur trop d'endroits différents. Ces pages d'info peuvent servir à accrocher un nouveau public vers nos sites internet OSM locaux (à tout le moins, il devrait faire systématiquement un renvoi vers eux). Mais bon, c'est peut-être la rançon de d'avantage de liberté... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs
Les mechanical edits restent possibles mais il faut prendre des précautions. Les changements globaux sans annonces sont rarement bien perçus. C'est plus facile si c'est fait à l'échelle de son propre pays pour commencer. Le problème si on ne fait rien, c'est que des doublons de tags peuvent longtemps persister dans OSM et des actions de nettoyage doivent parfois être entreprises. Mais pour ne pas froisser les suceptibilités, il vaut mieux en parler avant pour expliquer la démarche. Il ne faut pas prendre les gens par surprise, expliquer, etc. Mais on trouvera toujours des gens qui sont contre, par principe. Si ça résiste trop, on peut lancer une consultation publique par le biais d'un vote ou d'un sondage en ligne pour peser les forces en présence (la majorité silencieuse). Pour les AED, c'est un peu ma faute aussi. Un premier vote avait valider l'emergency=aed avec très peu de gens sur le wiki (il faut dire que la discussion implique peu de monde). Comme je suis contre l'usage des abbréviations dans les tags par principe, j'ai relancé un deuxième vote avec beaucoup plus de publicité pour obtenir un autre résultat sans abbréviation avec succès cette fois-ci (je crois que le problème des abbréviations est largement compris ... sauf par ceux qui les utilisent couramment ;-) mais je n'ai rien fait ensuite pour que les données changent dans la base. Les stats étaient encore largement en faveur de l'ancienne version jusqu'à ce que les allemands décident d'adopter la nouvelle version (c'est chez-eux qu'il y en a le plus). Après, c'est plus facile de convaincre les derniers récalcitrants. Les changements ne peuvent pas / plus se faire de manière brutale à l'échelle monde. Il faut savoir y aller progressivement. Et ceux qui sont contre le wiki sont en fait aussi ceux qui ne veulent pas chercher le consensus. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: man-made=tower avec tower:type=tower :))
2014-12-16 11:25 GMT+01:00 Yves Pratter yves.prat...@gmail.com: Lorsque celles-ci donnent des valeurs génériques, inutile de les bloquer sur un domaine particulier avec un préfix. Ok, ça me va :-) Le problème avec les tags trop génériques, genre type, operator, location, etc, c'est qu'ils empêchent le balisage de plusieurs choses sur le même élément OSM (noeud ou polygone). Ou pire lorsqu'ils sont quand même utilisés, ils peuvent être mal interprétés car les lecteurs peuvent les rattacher indûment à l'un ou à l'autre des tags principaux. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSMOSE] : tag building obligatoire sur man_made=water_tower ?
2014-12-12 15:11 GMT+01:00 Art Penteur art.pent...@gmail.com: Osmose ne devrait pas râler sur l'absence de building. +1 PS: on pourrait peut-être améliorer le wiki +1 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] OSM France BANO project... openaddresses in France
On Thu, Dec 11, 2014 at 1:20 AM, Imre Samu pella.s...@gmail.com wrote: Hi Christian, As I read OKFN article [1] about BANO project ( November 17, 2014 ) It's not perfectly clear to me what it is the BANO license ? ( only ODBL or Dual licensed ? ) BANO is ODbL only. The article you refer is about another similar project but different from the one discussed in this thread. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] https et remote control
2014-12-09 16:56 GMT+01:00 JB jb...@mailoo.org: Il y a une astuce, un truc à changer quelque part pour ouvrir une zone directement dans JOSM à partir d'une page https ? C'est une histoire de validation de certificat. Regarde la réponse de Matija Nalis ici: https://help.openstreetmap.org/questions/2208/how-do-i-enable-the-remote-control-in-josm ou celle -là: https://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouistreham Riva-Bella
2014-12-06 15:34 GMT+01:00 Stéphane Péneau stephane.pen...@wanadoo.fr: On fait quoi ? Un alt_name=Ouistreham Riva-Bella en attendant ? Selon moi, alt_name suppose une alternative relativement officielle. Là, on trouve un cas assez rare, voir exceptionnel où c'est la mairie qui pose des panneaux pour imposer (le maire dira anticiper) une version qui a pourtant peu de chance de passer la rampe des décrets (si on en croit la presse, ça n'a même pas encore passé la rampe du conseil municipal ! le préfet pourrait rapidement mettre son hola sur cette initiative). Si je comprends bien, rive-bella est un des lieux-dits de la commune et le nom Ouistreham Riva-Bella désignait uniquement la plage et la station balnéaire y attenant . Plutot que alt_name, j'opterais pour loc_name qui marque d'avantage le caractère pour l'instant local de l'initiative (et nominatim le supporte aussi, je crois). L'ajout d'un tag note pourrait aussi éclairer les autres contributeurs et utilisateurs (initiative du maire, démarche officielle pas encore lancée, etc). Je me dis que certains maires ont dédidément beaucoup de temps libre mais l'essentiel est d'être sur la photo... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle analyse Osmose d'intégration des codes postaux
2014-12-06 19:34 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com: Note: cette analyse est basé sur la tag addr:postcode, que je considère pour ma part comme n'étant pas le bon. Selon moi on devrait utiliser postal_code pour les surfaces de code postaux. Voir mon mail sur talk-fr De l'usage des tags postal_code addr:postcode qui n'a soulevait aucun intérêt. Je suis aussi d'accord. La tendance est d'utiliser postal_code sur les zones et addr:* sur les adresses individuelles, sans doute pour des raisons historiques (le premier étant bien plus ancien dans OSM que le second). Par contre, je voudrais revenir sur l'Allemagne qui a accompli une action de groupe pour modéliser tous ses codes postaux sur l'ensemble de son territoire avec la relation de type=boundary + boundary=postal_code. Pourrait-on envisager le même type d'action en France ? Cette modélisation est plus cohérente avec la réalité dans nos pays puisque les codes postaux sont relativement indépendants des limites communales (plusieurs communes avec le même code postal ou une commune avec plusieurs codes postaux). A terme, plus il y aura de pays pour adopter ce type de relation, plus il y aura de chance pour que les logiciels de géocodage l'adoptent et cela nous permettra de nettoyer les postal_code et autres addr:postcode qui seraient à l'intérieur de ce polygone et donc redondants (répétés sur les relations commune. les noeuds/ways place et sur de nombreuses adresses individuelles). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
2014-12-04 23:40 GMT+01:00 Vincent de Château-Thierry osm.v...@free.fr: Voilà, vous avez désormais à droite du nom de commune, en haut de page, un 4è lien 'FANTOIR' qui ouvre une nouvelle page avec tout le contenu 'Enregistrement Voie' du Fantoir de la commune, sans aucun filtre. La doc Fantoir correspondante est ici : http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf Lorsque vous publiez des données opendata, veillez à respecter les clauses de license: http://wiki.data.gouv.fr/wiki/Licence_Ouverte_/_Open_Licence en l'occurence, mentionner la source (a minima) et la date de mise à jour Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
2014-11-29 0:14 GMT+01:00 Sébastien Dinot sebastien.di...@free.fr: Cette perspective me semble très intéressante ; je suis impatient d'obtenir les premières séries temporelles Sentinel 2 et voir ce que nous allons pouvoir en faire au profit d'OSM. C'est effectivement une annonce fort alléchante. Surtout si une agence se charge de traiter le volume considérable des données pour les mettre dans une forme exploitable par des utilisateurs aux moyens limités comme nous. Je doute que l'on puisse faire le job nous-même (en particulier pour créer des sets sans nuages) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Crèches, halte-garderies, multi-accueils, écoles maternelles
2014-11-27 23:48 GMT+01:00 althio forum althio.fo...@gmail.com: Une modif du wiki https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool date du 20 octobre... La version précédente était : Crèche, halte-garderie amenity=nursery ou amenity=creche (en débat) pas de school:FR=* Quelqu'un a donc choisit un autre tag (rejeté à l'international) amenity=childcare et a supprimé la notion de 'en débat'. La version anglais est toujours sur amenity=kindergarten. Pour maternelle, ca a toujours été kindergarten pour être conforme à l'international, même si une infime minorité en France veux utiliser school, sans doute par idéologie (kindergarten pouvant se traduire littéralement par jardin d'enfant). Pourtant, kindergarten inclue une notion de preschool assez compatible avec nos maternelles. Pour crêche, c'est plus compliqué. Même à l'international, il n'y a pas de consensus clair parce que la notion de crêche comme chez-nous n'existe pas dans tous les pays. Le tag childcare est ambigue parce qu'il s'applique chez les anglo-saxons aussi bien à des structures de gardes à la journée (boulot) que dans des centres commerciaux, le temps de faire ses courses. Chez-nous, on distingue halte-garderie (occasionel) et crèches (récurrent) (même si certaines font les deux). C'est pourquoi le wiki en anglais sur childcare mentionne l'usage de amenity=creche promu par certains en Europe principalement. Ce que je propose, c'est de clarifier le wiki français pour utiliser amenity=childcare pour les halt-garderies, amenity=creche pour les crèches et amenity=creche + childcare=yes pour les crèches qui font aussi halte-garderie (multi-accueil) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] De l'usage des tags postal_code addr:postcode
2014-11-26 11:10 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: postale et on en a strictement aucune en France (type=boundary, boundary=postal_area) contrairement à nos voisins Le bon tag est boundary=postal_code: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?
2014-11-25 13:13 GMT+01:00 sly (sylvain letuffe) lis...@letuffe.org: J'aime bien l'esprit de non_existing et je propose également : ** no:*building=yes J'adore ! Efficace et simple à se souvenir. J'ai moi aussi un avis positivement négatif sur ce genre de tag, qui me rappelle les entrance=exit (!) ou les amenity=drinking_water + drinkable=no (!!) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?
Notez que cette thématique n'est pas exclusive au cadastre ni à la France. Elle se pose pour tous les endroits où plusieurs sources existent (ou la même source mais avec des dates différentes). Je me souviens d'un cas où un contributeur s'échinait à supprimer un bout de route visible sur Bing mais qui n'existait plus sur le terrain après travaux. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?
2014-11-25 13:31 GMT+01:00 Yves Pratter yves.prat...@gmail.com: * [building=no] n'est pas satisfaisant (cf. sly: risque de mauvaise interprétation par les usagers qui feraient un building=* = bâtiment générique) Oui et n’empêche pas le rendu par les moteurs qui ne géreraient pas explicitement la valeur « no » Pas d'accord avec ça. La valeur 'no' est courante dans OSM (voir taginfo) et de nombreux tags sont vérifiés avec ça. Par exemple, le oneway=no, cher à notre ami Sly qui voulait en mettre partout à ses débuts ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?
2014-11-24 13:32 GMT+01:00 Yves Pratter yves.prat...@gmail.com: Ça fonctionne assez bien, mais on peut passer à côté de quelques bâtiments. Avec cette méthode, est-ce qu'on ne risque pas de remettre dans OSM des bâtiments qui ont été supprimés/non importés auparavant parce qu'ils n'existent pas sur le terrain ? (plus fréquent qu'on ne le pense) Personnellement, pour palier ce problème, il m'est arrivé de laisser les polygones du cadastre avec un building=no + ev. 1 note mais je n'ai jamais été vraiment 100% satisfait de cette solution. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?
2014-11-24 17:18 GMT+01:00 Yves Pratter yves.prat...@gmail.com: Et oups, ce n’est pas destroyed, mais demolished http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/demolished Le problème avec ce tag, c'est qu'il sous-entend que le bâtiment a existé. Mais en est-on vraiment sûr ? Je peux imaginer que des permis ont été déposés mais jamais réalisés... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à dispo de support de formations
2014-11-21 14:34 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr: j'ai noté deux erreurs de frappe : Moi, j'aime bien la citation du slide 41: L'orientation peut avoir du sens J'ajouterais : Se perdre peut mener nul part :-)) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] query features, une nouvelle fonction sur la page principale d'osm.org
C'est en place depuis une quinzaine de jours. Comme ça n'arrive pas très souvent et que je n'ai vu passer aucun message qui en parle sur cette liste, je me permets de le mentionner ici : - le site principal openstreetmap.org a une nouvelle fonction symbolisée par une icône avec un point d'interrogation à droite de la carte. Si on clique dessus puis sur un point de la carte, on obtient une liste des features (élément) proches du point ou englobant ce point. Ca passe par une requête overpass-API (vu sur Wochennotiz) Reste à mettre à jour la traduc. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap
2014-11-18 20:44 GMT+01:00 Pierre Knobel pierr...@gmail.com: Je trouve que c'est une énorme concession qu'on leur fait, de les autoriser à vendre nos contributions à Google (si on choisit de contribuer à la BAN... pour ma part ce n'est pas encore décidé). C'est toute la question de cette histoire de double license. Je ne sais pas dans quelle mesure il sera légalement possible de distribuer le même jeu de données avec des clauses contradictoires comme le partage à l'identique. De fait, la license payante annule les contraintes de la license libre. Ou inversement... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
2014-11-19 11:03 GMT+01:00 david.croc...@online.fr: Bonjour Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. Euh, si les adresses sont déjà dans OSM, il suffit de mettre le code fantoir sur la voie, pas besoin de transformer les addr en relation. Je rappelerais juste ici que d'après les stats mondiales, le modèle associatedStreet reste bien en deça du modèle sans relation et est même en perte de vitesse (3.4M contre 42.7M alors qu'on avait 2.1M contre 23M il y a un an). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
2014-11-19 11:08 GMT+01:00 Charles Nepote char...@nepote.org: En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Je ne pense pas que ce soit une bonne idée. A terme, la base adresse unitifée devra identifier les divergences sur les noms de voies (ou abréviations) entres les divers bases nationales (IGN, la poste, cadastre, etc). Le moyen le plus facile pour comparer ces noms sera d'abord d'utiliser l'identifiant unique qu'est le code fantoir. En l'ajoutant dans OSM, tu valides le fait que le nom dans OSM est le nom correct. Aux autres ensuite de s'adapter. Et en leur fournissant le code fantoir depuis OSM, tu facilites la tâche de rapprochement. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
2014-11-19 11:38 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com: J'ai fait un script pour ça. Je me demande si ça ne faudrait pas le coup d'en faire un service web sur une commune (id de relation). Attention, Je suis contre un tel changement automatisé. Il faudrait qu'il y a un consensus d'abord sur ce sujet. Et je pense qu'il reste trop de problèmes avec la relation associatedStreet qui est aussi critiquée dans d'autres pays. Denis a raison de pointer ses avantages mais il y a aussi des inconvénients majeurs comme la complexité accrue de modifier ces données par des nouveaux arrivants (esayez de déplacer un numéro d'un bâtiment vers un autre ou l'attacher à une autre rue avec iD pour comprendre). L'immense majorité des contributeurs font moins de 10 contributions au total mais ce sont les plus précieux car ils corrigent ce qu'ils reconnaissent comme une erreur (le terrain, toujours le terrain). Alors que la quasi totalité de nos adresses proviennent du cadastre et qu'on y connait un taux d'erreur non négligeable. Faut-il rappeler que l'édition automatique de données OSM doit suivre certaines règles ([1]). Je sais que certains passent déjà outre cette règle et ont déjà massivement modifier les addr en relations (je ne suis pas idiot non plus). Mais j'ai laissé faire tant que c'était des initiatives personnelles. Je pourrais moi aussi faire un script (ou un plugin) qui permettrait ces changements dans le sens inverse (beaucoup plus simple à faire dans ce sens). Ca serait dommage d'en arriver là. Ou même d'en passer par le DWG car j'ai toujours estimé que nous étions assez grands pour nous mettre d'accord tous seuls. Pieren [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licences à réciprocité
2014-11-16 11:40 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Je pense que oui, ce type de licence serait plus adapté à OSM que l'ODbL actuelle. Je pense que non. C'est beaucoup trop compliqué à réaliser dans les faits. J'attends de voir un exemple qui fonctionne sur ce modèle. Comment savoir qui paye et qui ne paye pas ? dans quelle proportion ? une asso ne payera pas, un autoentrepeneur ne payera pas ou peu, une start-up pareil. Un chercheur ne payera pas, mais comment faire si son travail est fait pour un compte privé ? Un grand compte comme Apple payera mais comment savoir si les sommes sont justes, sachant qu'OSM n'est que très partiellement utilisé ? sur quoi sera basé la contribution ? chiffre d'affaire ? impossible sans confidentialité, etc Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap
2014-11-18 12:43 GMT+01:00 Ronan Morin ronan_mo...@hotmail.com: J'avoue ne pas bien voir l'interet de l'état/IGN/La Poste de s'associer avec nous alors qu'on ne leur apportera pas nos données alors qu'on profite de leurs et que notre fichier BAN(O) sera en concurrence avec le leur et théoriquement meilleur(à terme, avec les infos de la BAN(O) plus les corrections OSM, on aura une base plus précise). Maintenant je constate qu'il n'y a que des avantages pour nous vu qu'on aura plus de données, de la visibilité pour OSM, un guichet unique pour la remontée des erreurs et le droit de publier notre BAN(O) dans notre licence... Le terme d' association est sans doute abusif. Ils n'ont pas besoin d'OSM. Mais je suppose que ça fait mieux sur la photo. Comme ça, ils peuvent dire que la société civile est impliquée. Le seul truc positif, c'est qu'ils vont veiller à ce que ces données soient dans une license compatible pour OSM. Et c'est déjà très bien (on aurait pu avoir pire). Sinon, pour revenir au diagramme, je me dis qu'en France, on a quand même un certain talent pour faire compliquer quand on pourrait faire beaucoup plus simple. On essaie une nouvelle fois de ménager tout le monde et on sort une organisation de type raffinerie, avec le risque que ça ne fonctionne pas. Mais bon, il faut dire que dans le domaine des usines à gaz, le nouveau directeur de l'IGN est à bonne école. Grâce à vos articles, je découvre qu'il était le principal technocrate impliqué dans le naufrage de l'ecotaxe... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Non respect des conditions d'utilisation d'OSM
2014-11-17 14:33 GMT+01:00 Arnaud Vandecasteele arnaud@gmail.com: Avez-vous une procédure type pour ce genre de cas ? Une procédure est détaillée ici: https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution Il faut surtout contacter les responsables et leur signaler le problème. La plupart des cas se résolvent comme ça. Ca n'est pas mal intentionné mais juste de l'ignorance. Ce site a un forum et une page de contact. C'est donc plus facile. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap
2014-11-18 16:30 GMT+01:00 Yves Pratter yves.prat...@gmail.com: J’espère que coté OSM on ne saisira plus d’adresses, mais que les contributeurs le feront coté BAN ? C’est possible techniquement de mettre un « filtre » sur le serveur OSM pour empêcher les modifications d’adresses en France et ne laisser passer que celles qui viendraient de la BAN ? Comment envisagez vous le passage des données de la BAN vers OSM ? Non, on ne peut empecher quiconque de modifier des adresses dans OSM. Après, il faudra comparer entre BAN et OSM en continue. Si c'est de nouvelles adresses par exemple (absentes de BAN), il faudrait inciter le contributeur a faire une double contribution. Si c'est un changement (différent de BAN), ça peut aussi être une correction d'une véritable erreur qu'il faudrait vérifier individuellement. Ou alors, mais là, je pense tout haut, OSM-fr pourrait mettre en place un éditeur en ligne, genre iD, qui accepterait les contributions adresses en double licenses et qui serait directement versées dans OSM et soumises à BAN (en espérant qu'ils mettent en place une API ouverte mais là, j'ai des doutes). Tans que le BAN-unique-id ne serait pas dans OSM, on considèrerait la contribution OSM dans un statut à valider. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rapprochement IGN / La Poste / OSM-FR sur la Base Adresse Nationale
2014-11-14 18:53 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: - diffuser ces données auprès des utilisateurs selon des licences adaptées à leurs besoins respectifs (licence libre ODBL, licence avec repartage des bases dérivées et licence payante). J'ai du mal à saisir comment les mêmes données peuvent être publiées sous des licences différentes. Mais l'article du monde ([1]) donne une piste: Les licences de réutilisations de cette base d'adresses à laquelle collaboreront donc l'IGN, La Poste et OSM deviennent double : une licence gratuite qui permet à n'importe qui de la réutiliser sous condition de repartage et une licence payante qui permet de bénéficier de données supplémentaires et de la sécurité juridique promise par l'IGN et La Poste. Reste à savoir ce que recouvre ces données supplémentaires payantes. Uniquement la partie nominative, j'espère. Pieren [1] http://data.blog.lemonde.fr/2014/11/14/base-dadresse-union-de-raison-entre-lign-et-openstreetmap/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doubles licences...
2014-11-15 12:45 GMT+01:00 Ronan Morin ronan_mo...@hotmail.com: Si j'ai tout bien saisi, on va redistribuer BAN(O) gratuitement sous licence libre (odbl) une base à laquelle on ne contribue pas et qui sera vendue en parallèle par l'IGN et/ou La Poste. En plus ce ça, nous allons pomper les infos de la BAN(O), les inclure et les corriger dans OSM. Je ne sais pas si c'est une critique d'OSM ou du système de double licence choisi. Concernant OSM, on a plein de sources maintenant et qui sont corrigées par les contributeurs. A charge ensuite des autres acteurs de comparer leurs bases de données avec OSM et à se poser des questions là où OSM a une divergence. Donc a priori, sur le long terme, nous devrions pouvoir fournir gratuitement et librement la même base que l'IGN/La Poste, mais améliorée grâce à OSM... Indirectement. BAN ne pourra pas exploiter directement les contributions OSM (qu'il ne pourrait redistribuer dans son système de double license). Un mécanisme séparé sera nécessaire parce que les contributeurs devront accepter les termes des deux licenses. Par contre, BAN pourrait chercher à comparer son travail au nôtre et vérifier lorsque les contributeurs OSM modifient des données adresses (un mécanisme qu'on devra probablement aussi mettre en place de notre côté). Il faut quand même comprendre que la majeur partie des remontées seront faites par les communes qui ont parfois bien du mal à se faire entendre par les institutionnels. Pour les simples citoyens, le plus simple sera de passer par sa mairie pour faire corriger une erreur. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doubles licences...
2014-11-15 14:19 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Comparer des données X avec les données OSM pose aussi problème au niveau licence. Ce qui est dans OSM ne peut pas servir à la BAN, les contributions doivent donc être captée en amont. J'étais un peu plus subtil que ça ;-) Je pense que rien n'empêche de comparer deux jeux de données et d'ensuite inspecter soi-même sur place voir qui a raison. La source de l'information n'est pas OSM. Mais bon, c'est un peu border-line, c'est vrai. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retour sur la véloroute Véloscénie dans OSM
Merci pour ce retour très intéressant. Il semble que la plupart de ces itinéraires soient d'abord créés à partir de cartes, genre office du tourisme et que les retours de terrain dans OSM ne soient que partiels, surtout pour les longs trajets. Je trouve juste que ces relations actuellement dans OSM manquent de tags. On ne sait pas d'où viennent ces itinéraires (sans faire de recherches). Il faudrait en indiquer la source dans la relation (tag source). Et lorsque certaines parties sont affectées par des travaux, il faudrait aussi l'indiquer dans la relation avec un tag note par exemple. On peut encore utiliser le tag description pour birèvement décrire l'itinéraire (tout le monde n'a pas le dépliant de l'office du tourisme devant les yeux ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base officielle et libre des Codes Postaux
2014-11-14 12:33 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Dans le cadre de la semaine de l'innovation publique, ce soir à 17h au 104 à Paris sera signé un accord sur la Base Adresse Nationale entre Ca, c'est un scoop ! J'attend de voir la signature avant d'y croire tellement c'est incroyable. Ca fait plus de 10 ans que rien ne bougeait de ce côté-là. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Indiquer pont fermé d'un côté?
2014-11-13 13:38 GMT+01:00 Shohreh codecompl...@free.fr: Tu peux mettre simplement un access=no sur le pont. Après, tu peux peaufiner en ajoutant un noeud à l'endroit exact où se trouve la fermeture et y indiquer la nature de cette fermeture (barrière, chaîne, bollards, etc) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Indiquer pont fermé d'un côté?
2014-11-13 13:51 GMT+01:00 Yves Pratter yves.prat...@gmail.com: rajoutant éventuellement access:foot=no… Ouhla, attention de ne pas enduire les nouveaux en erreurs. Le bon tag est foot=no et non access:foot=no. Comme le access=no interdit déjà tout accès, d'autres tags access ne sont pas nécessaires. Pour le cas où le passage serait temporairement possible pour les piétons, on peut mettre access=no + foot=yes. Il faut aussi faire attention au caractère temporaire d'une interdiction. En général, on essaye d'éviter de mettre des infos trop temporaires dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Indiquer pont fermé d'un côté?
2014-11-13 14:28 GMT+01:00 Yves Pratter yves.prat...@gmail.com:
Je me suis basé sur ça :
no No access for the general public. Consider using additional access:*=*
tag(s) to indicate who can use the element (e.g., if only specific transport
modes allowed).
Le wiki utilise un template bizarre {{Tag|access|subkey=*}} qui
génère ce texte. Je l'ai enlevé sinon ça complique inutilement les
choses.
Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] State of the Map US 2015 in New York, NY, June 6-8
On Tue, Nov 11, 2014 at 5:41 PM, Randy Meech randy.me...@gmail.com wrote: It's that the US org has a demonstrated track record of running large conferences very well, and it seemed like a better partner for this. I'm sure other countries can organize large conferences as well. The location inside the country is more important than the country itself (all large conferences have the same needs). For context, during this submission process the Buenos Aires event didn't post a schedule until the last minute, had sponsorship issues with logos not correct, not up on time, etc. For such issues, I would expect some support from the foundation. To my mind, since OSM is a worlwide project, the SOTM's should play like all international events and should happen around the world, not excluding any one. And like football world cup or olympic games, it should target a kind of continents rotation policy and not exclusively Europe or US (idealy). This conference will be very visible and we can't have stuff like that happening, so we opted for the US group. Visible... in US. This is always the same. The conference is mostly visible in the country where it is organized. Your request and arguments sound a bit too much US centric and will probably hurt a large part of the community. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
