Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le lundi 18 février 2013 à 16:29 +0100, Pieren a écrit : 2013/2/18 Christophe Merlet red...@redfoxcenter.org: On a bien compris que quelque soit l'avis des contributeurs francophones au projet tu feras tout ton possible pour aller au bout de ton idée fixe quitte a baratiner les instances internationales. C'est moche. Si c'était une idée fixe, ça fait longtemps que ces relations ne seraient plus dans la base de données. Si c'était pour ne pas tenir compte de l'avis des contributeurs francophones, je n'aurais pas relancé x fois le sujet en essayant de convaincre du bien fondé du problème. Quant à baratiner les instances internationales, les listes de diffusions sont publiques et tu peux aussi y prendre part pour présenter tes arguments (un peu plus développés que je suis contre). C'est sûr que c'est plus facile d'adopter cette posture: http://fr.wikipedia.org/wiki/Singes_de_la_sagesse J'ai déjà exprimé mon avis plus longuement et je n'aime pas radoter. S'il y a un véritable risque juridique avéré, la FFRP le fera savoir en temps et en heure par LRAC. On lui demandera alors de développer ses arguments. La communauté OSM a de son coté tenté de prendre contact formellement avec eux à plusieurs reprises. On est dans notre bon droit. Si je dois défendre mon point de vue devant une autorité, j'y serais, je n'ai pas l'habitude de me cacher derrière mon petit doigt. J'ai déjà eu à répondre plusieurs fois de l'hébergement d'un nœud TOR sur mon serveur, j'assume mes responsabilités et il est toujours en service. Et je ne parle pas de mon miroir wikileaks... Si on prenait au pied de la lettre ton interprétation exagérément élargi des notions de propriétés intellectuelles, on pourrait supprimer la moitié des données d'OSM. Curieusement tu te focalise uniquement sur ces fameux chemins de randonnées :/ Bref, j'estime que tu FUD ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Le rendu se fiche complètement de la superposition des polygones. D'où sort tu ça ? Chaque polygone est traité un à un par mapnik et dessiné indépendamment des autres. Mais ça pour le savoir, il faut avoir utilisé mapnik... Ca serait bien de vérifier avant d'écrire n'importe quoi et comme d'habitude quand tu te trompe à noyer le poisson en rajoutant un fatras de pseudo explications. Le 18 février 2013 16:58, Philippe Verdy verd...@wanadoo.fr a écrit : Non c'est un problème de rendu quand il y a des polygones de même type partiellement superposés (dont l'intersection a une surface non nulle) -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le copyright d'origine française est reconnu au Royaume-Uni à partir du moment où il est valide en France. On a la convention de Berne et des traités internationaux. Qui fait aussi que le droit de la personne reconnu pour les personnes françaises est aussi opposable devant une cour aux Etats-Unis, alors qu'il n'existe pas pour les Américains. De même quand un photographe français prend des photos volées en Angleterre : la publication en France est poursuivie par une plainte recevable au Royaume-Uni (mais qui sera jugée en France : échange des procédures judiciaires : si la France reconnait le litige, le juge au Royaume-Uni prononcera la condamnation et elle sera exécutable en France). De même pour les photos de la Tour Eiffel (bien que visibles depuis un espace public, le critère d'originalité de l'élément essentiel de la photo est bien reconnu comme valide aux USA). Ce n'est pas parce que la Fondation OSM est au Royaume-Uni ainsi que ses serveurs, que le droit français ne peut pas du tout s'y appliquer. Notamment en terme de droit de propriété intelliectuelle puisque les deux pays sont cosignataires d'un traité de coopération et de reconnaissance de leur droit respectif dans ce domaine. Le 18 février 2013 17:18, Eric Marsden eric.mars...@free.fr a écrit : Cette jurisprudence absurde concernant les itinéraires de randonnée s'applique aux juridictions françaises, et donc pas au droit du Royaume Uni, qui – à ma connaissance – n'a pas reconnu de copyright sur les tracés d'itinéraire. Il me semble (sans être avocat) que c'est le copyright anglais et non le droit d'auteur français qui s'applique à la base OSM, tel que distribué sur openstreetmap.org. Détruire des données fort utiles aux randonneurs serait donc une grave erreur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bassins versants
Bonjour, Je viens de remarquer cette entrée dans les journaux utilisateurs : http://www.kompf.de/gps/rivermap.html Ou comment _ extraire les données (filaires) relatives aux cours d'eau d'un extrait Geofabrik, _ les analyser https://github.com/skaringa/rivers pour constituer les grands bassins versants, _ et finalement en faire le rendu Les cours d'eau que l'algo n'arrive pas à rattacher à un bassin versant sont affichés en gris. C ela permet de mettre en évidence les défauts de connexion dans le filaire des cours d'eau Ca a l'air sympa, à première vue. Je ne sais pas si ce serait facilement transposable à la France -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration Inventaire régional Pays de la Loire
Le 18 févr. 2013 à 16:59, Pieren a écrit : 2013/2/18 ades_...@orange.fr ades_...@orange.fr: Ça pourrait donc donner (pour une ferme à Guérande) ref=IA44003599 historic (ou building) =ferme historic:date=Temps modernes ; 17e siècle (?) ; 19e siècle ; 20e siècle source=(c) Région Pays de la Loire - Inventaire général, 2005 (Le Boeuf François ; Durandière Ronan auteurs) 'historic' ne remplace pas 'building' mais se combine. Le tag 'building' renseigne la typologie et 'historic' le caractère historique: http://wiki.openstreetmap.org/wiki/Building http://wiki.openstreetmap.org/wiki/Historic noté Pour 'historic:date', je ne comprends pas si c'est la date de contruction ou une période ou époque. Dans le premier cas, il y a déjà: http://wiki.openstreetmap.org/wiki/Key:start_date pas forcement pertinent, date rarement connue, et impossible a extraire facilement de la base (peut être contenue dans la notice historique de la fiche, mais au milieu d'un texte de env 4000 signes.) sinon il y a ces 3 propositions (peu usitées): http://wiki.openstreetmap.org/wiki/Key:historic:civilization Pas trop pertinent non plus, on est plus largement dans l'interprétation plus que dans l'objectivité http://wiki.openstreetmap.org/wiki/Key:historic:period http://wiki.openstreetmap.org/wiki/Key:historic:era Les deux champs sont faciles à compléter, suffit de découper leur champ datation de l'oeuvre. Néolithique; Antiquité ; Moyen Age; Epoque Moderne et Epoque contemporaine pour le tag historic:period . Pour le tag historic:era, c'est simple à modifier, 20e siècle =20th century, en oubliant les notions de début, moitié quart, pas forcement nécessaires dans OSM. Est-ce que la traduction du siècle et des périodes est nécessaire ? reste la question du tag d'un nœud ou d'une surface ? dans le cas d'un nœud ça fera comme pour les postes ou écoles et on n'aura pas de conflit avec les tags déjà porté sur le bâti mais un complément. Normalement le point indiqué dans la bas est le centroïd du bâtiment. Ça me plait moins que de tagger la surface mais, dans ce cas, quid des bâtiments déjà renseignés avec le tag historic= ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Le 18 février 2013 17:27, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu se fiche complètement de la superposition des polygones. D'où sort tu ça ? Chaque polygone est traité un à un par mapnik et dessiné indépendamment des autres. Mais ça pour le savoir, il faut avoir utilisé mapnik... PAs immédiatement non. OSM est d'abord converti en polygone GIS. C'est lors de cette conversion qu'on détecte les intersections. Et ce n'est pas parceque dans OSM on n'a que des polygones simples que cela ne crée pas des polygones composés dans le schéma GIS, à partir du moment où ils ont des intersections entre eux : c'est le but de l'extraction des features que de déterminer les intersections, fusionner les segments communs quand il y en a (par paire pour les éliminer ensuite quand ils ont des tags communs, afin de rechercher les bordures de polygones à garder), et recréer des polygones GIS valides (avec plus de contraintes que dans OSM). Ca serait bien de vérifier avant d'écrire n'importe quoi et comme d'habitude quand tu te trompe à noyer le poisson en rajoutant un fatras de pseudo explications. Je ne noie pas le poisson. C'et toi qui réagit n'importe comment ici et répond n'importe quoi ici juste pour avoir raison ! L'anomalie était explicable par un défaut dans la base, même si ce n'était pas évident à voir. Et j'ai bel et bien trouvé des problèmes de géométrie dans la base, qui sont liés à des intersection de surfaces non nulles et à la création de polygones invalides dans l'export GIS, qui disparaissent alors du rendu. Le premier problème étant bien décrit dans le schéma que j'ai posté plus précisément avec les 2 segments en exemple. On était bien dans ce cas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 18 février 2013 17:33, Ab_fab gamma@gmail.com a écrit : Ou comment _ extraire les données (filaires) relatives aux cours d'eau d'un extrait Geofabrik, _ les analyser https://github.com/skaringa/rivers pour constituer les grands bassins versants, _ et finalement en faire le rendu Il y deux approches : - topologique - relationnelle Les cours d'eau que l'algo n'arrive pas à rattacher à un bassin versant sont affichés en gris. C ela permet de mettre en évidence les défauts de connexion dans le filaire des cours d'eau Ca a l'air sympa, à première vue. Je ne sais pas si ce serait facilement transposable à la France On à déjà deux outil, non graphique pour faire ça, suivant deux approches différentes : - http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la sly) - http://suivi.openstreetmap.fr/cours-eau/suivi-affluents.html (à la fred (moi)) Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Le 18 février 2013 17:38, Philippe Verdy verd...@wanadoo.fr a écrit : Le 18 février 2013 17:27, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu se fiche complètement de la superposition des polygones. D'où sort tu ça ? Chaque polygone est traité un à un par mapnik et dessiné indépendamment des autres. Mais ça pour le savoir, il faut avoir utilisé mapnik... PAs immédiatement non. OSM est d'abord converti en polygone GIS. C'est lors de cette conversion qu'on détecte les intersections. Absolument pas (où se trouve le code qui fait ça ?). Il n'y a pas de détection faite pas osm2pgsql à ce niveau ni ailleurs. Deux polygones 'building' sont totalement distincts et traités séparément et pas combinés dans le schéma GIS. Ils peuvent se recouvrir autant qu'ils veulent, ça ne posera de problème à personne dans la chaine de rendu mapnik. La preuve ? Et en image en plus ! http://osmose.openstreetmap.fr/fr/map/?zoom=18lat=50.75609lon=3.24279layers=BFFTitem=0level=1,2,3 http://osmose.openstreetmap.fr/fr/map/?zoom=18lat=48.10503lon=-1.67526layers=BFFTitem=0level=1,2,3 Les deux polygones de bâti se recouvrent un tout petit peu dans le premier cas, comme tu le décrit, plus franchement dans le second, mais ils sont bien rendus car osm2pgsql et mapnik se contrefichent de ces chevauchements. Il y a d'innombrables bâtiments chevauchants en France (cadastre) et sûrement ailleurs et cela ne pose pas de problème au rendu... le cas soulevé ici est autre et ton explication n'est pas la bonne. Dernier message pour moi sur ce sujet. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration Inventaire régional Pays de la Loire
Le 18 février 2013 17:38, ades_...@orange.fr ades_...@orange.fr a écrit : Le 18 févr. 2013 à 16:59, Pieren a écrit : 2013/2/18 ades_...@orange.fr ades_...@orange.fr: Ça pourrait donc donner (pour une ferme à Guérande) ref=IA44003599 historic (ou building) =ferme historic:date=Temps modernes ; 17e siècle (?) ; 19e siècle ; 20e siècle source=(c) Région Pays de la Loire - Inventaire général, 2005 (Le Boeuf François ; Durandière Ronan auteurs) 'historic' ne remplace pas 'building' mais se combine. Le tag 'building' renseigne la typologie et 'historic' le caractère historique: http://wiki.openstreetmap.org/wiki/Building http://wiki.openstreetmap.org/wiki/Historic noté Pour 'historic:date', je ne comprends pas si c'est la date de contruction ou une période ou époque. Dans le premier cas, il y a déjà: http://wiki.openstreetmap.org/wiki/Key:start_date pas forcement pertinent, date rarement connue, et impossible a extraire facilement de la base (peut être contenue dans la notice historique de la fiche, mais au milieu d'un texte de env 4000 signes.) sinon il y a ces 3 propositions (peu usitées): http://wiki.openstreetmap.org/wiki/Key:historic:civilization Pas trop pertinent non plus, on est plus largement dans l'interprétation plus que dans l'objectivité http://wiki.openstreetmap.org/wiki/Key:historic:period http://wiki.openstreetmap.org/wiki/Key:historic:era Les deux champs sont faciles à compléter, suffit de découper leur champ datation de l'oeuvre. Néolithique; Antiquité ; Moyen Age; Epoque Moderne et Epoque contemporaine pour le tag historic:period . Pour le tag historic:era, c'est simple à modifier, 20e siècle =20th century, en oubliant les notions de début, moitié quart, pas forcement nécessaires dans OSM. Est-ce que la traduction du siècle et des périodes est nécessaire ? reste la question du tag d'un nœud ou d'une surface ? Si on a l'emprise du bâtiment en question, on taggue le polygone, c'est une information plus riche qu'un simple nœud. dans le cas d'un nœud ça fera comme pour les postes ou écoles et on n'aura pas de conflit avec les tags déjà porté sur le bâti mais un complément. Euh... doit-on comprendre que cela ne te pose pas de problème d'avoir un tag sur le polygone doublé sur un nœud ? C'est à éviter et c'est signalé par osmose comme erreur (à raison). Normalement le point indiqué dans la bas est le centroïd du bâtiment. Ça me plait moins que de tagger la surface mais, dans ce cas, quid des bâtiments déjà renseignés avec le tag historic= ? Justement, le centroid c'est une information plus pauvre que l'emprise du bâtiment complet. Connaitre le X/Y du château de Versailles c'est quand même moins sexy que de montrer sur une carte sa forme exacte. Le centroid, on peut toujours le recalculer si on veut appauvrir l'info. Si il y a déjà un historic=* sur le bâtiment, on le complètera avec les tags supplémentaires, mais ça ne doit pas venir en conflit, ou alors il y a un souci. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18 février 2013 17:20, Christophe Merlet red...@redfoxcenter.org a écrit : Bref, j'estime que tu FUD ! Fear : On ne peut pas dire que la discussion se déroule sous grosse tension. Est-ce que la suppression va remettre en cause des services s'appuyant sur ces itinéraires OSM ?. J'aimerai bien connaitre le nb de kilomètres de relation à supprimer (sachant que les chemins eux-même ne sont pas concernés) Uncertainty : On sait que la FFRP a déjà ester en justice contre un éditeur reproduisant les itinéraires, et qu'elle a gagné. Certain ! Doubt : aucun avis judique un minimum éclairé n'a autorisé les GR dans OSM. Si le doute c'est le silence de la fédé, alors le doute est de leur côté ! Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Affiche pour une cartopartie
Bonjour, Existe-t-il des modèles (format libre, de préférence) de fichiers pour créer une affiche pour une cartopartie ? Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour Le 18/02/2013 14:13, Jean-François Gaffard a écrit : les itinéraires qui ont plus de 70 ans d'existence sans avoir été modifiés riquent d'être peu nombreux, Non ? *Sans avoir été modifié* : oui Est-ce que la modification d'une partie d'un GR rend _nouveau_ au sens droit d'auteur l'ensemble du GR ? -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Il y avait aussi d'autres problèmes que le chevauchement partiel de batiments normalement mitoyens. En particulier des relations en doublon, certaines partiellement taguées sur les chemins, d'autres dans les relations; et des membres avec des layers différents. Il est fort possible que le bâtiment manquant dans tout ça dispariassait sous un autre layer (il y avait aussi plusioeurs niveaux superposés entre farm, farmyard, forest Le tout dans le même layer 0 par défaut. Et au delà de cela un des batiments dessinés n'était pas fermé lui-même (je pense que se fermeture empruntait un chemin du batiment voisin, lequel se retrouvait alors ouvert et non dessiné). J'ai démélé ce tas de fils. Maintenant c'est vrai avec des multipolygones partout jusqu'à ce que ça colle (et non plus des polygones simples). Il y avait aussi des tas d'erreurs de validation même dans JOSM, que j'ai réglées aussi. Ce que fait la conversion OSM vers GIS quand il y a des tas de problèmes, comme ça, et qu'il essaye de recoller les morceaux n'est pas garanti de produire toujours un résultat visible, et cela ne m'étonne donc pas que certaines choses étaient tracées ou non. Dans le cas cité par Hélène concernant les riverbank non tracées, à chaque fois que j'ai regardé il y avait bien un problème de géométrie à la base, même si ce n'était pas immédiatement sur le polygone manquant lui-même. Il y a un effet de propagation des erreurs sur les polygones voisins quand la conversion OSM vers GIS tente de recoller les morceaux selon les modèles de représentation utilisés. La conversion ne fait pas que prendre un polygone OSM poir en faire un polygone GIS. Même un polygone OSM simple doit être souvent redécoupé, réorienté, et il faut aussi recalculer les zones internes ou externes et signaler ce qui ne corespond pas à la base (car il y a alors sans doute un autre polygone englobant ouvert (il y avait aussi le cas ici dans une grande zone farm englobant le tout, et entre deux zones résidentielles internes dans cette farm qui possédaient elles aussi des intersections mutuelles): Enfin il restait des segments parasites (invisibles dans JOSM sauf si on les sélectionne un par un avec ALT+clic mais bel et bien superposés aux contours des bâtiments, avec un nombre pair de superspositions, ces segments s'annulent entre eux). Ce que fait ensuite Mapnik (qui travaille sur les polygnes GIS), on s'en fiche, le problème était avant, lors de l'export OSM et la conversion vers GIS. Le 18 février 2013 18:04, Christian Quest cqu...@openstreetmap.fr a écrit : Le 18 février 2013 17:38, Philippe Verdy verd...@wanadoo.fr a écrit : Le 18 février 2013 17:27, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu se fiche complètement de la superposition des polygones. D'où sort tu ça ? Chaque polygone est traité un à un par mapnik et dessiné indépendamment des autres. Mais ça pour le savoir, il faut avoir utilisé mapnik... PAs immédiatement non. OSM est d'abord converti en polygone GIS. C'est lors de cette conversion qu'on détecte les intersections. Absolument pas (où se trouve le code qui fait ça ?). Il n'y a pas de détection faite pas osm2pgsql à ce niveau ni ailleurs. Deux polygones 'building' sont totalement distincts et traités séparément et pas combinés dans le schéma GIS. Ils peuvent se recouvrir autant qu'ils veulent, ça ne posera de problème à personne dans la chaine de rendu mapnik. La preuve ? Et en image en plus ! http://osmose.openstreetmap.fr/fr/map/?zoom=18lat=50.75609lon=3.24279layers=BFFTitem=0level=1,2,3 http://osmose.openstreetmap.fr/fr/map/?zoom=18lat=48.10503lon=-1.67526layers=BFFTitem=0level=1,2,3 Les deux polygones de bâti se recouvrent un tout petit peu dans le premier cas, comme tu le décrit, plus franchement dans le second, mais ils sont bien rendus car osm2pgsql et mapnik se contrefichent de ces chevauchements. Il y a d'innombrables bâtiments chevauchants en France (cadastre) et sûrement ailleurs et cela ne pose pas de problème au rendu... le cas soulevé ici est autre et ton explication n'est pas la bonne. Dernier message pour moi sur ce sujet. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour Le 18/02/2013 14:01, Jean-François Gaffard a écrit : les itinéraires de randonnées sont une oeuvre de l'esprit propriété de la FFRP. D'après ce que j'ai compris, il semblerait que le propriétaire ne serait pas la Fédération, mais l'association ayant demandé l'agrément du parcours en sentier à la fédération. -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Chaque fois que l'éclairage de la Tour Eiffel est modifié, l'ensemble obtenu est nouveau. Cela pourrait aussi s'appliquer aux jardins ou aux bassins en dessous. Chaque année modèle d'un véhicule est une nouveauté aussi même si peu de choses changent dans l'ensemble. Seul l'original non modifié n'a pas d'extension de durée des droits qui s'y attachent. Maintenant la plupart des changements sur les GR ne surviennent pas du fait de l'asso qui a promu ce GR : ce sont des modifications faites par les propriétaires ou la collectivité. Ce qui constituerait une nouveauté serait quand l'asso décide de changer l'itinéraire à cause de ces changements, pour prendre une autre voie (par exemple l'ancien chemin est maintenant bloqué aux cyclistes ou piétons par le passage d'une route rapide, ou bien l'ancien chemin est interdit d'accès car devenu trop dangereux ou inutilisable ou partiellement détruit, ou bien un propriétaire rompt l'accord et décide de fermer l'accès à sa propriété par son chemin privé et pose une barrière ou un panneau, ou bien le domaine traversé public fait l'objet d'un programme de protection de certaines espèces, par exemple une plage devenant interdite pour laisser s'y attrouper des phoques ou veaux de mer, ou pour la reproduction des crabes, ou pour la protection des fragiles plantations sur des dunes). Le 18 février 2013 18:35, David Crochet david.croc...@online.fr a écrit : Bonjour Le 18/02/2013 14:13, Jean-François Gaffard a écrit : les itinéraires qui ont plus de 70 ans d'existence sans avoir été modifiés riquent d'être peu nombreux, Non ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Je reviens encore une fois sur ces name qu'on trouve sur des way uniquement utilisé par des boundary. J'essaye de faire un rendu propre sur les limites administratives et découpages courants*, mais ce name artificiels, arbitraires et de confort viennent vraiment polluer le rendu. De plus, ils sont particulièrement difficile à masquer. De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? 2) remplacer ces name par note ou description ? Dans quel ordre ? opère-t-on ? * voir ici ce que ça donne: http://tile.openstreetmap.fr:13080/?lat=48.8286lon=2.38914zoom=16layers=0B -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Encore un revert svp
Bonsoir, Il s'agit de celui-ci: http://www.openstreetmap.org/browse/changeset/15078511 (désolé mais je ne comprends rien à ce que tu as été fait sur les landuse). Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour Autant je suis d'accord pour la Tour Eiffel puisque c'est l'ensemble qui est modifié, mais bon, je vois mal le fait qu'à Pouziou-les-trois-clochers le GR est modifié que _l'ensemble_ est soumis à un nouveau droit. Ce n'est que mon point de vue. -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 18/02/2013 17:49, Frédéric Rodrigo a écrit : - http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la sly) bonjour Comment est généré cette page? Le canal de Bourgogne existe bien dans osm http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=2102783 d'autre cours d'eau figuarnt dans OSm avec leur ref:sandre n'existe même pas dans la page cordialement Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Ah mais après on ne verra plus les tirets cadratin ;-) - Mail original - De: Christian Quest cqu...@openstreetmap.fr À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Lundi 18 Février 2013 18:55:38 Objet: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III) Je reviens encore une fois sur ces name qu'on trouve sur des way uniquement utilisé par des boundary. J'essaye de faire un rendu propre sur les limites administratives et découpages courants*, mais ce name artificiels, arbitraires et de confort viennent vraiment polluer le rendu. De plus, ils sont particulièrement difficile à masquer. De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? 2) remplacer ces name par note ou description ? Dans quel ordre ? opère-t-on ? * voir ici ce que ça donne: http://tile.openstreetmap.fr:13080/?lat=48.8286lon=2.38914zoom=16layers=0B -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Qu'est-ce qui ne va pas dedans ? Tout est bon et valide (ce qui n'était pas le cas avant). Et c'est conforme à ce qui est documenté sur la façon de faire. Je n'ai fait que le strict nécessaire en chargeant le batiment qui dispaissait, et en remontant de proche en proche sur les erreurs de validations que cela entrainait (car ces bâtiments touchent aussi des landuse, et c'est quelquepart dans ce bazar qu'était le problème ; je n'ai rien envoyé tant que le validateur signalait un problème). Le 18 février 2013 18:59, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Il s'agit de celui-ci: http://www.openstreetmap.org/browse/changeset/15078511 (désolé mais je ne comprends rien à ce que tu as été fait sur les landuse). Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Le 18/02/2013 16:26, Christian Quest a écrit : Ca ressemble à une désynchro de la base osm2pgsql qui se remet à jour lorsque l'on modifie l'objet vu ce qu'a signalé Helène sur une rivière. C'était déjà l'avis de Lapinos (et c'était bien la Garonne). Et c'était dans ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/031063.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Ce que je veux dire est que ce qui constitue l'ensemble original dans le sentier c'ets le fait de le taguer comme un ensemble distinct et bien identifié. Si on n'a qu'un réseau de sentiers interconnectés, il n'y a plus de trajets et plus de problèmes (et les baladeurs prendront alors ces sentiers dans l'ordre qu'ils voudront, sur place ils verront le balisage du GR mais on n'est pas obligé de le mettre en tant que tel dans OSM). Maintenant c'est vrai qu'on n'a pas besoin d'être plus prudent que nécessaire : ces balises sont faites pour être visibles par tout le monde et on ne pourra jamais empêcher que celles-ci apparaissent de façon disparâtre ça et là sur la carte, au gré des balades, pour finalement le snetier soit reconstitué (mais sans garantie sur la cohérence de date entre les segments : ce n'est donc pas un import brut des données du GR depuis la base privée). Bref laisson cela et attendons que la FRPP se manifeste puisqu'on a les outils si nécessaires pour enlever si réellement ça les gène (de la même façon qu'une entrerpise qui ne voudrait pas être citée dans la carte pourrait aussi en faire la demande). La procédure de réglement amiable devrait suffire (et sera en fait assez rapide). On n'est pas ici dans le domaine de la protection de la vie privée (dont on doit tenir compte à priori), puisque on est en terme de droit commerciaux ici, aucun litige n'est recevable sans tentative de réglement amiable, d'autant plus que la FFRP a déjà été contactée à de nombreuses reprises et ne peut pas tellement feindre d'ignorer la question même si elle n'a jamais voulu répondre directement. Le cas cité du procès passé était lié à un usage commercial exclusif et à une tentative de réglement amiable qui n'avait pas abouti, alors il y avait matière à justice, mais on n'en est pas là. D'autant plus qu'on ne dispose pas de leur base de données et que les données mises dans la base relèvent de collectes individuelles très fragmentaires à diverses périodes, et que notre balisage est assez générique pour admettre des données de sources diverses ne dépendant pas non plus seulement de la FFRP (par exemple des clubs sportifs, des collectivités via leur services de promotion touristique, des sociétés de chasse, des assos de protection de la nature, et diverses autres classifications d'origine non française comme l'Unesco ou l'Union européenne, ou des assos d'autres pays qui visitent la France et peuvent avoir leurs propres critières pour signaler un trajet remarquable...) Le 18 février 2013 18:59, David Crochet david.croc...@online.fr a écrit : Bonjour Autant je suis d'accord pour la Tour Eiffel puisque c'est l'ensemble qui est modifié, mais bon, je vois mal le fait qu'à Pouziou-les-trois-clochers le GR est modifié que _l'ensemble_ est soumis à un nouveau droit. Ce n'est que mon point de vue. -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM-FR: communiqué de presse envoyé !
Le 18/02/2013 11:01, Christian Quest a écrit : Envoyez aux médias lyonnais... Il est disponible ici: http://openstreetmap.fr/communique-20130218 Tout le monde peut contribuer au projet en ajoutant des informations manquantes ou erronées, Ajouter des informations erronées ? Fichtre. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OpenData Communauté Urbaine de Bordeaux en ODbL
Bonjour, Une brève pour annoncer que l'OpenData de la Communauté Urbaine de Bordeaux n'est plus sous APIE mais ODbL. http://data.lacub.fr/license On va pouvoir, enfin, y aller. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenData Communauté Urbaine de Bordeaux en ODbL
Bonjour Fred, Le 18/02/2013 20:26, Frédéric Rodrigo a écrit : Une brève pour annoncer que l'OpenData de la Communauté Urbaine de Bordeaux n'est plus sous APIE mais ODbL. Bravo ! -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
2013/2/18 Christophe Merlet red...@redfoxcenter.org: Bref, j'estime que tu FUD ! Bien sûr, je FUD. Et la première chambre de la cour de cassation, elle FUD aussi en juin 1998: http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT07041272fastReqId=109256579fastPos=1 la cour d'appel n'a pas donné de base légale (...) pour rejeter l'action en contrefaçon dirigée par la Fédération française de randonnée pédestre (FFRP) contre la société xxx. Et la cour d'appel de Grenoble, en octobre 2001, elle FUD aussi: http://droit-finances.commentcamarche.net/jurisprudence/cour-d-appel-2/1055486-cour-d-appel-de-grenoble-du-31-octobre-2001-01-01470 Un itinéraire de randonnée, s'il résulte d'une création originale, révélatrice de la personnalité de son concepteur, est une oeuvre de l'esprit juridiquement protégée. S'il y a un véritable risque juridique avéré, la FFRP le fera savoir en temps et en heure par LRAC. Et c'est toi qui payera les frais d'avocats ? La position des contributeurs OSM sur ce genre de question a toujours été de ne pas faire peser de risque juridique sur le projet. Ce n'est pas à OSM de définir de nouvelles jurisprudences. On n'a ni l'armée d'avocats de Microsoft, ni les moyens de mediawiki. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Tu expliques par exemple ce charcutage: http://www.openstreetmap.org/browse/relation/2769549 Je ne suis pas loin de penser que c'est du vandalisme... Je maintiens ma demande de revert. Romain Le 18 février 2013 19:49, Philippe Verdy verd...@wanadoo.fr a écrit : Qu'est-ce qui ne va pas dedans ? Tout est bon et valide (ce qui n'était pas le cas avant). Et c'est conforme à ce qui est documenté sur la façon de faire. Je n'ai fait que le strict nécessaire en chargeant le batiment qui dispaissait, et en remontant de proche en proche sur les erreurs de validations que cela entrainait (car ces bâtiments touchent aussi des landuse, et c'est quelquepart dans ce bazar qu'était le problème ; je n'ai rien envoyé tant que le validateur signalait un problème). Le 18 février 2013 18:59, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Il s'agit de celui-ci: http://www.openstreetmap.org/browse/changeset/15078511 (désolé mais je ne comprends rien à ce que tu as été fait sur les landuse). Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 19:49, Philippe Verdy verd...@wanadoo.fr a écrit : Qu'est-ce qui ne va pas dedans ? Tout est bon et valide (ce qui n'était pas le cas avant). Et c'est conforme à ce qui est documenté sur la façon de faire. Je n'ai fait que le strict nécessaire en chargeant le batiment qui dispaissait, et en remontant de proche en proche sur les erreurs de validations que cela entrainait (car ces bâtiments touchent aussi des landuse, et c'est quelquepart dans ce bazar qu'était le problème ; je n'ai rien envoyé tant que le validateur signalait un problème). On ne doit pas avoir le même validateur alors... 37 relations dupliquées, 60 chemins dupliqués, 6 chemins orphelins... ça sent l'upload double tout ça. Et franchement, y'a des endroits où c'est l'art de se compliquer la vie pour rien, comme dessiner un bâtiment sans trou en multipolygone. C'est la nouvelle mode pour les maisons mitoyennes ? Tout en relation multipolygone ? Doit-on mettre à jour les scripts d'extraction du cadastre ? -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
J'ai deux réponses à la question. - la première, en effet, je ne comprends pas l'intérêt, aujourd'hui, d'avoir un name sur un way boundary. (C'est un résidu de l'ancien temps, c'est le relations qui font le travail, avis pas partagé par tous par ici, si je me souviens bien). - la deuxième, qui est la réponse au taggage pour le rendu : tu ne serais pas en train de modifier le taggage pour _ton _rendu ? (je sais, c'est tellement tentant, quand on est dedans… Mais un filtre boundary + not river + not highway + not je ne sais pas quoi d'autre = je ne marque pas le nom ?) JB. Le 18.02.2013 18:55, Christian Quest a écrit : Je reviens encore une fois sur ces name qu'on trouve sur des way uniquement utilisé par des boundary. J'essaye de faire un rendu propre sur les limites administratives et découpages courants*, mais ce name artificiels, arbitraires et de confort viennent vraiment polluer le rendu. De plus, ils sont particulièrement difficile à masquer. De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? 2) remplacer ces name par note ou description ? Dans quel ordre ? opère-t-on ? * voir ici ce que ça donne: http://tile.openstreetmap.fr:13080/?lat=48.8286lon=2.38914zoom=16layers=0B [1] Links: -- [1] http://tile.openstreetmap.fr:13080/?lat=48.8286amp;lon=2.38914amp;zoom=16amp;layers=0B ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Et si on évitait de radicaliser nos points de vue respectifs ? Romain a relancé la FFRP... mais encore faudrait-il se poser la bonne question car là je pense qu'on n'est pas tous sur la même longueur d'onde. Première question: la présence de ces données dans la base OSM Deuxième question: l'utilisation de ces données Si l'une ou l'autre voit une réponse négative à une demande claire faite à la FFRP (si besoin par LRAR), oui, je pense qu'il faudra retirer les données. Mais il faudra aussi sans arrêt aller à leur chasse et faire le ménage car avant que tout les contributeur (y compris les nouveaux) saisissent le problème il pourra circuler beaucoup de peta-octets dans les fibres optiques. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 20:44, Romain MEHUT romain.me...@gmail.com a écrit : Tu expliques par exemple ce charcutage: http://www.openstreetmap.org/browse/relation/2769549 Je ne suis pas loin de penser que c'est du vandalisme... Je maintiens ma demande de revert. Vandalisme ? Qu'est-ce que j'ai détruit ? STRICTEMENT Rien du tout ! J'ai même tenu compte des suppressions de points faites pendant ce temps pour les garder. Je n'ai rien ajouté non plus. Tout est là là où c'était, il n'y a pas plus de noeuds et aucun d'eux n'a bougé. Tous les attributs sont gardés aussi. L'anomalie était sur la composition des polygones, leur chevauchement, les traits superposés (certains inutiles en excédent, utilisés seulement dans une autre relation superposée sans aucun tags). Là tu exagères. Uniquement parce que tu ne comprends pas ce qui est pourtant fait comme ça un peu partout sur la carte. Certes c'est différent de la façon que tu avais fait, mais es-tu propriéaire des données que tu mets ? J4ai juste utilise CTRL+ALT+A pour transformer un polygone fermé en multipolygone, puis scindé les segments superposés communs, puis les ai fusionné. J'ai aussi vérifié lors de la fusion que cela ne fusionnait pas 2 segments de la même relation (sinon il en reste un et cela ne ferme pas: ce cas se produisant pour les polygones mitoyens inclus en inner d'un autre). C'est très basique comme transformation. Et c'est là que j'ai détecté des noeuds qui n'avaient pas été fusionnés et des traits pour rien (sans aucun tag utiisable, jusqu'à 5 superposés au même endroit, dont 2 ou 3 seulement servaient avant, car ces segments ne faisaient en fait partie d'aucun polygone fermé mais étaient des résidus laissés ouverts par la construction partielle d'autres relations jamais terminées et qui faisaient doublon avec les dernières versions utilisables). J'ai gardé tous les ID, les historiques avec car je n'ai fait que des fusions ou scissions. JOSM a fait ça assez facilement. C'est vrai que je ne m'attendais pas à en modifier autant (150 polygones environ alors qu'au départ j'étais partir de 4 ou 5 à problèmes, mais le validateur m'a insiqué d'autres polygones voisins). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM-FR: communiqué de presse envoyé !
Oups ! Le 18 février 2013 20:05, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 18/02/2013 11:01, Christian Quest a écrit : Envoyez aux médias lyonnais... Il est disponible ici: http://openstreetmap.fr/**communique-20130218http://openstreetmap.fr/communique-20130218 Tout le monde peut contribuer au projet en ajoutant des informations manquantes ou erronées, Ajouter des informations erronées ? Fichtre. -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendus Mapnik incompréhensibles
Pour avoir corrigé quelques milliers de bâtiments partiellement superposés, je n'ai jamais vu de cas ou cela faisait disparaitre le bâtiment. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Phillipe, Pour exemple, explique-moi juste celui-ci http://www.openstreetmap.org/browse/relation/2769549 Pourquoi avoir créer un multipolygone en 8 membres avec chacun en rôle outer là où il suffit d'avoir juste un polygone simple où tous les membres sont reliés? Merci. Romain Le 18 février 2013 20:55, Philippe Verdy verd...@wanadoo.fr a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Le 18 février 2013 20:49, JB jb...@mailoo.org a écrit : ** J'ai deux réponses à la question. – la première, en effet, je ne comprends pas l'intérêt, aujourd'hui, d'avoir un name sur un way boundary. (C'est un résidu de l'ancien temps, c'est le relations qui font le travail, avis pas partagé par tous par ici, si je me souviens bien). – la deuxième, qui est la réponse au taggage pour le rendu : tu ne serais pas en train de modifier le taggage pour *ton *rendu ? (je sais, c'est tellement tentant, quand on est dedans… Mais un filtre boundary + not river + not highway + not je ne sais pas quoi d'autre = je ne marque pas le nom ?) Je l'ai fait ce filtre, je ne suis donc plus concerné par le problème, mais c'est se compliquer la vie inutilement pour une raison de confort d'édition que l'on pourrait régler autrement (tag note/description). Le filtre fonctionne plutôt dans l'autre sens avec: name is not null and coalesce(highway, waterway, railway, boundary) != 'administrative' et encore, il ne faudrait l'utiliser que si on a des relations boundary reliées à cet objet... bref, pas mal de complication. Je pensais aux autres réutilisateurs ;) -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Il n'ont pas les mêmes voisins, regarde bien. Les 8 pour lintérieur oui, mais à l'extérieur ce sont des surfaces différentes. Il n'y a aucun trait ni aucun noeud superposé c'est tout. Le 18 février 2013 21:03, Romain MEHUT romain.me...@gmail.com a écrit : Phillipe, Pour exemple, explique-moi juste celui-ci http://www.openstreetmap.org/browse/relation/2769549 Pourquoi avoir créer un multipolygone en 8 membres avec chacun en rôle outer là où il suffit d'avoir juste un polygone simple où tous les membres sont reliés? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 21:07, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'ont pas les mêmes voisins, regarde bien. Les 8 pour lintérieur oui, mais à l'extérieur ce sont des surfaces différentes. Il n'y a aucun trait ni aucun noeud superposé c'est tout. Bref, on n'a pas du tout la même façon de concevoir les polygones. S'il te plait, pourrais-tu annuler ton changeset? J'ai déjà passé pas mal de temps à redessiner les landuse dans ce secteur et j'ai pas vraiment envie de repasser derrière toi... Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 20:47, Christian Quest cqu...@openstreetmap.fr a écrit : Le 18 février 2013 19:49, Philippe Verdy verd...@wanadoo.fr a écrit : Qu'est-ce qui ne va pas dedans ? Tout est bon et valide (ce qui n'était pas le cas avant). Et c'est conforme à ce qui est documenté sur la façon de faire. Je n'ai fait que le strict nécessaire en chargeant le batiment qui dispaissait, et en remontant de proche en proche sur les erreurs de validations que cela entrainait (car ces bâtiments touchent aussi des landuse, et c'est quelquepart dans ce bazar qu'était le problème ; je n'ai rien envoyé tant que le validateur signalait un problème). On ne doit pas avoir le même validateur alors... 37 relations dupliquées Faux. Elles sont dupliquées peut-être sur ton PC qui en a une autre version, mais pas dans la base. , 60 chemins dupliqués Aucun non plus. 6 chemins orphelins... Aucun non plus tu te trompes en comparant à ce que tu as sur ton PC. ça sent l'upload double tout ça. Non, il n'y a eu qu'un seul upload, un seul changeset, qui s'est fermé normalement à la fin. Si c'était en double, ce seul changeset (puisqu'il n'y en a pas d'autres à cet endroit) contiendrait les doublons, ce qui n'est pas le cas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenData Communauté Urbaine de Bordeaux en ODbL
Bonsoir, Frédéric Rodrigo a écrit : Une brève pour annoncer que l'OpenData de la Communauté Urbaine de Bordeaux n'est plus sous APIE mais ODbL. http://data.lacub.fr/license On va pouvoir, enfin, y aller. Comme tu dis ! :) Merci à ceux qui ont œuvré à ce changement qui ne doit certainement rien au hasard. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Moi mon préféré c'est plutôt celui-là: http://www.openstreetmap.org/browse/relation/2769501 Une relation pour 2 way minuscules d'un bout bâtiment. Oh, mais attendez...un bâtiment lui même décrit par... voyons... 1, 2, 3... oui, 8 relations, 34 ways, 96 noeuds, alors qu'il suffit de 0 relations et 9 ways et toujours 96 noeuds pour le décrire tout aussi bien ;) Et pour les doublons qui n'existent pas, en voici juste un échantillon; http://www.openstreetmap.org/browse/relation/2769504 et http://www.openstreetmap.org/browse/relation/2769542 Mais ça doit être que sur mon Mac... bien sûr. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Please help needed! Désolé d'insister mais je rencontre des élus de ce secteur très bientôt... Romain Le 18 février 2013 21:20, Christian Quest cqu...@openstreetmap.fr a écrit : Moi mon préféré c'est plutôt celui-là: http://www.openstreetmap.org/browse/relation/2769501 Une relation pour 2 way minuscules d'un bout bâtiment. Oh, mais attendez...un bâtiment lui même décrit par... voyons... 1, 2, 3... oui, 8 relations, 34 ways, 96 noeuds, alors qu'il suffit de 0 relations et 9 ways et toujours 96 noeuds pour le décrire tout aussi bien ;) Et pour les doublons qui n'existent pas, en voici juste un échantillon; http://www.openstreetmap.org/browse/relation/2769504 et http://www.openstreetmap.org/browse/relation/2769542 Mais ça doit être que sur mon Mac... bien sûr. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Bonsoir, Le 18/02/2013 19:19, f.dos.san...@free.fr a écrit : Ah mais après on ne verra plus les tirets cadratin ;-) - Mail original - De: Christian Quest cqu...@openstreetmap.fr De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Toujours d'accord avec ça. Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? Peut-être ? 2) remplacer ces name par note ou description ? Sûrement Dans quel ordre ? opère-t-on ? Je proposerais bien le 2) dès à présent avec transfert du name=* sur un tag note=*. Pour le 1), je trouve que JOSM est déjà pas mal pourvu, avec l'appartenance des objets indiquée en bas du panneau des propriétés. Encore faut-il y jeter un oeil. Je trouve qu'une action sur la visibilité des relations dans Potlatch aurait sûrement plus d'impact sur la robustesse de ces objets : il est vraiment trop facile de les supprimer / altérer sans s'en rendre compte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18/02/2013 20:39, Pieren a écrit : Et la première chambre de la cour de cassation, elle FUD aussi en juin 1998: http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT07041272fastReqId=109256579fastPos=1 la cour d'appel n'a pas donné de base légale (...) pour rejeter l'action en contrefaçon dirigée par la Fédération française de randonnée pédestre (FFRP) contre la société xxx. Juste au dessus : l'arrêt attaqué énonce que les sentiers de randonnée sont ouverts à tous et que leur figuration sur les cartes de l'IGN démontrait qu'ils étaient dans le domaine public, de sorte que les *sentiers balisés par la FFRP* ne constituaient pas en eux-mêmes des oeuvres de l'esprit ; Cet arrêt concerne les sentiers balisés par la FFRP et date de 1998, à une époque où les GPS ne courraient pas les rues, et les images satellite publiques étaient un rêve de Noël. Dans le cas qui me préoccupe, des fragments de sentiers GR sont parcourus également par les sentiers de randonnées pédestres communaux, et *balisés par l'intercommunalité* ; Et, à mon humble avis, ce que dis cet arrêt de la cour, c'est que l'auteur du balisage peut être considéré comme l'auteur de l'itinéraire. = Les itinéraires que je convoite de faire figurer dans OSM sont les oeuvres de l'esprit de l'intercommunalité (qui les fait baliser par des assos d'insersion) et qui, brave fille, ne mets de copyright nulle part. Il y a convergence aussi avec le sujet de percherie ici : http://forum.openstreetmap.fr/viewtopic.php?f=3t=505#p2389 Bref, les choses changent à grande vitesse, et 1998 s'enfuit ventre à terre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18/02/2013 20:54, Christian Quest a écrit : Et si on évitait de radicaliser nos points de vue respectifs ? Romain a relancé la FFRP... mais encore faudrait-il se poser la bonne question car là je pense qu'on n'est pas tous sur la même longueur d'onde. Première question: la présence de ces données dans la base OSM Deuxième question: l'utilisation de ces données Si l'une ou l'autre voit une réponse négative à une demande claire faite à la FFRP (si besoin par LRAR), oui, je pense qu'il faudra retirer les données. Mais il faudra aussi sans arrêt aller à leur chasse et faire le ménage car avant que tout les contributeur (y compris les nouveaux) saisissent le problème il pourra circuler beaucoup de peta-octets dans les fibres optiques. Il y a dans ce sujet un point qui m'échappe. Depuis la dernière grosse discussion (juin 2012) sur le quasi-même sujet, on a quand même eu du nouveau sur la thématique de violation de copyright avec la suppression des données autour de Valenciennes, données issues de Google. Quand il s'est agit de faire le ménage des données de Cedric007, il n'y avait (dites moi si je me trompe) a peu près aucune voix discordante sur le coeur du débat, à savoir : on fait le ménage des données litigieuses. Ça faisait mal à tout le monde de supprimer un travail manuel assez colossal, mais dès lors que la source était identifiée et avérée (Google), malgré la bonne foi du contributeur en cause, l'issue ne faisait pas de doute. Je ne comprends pas en quoi, sur le sujet des relations décrivant des itinéraires GR dont la propriété intellectuelle revient à la FFRP, on est dans une situation différente. C'est protégé, c'est dans la base, ça n'a en l'état pas à y être faute d'une autorisation formelle. En sauvegardant le contenu en cause dans un fichier, puis en le supprimant de la base, on est réglo, et le jour où la FFRP nous donne le go pour saisir les itinéraires des GR dans OSM (si ce jour arrive...), on se fera un plaisir de ressortir notre fichier. Mais on n'en est pas là. vincent ps. je donne mon avis ici faute d'être à Lyon en fin de semaine ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Je suis occupé mais pour l'instant la carte est correcte, je nettoierai les doublons créés dans la même minute (que je ne m'explique pas) dans un peu plus d'une heure Le 18 février 2013 21:24, Romain MEHUT romain.me...@gmail.com a écrit : Please help needed! Désolé d'insister mais je rencontre des élus de ce secteur très bientôt... Romain Le 18 février 2013 21:20, Christian Quest cqu...@openstreetmap.fr a écrit : Moi mon préféré c'est plutôt celui-là: http://www.openstreetmap.org/browse/relation/2769501 Une relation pour 2 way minuscules d'un bout bâtiment. Oh, mais attendez...un bâtiment lui même décrit par... voyons... 1, 2, 3... oui, 8 relations, 34 ways, 96 noeuds, alors qu'il suffit de 0 relations et 9 ways et toujours 96 noeuds pour le décrire tout aussi bien ;) Et pour les doublons qui n'existent pas, en voici juste un échantillon; http://www.openstreetmap.org/browse/relation/2769504 et http://www.openstreetmap.org/browse/relation/2769542 Mais ça doit être que sur mon Mac... bien sûr. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18/02/2013 21:20, Christian Quest a écrit : Moi mon préféré c'est plutôt celui-là: http://www.openstreetmap.org/browse/relation/2769501 Une relation pour 2 way minuscules d'un bout bâtiment. Oh, mais attendez...un bâtiment lui même décrit par... voyons... 1, 2, 3... oui, 8 relations, 34 ways, 96 noeuds, alors qu'il suffit de 0 relations et 9 ways et toujours 96 noeuds pour le décrire tout aussi bien ;) Et pour les doublons qui n'existent pas, en voici juste un échantillon; http://www.openstreetmap.org/browse/relation/2769504 et http://www.openstreetmap.org/browse/relation/2769542 Mais ça doit être que sur mon Mac... bien sûr. Ou alors sur les système *nix. Je l'ai aussi sur ma machine. C'est fou comme c'est fragile nos ordinateurs. P't-être que je vais devoir passer à Windows pour plus avoir des doublons... J'en ai d'autres, sur ce seul bâtiment : http://www.openstreetmap.org/browse/relation/2769498 et http://www.openstreetmap.org/browse/relation/2769536 http://www.openstreetmap.org/browse/relation/2769485 et http://www.openstreetmap.org/browse/relation/2769523 http://www.openstreetmap.org/browse/relation/2769532 et http://www.openstreetmap.org/browse/relation/2769494 ... Je continue ? Je ne dirai pas ce que je pense de cette façon de cartographier : utilisation de relation où un way suffit, parce que quelqu'un quelque part va encore pleurer qu'on l'insulte lâchement et injustement dans son dos alors que lui ne fait que du bien à la planète. Mais je me doute que vous devinez ce que j'en pense... À mon avis, il a pété un doublon. En fait on devrait garder ce genre de ramassis dans un coin pour montrer ce qu'il ne faut pas faire. Moi, je compte 16 relations (doublons inclus) et 34 chemins (doublons inclus) là où 8 polygones auraient suffi. J'ai rarement vu autant de conneries au m² ! -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 21:57, Vincent Pottier vpott...@gmail.com a écrit : J'ai rarement vu autant de conneries au m² ! Alors revert complet! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18/02/2013 21:55, Philippe Verdy a écrit : pour l'instant la carte est correcte, Quoi ? La carte est correcte ? ou le rendu ? je nettoierai les doublons créés dans la même minute (que je ne m'explique pas) dans un peu plus d'une heure Et tu nettoieras les relations inutiles ? et les ways coupés en 4 pour les mettre dans des multipolygones ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
On 18/02/2013 21:45, Vincent de Chateau-Thierry wrote: Je ne comprends pas en quoi, sur le sujet des relations décrivant des itinéraires GR dont la propriété intellectuelle revient à la FFRP, on est dans une situation différente. C'est protégé, c'est dans la base, ça n'a en l'état pas à y être faute d'une autorisation formelle. J'y vois une différence : - dans le cas des données de Cedric007, il y avait recopie d'informations à partir de la carte Google. - dans le cas des GR et du balisage rouge/blanc, on ne fait que cartographier ce qu'on voit sur le terrain (on ne recopie pas les topo-guides FFRP). Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
J'ai fait mon 1er revert ;) J'espère que tout est revenu comme avant... Romain Le 18 février 2013 22:17, Vincent Pottier vpott...@gmail.com a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18/02/2013 22:19, Jean-Claude Repetto a écrit : On 18/02/2013 21:45, Vincent de Chateau-Thierry wrote: J'y vois une différence : - dans le cas des données de Cedric007, il y avait recopie d'informations à partir de la carte Google. - dans le cas des GR et du balisage rouge/blanc, on ne fait que cartographier ce qu'on voit sur le terrain (on ne recopie pas les topo-guides FFRP). Ça fait une différence sur la manière, ok, mais pas sur le bilan : on a d'un côté des infos propriétaires, non autorisées, dans la base. Et de l'autre aussi. Non ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Il n'y avait strictement rien d'incorrect, visiblement le serveur a créé les mêmes objets deux fois et c'est tombé sur moi, car je n'ai eu strictement aucune erreur. Le 18 février 2013 21:57, Vincent Pottier vpott...@gmail.com a écrit : Le 18/02/2013 21:20, Christian Quest a écrit : Moi mon préféré c'est plutôt celui-là: http://www.openstreetmap.org/browse/relation/2769501 Une relation pour 2 way minuscules d'un bout bâtiment. Oh, mais attendez...un bâtiment lui même décrit par... voyons... 1, 2, 3... oui, 8 relations, 34 ways, 96 noeuds, alors qu'il suffit de 0 relations et 9 ways et toujours 96 noeuds pour le décrire tout aussi bien ;) Et pour les doublons qui n'existent pas, en voici juste un échantillon; http://www.openstreetmap.org/browse/relation/2769504 et http://www.openstreetmap.org/browse/relation/2769542 Mais ça doit être que sur mon Mac... bien sûr. Ou alors sur les système *nix. Je l'ai aussi sur ma machine. C'est fou comme c'est fragile nos ordinateurs. P't-être que je vais devoir passer à Windows pour plus avoir des doublons... J'en ai d'autres, sur ce seul bâtiment : http://www.openstreetmap.org/browse/relation/2769498 et http://www.openstreetmap.org/browse/relation/2769536 http://www.openstreetmap.org/browse/relation/2769485 et http://www.openstreetmap.org/browse/relation/2769523 http://www.openstreetmap.org/browse/relation/2769532 et http://www.openstreetmap.org/browse/relation/2769494 ... Je continue ? Je ne dirai pas ce que je pense de cette façon de cartographier : utilisation de relation où un way suffit, parce que quelqu'un quelque part va encore pleurer qu'on l'insulte lâchement et injustement dans son dos alors que lui ne fait que du bien à la planète. Mais je me doute que vous devinez ce que j'en pense... À mon avis, il a pété un doublon. En fait on devrait garder ce genre de ramassis dans un coin pour montrer ce qu'il ne faut pas faire. Moi, je compte 16 relations (doublons inclus) et 34 chemins (doublons inclus) là où 8 polygones auraient suffi. J'ai rarement vu autant de conneries au m² ! -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 22:29, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y avait strictement rien d'incorrect, visiblement le serveur a créé les mêmes objets deux fois et c'est tombé sur moi, car je n'ai eu strictement aucune erreur. Non juste un modèle de conception à dégouter n'importe quel nouveau contributeur... Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18 février 2013 22:25, Vincent de Chateau-Thierry v...@laposte.net a écrit : Ça fait une différence sur la manière, ok, mais pas sur le bilan : on a d'un côté des infos propriétaires, non autorisées, dans la base. Et de l'autre aussi. Non ? Qu'est-ce qui n'est pas autorisé ? C'est de collecter à partie de leur base de données. Maintenant ce qu'on voit sur le terrain dans le domaine public n'est pas relevé comme une copie de base de données, ce ne sont que des éléments individuels qui, eux, n'ont aucune protection. Sinon tous les journaux qui ne font que citer le simple nom GR20 ou même cette liste elle-même est hors la loi juste en parlant des GR. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 22:37, Romain MEHUT romain.me...@gmail.com a écrit : Le 18 février 2013 22:29, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y avait strictement rien d'incorrect, visiblement le serveur a créé les mêmes objets deux fois et c'est tombé sur moi, car je n'ai eu strictement aucune erreur. Non juste un modèle de conception à dégouter n'importe quel nouveau contributeur... De tpute façon ce n'est plus le propos puisque vous avez tout annulé. Si le problème qu'il y avait au début (et le suivant quand j'ai envoyé la modif créant les objets deux fois dans la même minute) était un problème de synchro sur le serveur, il n'a plus lieu d'être et il verra la restauration cette fois (espérons le...). J'ai bien l'impression que ma requête a été traitée par deux instances simultanées sur le serveur et que celles-ci ne sont pas correctement synchro entre elles. Je note cependant en ce moment assez souvent des erreurs JOSM inattendues, comme des références nulles simplement en chargeant des données de la base et en ouvrant une relation (bien que je l'ai réinstallé et que j'ai désactivé la quasi-totalité des plugins, au cas où). Dans des cas comme ça je n'enregistre rien et je relance depuis zéro, et je ne sauve localement que les modifs en cours qui n'ont pas eu encore la moindre alerte sur une exception interne de JOSM. C'est peut-être une nouvelle ano de JOSM. Parfois il me faut même tenter de charger la même donnée et relancer plusieurs fois. PArfois je résoud le problème ne chargeant la version latest au lieu de la version release, ou l'inverse. JOSM n'affiche pas assez de traces de débogage sur la console Java je trouve, quand il récoupère certaines exceptions ou quand il en affiche une. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 22:37, Romain MEHUT romain.me...@gmail.com a écrit : Le 18 février 2013 22:29, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y avait strictement rien d'incorrect, visiblement le serveur a créé les mêmes objets deux fois et c'est tombé sur moi, car je n'ai eu strictement aucune erreur. Non juste un modèle de conception à dégouter n'importe quel nouveau contributeur... Pas d'erreur sur le plan formel*, mais sans intérêt dans le cas présent ! Si on généralisait cette façon de faire sur les bâtiments, je ne vous explique pas le résultat en terme d'objets dans la base. La où on a deux polygones mitoyens, on se retrouve avec 3 ways et 2 relations, bonjour l'inflation des data sans parler de l'augmentation des calculs nécessaires à osm2pgsql pour recréer les géométries des ways puis des relations pour au final se retrouver avec de bêtes polygones ;) Sur les 25 millions de polygone building=* qu'on a en France, on doit bien en avoir la moitié de mitoyen... ça ferai 12 millions de relations en plus ? Un paille... il n'y en a que 11 millions actuellement dans planet. Sur le landuse, ça peut se discuter car on a des imbrications complexes qui peuvent parfois justifier un tel modèle... mais il faut aussi savoir rester simple et oublier le côté idéal et puriste. Les relations ont deux défauts: c'est incompréhensible à beaucoup de contributeurs, c'est super facile à casser. Deux bonnes raisons pour ne pas en abuser même si ctrl-alt-A permet de les créer facilement. Un nouveau test à rajouter dans validator (et osmose): multipolygones avec uniquement des outer en commun avec un (multi)polygon portant les mêmes tags * à part ces doublons créés par JOSM et les serveurs OSM... du jamais vu jusque là il fallait que ça tombe sur Philippe ! -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
citer une marque est une chose, reproduire un produit protégé en est une autre ! si quelqu'un reproduit un jean's, parce qu'il en a vu un porté dans un espace public, il va se prendre un joli procès. Pareil pour un smartphone avec les angles arrondis, et pareil avec un itinéraire balisé ! personne n'aurait l'idée de ré-écrire une chanson entendue à la radio, et d'en vendre des cd, pour un itinéraire de GR c'est pareil: ça peut paraître abstrait physiquement, mais c'est exactement la même législation qui s'applique ! je soutiens l'idée de Pieren d'en faire une grosse discussion le week-end prochain ;) Sylvain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Potlatch: les relations ne lui disent pas merci !
Le 18 février 2013 21:27, Vincent de Chateau-Thierry v...@laposte.net a écrit : Je trouve qu'une action sur la visibilité des relations dans Potlatch aurait sûrement plus d'impact sur la robustesse de ces objets : il est vraiment trop facile de les supprimer / altérer sans s'en rendre compte. Je viens de découvrir avec effroi (oui, c'est un mot fort !) que Potlatch se contrefiche des relations. 1) si on n'est pas en mode advanced, elle ne sont même pas visibles, 2) si on supprime un membre de relation il ne bronche pas Euh... c'est une blague ? -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18 février 2013 23:15, Sylvain Maillard sylvain.maill...@gmail.com a écrit : citer une marque est une chose, reproduire un produit protégé en est une autre ! si quelqu'un reproduit un jean's, parce qu'il en a vu un porté dans un espace public, il va se prendre un joli procès. Pareil pour un smartphone avec les angles arrondis, et pareil avec un itinéraire balisé ! personne n'aurait l'idée de ré-écrire une chanson entendue à la radio, et d'en vendre des cd, pour un itinéraire de GR c'est pareil: ça peut paraître abstrait physiquement, mais c'est exactement la même législation qui s'applique ! je soutiens l'idée de Pieren d'en faire une grosse discussion le week-end prochain ;) On en parle... avec un spécialiste du droit des marques, du droit de la propriété intellectuelle et du droit des bases de données alors, sinon il n'en ressortira rien de bien sérieux et étayé mais juste il faut vérifier avec un avocat. Je vais solliciter Benjamin Jean qui me semble compétent dans ce domaine. Je sais déjà qu'il ne sera pas à Lyon, mais avoir son avis sur le sujet nous permettrai de ne pas perdre un petit peu notre temps. -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 23:05, Christian Quest cqu...@openstreetmap.fr a écrit : * à part ces doublons créés par JOSM et les serveurs OSM... du jamais vu jusque là il fallait que ça tombe sur Philippe ! Je connais un cas pas si rare que ça : c'est quand pour une raison ou une autre la session HTTP tombe en cours de route : JOSM ne signale rien du tout mais arrêt l'upload en laissant des objets orphelins ou des objets qui auraient du être affacés à la fin. On s'en rend compte uniquement parce que le changeset n'est pas fermé : c'est pour ça qu'après un upload j'appuie sur CTRL+ALT+Q pour vérifier que le changeset est bien fermé et complet et n'a pas été interrompu en cours. Et c'était justement le cas lors de l'import qui a raté avec toutes les créations d'objets en double (alors que ce sont normalement les premières à être envoyées, avant les modifs et les suppression à la fin, mais le changeset contenait bien le tout : créations, modifs, et suppressions c'est la première partie qui s'est exécutée deux fois sur le serveur et dans la même session HTTP car les IDs que j'avais dans mon fichier OSM étaient ceux de la seconde version, et aucun de la première version envooyée par JOSM). J'ai ce genre d'erreur beaucoup plus souvent si je laisse JOSM tout envoyer en une seule transaction: pour limiter les dégats je lui fait envoyer les objets par petits paquets de 5 objets maxi (il faut plus de requêtes mais elles sont moins lourdes sur le serveur, il y a moins de chance que la session tombe pendant l'exécution d'une grosse requête) ; cela allège énormément aussi le temps pour résoudre les conflits, même si quand il y en a un je vais systématiquement faire CTRL+ALT+M après pour resynchroniser tous les autres objets en cours de modif et qui n'ont pas encore été envoyés et marqués en conflit par le serveur. Ca permet aussi de limiter énormément le nombre de conflits à résoudre pour pouvoir faire une sauvegarde intermédiaire (quand il y en a le plus, c'est quand un conflit survient sur l'envoi d'un chemin modifié avec un conflit par noeud modifié par quelqu'un d'autre (mais ça dépasse rarement une vingtaine de conflits à résoudre pour fusionner et recontrôler le tout, sauvegarder à nouveau, avant d'envoyer la suite). Je me demande pourquoi JOSM par défaut essaye toujours de tout envoyer en une seule requête (ce qui complique ensuite les corrections en cas de problème en milieu d'un gros paquet). Mais il se trouve qu'ici justement je veais de réinstaller JOSM et que j'avais oublié de réduire la taille des requêtes. Une grosse transaction est partie mais je ne sais pas comment JOSM a récupéré une exception interne inattendue pour reprendre l'envoi sans rien dire et faire comme si de rien n'était, en envoyant à nouveau les objets à créer avec les mêmes ID négatifs sans lire la réponse du serveur lors du premier essai d'envoi ! La requête n'était pourtant pas si volumineuse, mais l'envoi a été inhabituellement long (je penche pour une rupture de session TCP entre chez moi et le serveur non rapportée par un routeur intermédiaire ou par le FAI, ou rapportée tardivement : en TCP il faut au moins 30 secondes minimum pour avoir au moins une erreur timeout en attente d'un ACK ou d'un NAK TCP, qui normalement ne prend que le temps du round-trip voisin de 20 ms si on le reçoit, multiplié par le nombre d'essais d'envoi des datagrammes non acquittés, ce qui prend alors au moins 3 minutes si la rupture de session TCP n'est pas rapportée au client ; bien plus long en fait que l'exécution de la requête que j'avais envoyée; sans doute le timeout est arrivé mais bien après). TCP est réputé fiable mais qui n'a jamais téléchargé un gros fichier ISO qui s'est avéré corrompu une fois qu'on l'utilise (alors qu'il se monte très bien ou peut être gravé sans erreur sur un DVD) ? Il y a bien la solution HTTPS mais le serveur actuellement ne semble l'utiliser que pour l'authentification et pas pour la signature sécurisée des transferts (je ne parle pas du cryptage ici mais d'un hachage sûr comme MD5 au minimum -- SHA1 préférable -- au sein même de la session HTTP ou bien au sein des transactions XML) : on envoie du XML brut, sans aucune clé de vérification par le serveur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
2013/2/18 Christian Quest cqu...@openstreetmap.fr: Le 18 février 2013 20:49, JB jb...@mailoo.org a écrit : – la deuxième, qui est la réponse au taggage pour le rendu : tu ne serais pas en train de modifier le taggage pour ton rendu ? (je sais, c'est tellement tentant, quand on est dedans… Mais un filtre boundary + not river + not highway + not je ne sais pas quoi d'autre = je ne marque pas le nom ?) Je l'ai fait ce filtre, je ne suis donc plus concerné par le problème C'est vrai que ça ressemble à du changer un tag pour faciliter le boulot des réutilisateurs. La question est de savoir si un nom doit aller dans le tag name ou note. Je pense que normalement, ça va dans name. Si on ne veut pas le voir sur son application (rendu ou autre), tu as trouvé toi-même la solution. Ça n'est sûrement pas le dernier tag à filtrer par le réutilisateur. Pieren, même pas fan du tiret long/cadratin ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Le 18/02/2013 23:36, Pieren a écrit : La question est de savoir si un nom doit aller dans le tag name ou note. Non. La question est de savoir si ce qui n'a pas de nom en propre doit porter un tag name. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Ce soir, 23h32... un poisson a été noyé de sang froid suite à plein de touche enfoncées sur un clavier. RIP poisson ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
Le 18 février 2013 23:05, Christian Quest cqu...@openstreetmap.fr a écrit : Sur les 25 millions de polygone building=* qu'on a en France, on doit bien en avoir la moitié de mitoyen... ça ferai 12 millions de relations en plus ? Un paille... il n'y en a que 11 millions actuellement dans planet. Ton calcul est faux. Tu oublies de prendre en compte la taille des listes de noeuds membres des ways ! Les relations divisent ces tailles par deux (voir plus si le nombre de superposition est supérieur à deux avec des polygones multiniveaux comme pour les boundary) et ce sont pourtant ces listes de noeuds qui constituent le plus gros de la volumétrie TOTALE. Dès qu'un way superposé comprend 3 noeuds ou plus (la très grande majorité d'entre eux en fait), la volumétrie totale décroit rapidement avec le nombre de relations qui l'utiise (une seule référence de chemin membre suffit pour toute la liste de noeuds partagés pour chaque relation, alors qu'avec uniquement des polygones simples ces longues listes de noeuds sont dupliquées partout autour, notamment pour les boundary=*, landuse=*, et natural=*, et water=* qui sont presque toujours mitoyens les uns les autres). L'enfer ce sont les superpositions multiples de chemins qui sont sensés être identiques mais ne sont pas modifiés ensembles (surtout pour les chemins très longs : de nombreux noeuds intermédiaires sont souvent oubliés, et quand il faut trouver le quel dans une liste de 200 noeud ou plus, on passe un bon moment à chercher où est le trou !) Il suffit juste de comparer la taille des fichiers OSM : ils sont beaucoup plus petits en modèle multipolygone sans superposition de chemins, qu'avec des polygones simples. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Le 18 février 2013 23:41, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 18/02/2013 23:36, Pieren a écrit : La question est de savoir si un nom doit aller dans le tag name ou note. Non. La question est de savoir si ce qui n'a pas de nom en propre doit porter un tag name. Oui, tient, pourquoi pas mettre un name=Savoie — Haute-Savoie — Ain sur ce nœud: http://osm.org/?node=343663087 C'est en poussant la logique un cran plus loin qu'on voit si ça tient la route ou pas... -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
2013/2/18 Christian Quest cqu...@openstreetmap.fr: C'est en poussant la logique un cran plus loin qu'on voit si ça tient la route ou pas... Comme ici par exemple: http://fr.wikipedia.org/wiki/Dreil%C3%A4ndereck_%28B%C3%A2le%29 Mais s'il n'y plus de nom pour les frontières. on ne devra plus dire la frontière franco-allemande mais limite administrative qui fait partie de la relation France et de la relation Allemagne ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM-FR: communiqué de presse envoyé !
ah ouais tiens, on a laissé passé ça ... tu as envoyé le communiqué de presse à qui pour le moment ? Sylvain Le 18 février 2013 20:58, Christian Quest cqu...@openstreetmap.fr a écrit : Oups ! Le 18 février 2013 20:05, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 18/02/2013 11:01, Christian Quest a écrit : Envoyez aux médias lyonnais... Il est disponible ici: http://openstreetmap.fr/**communique-20130218http://openstreetmap.fr/communique-20130218 Tout le monde peut contribuer au projet en ajoutant des informations manquantes ou erronées, Ajouter des informations erronées ? Fichtre. -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Oui, mais là tu taggue un monument... le nœud que j'ai indiqué et en plein milieu du Rhône (et du Fier qui s'y jette là justement). Le 18 février 2013 23:55, Pieren pier...@gmail.com a écrit : 2013/2/18 Christian Quest cqu...@openstreetmap.fr: C'est en poussant la logique un cran plus loin qu'on voit si ça tient la route ou pas... Comme ici par exemple: http://fr.wikipedia.org/wiki/Dreil%C3%A4ndereck_%28B%C3%A2le%29 Mais s'il n'y plus de nom pour les frontières. on ne devra plus dire la frontière franco-allemande mais limite administrative qui fait partie de la relation France et de la relation Allemagne ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un revert svp
2013/2/18 Philippe Verdy verd...@wanadoo.fr: Ton calcul est faux. Tu oublies de prendre en compte la taille des listes de noeuds membres des ways ! Les relations divisent ces tailles par deux (voir plus si le nombre de superposition est supérieur à deux avec des polygones multiniveaux comme pour les boundary) et ce sont pourtant ces listes de noeuds qui constituent le plus gros de la volumétrie TOTALE. Petit rappel sur ce que sont les relations de type multipolygon depuis toujours ([1]): Relations of type multipolygon are used to represent complex areas. Simple areas are mapped in OSM by creating one circular way and tag it with something that suggests an area rather than a circular way. For example, a circular way tagged landuse=forest will be assumed to be an area, while a circular way tagged junction=roundabout will not. Il y a chez certains contributeurs un tel amour des relations qu'ils ont tendance à en mettre partout ;-) Faire des relations, y compris pour les quatre murs d'un bâtiments, a aussi été suggéré sur cette liste à une lointaine époque. Je ne citerais pas les noms des coupables parce que certains sont encore parmi nous :-) Pieren [1] http://wiki.openstreetmap.org/wiki/Relation:multipolygon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM-FR: communiqué de presse envoyé !
Le 19 février 2013 00:02, Sylvain Maillard sylvain.maill...@gmail.com a écrit : ah ouais tiens, on a laissé passé ça ... tu as envoyé le communiqué de presse à qui pour le moment ? A ceux en jaune au bas de ce document: https://docs.google.com/document/d/1ouImTq6wQLV9MJZ-HgLPdBkVvUSOUMjHtzxNklh0Wyk/edit -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Je vais prendre une autre analogie, celle des chansons : chntonner sur les mêmes notes les mêmes vers peut constituter une violation de droit car il y a assez déléments communs et rien de réellement inventif dans l'interprétation qui rende ce contenu reproduit réellement différent : c'est essentiellement la même chanson, même si c'est un interprête différent, le droit d'auteur s'applique. En revanche le droit d'auteur ne s'applique pas aux notes utilisées ni aux mots chantés (elles/ils n'ont aucun caractère original par elles-mêmes, sauf si ce sont des facsimilés de sons d'instruments protégés). Il faut donc que l'oeuvre soit reconnaissable en tant que telle et facilement extractible de l'oeuvre dérivée pour juger qu'il y a une reproduction sujète au droit de l'auteur original. Maintenant avec ces notes, on peut emprunter toutes sortes de styles et même trouver légalement des inspirations pour faire autre chose. C'est ce qu'on fait dans OSM où il ne s'agit pas de créer une deuxièmz base de données des GR français mais donner une colection de chemins de randonnées d'origines diverses, évaluées par des tas de contributeurs et originaires de tas de pays. Les critères d'entrée dans OSM seront très différents de ceux des GR français. On n'aboutiera jamais à la même base même s'il y a des éléments individuels communs (mais classés différemment sous une autre nomenclature plus... internationale et non franco-française selon les critères de la FFRP). La FRPP ne sera pas la seule contributrice (et n'est pas non plus gardienne, de droit, des intérêts des autres contributeurs : elle n'a pas de monopole légal et surtout pas international et n'est pas la seule habilitée à juger des chemins intéressants : au delà des GR en France on trouve aussi de nombreux circuits promus par diverses assos ou sociétés ou collectivités, qui ne seront jamais des GR selon les critères de la FRPP, et qui pourtant ont leur place dans la base OSM en tant que tels, selon NOS critères collectifs). Bref on peut même décider q'u'un GR classé n'a aucun intérêt dans OSM parce que d'autres sociétés ou groupes ont fait un meilleur travail d'évaluation répondant mieux à nos critères ou répondant mieux aux attentes de leur propre public. Pour nous il suffit juste de marquer des collections de sentiers d'origine diverses, qu'on peut remarquer sur le terrain, pour les classer en fonction d'une activité donnée ou d'un public concerné (par exemple un public anglophone sera intéressé par des chemins où les indications sont en anglais, ou bien où il existe des guides anglophones). Notre problème est alors celui-ci: quoi mettre en *référence* ? On n'a pas besoin d'indiquer que c'est un circuit balisé correspondant à une norme unique mais on peut très bien taguer des critères objectifs qui sont ceux qui justement permettent à la FFRP de promouvoir un circuit : intérêt du site (on a des données environnementales et patrimoniales), facilités d'accès, nature des chemins, surfaces, pentes, équipements de sécurité, points d'eau potable, pratiques sportives autorisées, domaines de chasse ou pêche, ouverture au public, données sur les dangers potentiels et les zones fragiles à préserver et éviter... Au vu de tout ça on peut alors dresser notre propre classification et créer un réseau libre de droit indépendant qui passera sans doute par endroit par un GR donné, mais qui s'en écarrtera aussi et prendra d'autres sentiers ou routes utilisables. Et au final on a une autre base de données originale, de laquelle on ne peut plus extraire la partie GR seule même par des moyens détournés (par exemple par des tags équivalents partout en France à la désignation d'un GR, même s'ils ne le disent pas). Ce qui veut dire alors qu'au lieu de mentionner une réference unique, on va référencer les critères séparés conduisant à considérer qu'un sentier peut être utilisé comme un circuit de randonnée ou pas. D'ailleurs est-on obligé de créer des circuiits ? Ne suffit-il pas de créer un réseau plus ou moins maillé, laissant le libre choix au randonneur parmi les chemins possibles, celui-ci prenant sa décision en fonction des critères individuels évalués séparément ? Après tout c'est ce qu'on fait pour faire de la navigation routière : un gros maillage dans lequel on cherche un chemon selon divers critères : temps de parcours, prix des péages, consommation de carburant, présence de certains POIs au choix, présence de certains équipements comme les stations de carburant et aires de repos. Et avec tout ça on se crée soi-même son parcours (les navigateurs GPS nous en proposent quelques-uns mais on a encore le choix à tout moment de s'en écarter même si au final on part et on arrive au même endroit. Bref, ce que je propose c'est non pas cartographier les GR, mais simplement les chemins pour piétons ou cyclistes, ou pour d'autres types d'utilisateurs, et savoir comment contourner des parcours infranchissables à pied (on ne traverse pas les autoroutes ou voies ferrées ou des fleuves
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Je te rejoint après avoir fait un petit essai avec des relations pour des AOC près de chez moi. Je me suis retrouvé avec plein de parcelle agricole partant le nom de l'AOC alors que réellement elles ne porte pas ce nom mais ce serait plutôt une aire géographique. Concernant le nom des frontières, j'ai constaté que cela concerne principalement les frontières entre région. Il ne faut pas oublier qu'elle sont également des frontières de communes, arrondissement, canton et autre découpage administratif et politique. A moins d'indiquer la totalité des noms possible, leur nom est incomplet. Avoir le nom de deux régions sur une frontière quand on recherche les limites administrative entre deux communes de part et d'autres d'une limite entre région est compréhensible mais un peut limite. Je ne connaît pas les anciennes utilisations d'OSM mais les relations semble répondre correctement au besoin sans avoir à définir un nom sur chaque frontière. Le 18 février 2013 23:41, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 18/02/2013 23:36, Pieren a écrit : La question est de savoir si un nom doit aller dans le tag name ou note. Non. La question est de savoir si ce qui n'a pas de nom en propre doit porter un tag name. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Merci Hélène d'avoir lu ce sujet, Il me semble qu'il y a plusieurs questions autour des licences en suspend. Peut être serait il possible d'aborder le sujet pendant l’événement de Lyon. En attendant une confirmation de l'autorisation (ou pas) des circuit GR, pourquoi ne renommez vous pas les relations de tel sorte qu'ils soient considéré comme de simple circuit pédestre ? C'est à dire en s'interdisant l'utilisation de GR ou tout autre similitude. Dans tous les cas, cela reste des circuits de randonnées,* si ils sont indiqués c'est qu'un contributeur les a parcouru* et il n'est pas obligatoire de les classer en GR. En tant qu'utilisateur final, savoir qu'il y a un circuit de randonné peut être suffisant. Cela permet d'éviter de tendre le bâton pour ce faire battre en attendant d'être certains de pouvoir utiliser le sigle GR. Le 18 février 2013 21:36, Hélène PETIT h...@free.fr a écrit : Le 18/02/2013 20:39, Pieren a écrit : Et la première chambre de la cour de cassation, elle FUD aussi en juin 1998: http://www.legifrance.gouv.fr/**affichJuriJudi.do?oldAction=** rechJuriJudiidTexte=**JURITEXT07041272** fastReqId=109256579fastPos=1http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT07041272fastReqId=109256579fastPos=1 la cour d'appel n'a pas donné de base légale (...) pour rejeter l'action en contrefaçon dirigée par la Fédération française de randonnée pédestre (FFRP) contre la société xxx. Juste au dessus : l'arrêt attaqué énonce que les sentiers de randonnée sont ouverts à tous et que leur figuration sur les cartes de l'IGN démontrait qu'ils étaient dans le domaine public, de sorte que les *sentiers balisés par la FFRP* ne constituaient pas en eux-mêmes des oeuvres de l'esprit ; Cet arrêt concerne les sentiers balisés par la FFRP et date de 1998, à une époque où les GPS ne courraient pas les rues, et les images satellite publiques étaient un rêve de Noël. Dans le cas qui me préoccupe, des fragments de sentiers GR sont parcourus également par les sentiers de randonnées pédestres communaux, et *balisés par l'intercommunalité* ; Et, à mon humble avis, ce que dis cet arrêt de la cour, c'est que l'auteur du balisage peut être considéré comme l'auteur de l'itinéraire. = Les itinéraires que je convoite de faire figurer dans OSM sont les oeuvres de l'esprit de l'intercommunalité (qui les fait baliser par des assos d'insersion) et qui, brave fille, ne mets de copyright nulle part. Il y a convergence aussi avec le sujet de percherie ici : http://forum.openstreetmap.fr/**viewtopic.php?f=3t=505#p2389http://forum.openstreetmap.fr/viewtopic.php?f=3t=505#p2389 Bref, les choses changent à grande vitesse, et 1998 s'enfuit ventre à terre __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Je ne suis pas juriste, mais, je persiste à penser qu'il n'y a aucune urgence à retirer les itinéraires, mais que ce n'est pas intéressant de mettre GR x. Dans une procédure civile portant sur la protection d'un droit intellectuel, il faut démontrer les risques de préjudice. C'était évident pour une édition papier. Ce n'est pas prouvable, tant que c'est immatériel. Le risque ne se manifesterait que, si un éditeur papier basait sa carte sur OSM. OSM pourrait clore la procédure en retirant les données. L'éditeur pourrait engager une procédure amiable. Il resterait à tester la validité, en tant que jurisprudence, des arrêts de 1998. Comme déjà évoqué, le cadre juridique a tellement changé qu'il n'y a pas de raison de supposer que la FFRP garderait une pleine main sur ce qui est devenu une co-construction multipartenariale. Attendons et voyons comment cela bouge. La FFRP attaquant une fondation anglaise sans craindre de violents retours de bâton, ce n'est pas forcément un scénario prévisible. Christian Rogel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Potlatch: les relations ne lui disent pas merci !
Il y a un possible successeur de Potlatch qui gérera mieux les multipolygones dans les tuyaux : http://mapbox.com/blog/announcing-id/ Multipolygon relations, a complex part of the OpenStreetMap data model, are now displayed accurately and can be edited with iD 2013/2/18 Christian Quest cqu...@openstreetmap.fr Le 18 février 2013 21:27, Vincent de Chateau-Thierry v...@laposte.net a écrit : Je trouve qu'une action sur la visibilité des relations dans Potlatch aurait sûrement plus d'impact sur la robustesse de ces objets : il est vraiment trop facile de les supprimer / altérer sans s'en rendre compte. Je viens de découvrir avec effroi (oui, c'est un mot fort !) que Potlatch se contrefiche des relations. 1) si on n'est pas en mode advanced, elle ne sont même pas visibles, 2) si on supprime un membre de relation il ne bronche pas Euh... c'est une blague ? -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le lundi 18 février 2013 17:33:30 Ab_fab a écrit : Bonjour, Je viens de remarquer cette entrée dans les journaux utilisateurs : http://www.kompf.de/gps/rivermap.html Ach, ces allemands … j'ai l'impression que leur réseau hydro est sacrément bien avancé ! C'est beau :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Je crois que la question des limites est une des plus importantes, alors que je n'en ai jamais tracé une sur osm :-) Donc, de mon point de vue théorique, vu qu'une limite administrative ne dépend que d'une seule autorité (l'administration), que cette autorité définit en même temps les composés et leurs limites, je réponds NON, pas de noms aux limites. En effet, il suffit de donner un nom aux composés (nom des départements, régions...), comme le fait l'autorité administrative, et donner quelque part le nom de cette autorité. Ce dernier point me parait important : bien que l'autorité administrative n'existe pas sur le terrain, ce pseudo POI permet d'expliciter la référence de ce que l'on décrit ; la Bretagne, par exemple, est enfin bref je veux pas créer un troll :-) Cette question d'affirmer le nom de l'autorité administrative n'est pas prévue dans les tags boundary que j'ai vu sur le wiki d'osm, et je pense que c'est une erreur. Informatiquement parlant c'est plus difficile de déterminer qui limite quoi et pourquoi. Même si je ne fiche rien, je réfléchis beaucoup à la façon de placer les limites de quartier à st etienne :-) Bien que ces limites sont clairement placées sur wikipedia, je n'ai trouvé nulle part une référence, et elles n'ont pas de conséquences administratives ; ce n'est pas comme les arrondissements parisiens, par ex. Il s'agit surtout de tradition, je pense, jamais vraiment officialisée, ou, du moins, l'officialisation est ubuesque : selon la mairie il existe par exemple le quartier de La Terrasse - Bel Air - Bergson - Carnot - Montaud :-) Une tradition diversifiée couplée à une administration folle qu'est-ce que ça peut donner sur les names des boundaries ? (et notez l'éventuel usage de tirets quadratins, qui seraient donc bien nécessaires ?? ) Le 18 février 2013 18:55, Christian Quest cqu...@openstreetmap.fr a écrit : Je reviens encore une fois sur ces name qu'on trouve sur des way uniquement utilisé par des boundary. J'essaye de faire un rendu propre sur les limites administratives et découpages courants*, mais ce name artificiels, arbitraires et de confort viennent vraiment polluer le rendu. De plus, ils sont particulièrement difficile à masquer. De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? 2) remplacer ces name par note ou description ? Dans quel ordre ? opère-t-on ? * voir ici ce que ça donne: http://tile.openstreetmap.fr:13080/?lat=48.8286lon=2.38914zoom=16layers=0B -- Christian Quest - OpenStreetMap France Week-end SOTM-FR à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : Des textes à promenades http://drivrsdu.fr/des-textes-a-promenades/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] UI 翻訳レビューのお願い
おかのさん、翻訳協力ありがとうございます！ メールに気づくのが遅れてすみません。現在、翻訳はあまりアクティブでないので承認フローは成立しておりません。アプリを触ったことがあってOKと思ったらどなたでも承認お願いします。私も夜、みてみます。東 2013年2月12日火曜日 OKANO Takayoshi k...@na.rim.or.jp: おかのといいます。 JOSM と KeepRight の翻訳で、いくつか誤字や誤訳のようなものがありましたので、 Launchpad 上で修正の提案をしておきました。 https://translations.launchpad.net/josm/trunk/+pots/josm/ja/+translate?show=new_suggestions https://translations.launchpad.net/keepright/trunk/+pots/keepright/ja/+translate?show=new_suggestions すみませんが、権限をお持ちの方、レビューをお願いします。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org javascript:; http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] New user reinstating old railways in Norfolk
New user MATTHEW NIBARI [1] has created just two changesets [2], both yesterday (17th February). The OSM History viewer views of these are as follows: http://osmhv.openstreetmap.de/changeset.jsp?id=15065237 http://osmhv.openstreetmap.de/changeset.jsp?id=15066769 I've been though every way listed there, and every single change in both of these changesets involves changing railway=abandoned or railway=disused to railway=rail, and removing any highway=* tags. I haven't checked every way, but I expect that all these railway lines are indeed disused or abandoned, and so the previous tagging was correct. I sent Matthew a message a couple of hours ago through the OSM system to explain that our tagging should reflect the current reality, and that his changes are therefore inappropriate. His reply was that he was trying to track down old railway lines and make them easier to find in OSM. He didn't seem to see a problem with changing the tagging. His user page [1] includes the text If people are having problems please note the edited sections must not be changed for any reason so if anyone inbox me or changes it back, I will revert back if its put back suggesting he may revert any changes to his new tagging regardless of other's views. I've sent a second email half an hour ago to explain in more detail why current roads need to be tagged as roads and not railways, and suggested that he should discuss things with the community on talk-gb to find a suitable way to achieve his ends without messing up the map data for everyone else. At that stage I'd only found a couple of road-rail changes in one changeset, and wasn't aware of the History Viewer, so didn't know that *every* change was removing highway tags and changing to railway=rail. I thus wasn't sure whether the whole changeset would need reverting or just a part of it, and so I asked Matthew what his changes had involved. However, I think it's now clear that the whole of both changesets [3,4] need to be reverted. Presumably, this should be done as quickly as possible to avoid the risk of subsequent edits complicating things. I don't have any recent experience of doing reverts, so is there anyone reading this who would be able to do them instead? I haven't had a reply from Matthew to my second message yet, but once this has posted, I'll send him a web link to this thread. Many thanks, Robert. [1] http://www.openstreetmap.org/user/MATTHEW%20NIBARI [2] http://www.openstreetmap.org/user/MATTHEW%20NIBARI/edits [3] http://www.openstreetmap.org/browse/changeset/15065237 [4] http://www.openstreetmap.org/browse/changeset/15066769 -- Robert Whittaker ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] New user reinstating old railways in Norfolk
It may be worth pointing out that you can have different view of the same data. For example ITO have a map highlighting the former railways: http://www.itoworld.com/map/198#fullscreenlat=52.58151540618443lon=1.0302901709739063zoom=9 Shaun ITO World Developer On 18 Feb 2013, at 14:24, Robert Whittaker (OSM lists) robert.whittaker+...@gmail.com wrote: New user MATTHEW NIBARI [1] has created just two changesets [2], both yesterday (17th February). The OSM History viewer views of these are as follows: http://osmhv.openstreetmap.de/changeset.jsp?id=15065237 http://osmhv.openstreetmap.de/changeset.jsp?id=15066769 I've been though every way listed there, and every single change in both of these changesets involves changing railway=abandoned or railway=disused to railway=rail, and removing any highway=* tags. I haven't checked every way, but I expect that all these railway lines are indeed disused or abandoned, and so the previous tagging was correct. I sent Matthew a message a couple of hours ago through the OSM system to explain that our tagging should reflect the current reality, and that his changes are therefore inappropriate. His reply was that he was trying to track down old railway lines and make them easier to find in OSM. He didn't seem to see a problem with changing the tagging. His user page [1] includes the text If people are having problems please note the edited sections must not be changed for any reason so if anyone inbox me or changes it back, I will revert back if its put back suggesting he may revert any changes to his new tagging regardless of other's views. I've sent a second email half an hour ago to explain in more detail why current roads need to be tagged as roads and not railways, and suggested that he should discuss things with the community on talk-gb to find a suitable way to achieve his ends without messing up the map data for everyone else. At that stage I'd only found a couple of road-rail changes in one changeset, and wasn't aware of the History Viewer, so didn't know that *every* change was removing highway tags and changing to railway=rail. I thus wasn't sure whether the whole changeset would need reverting or just a part of it, and so I asked Matthew what his changes had involved. However, I think it's now clear that the whole of both changesets [3,4] need to be reverted. Presumably, this should be done as quickly as possible to avoid the risk of subsequent edits complicating things. I don't have any recent experience of doing reverts, so is there anyone reading this who would be able to do them instead? I haven't had a reply from Matthew to my second message yet, but once this has posted, I'll send him a web link to this thread. Many thanks, Robert. [1] http://www.openstreetmap.org/user/MATTHEW%20NIBARI [2] http://www.openstreetmap.org/user/MATTHEW%20NIBARI/edits [3] http://www.openstreetmap.org/browse/changeset/15065237 [4] http://www.openstreetmap.org/browse/changeset/15066769 -- Robert Whittaker ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] New user reinstating old railways in Norfolk
On 18/02/13 14:24, Robert Whittaker (OSM lists) wrote: New user MATTHEW NIBARI [1] has created just two changesets [2], both yesterday (17th February). The OSM History viewer views of these are as follows: http://osmhv.openstreetmap.de/changeset.jsp?id=15065237 http://osmhv.openstreetmap.de/changeset.jsp?id=15066769 I've been though every way listed there, and every single change in both of these changesets involves changing railway=abandoned or railway=disused to railway=rail, and removing any highway=* tags. I haven't checked every way, but I expect that all these railway lines are indeed disused or abandoned, and so the previous tagging was correct. He posted diary entries as well, and several of us have tried to engage with him there. From his last comment here: http://www.openstreetmap.org/user/MATTHEW%20NIBARI/diary/18652 I wonder if he is just very confused and thinks this is the correct way to create a custom map for himself? His english doesn't seem to be brilliant which may not be helping with people's attempts to explain the problem to him. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] New user reinstating old railways in Norfolk
Robert Whittaker (OSM lists) wrote: However, I think it's now clear that the whole of both changesets [3,4] need to be reverted. Presumably, this should be done as quickly as possible to avoid the risk of subsequent edits complicating things. I don't have any recent experience of doing reverts, so is there anyone reading this who would be able to do them instead? Done. http://www.openstreetmap.org/browse/changeset/15078224 http://www.openstreetmap.org/browse/changeset/15078231 cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/New-user-reinstating-old-railways-in-Norfolk-tp5749762p5749768.html Sent from the Great Britain mailing list archive at Nabble.com. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] New user reinstating old railways in Norfolk
He's responded positively to comments in his latest diary entry, and has asked for help with JOSM. Hopefully this can now be resolved! Only trouble is, I fear what he wants to do is quite complex and he might struggle and get annoyed again :-s On Mon, Feb 18, 2013 at 3:07 PM, Richard Fairhurst rich...@systemed.netwrote: Robert Whittaker (OSM lists) wrote: However, I think it's now clear that the whole of both changesets [3,4] need to be reverted. Presumably, this should be done as quickly as possible to avoid the risk of subsequent edits complicating things. I don't have any recent experience of doing reverts, so is there anyone reading this who would be able to do them instead? Done. http://www.openstreetmap.org/browse/changeset/15078224 http://www.openstreetmap.org/browse/changeset/15078231 cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/New-user-reinstating-old-railways-in-Norfolk-tp5749762p5749768.html Sent from the Great Britain mailing list archive at Nabble.com. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] road names along the A50 (and elsewhere)
Recently various sections along the A50 between Derby and Stoke have grown names, for example here: http://www.openstreetmap.org/browse/way/202232245/history I've driven along that section of road many times, and I don't believe I've seen a name on any of the new sections. According to Musical Chairs, there are genuinely no names: http://ris.dev.openstreetmap.org/oslmusicalchairs/map?zoom=15lat=52.87983lon=-1.66551layers=B0TTview_mode=pseudorandom Some similar roads in Derbyshire do have official names, such as the A52 Brian Clough Way between Derby and Nottingham, or well-used unoffical ones such as the A61 which locals regularly used to refer to as just the Dronfield Bypass, but I've never heard of ones for the A50 being used. I'm planning to remove names that I can't find evidence for, but thought that I'd better check to make sure that I'm not missing anything obvious. Do these names have any basis in reality? Foston Hatton Hilton Bypass** sounds like something that might have been written on a planning application, but I've never seen it used anywhere. Cheers, Andy ** Some of the given names (such as Foston Hatton Hilton Bypass) are further complicated by having soft hyphens (hex AD) inserted between syllables, which results in the rendering of hyphens in some places but not others. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] road names along the A50 (and elsewhere)
The user looks like a troll. None of his/her/bot changesets have any comments. And they bounce all over the world. I think he deleted the original roads on the 21 jan 2013 as the history in OSM says they are new roads. Can someone look at reverting them all. I sent the user this PM. What are you doing with your edits here?: http://www.openstreetmap.org/browse/changeset/14728720 You appear to have deleted major roads A50 and replaced them with strange names. Where are you getting your information. Your changesets have no notes in them explaining what you have done. Can you explain what you are doing before we revert the changes and look at getting you banned. Cheers, John Date: Mon, 18 Feb 2013 23:11:53 + From: li...@mail.atownsend.org.uk To: Talk-GB@openstreetmap.org Subject: [Talk-GB] road names along the A50 (and elsewhere) Recently various sections along the A50 between Derby and Stoke have grown names, for example here: http://www.openstreetmap.org/browse/way/202232245/history I've driven along that section of road many times, and I don't believe I've seen a name on any of the new sections. According to Musical Chairs, there are genuinely no names: http://ris.dev.openstreetmap.org/oslmusicalchairs/map?zoom=15lat=52.87983lon=-1.66551layers=B0TTview_mode=pseudorandom Some similar roads in Derbyshire do have official names, such as the A52 Brian Clough Way between Derby and Nottingham, or well-used unoffical ones such as the A61 which locals regularly used to refer to as just the Dronfield Bypass, but I've never heard of ones for the A50 being used. I'm planning to remove names that I can't find evidence for, but thought that I'd better check to make sure that I'm not missing anything obvious. Do these names have any basis in reality? Foston Hatton Hilton Bypass** sounds like something that might have been written on a planning application, but I've never seen it used anywhere. Cheers, Andy ** Some of the given names (such as Foston Hatton Hilton Bypass) are further complicated by having soft hyphens (hex AD) inserted between syllables, which results in the rendering of hyphens in some places but not others. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
