Re: [OSM-talk-fr] [Openstreetmap] remappage après suppression des données CEDRIC007
Si vous supprimez les données, je veux bien passer deux - trois soirées à dessiner des routes depuis Bing (je ne connais pas du tout cette région par contre)... Mika_Gueret Le mardi 27 novembre 2012 à 17:09 +0100, Philippe Pary a écrit : Salut, J'interviens tard sur cette affaire, désolé. C'est une vieille affaire que celle de CEDRIC007. On en avait déjà parlé sur cette liste lorsque j'avais soulevé le lièvre en 2010. La suppression des données sera une bonne chose, notamment pour occuper nos longues soirées d'hiver. La violation de licence était flagrante, si l'affaire s'était ébruité, ç'aurait fait du mal à notre image. La reconstruction du Valenciennois ne sera pas trop compliquée je pense : CEDRIC007 était un bourrin du tracé de voirie. À nous de bourriner autant que lui. Les détails les plus chronophages comme les POI ne devraient pas souffrir de la disparition de ces données. Tout au plus auront-ils été mal calés et devra-t-on corriger leur position sur la carte*. C'est du gâteau ! Philippe, peut-être trop optimiste * changer leur position sur le terrain serait long et pénible Le 27/11/2012 09:13, adrien carpentier a écrit : Salut! on a suivi de loin la discussion sur le sujet des contrib de cédric007 sur le valenciennois nous sommes plusieurs du npdc à pouvoir essayer d'aider à remapper après la suppression cependant, il va vraiment me manquer de temps en ce moment pour coordonner le remappage est-il possible de nous y guider un peu? notamment quand aura lieu la suppression, quels secteurs ont été touchés?, charge à celles et ceux motivés de préciser le coin qu'ils vont retravailler tous les ajouts des autres contributeurs sur les données créées par cédric peuvent-ils être sauvés dans un calque pour nous en resservir? Merci de votre aide à bientôt adrien -- http://www.virage-energie-npdc.org/ ___ Openstreetmap mailing list openstreet...@chtinux.org http://lists.linux62.org/cgi-bin/mailman/listinfo/openstreetmap ___ 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] Soucis sur Nominatim
Il y a peut être un truc étrange avec deux way Bourgogne - Franche Comté qui viennent polluer la liste administrative des détails de France: http://nominatim.openstreetmap.org/details.php?place_id=98156803 Ces deux way sont les polygones des enclaves signalées par Pierre et étant des chemins fermés avec les tags admin_level et autre, Nominatim semble se mélanger les crayons. J'ai retiré les tags, pour que seules les relations s'appuyant dessus soient prises en compte par Nominatim et de plus cela ne devrait rien changer aux rendus Mapnik et autre. Voir: http://www.openstreetmap.org/browse/changeset/14069909 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
C'est ce que tu crois, le rendu est bien différent pour ces exclaves, il disparait même à certains niveaux de zoom là où la frontière de région apparaît encore. J'appelle cette modif taguer pour le rendu (Nominatim) au lieu de signaler l'anomalie à Nominatim (qui en a bien d'autres dans ses heuristiques hasardeuses). Car ta modif consiste à ne mettre plus aucun attribut sur les ways fermés faisant partie d'une ou plusieurs relations et qui servent à coder des exclaves : cela marche bien pour les landuse=* ou natural=* mais pas encore pour les boundary (qui sont de plus différenciés par types et par niveau) : on ne les trouve plus par une requête sur les ways, uniquement par une requête sur les relations. Pire, des nœuds situés dans une exclave sont maintenant considérés comme faisant partie de la surface de la relation englobante (c'est une autre anomalie aussi dans Nominatim qui ne sait pas se débrouiller correctement avec les surfaces bien décrites, et parfois invente des règles de résolution encore plus floues pour interpréter de façon grossière des géométries défaillantes, comme on l'a vu il y a quelques mois encore pour Rennes en Loire-Atlantique et Pays de la Loire au lieu de l'Ille-et-Vilaine et la Bretagne, ou pour l'Ille-et-Vilaine classée en Pays de la Loire). Nominatim a toujours été assez mauvais dans ses heuristiques (acceptables quand la géométrie est défaillante, mais dans certaines limites qui étaient très largement dépassées) et ce n'est pas nouveau. Mais là il l'est aussi dans les cas où aucune heuristique n'est nécessaire avec une géométrie correcte, tout bonnement car ses imports de géométrie convertis en OpenGIS (avec sa propre version de l'outil de conversion OSM vers PostgreSQL) ne sont pas corrects (moins bons en tout cas que les mêmes conversions faites pour Mapnik ou d'autres moteurs de rendus). Bref Nominatim est seul à se tromper, et on corrige en modifiant le comportement des autres moteurs ? Le 28 novembre 2012 09:23, Christian Quest cqu...@openstreetmap.fr a écrit : Il y a peut être un truc étrange avec deux way Bourgogne - Franche Comté qui viennent polluer la liste administrative des détails de France: http://nominatim.openstreetmap.org/details.php?place_id=98156803 Ces deux way sont les polygones des enclaves signalées par Pierre et étant des chemins fermés avec les tags admin_level et autre, Nominatim semble se mélanger les crayons. J'ai retiré les tags, pour que seules les relations s'appuyant dessus soient prises en compte par Nominatim et de plus cela ne devrait rien changer aux rendus Mapnik et autre. Voir: http://www.openstreetmap.org/browse/changeset/14069909 ___ 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] Grosse suppression de données autour de valenciennes
Où que j'écrive, même dans un message court, on me le reproche de toute façon. Et en plus il n'y avait aucune hors sujet. Sinon que dire des autres réactions sur le même ticket et même avant moi ? Le 28 novembre 2012 06:08, Marc SIBERT m...@sibert.fr a écrit : On te demande de ne pas t’épancher sur les outils techniques. Tu peux toujours le faire sur talk-fr. Il y a des fils pour ça ! WTF ? -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Bonjour Philippe et la liste, Sur le fond du message, je suis en complet désaccord avec toi (Philippe). La suppression des données provenant de Google ne devient pas urgente maintenant. Elle était DÉJÀ urgente il y a deux ans !! Le fait que le problème n'a pas été traité à l'époque n'enlève rien à l'urgence actuelle. En tant que membre du DWG, c'est le rôle de Sly de faire cette suppression au nom de la fondation et de la communauté. Quelques puissent être les scrupules, regrets, et grincements de dents des uns et des autres. Le plus tôt sera le mieux. La règle que les données doivent être libres est la base du contrat qui unit Osm et ses contributeurs et utilisateurs. Cette règle ne souffre donc aucune exception ou tergiversation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: [Maps-l] Wikimedia/mapping event in Europe early next year?
Bonjour, Wikimedia envisage de monter en début d'année prochaine un rassemblement relatif au développement de l'extension geodata quelque part en Europe ainsi que le mapping. Je transmets le message, si d'aventure de bonnes volontés se sentent d'attaque pour monter la chose. Plus d'infos dans le message original joint ci-dessous -- Forwarded message -- From: Erik Moeller e...@wikimedia.org Date: 2012/11/28 Subject: [Maps-l] Wikimedia/mapping event in Europe early next year? To: map...@lists.wikimedia.org Hi folks, it's been a long time coming, but we're finally gearing up for putting some development effort into an OSM tileservice running in production to serve Wikimedia sites. This is being driven by the mobile team but obviously has lots of non-mobile use cases as well, including the recent Wikivoyage addition to the Wikimedia familiy. This work will probably not kick off before January/February 2013; before then, the mobile team is working to finish up the GeoData extension ( https://www.mediawiki.org/wiki/Extension:Geodata ). To get broader community involvement and sync up with existing volunteer efforts in this area, it'd IMO be useful to plan a face-to-face meetup/hackfest just focused on geodata/mapping related development work sometime around Feb/March 2013. WMF is not going to organize this, but we can help sponsor travel and bring the key developers from our side who will work on this. Are there any takers for supporting a 20-30 people development event in Europe focused on mapping/geodata? I'm suggesting Europe because I know quite a few of the relevant folks are there, but am open to other options as well. Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Maps-l mailing list map...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l -- 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] A quand un Osmecum pour l'utilisation facile d'OSM?
J'avais une idée dans le meme type depuis quelque temps : bravo Yohan pour l'avoir mise en œuvre ! C'est vraiment quelque chose dans le genre qu'il nous manque ... tiens nous au jus Le 26 novembre 2012 16:40, Vincent Pottier vpott...@gmail.com a écrit : Le 26/11/2012 16:48, Yohan Boniface a écrit : On 11/26/2012 04:09 PM, Christian Rogel wrote: 1 Je veux mettre un bout de carte Mapnik, OpenMapquest, Opencyclemap, etc. sur mon site/mon blog/mon message 2 Même chose avec des marqueurs Pour info, je bosse sur un projet de ce type. Démo ici: http://youmap.fluv.io/ Plus d'infos sur cette liste dans les jours/semaines à venir. Yohan Pour info, J'ai réalisé plusieurs cartes avec pois, traces... et petit affichage d'info. J'ai fait une petite bibliothèque javascript pour faire tourner ça. Les données sont dans un fichier geoJSON. Les templates dans un fichier. Les styles dans un fichier... Bref, assez structuré pour pouvoir être repris, automatisé. E gros, on doit pouvoir faire des fichiers template et style assez standard, et permettre la customisation. Si ça intéresse du monde... (ça m'aidera à faire progresser...) Deux exemples : avec des layers lonvia : route shading, pas mal de pois... http://frvipofm.net/aep/carte/**carte.htmlhttp://frvipofm.net/aep/carte/carte.html avec deux pois et deux traces gpx http://frvipofm.net/pele/**carte.htmlhttp://frvipofm.net/pele/carte.html À explorer sous Firebug. FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A quand un Osmecum pour l'utilisation facile d'OSM?
2012/11/26 Yohan Boniface yohanbonif...@free.fr: Et la remarque: je compte ajouter une option d'import sur YouMap (nom de code provisoire) Une appellation très proche du déjà existant YouMapps de SPOT Images: http://www.youmapps.org/ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Bon... la bonne nouvelle c'est que Nominatim se met à jour très très vite, ce qui facilite les corrections ! La mauvaise, c'est que ça coinçait toujours... la Côte d'Or est en Champagne-Ardenne et la Nièvre est un niveau trop haut... Le noeud label de Champagne Ardenne avait plein de tags du genre place=state des names en veux-tu en voilà, et un admin_level=4... du coup, ça mettait sûrement la pagaille et la Champagne-Ardenne était liée à ce noeud et pas à la relation ! Des enclaves entre Nièvre et Côté d'Or avaient aussi leurs way surtagguées alors qu'elles font partie de multiples relations. Après nettoyage... la Côte d'Or est retournée en Bourgogne :-) J'espère que ça va être bon aussi pour la Nièvre... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Sauf que l'idée était de réflechir avant d'agir et cela me paraît être aussi la base d'un projet collaboratif. Débattre, trouver la meilleure solution et agir au mieux selon les compétences de chacun. Si c'est juste pour dire le DWG a décidé de et donc on fait comme dieu à décide, cela confirme bien ce que je craignais à savoir : je n'ai plus aucun doutes sur la volonté de ce groupe de s'accaparer l'ensemble du projet. P.S : Ça fait vraiment cours de maternelle tout ces débats sur les messages de M. Verdy. Les messages sont longs (certes) et si votre cerveau n'est pas capable d'en retirer la synthèse (qui est très souvent intéressante), passez votre chemin. A bon entendeur. -- View this message in context: http://gis.19327.n5.nabble.com/Grosse-suppression-de-donnees-autour-de-valenciennes-tp5737510p5737967.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Le mardi 27 novembre 2012 13:04:54 Emmanel Dewaele a écrit : Je vous présente Nomino, un modeste éditeur de données OpenStreetMap, dédié à la traduction des noms de lieux en différentes langues. Super ! Je vois que le boulot est déjà bien avancé par rapport à quelques temps en arrière. On est quasi prêts pour générer de belle carte du monde en français. Un scénario de test: dans la boite Preferences, cliquer sur Toolserver localised maps puis choisir fr (French) dans le menu. La carte s'affiche avec les noms de lieux traduits en français, et donc des noms de lieux non traduits. Si on va par exemple en Russie ou en Ukraine, on trouve beaucoup de villes dont la forme française n'est pas renseignée, il suffit d'ouvrir l'objet et d'entrer le nom de la ville en français. J'ajouterai (car j'ai cherché 2 minutes) qu'il faut faire un clic-droit à l'emplacement désiré (comme écrit à droite) pour sélectionner le lieu à modifier. On peut le trouver assez facilement par Wikipédia, en cherchant le nom de la ville dans la langue locale. Et un petit bouton pour lancer la recherche directe ? ;-) Apparemment, tous les types d'objet ne peuvent pas être modifiés, genre tourism=attraction. J'ai essayé au chutes du niagara, où je n'ai pu sélectionner ni le tourism=attraction : http://www.openstreetmap.org/browse/node/1180806843 ni le waterway=waterfall http://www.openstreetmap.org/browse/node/399904172 mais j'ai eu le natural=cliff (peut-être grâce au wikipedia=*) http://www.openstreetmap.org/browse/way/162157664 Pour finir, un petit lien vers l'objet sur osm.org sur la page d'édition serait un petit plus. Bravo et merci -- 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] Nouvel éditeur spécialisé traduction
Emmanuel, Je t'invite à aller présenter un de ces jours ton outil sur la liste Map Integration de Wikimedia. https://lists.wikimedia.org/mailman/listinfo/maps-l C'est la liste où se discute ce qui est relatif aux rendus dans les différentes langues, sur le Toolserver. Tu pourrais donc recevoir des retours intéressants Le 27 novembre 2012 22:04, Emmanel Dewaele emmanuel.dewa...@gmail.com a écrit : Bonsoir, Je vous présente Nomino, un modeste éditeur de données OpenStreetMap, dédié à la traduction des noms de lieux en différentes langues. Nomino en quelques points: - Une application web, sans installation et utilisable sur toutes plateformes (même si pour l'heure ça donne moyen sur téléphone et tablette) - Une application simple: l'interface se veut dépouillée et utilisable par des contributeurs débutants sans lecture de documentation préalable - Une application efficace: au lieu d'ouvrir toutes les données sur une zone, comme le font classiquement JOSM et Potlatch, on ne charge que certains objets individuellement pour éditer les tags de type name:**. Même on peut déjà s'identifier sur osm.org et d'enregistrer les modifications, l'éditeur est en version alpha, testez le à vos risques et périls. Un scénario de test: dans la boite Preferences, cliquer sur Toolserver localised maps puis choisir fr (French) dans le menu. La carte s'affiche avec les noms de lieux traduits en français, et donc des noms de lieux non traduits. Si on va par exemple en Russie ou en Ukraine, on trouve beaucoup de villes dont la forme française n'est pas renseignée, il suffit d'ouvrir l'objet et d'entrer le nom de la ville en français. On peut le trouver assez facilement par Wikipédia, en cherchant le nom de la ville dans la langue locale. L'application: http://nomino.comptoir.net Le code source: http://gitorious.org/nomino/nomino Merci beaucoup à Cyrille Giquello et sa superbe bibliothèque pour l'accès à l'API OpenStreetmap: https://github.com/Cyrille37/yapafo Emmanuel -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Sauf que dans le cas présent, ce n'est pas une règle sortie du chapeau par le DWG (comme cet été), mais c'est bien ce qui fait la nature d'osm qui est en jeu ! Si demain google me fait un procès parce que j'utilise à tort ses données, je peux plaider la bonne foi tant que j'ai confiance dans le fait que les données d'osm sont libres. Je suis par contre complètement en tort si je continue à les utiliser alors que je sais qu'il s'agit de contrefaçons. C'est pour ça, à mon avis, qu'il faut agir vite ! Cela n'empêche pas la discussion, mais on n'a pas les moyens de prendre encore deux ans pour le faire, ne serait-ce que pour prouver notre bonne foi. D'autant que chaque jour qui passe empire encore le problème, les données litigieuses pouvant être modifiées, ce qui provoquera des pertes supplémentaires. Concernant le ps: les tirades de Philippe ne me derangent pas plus que ça, et expriment souvent un point de vue intéressant. C'est justement ce point de vue que je combats ici : ce n'est pas parce que le problème a été signalé deux ans auparavant puis oublié qu'il en devient moins urgent. partir-en-vtt ad...@partir-en-vtt.com a écrit : Sauf que l'idée était de réflechir avant d'agir et cela me paraît être aussi la base d'un projet collaboratif. Débattre, trouver la meilleure solution et agir au mieux selon les compétences de chacun. Si c'est juste pour dire le DWG a décidé de et donc on fait comme dieu à décide, cela confirme bien ce que je craignais à savoir : je n'ai plus aucun doutes sur la volonté de ce groupe de s'accaparer l'ensemble du projet. P.S : Ça fait vraiment cours de maternelle tout ces débats sur les messages de M. Verdy. Les messages sont longs (certes) et si votre cerveau n'est pas capable d'en retirer la synthèse (qui est très souvent intéressante), passez votre chemin. A bon entendeur. -- View this message in context: http://gis.19327.n5.nabble.com/Grosse-suppression-de-donnees-autour-de-valenciennes-tp5737510p5737967.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Les ways surtagués le sont depuis longtemps et partout avec boundary=administrative et le plus petit admin_level=* parmi les relations dont ils sont membres. Cela n'a jamais posé ce genre de problème et cela aide encore pas mal d'outils qui ne savent pas lire les relations parentes et se contentent des noeuds et ways (ils ne travaillent pas au niveau surface, juste sur le filaire). En aucun cas cela n'a jamais posé la moindre ambiguïté d'interprétation concernant les surfaces car cela a toujours signifié le type de séparation entre les relations qu'on *peut* (sans être obligé de le faire) chercher de chacun des deux côtés. Il n'y a que sur les lignes de côtes qu'on ne met plus ces attributs car ce ne sont pas des limites administratives en tant que telles, même si des relations les réutilisent à défaut d'autre chose pour approcher au mieux la ligne de base administrative difficile à placer (sachant aussi que la ligne de côte est aussi difficile à placer exactement, les deux lignes se confondent pour l'instant dans leurs limites de précision). En revanche pour les landuse=* ou natural=*, les attributs du chemin et des relations ont des effets néfastes quand ils existent des deux côtés (car tous les landuse ne sont pas nécessairement des relations s'ils sont un unique chemin fermé). C'est peut-être là le hic de Nominatim avec ces petites exclaves, inclues comme enclaves d'une autre surface unique : elles sont définies comme des chemins fermés et non des suites de chemins ouverts membres de relations. Nominatim les traite comme les landuse=* et natural=* Mais il y a encore légions de landuse=* et natural=* qui définissent leur unique chemin fermé dans une relation avec les mêmes attributs (ce qui n'est pas non plus un doublon quand la relation peut avoir d'autres membres que ce seul chemin fermé). On compte par exemple les water=riverbank, les bâtiments en pagaille, les relations place=island pour les petites îles non découpées administrativement et donc la ligne de côte est un unique chemin fermé (mais pourtant dans une relation avec les mêmes attributs et souvent aucun autre way membre ou juste des noeuds membres sous des rôles divers. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
On 28/11/2012 11:16, Ab_fab wrote: Si on va par exemple en Russie ou en Ukraine, on trouve beaucoup de villes dont la forme française n'est pas renseignée, il suffit d'ouvrir l'objet et d'entrer le nom de la ville en français. On peut le trouver assez facilement par Wikipédia, en cherchant le nom de la ville dans la langue locale. On pourrait pré-remplir le champ de la traduction française: - On regarde dans quel circonscription administrative du niveau adéquat (FIXME - de quel niveau s'agit-il ?) se situe le point. Disons pour l'exemple qu'il est en Russie. - On déduit la langue à partir de la circonscription administrative, ce qui suppose une table de correspondance entre circonscription administrative et langue par défaut dans cette circonscription. Cette opération ignore les cas multilingues qu'il faudra donc énumérer et exclure du pré-remplissage. - On regarde donc dans name:RU s'il existe. Sinon on regarde dans name. - Si la page http://ru.wikipedia.org/wiki/name existe, alors on prend le nom fr.wikipedia.org s'il existe (FIXME - j'ignore le mécanisme Wikipedia à utiliser pour implémenter ça) et on s'en sert pour pré-remplir le champ de la traduction française. Techniquement ça pourrait être automatisé, mais je crois que la validation humaine systématique est souhaitable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Le 28 novembre 2012 10:55, Christian Quest cqu...@openstreetmap.fr a écrit : Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ 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] Soucis sur Nominatim
Bref c'est pour ça que Nominatim se trompe : il ne voyait comme contour fermé que les enclaves et ignorait les lignes non fermées. Ce problème est là dans Nominatim depuis longtemps : pour trouver une région d'appartenance d'un lieu, il utilise alors une heuristique approximative basée sur les centroïdes des régions fermées les plus proches. (Cela a toujours été le cas par exemple pour Rennes qui passe en Pays de la Loire dans Nominatim, chaque fois que la relation Bretagne n'est plus fermée, ce qui arrive souvent étant donné la complexité de sa limite côtière : le centroïde de la Bretagne étant alors calculé uniquement sur les îles fermées tout autour, majoritairement dans le Finistère et les côtes d'Armor et ce centroïde des îles bretonnes est très éloigné vers l'ouest, bien plus éloigné du lieu cherché que celui du contour fermé des Pays de la Loire). Nominatim ne détecte pas ces anomalies de frontières ouvertes pour utiliser d'abord (avant l'importation des seuls polygones), une heuristique de fermeture des extrémités ouvertes les plus proches au moins par un segment, ce qui éviterait pourtant des anomalies très grossières avec son heuristique actuelle. Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Le 28 novembre 2012 10:55, Christian Quest cqu...@openstreetmap.fr a écrit : Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ 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] Soucis sur Nominatim
2012/11/28 Philippe Verdy verd...@wanadoo.fr: Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Les paroles s'envolent, les écrits restent. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction - wikipedia interlink traduction
On mercredi 28 novembre 2012, Jean-Marc Liotier wrote: Techniquement ça pourrait être automatisé, mais je crois que la validation humaine systématique est souhaitable. La validation est souvent faite en amont chez wikipedia interlink wiki (un projet était/est en cours sur talk pour automatiser ça) est-il utile de revalider une 2ème fois ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction - wikipedia interlink traduction
On 28/11/2012 11:57, sly (sylvain letuffe) wrote: On mercredi 28 novembre 2012, Jean-Marc Liotier wrote: Techniquement ça pourrait être automatisé, mais je crois que la validation humaine systématique est souhaitable. La validation est souvent faite en amont chez wikipedia interlink wiki (un projet était/est en cours sur talk pour automatiser ça) est-il utile de revalider une 2ème fois ? http://en.wikipedia.org/wiki/Paris,_Denmark s'appelle Paris et non Paris, Denmark. Une validation humaine est donc bien nécessaire en raison de la manière dont Wikipedia traite les homonymies. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Ils sont nouveaux mais correspondent à quoi ? As-tu au moins regardé avant d'affirmer que la relation est brisée ? La relation n'est pas brisée, je les ai toutes vérifiées dans JOSM avant de renvoyer mes modifs. Ces noeuds désormais visibles, sont ceux qui portent des tags, en l'occurrence j'en ai trouvé un qui est une borne géodésique. http://www.openstreetmap.org/?lat=48.0573lon=3.829744zoom=18layers=Mrelation=27768 Avant d'affirmer n'importe quoi et de faire partir ceux qui te lisent encore sur de fausses pistes, il serait bon de VERIFIER. Pour vérifier qu'un multipolygone ferme bien il y a des outils fiables disponibles comme http://analyser.openstreetmap.fr/ -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction - wikipedia interlink traduction
http://en.wikipedia.org/wiki/Paris,_Denmark s'appelle Paris et non Paris, Denmark. Une validation humaine est donc bien nécessaire en raison de la manière dont Wikipedia traite les homonymies. Ha ouais, bien vu... J'espère qu'ils ont fait gaffe à ça sur le projet dont je parlais, ha moins que la syntaxe du séparateur _ soit générale à tout wikipedia -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Le 28 novembre 2012 11:24, khris78 ch...@gallioz.fr a écrit : Concernant le ps: les tirades de Philippe ne me derangent pas plus que ça, et expriment souvent un point de vue intéressant. C'est justement ce point de vue que je combats ici : ce n'est pas parce que le problème a été signalé deux ans auparavant puis oublié qu'il en devient moins urgent. Je n'ai pas dit que c'était moins urgent, mais s'il y a eu 2 ans de réflexion et aucune solution, c'est d'abord parce que le problème n'était pas simple à régler et qu'aujourd'hui il n'est pas plus simple pour autant maintenant. Les réflexions sur les méthodes de changement de licence ayant porté leur fruit, il est temps d'y repenser en fonction de justement ce qui a été pensé pour le changement de licence et les données incompatibles. Et je trouve parfaitement dommage de ne pas utiliser maintenant correctement les outils et méthodes qui ont été développés dans ces 2 dernières années, notamment en terme de collaboration. Si on supprime tout de suite sans prévenir personne et qu'on laisse en l'état, on attend que les autres devront détecter les anomalies par des recherches inextricables point par point (surtout ici où il va y en avoir beaucoup disséminées partout entre des tonnes d'autres modifs et ajouts conservés). Je ne m'attend pas du tout à ce que le passage du Bot laisse une place propre et nette où il suffira de remapper: On va avoir des tonnes de fragments dont on se demandera à quoi il servent où à quoi les rattacher, et si personne n'est prévenu, un réparateur passant par là pourra faire des réparations sans trop comprendre (regardez ce qu'il y a maintenant en Ukraine et en Pologne : un vrai massacre avec des tonnes de miettes de données raccrochées à rien du tout, et des réparations faites dans n'importe quel sens, et une grande difficulté à savori quoi conserver alors que les licences étaient bien compatibles ODbL et les données parfaitement sensées au départ). Et on va mettre du temps à faire le nettoyage et les réparations manuelles si on n'a pas de quoi comparer pour savoir comment garder ce qui reste, justement à cause des 2 ans passés qui ont compliqué la situation. Oui le nettoyage est urgent, mais pas n'importe comment car il sera plus compliqué que ce qu'on croit simple avec juste le passage du Bot (pour les changement de licence, il y a eu un très long travail préparatoire qui a permis d'éviter de de retrouver avec une carte complètement incohérente, et un suivi en ligne de suppressions d'objets essentiels à la main, et leur recréation à part, avant la purge de celles qui restent par le bot). On est dans le cas ici où la même préparation est nécessaire, justement à cause des 2 ans passés, et même si cela prend 2 semaines de plus, ce n'est rien à côté des 2 ans passés, cela n'aggravera pas significativement le problème actuel. Et pendant ces 2 semaines, il peut se faire déjà du nettoyage important (sans le bot qui passera à la fin pour contrôler tout ça), le problème n'est pas ignoré. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Outil de vérification des relations de type transports publics
Bonjour à tous, Depuis quelques temps, je travaille à l'écriture d'une application nommée OSM_checkTransportRelationshttps://github.com/windu2b/OSM_checkTransportRelations(codée en Java et basée sur les classes-métier de JOSM) destinée à valider les relations concernant les relations de 'type=route' (bus, tram, métro, ...). Bien que loin d'être aussi aboutie que je le souhaite, je vous la présente tout de même car je viens de finir une première version utilisable, et disponible ici https://github.com/windu2b/OSM_checkTransportRelations/tags . *Concrètement, en quoi consiste-t-elle ?* Tout simplement à vérifier : * la présence des éléments attendus dans une telle relation (ways, stops et platforms) ; * que le bon rôle est associé aux éléments le cas échéant ; * qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; * qui les ways qui composent l'itinéraire sont continues ; * ... La liste des règles testées se trouve ici, et je vous invite à m'en soumettre.http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation *Que manque-t-il ?* Beaucoup de choses ! * améliorer le code ; * améliorer les tests unitaires ; * avoir une meilleure granularité pour les logs (au minimum NOTICE, WARNING, ERROR) ; * ajouter d'autres règles ; * ajouter la prise en compte des relations 'type=route_master', qui contiennent plusieurs relations 'type=route' ; * pouvoir fournir en paramètre des listes de relations à tester (par ex., sous la forme : 1;3;4-8 pour tester les relations, 1, 3 et de 4 à 8); * pour chaque relation à tester, accepter en paramètre une liste ordonnée des arrêts par lesquels l'itinéraire est censé passer, afin de vérifier qu'aucun arrêt n'a été oublié ou n'est en trop ; * ... Je vous invite à tester mon appli (vous trouverez sur cette page des relations qui ont besoin d'être vérifiéeshttp://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun), à l'améliorer si vous êtes développeurs, à me remonter vos questions/demandes/critiques, ... soit par mail, soit directement sur Githubhttps://github.com/windu2b/OSM_checkTransportRelations/issues . Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Le 28 novembre 2012 12:10, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 11:24, khris78 ch...@gallioz.fr a écrit : Concernant le ps: les tirades de Philippe ne me derangent pas plus que ça, et expriment souvent un point de vue intéressant. C'est justement ce point de vue que je combats ici : ce n'est pas parce que le problème a été signalé deux ans auparavant puis oublié qu'il en devient moins urgent. Je n'ai pas dit que c'était moins urgent, mais s'il y a eu 2 ans de réflexion et aucune solution, c'est d'abord parce que le problème n'était pas simple à régler et qu'aujourd'hui il n'est pas plus simple pour autant maintenant. Techniquement, le problème est beaucoup plus simple à régler aujourd'hui en utilisant une évolution du robot de rédaction. C'est cet outil qui va permettre de conserver ce qui peut l'être. Il y a deux ans, cet outil n'existait tout simplement pas (peut être même pas en rêve). Oui, il y aura des dégâts et des miettes et la meilleure chose que l'on pourra faire à mon avis sera d'utiliser HOT Task Manager pour se répartir les zones à refaire sans se marcher sur les pieds. En se concentrant tous sur cette zone ça devrait vite être réglé. Je ne vois pas comment on peut faire du nettoyage avec la situation actuelle. Cela nécessite de retrouver les objets impactés, ce qui n'est pas facile pour ceux modifiées depuis (et en 2 ans, ça doit en faire beaucoup) et on risque plus d'avoir l'effet inverse: corriger des objets qui risquent d'être détruits par le bot (expérience que je retire de juillet dernier). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
On mercredi 28 novembre 2012, Christian Quest wrote: et on risque plus d'avoir l'effet inverse: corriger des objets qui risquent d'être détruits par le bot (expérience que je retire de juillet dernier). +1 C'est en effet un des risques qui m'inquiète quand des personnes, pas forcément au fait de toutes les subtilités des fusions des chemins, des historiques complexes, vont tenter de repartir d'un existant pour en faire un nouveau contenu compatible au niveau licence. Le risque de voir une partie qu'on pense pourtant avoir refaite disparaître me semble élevé et le risque de frustration/désillusion existe. (ça se produit quand on a tout retracé à la main, et que l'on a fusionné sans faire attention avec un objet tinté, ou que l'on a refait pour rien car seul le nom était tinté, ou que sais-je encore) Si toi, qui n'est pas le moins au courant de tous, a réussi à te faire avoir, c'est que ça risque de se reproduire. Je ré-itère, avec cet argument supplémentaire, ma recommendation de d'abord vider, puis refaire. (Basus sana in OSM sano) Lors du changement de licence, certes chambéry et environ n'était que peu tinté, mais j'ai mis en pause pendant ~1 an tout type de modification d'existant et attendu le passage du bot pour réparé l'esprit plus tranquille. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Alors ces cercles sont juste une nuisance inutile. Ils ne servent à rien dans le cas d'une visualisation d'une relation, si ce ne sont : ni des nœuds membres, ni des extrémités non connectées de ways membres (là ils seraient bien plus utiles). Le cercle devrait aussi être distingué par un symbole différent de celui des nœuds membres (par exemple un carré fin et non un cercle épais, ou une autre couleur que le bleu des membres). Cela prête largement à confusion car rien dans les données de la relation elle même ne mentionne ces nœuds, il n'y a pas lieu même de les signaler dans cette analyse (le rendu en arrière plan s'en chargera, et on peut cliquer sur un chemin de la liste pour le détailler). De très nombreux noeuds sur tous les chemins membres pourraient avoir ces cercles, et cela sera illisible sur la minicarte. Je veux bien comprendre ces symboles en revanche quand on visualise un chemin (fermé ou pas d'ailleurs), pour les nœuds avec attributs, là c'est utile. Car ces nœuds sont bien membres du chemin (même si on n'en voit pas les attributs dans la définition du chemin lui-même). Mais tant qu'à faire autant le signaler dans la liste des noeuds en dessous, et pas forcément sur la mini-carte qui est surtout là pour avoir un aperçu rapide de l'objet dans son état actuel. Plus utile serait aussi d'indiquer dans les listes de membres et d'attributs ceux qui ont été ajoutés, modifiés ou retirés dans la dernière modification visualisée, par un fond de couleur comme dans l'éditeur de conflits de JOSM (même si on ne voit pas la valeur précédente) et aussi, dans les mêmes listes de membres, ceux-ci sont dans une version faisant partie de ce même changeset (par une mise en gras par exemple ou un indicateur cliquable (par exemple un lien (modifié) invidant à consulter les données de ce membre modifié, même si la présence de ce membre n'a pas changé dans la relation). Si le rôle d'un membre a changé, ce rôle aussi devrait être signalé comme modifié. Si l'ordre des membres d'une relation a changé, c'est une modif mineure, le fond de couleur n'est pas absolument nécessaire ou doit rester discret (beige clair comme dans JOSM?) Actuellement on n'a que le lien historique qui souvent plante (il charge souvent trop de versions et pour les relations cela déborde souvent la capacité du serveur à afficher des listes interminables), et pas non plus moyen par ce lien d'afficher un diff navigable entre deux versions successives. Tout le monde n'a pas JOSM pour voir ce qui est touché (Potlatch ne sait pas faire), et cela prend aussi beaucoup de temps et on n'est pas toujours prêt à charger un objet pour en consulter l'historique quand on a des modifs en cours et qu'on va voir en ligne un objet qui n'est pas partie des données modifiées en cours. Ce que j'ai dit sur le comportement très approximatif de Nominatim reste vrai sur les relations ouvertes. Le 28 novembre 2012 12:06, Christian Quest cqu...@openstreetmap.fr a écrit : Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Ils sont nouveaux mais correspondent à quoi ? As-tu au moins regardé avant d'affirmer que la relation est brisée ? La relation n'est pas brisée, je les ai toutes vérifiées dans JOSM avant de renvoyer mes modifs. Ces noeuds désormais visibles, sont ceux qui portent des tags, en l'occurrence j'en ai trouvé un qui est une borne géodésique. http://www.openstreetmap.org/?lat=48.0573lon=3.829744zoom=18layers=Mrelation=27768 Avant d'affirmer n'importe quoi et de faire partir ceux qui te lisent encore sur de fausses pistes, il serait bon de VERIFIER. Pour vérifier qu'un multipolygone ferme bien il y a des outils fiables disponibles comme http://analyser.openstreetmap.fr/ -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Les dégâts m'inquiètent moins (ils seront visibles et vite corrigés) que les miettes ; on en trouve encore un peu partout (moins certainement en France que dans les pays où le changement de licence a été beaucoup moins accepté, ce qui a obligé OSM a y rétablir tout un tas de données : en Pologne par exemple, par une décision communautaire et des vérifications de licence séparées, à leur source, sans demander à l'auteur initial des imports). Le 28 novembre 2012 12:22, Christian Quest cqu...@openstreetmap.fr a écrit : Le 28 novembre 2012 12:10, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 11:24, khris78 ch...@gallioz.fr a écrit : Concernant le ps: les tirades de Philippe ne me derangent pas plus que ça, et expriment souvent un point de vue intéressant. C'est justement ce point de vue que je combats ici : ce n'est pas parce que le problème a été signalé deux ans auparavant puis oublié qu'il en devient moins urgent. Je n'ai pas dit que c'était moins urgent, mais s'il y a eu 2 ans de réflexion et aucune solution, c'est d'abord parce que le problème n'était pas simple à régler et qu'aujourd'hui il n'est pas plus simple pour autant maintenant. Techniquement, le problème est beaucoup plus simple à régler aujourd'hui en utilisant une évolution du robot de rédaction. C'est cet outil qui va permettre de conserver ce qui peut l'être. Il y a deux ans, cet outil n'existait tout simplement pas (peut être même pas en rêve). Oui, il y aura des dégâts et des miettes et la meilleure chose que l'on pourra faire à mon avis sera d'utiliser HOT Task Manager pour se répartir les zones à refaire sans se marcher sur les pieds. En se concentrant tous sur cette zone ça devrait vite être réglé. Je ne vois pas comment on peut faire du nettoyage avec la situation actuelle. Cela nécessite de retrouver les objets impactés, ce qui n'est pas facile pour ceux modifiées depuis (et en 2 ans, ça doit en faire beaucoup) et on risque plus d'avoir l'effet inverse: corriger des objets qui risquent d'être détruits par le bot (expérience que je retire de juillet dernier). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ 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] Nouvel éditeur spécialisé traduction
Merci pour vos retours, j'en déduis qu'il n'y pas d'anomalies trop flagrantes. Et un petit bouton pour lancer la recherche directe ? ;-) D'autres évolutions vont venir, notamment pour intégrer les propositions de traduction du Wikipedia place name tool (http://meta.wikimedia.org/wiki/User:WikedKentaur/OSM-Wikipedia_place_name_tool). Cet outil se sert des liens interwiki pour établir des correspondances sur des noms d'articles liés à des objets OpenStreetMap. Apparemment, tous les types d'objet ne peuvent pas être modifiés, genre tourism=attraction. La recherche d'objets se base sur Nominatim, qui ne retourne pas forcément tous les objets du monde. Si vous avez une meilleure idée, je suis preneur. Pour finir, un petit lien vers l'objet sur osm.org sur la page d'édition serait un petit plus. Bonne idée, je viens de le faire. -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914p5738000.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Autant que je puisse comprendre les choses, le How to launch du README concerne JOSM ; si tu confirmes, peut être as-tu fait un copié collé ? Cela dit cela rend les choses plus difficile pour OSM_checkTransportRelations. Il faudrait que le README de OSM_checkTransportRelations explique comment lancer OSM_checkTransportRelations, et non pas JOSM :-) Peut être pourrais-tu trouver un nom de projet plus court ? Je n'ai pas trouvé de jar exécutable. Comme j'ai trouvé les sources (suis-je formidable) j'imagine qu'il faut compiler en local ton projet. Mais, apparamment, tu utilises eclipse. Je n'ai rien contre mais moi j'utilise netbeans :-) Certes je pourrais m'adapter facilement, mais bon... ne pourrais-tu pas fournir le jar, ou faire tes projets avec maven ? Cordialement. Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Bonjour à tous, Depuis quelques temps, je travaille à l'écriture d'une application nommée OSM_checkTransportRelationshttps://github.com/windu2b/OSM_checkTransportRelations(codée en Java et basée sur les classes-métier de JOSM) destinée à valider les relations concernant les relations de 'type=route' (bus, tram, métro, ...). Bien que loin d'être aussi aboutie que je le souhaite, je vous la présente tout de même car je viens de finir une première version utilisable, et disponible icihttps://github.com/windu2b/OSM_checkTransportRelations/tags . *Concrètement, en quoi consiste-t-elle ?* Tout simplement à vérifier : * la présence des éléments attendus dans une telle relation (ways, stops et platforms) ; * que le bon rôle est associé aux éléments le cas échéant ; * qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; * qui les ways qui composent l'itinéraire sont continues ; * ... La liste des règles testées se trouve ici, et je vous invite à m'en soumettre.http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation *Que manque-t-il ?* Beaucoup de choses ! * améliorer le code ; * améliorer les tests unitaires ; * avoir une meilleure granularité pour les logs (au minimum NOTICE, WARNING, ERROR) ; * ajouter d'autres règles ; * ajouter la prise en compte des relations 'type=route_master', qui contiennent plusieurs relations 'type=route' ; * pouvoir fournir en paramètre des listes de relations à tester (par ex., sous la forme : 1;3;4-8 pour tester les relations, 1, 3 et de 4 à 8); * pour chaque relation à tester, accepter en paramètre une liste ordonnée des arrêts par lesquels l'itinéraire est censé passer, afin de vérifier qu'aucun arrêt n'a été oublié ou n'est en trop ; * ... Je vous invite à tester mon appli (vous trouverez sur cette page des relations qui ont besoin d'être vérifiéeshttp://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun), à l'améliorer si vous êtes développeurs, à me remonter vos questions/demandes/critiques, ... soit par mail, soit directement sur Github https://github.com/windu2b/OSM_checkTransportRelations/issues. Francescu ___ 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] Outil de vérification des relations de type transports publics
Réflexion faite, un arrêt de bus a toujours au moins un noeud sur la voie. S'il n'y a qu'un poteau indicateur cela reste suffisant pour une platform et on le place à côté de la voie et pas sur la voie. Il y a donc au moins deux éléments (pour un arrêt dans un seul sens) une relation se justifie. En revanche sur un arrêt bidirectionnel, il n'y a pas forcément un poteau des deux côtés, le même poteau indicateur est valable pour les deux sens sur une rue ou route pas trè large qu'on ne veut pas encombrer pour les arrêts occasionnels à la demande. Le seul cas serait celui des arrêts à la demande sans poteau (autorisés souvent seulement pour la descente mais non marqués car se faisant devant une propriété privée située sur le trajet) ou juste connus à certains endroits (par exemple au stop d'un carrefour rural). Plus jeune c'est comme ça que je prenais le bus tous les jours sur une route de campagne : il fallait faire près d'un kilomètre à pied pour rejoindre l'arrêt mais le bus s'arrêtait devant chez moi à la demande, uniquement pour descendre, mais pas pour monter car il n'y avait pas de plateforme d'attente et pas moyen de se signaler assez tôt à distance ; un arrêt a été fait plus tard plus près lorsque d'autres constructions sont apparues autour. Je me demande si le schéma a prévu les arrêts interdits à la montée ou la descente (cela concerne même des arrêts avec plateforme d'attente pour d'autres lignes) : souvent en fin de ligne le bus ne prend plus personne et ce n'est pourtant pas encore le terminus, cela limite le nombre d'arrêts nécessaires quand personne ne descend là et cela accélère la desserte si seulement des passagers descendent, mais souvent il n'y a aucune plateforme d'attente sécurisée ou non gênante pour les autres piétons, ou si la plateforme est là c'est pour ceux qui attendent une autre ligne ou vont y faire une correspondance en descendant de la première ligne à descente seulement... Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 28/11/2012 13:21, Ista Pouss a écrit : Autant que je puisse comprendre les choses, le How to launch du README concerne JOSM ; si tu confirmes, peut être as-tu fait un copié collé ? Cela dit cela rend les choses plus difficile pour OSM_checkTransportRelations. Il faudrait que le README de OSM_checkTransportRelations explique comment lancer OSM_checkTransportRelations, et non pas JOSM :-) Peut être pourrais-tu trouver un nom de projet plus court ? Je n'ai pas trouvé de jar exécutable. Comme j'ai trouvé les sources (suis-je formidable) j'imagine qu'il faut compiler en local ton projet. Mais, apparamment, tu utilises eclipse. Je n'ai rien contre mais moi j'utilise netbeans :-) Certes je pourrais m'adapter facilement, mais bon... ne pourrais-tu pas fournir le jar, ou faire tes projets avec maven ? Je me suis dit exactement la même chose. Ça m'intéresse pas mal de regarder, mais j'utilise Idea... Jean signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Le 28 novembre 2012 13:13, Emmanel Dewaele emmanuel.dewa...@gmail.com a écrit : Merci pour vos retours, j'en déduis qu'il n'y pas d'anomalies trop flagrantes. Je trouve la cinématique d'édition un peu lourde, mais c'est opérationnel. Bravo ! Sinon faudrait internationaliser l'interface ;-) Apparemment, tous les types d'objet ne peuvent pas être modifiés, genre tourism=attraction. La recherche d'objets se base sur Nominatim, qui ne retourne pas forcément tous les objets du monde. Si vous avez une meilleure idée, je suis preneur. Peut-être des recherches node+way via overpass has-kv k=name/ + around radius=xxx/ ... mais cela ne marche pas sur les grands polygones. BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [Maps-l] Wikimedia/mapping event in Europe early next year?
Si c'est juste quelque part en Europe, ce sera dans un seule grande capitale accessible facilement depuis un autre pays voisin. Cela limite le choix à quelques grandes villes européennes bien desservies : Paris, Bruxelles, Francfort, Milan, voire même Londres (ils ont des tonnes de projets intéressants là-bas et depuis longtemps, et ils n'auront pas le soucis de la traduction immédiate et pourront même diffuser un live bien suivi par plein de monde). Sinon en France cela pourrait aussi être Nice si l'accent est mis sur WikiVoyage. L'Espagne est aussi une belle destination (Barcelone), mais elle est moins bien desservie sauf par l'avion, et moins centrale pour les voisins (hormi la France) et l'espagnol n'est pas aussi accessible et la communauté OSM espagnole n'est pas au top en ce moment. Je pense donc que ce sera plutôt Bruxelles si ce n'est pas Londres qui a tout ce qu'il faut pour organiser ça. 2012/11/28 Ab_fab gamma@gmail.com Bonjour, Wikimedia envisage de monter en début d'année prochaine un rassemblement relatif au développement de l'extension geodata quelque part en Europe ainsi que le mapping. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OSM présent dans l'Est Républicain
A travers l'initiative des Amis du Muséum de Gray, on parle d'OSM dans l'Est Républicain de ce jour. http://www.estrepublicain.fr/haute-saone/2012/11/28/observatoire-environnementaliste http://www.museum-gray.org/wikitest/index.php/Observatoire_des_d%C3%A9p% C3%B4ts_sauvages_de_d%C3%A9chets d'autre part je m'approche de la fin en ce qui concerne l'import du bâti dans le département de la Haute-Saône. http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Sa%C3%B4ne salut à tous Jeff ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le cas des 'stop_area' qui ne comportent qu'un noeud 'stop' et un noeud (ou une surface) 'platform', comme c'est le cas pour cet arrêt-terminushttp://www.openstreetmap.org/browse/relation/2434061, est pris en compte. Dans le cas où l'arrêt est minimaliste (pas d'Abribus), le noeud 'platform' est à placer là où se trouve le poteau des horaires, qui est le minimum obligatoire, pour que les passagers sachent où attendre le bus. Francescu Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 28 novembre 2012 13:54, Jean Couteau cout...@codelutin.com a écrit : Je me suis dit exactement la même chose. Ça m'intéresse pas mal de regarder, mais j'utilise Idea... Et bin c'est bon, non ? Idea comprend maven sauf erreur, donc, justement, c'est encore mieux ?... Graddle aussi pourrait aller je crois, si l'on veut faire exotique. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Oui, je travaille avec Eclipse et je n'ai pas encore déployé de jar, mais ce sera très prochainement fait ! Francescu Le 28 novembre 2012 13:21, Ista Pouss ista...@gmail.com a écrit : Autant que je puisse comprendre les choses, le How to launch du README concerne JOSM ; si tu confirmes, peut être as-tu fait un copié collé ? Cela dit cela rend les choses plus difficile pour OSM_checkTransportRelations. Il faudrait que le README de OSM_checkTransportRelations explique comment lancer OSM_checkTransportRelations, et non pas JOSM :-) Peut être pourrais-tu trouver un nom de projet plus court ? Je n'ai pas trouvé de jar exécutable. Comme j'ai trouvé les sources (suis-je formidable) j'imagine qu'il faut compiler en local ton projet. Mais, apparamment, tu utilises eclipse. Je n'ai rien contre mais moi j'utilise netbeans :-) Certes je pourrais m'adapter facilement, mais bon... ne pourrais-tu pas fournir le jar, ou faire tes projets avec maven ? Cordialement. Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Bonjour à tous, Depuis quelques temps, je travaille à l'écriture d'une application nommée OSM_checkTransportRelationshttps://github.com/windu2b/OSM_checkTransportRelations(codée en Java et basée sur les classes-métier de JOSM) destinée à valider les relations concernant les relations de 'type=route' (bus, tram, métro, ...). Bien que loin d'être aussi aboutie que je le souhaite, je vous la présente tout de même car je viens de finir une première version utilisable, et disponible icihttps://github.com/windu2b/OSM_checkTransportRelations/tags . *Concrètement, en quoi consiste-t-elle ?* Tout simplement à vérifier : * la présence des éléments attendus dans une telle relation (ways, stops et platforms) ; * que le bon rôle est associé aux éléments le cas échéant ; * qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; * qui les ways qui composent l'itinéraire sont continues ; * ... La liste des règles testées se trouve ici, et je vous invite à m'en soumettre.http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation http://wiki.openstreetmap.org/wiki/User:Windu.2b#R.C3.A8gles_de_validation *Que manque-t-il ?* Beaucoup de choses ! * améliorer le code ; * améliorer les tests unitaires ; * avoir une meilleure granularité pour les logs (au minimum NOTICE, WARNING, ERROR) ; * ajouter d'autres règles ; * ajouter la prise en compte des relations 'type=route_master', qui contiennent plusieurs relations 'type=route' ; * pouvoir fournir en paramètre des listes de relations à tester (par ex., sous la forme : 1;3;4-8 pour tester les relations, 1, 3 et de 4 à 8); * pour chaque relation à tester, accepter en paramètre une liste ordonnée des arrêts par lesquels l'itinéraire est censé passer, afin de vérifier qu'aucun arrêt n'a été oublié ou n'est en trop ; * ... Je vous invite à tester mon appli (vous trouverez sur cette page des relations qui ont besoin d'être vérifiéeshttp://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun), à l'améliorer si vous êtes développeurs, à me remonter vos questions/demandes/critiques, ... soit par mail, soit directement sur Github https://github.com/windu2b/OSM_checkTransportRelations/issues. Francescu ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Déjà limiter dans le nom uniquement aux relations alors que ce projet pourrait couvrir d'autres éléments relatifs aux transports, pourquoi pas juste Transmose, pour rappeler aussi Osmose ? jTransmose pour rappeler que c'est du Java ? Transpose, OpenTranspose, jOpenTranspose (JOT en abrégé)... Le 28 novembre 2012 13:54, Jean Couteau cout...@codelutin.com a écrit : Le 28/11/2012 13:21, Ista Pouss a écrit : Autant que je puisse comprendre les choses, le How to launch du README concerne JOSM ; si tu confirmes, peut être as-tu fait un copié collé ? Cela dit cela rend les choses plus difficile pour OSM_checkTransportRelations. Il faudrait que le README de OSM_checkTransportRelations explique comment lancer OSM_checkTransportRelations, et non pas JOSM :-) Peut être pourrais-tu trouver un nom de projet plus court ? Je n'ai pas trouvé de jar exécutable. Comme j'ai trouvé les sources (suis-je formidable) j'imagine qu'il faut compiler en local ton projet. Mais, apparamment, tu utilises eclipse. Je n'ai rien contre mais moi j'utilise netbeans :-) Certes je pourrais m'adapter facilement, mais bon... ne pourrais-tu pas fournir le jar, ou faire tes projets avec maven ? Je me suis dit exactement la même chose. Ça m'intéresse pas mal de regarder, mais j'utilise Idea... Jean ___ 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] Outil de vérification des relations de type transports publics
Le 28 novembre 2012 13:46, Philippe Verdy verd...@wanadoo.fr a écrit : Réflexion faite, un arrêt de bus a toujours au moins un noeud sur la voie. S'il n'y a qu'un poteau indicateur cela reste suffisant pour une platform et on le place à côté de la voie et pas sur la voie. Il y a donc au moins deux éléments (pour un arrêt dans un seul sens) une relation se justifie. En revanche sur un arrêt bidirectionnel, il n'y a pas forcément un poteau des deux côtés, le même poteau indicateur est valable pour les deux sens sur une rue ou route pas trè large qu'on ne veut pas encombrer pour les arrêts occasionnels à la demande. Je ne suis pas d'accord avec ça, pour une raison tout simple : les horaires de passage dans un sens et dans l'autre n'ont rien de commun. Et cela peut paraître perturbant (et même, ça ne lui viendrait pas à l'esprit) pour l'usager que de devoir aller regarder les horaires de passage sur le poteau d'en face. À ma connaissance, même les arrêts les plus minimalistes ont au moins un poteau avec un nom d'arrêt et des horaires de lignes. Le seul cas serait celui des arrêts à la demande sans poteau (autorisés souvent seulement pour la descente mais non marqués car se faisant devant une propriété privée située sur le trajet) ou juste connus à certains endroits (par exemple au stop d'un carrefour rural). Plus jeune c'est comme ça que je prenais le bus tous les jours sur une route de campagne : il fallait faire près d'un kilomètre à pied pour rejoindre l'arrêt mais le bus s'arrêtait devant chez moi à la demande, uniquement pour descendre, mais pas pour monter car il n'y avait pas de plateforme d'attente et pas moyen de se signaler assez tôt à distance ; un arrêt a été fait plus tard plus près lorsque d'autres constructions sont apparues autour. Je me demande si le schéma a prévu les arrêts interdits à la montée ou la descente (cela concerne même des arrêts avec plateforme d'attente pour d'autres lignes) : souvent en fin de ligne le bus ne prend plus personne et ce n'est pourtant pas encore le terminus, cela limite le nombre d'arrêts nécessaires quand personne ne descend là et cela accélère la desserte si seulement des passagers descendent, mais souvent il n'y a aucune plateforme d'attente sécurisée ou non gênante pour les autres piétons, ou si la plateforme est là c'est pour ceux qui attendent une autre ligne ou vont y faire une correspondance en descendant de la première ligne à descente seulement... Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 28 novembre 2012 14:10, Philippe Verdy verd...@wanadoo.fr a écrit : Déjà limiter dans le nom uniquement aux relations alors que ce projet pourrait couvrir d'autres éléments relatifs aux transports, pourquoi pas juste Transmose, pour rappeler aussi Osmose ? jTransmose pour rappeler que c'est du Java ? Transpose, OpenTranspose, jOpenTranspose (JOT en abrégé)... Transmose me plait bien, mais je reste ouvert à la discussion :-) Francescu Le 28 novembre 2012 13:54, Jean Couteau cout...@codelutin.com a écrit : Le 28/11/2012 13:21, Ista Pouss a écrit : Autant que je puisse comprendre les choses, le How to launch du README concerne JOSM ; si tu confirmes, peut être as-tu fait un copié collé ? Cela dit cela rend les choses plus difficile pour OSM_checkTransportRelations. Il faudrait que le README de OSM_checkTransportRelations explique comment lancer OSM_checkTransportRelations, et non pas JOSM :-) Peut être pourrais-tu trouver un nom de projet plus court ? Je n'ai pas trouvé de jar exécutable. Comme j'ai trouvé les sources (suis-je formidable) j'imagine qu'il faut compiler en local ton projet. Mais, apparamment, tu utilises eclipse. Je n'ai rien contre mais moi j'utilise netbeans :-) Certes je pourrais m'adapter facilement, mais bon... ne pourrais-tu pas fournir le jar, ou faire tes projets avec maven ? Je me suis dit exactement la même chose. Ça m'intéresse pas mal de regarder, mais j'utilise Idea... Jean ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Justement, on ne peut pas prendre le bus à tous les arrêts. Pourtant il y a bien un arrêt et il n'est pas toujours matérialisé par un poteau, mais figure sur les plans et horaires, ce n'est pas juste un arrêt d'agrément privé. Pendant des années j'ai pris le bus comme ça quand j'étais plus jeune à un arrêt devant un chemin privé mais seulement en descente, et sans poteau mais tout à fait officiel et pouvant être utilisé par n'importe qui voulant descendre au même endroit. Le 28 novembre 2012 14:08, Francescu GAROBY windu...@gmail.com a écrit : Le cas des 'stop_area' qui ne comportent qu'un noeud 'stop' et un noeud (ou une surface) 'platform', comme c'est le cas pour cet arrêt-terminushttp://www.openstreetmap.org/browse/relation/2434061, est pris en compte. Dans le cas où l'arrêt est minimaliste (pas d'Abribus), le noeud 'platform' est à placer là où se trouve le poteau des horaires, qui est le minimum obligatoire, pour que les passagers sachent où attendre le bus. Francescu Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Non, pour les arrêts réservés à la descente il n'y a même pas les horaires de ligne affichés sur place, et pas toujours de poteau non plus, on doit se signaler pour descendre à cet endroit (il faut savoir ça sur les horaires à la montée). Je pense que ça existe encore pour les lignes de bus rurales où peu de monde descend et pas à tous les passages du bus. Le 28 novembre 2012 14:12, Francescu GAROBY windu...@gmail.com a écrit : Le 28 novembre 2012 13:46, Philippe Verdy verd...@wanadoo.fr a écrit : Réflexion faite, un arrêt de bus a toujours au moins un noeud sur la voie. S'il n'y a qu'un poteau indicateur cela reste suffisant pour une platform et on le place à côté de la voie et pas sur la voie. Il y a donc au moins deux éléments (pour un arrêt dans un seul sens) une relation se justifie. En revanche sur un arrêt bidirectionnel, il n'y a pas forcément un poteau des deux côtés, le même poteau indicateur est valable pour les deux sens sur une rue ou route pas trè large qu'on ne veut pas encombrer pour les arrêts occasionnels à la demande. Je ne suis pas d'accord avec ça, pour une raison tout simple : les horaires de passage dans un sens et dans l'autre n'ont rien de commun. Et cela peut paraître perturbant (et même, ça ne lui viendrait pas à l'esprit) pour l'usager que de devoir aller regarder les horaires de passage sur le poteau d'en face. À ma connaissance, même les arrêts les plus minimalistes ont au moins un poteau avec un nom d'arrêt et des horaires de lignes. Le seul cas serait celui des arrêts à la demande sans poteau (autorisés souvent seulement pour la descente mais non marqués car se faisant devant une propriété privée située sur le trajet) ou juste connus à certains endroits (par exemple au stop d'un carrefour rural). Plus jeune c'est comme ça que je prenais le bus tous les jours sur une route de campagne : il fallait faire près d'un kilomètre à pied pour rejoindre l'arrêt mais le bus s'arrêtait devant chez moi à la demande, uniquement pour descendre, mais pas pour monter car il n'y avait pas de plateforme d'attente et pas moyen de se signaler assez tôt à distance ; un arrêt a été fait plus tard plus près lorsque d'autres constructions sont apparues autour. Je me demande si le schéma a prévu les arrêts interdits à la montée ou la descente (cela concerne même des arrêts avec plateforme d'attente pour d'autres lignes) : souvent en fin de ligne le bus ne prend plus personne et ce n'est pourtant pas encore le terminus, cela limite le nombre d'arrêts nécessaires quand personne ne descend là et cela accélère la desserte si seulement des passagers descendent, mais souvent il n'y a aucune plateforme d'attente sécurisée ou non gênante pour les autres piétons, ou si la plateforme est là c'est pour ceux qui attendent une autre ligne ou vont y faire une correspondance en descendant de la première ligne à descente seulement... Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas spécifiquement réservé) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 28/11/2012 14:09, Ista Pouss a écrit : Le 28 novembre 2012 13:54, Jean Couteau cout...@codelutin.com mailto:cout...@codelutin.com a écrit : Je me suis dit exactement la même chose. Ça m'intéresse pas mal de regarder, mais j'utilise Idea... Et bin c'est bon, non ? Idea comprend maven sauf erreur, donc, justement, c'est encore mieux ?... Graddle aussi pourrait aller je crois, si l'on veut faire exotique. A oui c'est sûr, pas de soucis de ce côté là. D'ailleurs, si je trouve le temps (que je n'ai pas vraiment en ce moment), j'essaierai de maveniser tout ça... signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
En plus de ça ce n'est pas parce que les horaires de passages sont différents dans chaque sens qu'il n'y a pas sur la même fiche les horaires dans les deux sens. On voit bien que tu n'as jamais pris le bus en milieu rural sur les petites lignes : c'est la même fiche horaire dans les deux sens et pour tous les arrêts de la ligne, qui est affichée à tous les arrêts comme aux points d'informations où elles sont distribuées, c'est plus simple de les mettre à jour avec un même imprimé. Les horaires de plus ne sont donnés que de façon indicatives pour certains arrêts et pas tous, mais le plan sur la fiche les mentionne tous avec les durées de trajet moyens estimées dans chaque sens en mentionnant seulement les horaires de départ et d'arrivée estimée de chaque terminus. Le 28 novembre 2012 14:12, Francescu GAROBY windu...@gmail.com a écrit : Le 28 novembre 2012 13:46, Philippe Verdy verd...@wanadoo.fr a écrit : Réflexion faite, un arrêt de bus a toujours au moins un noeud sur la voie. S'il n'y a qu'un poteau indicateur cela reste suffisant pour une platform et on le place à côté de la voie et pas sur la voie. Il y a donc au moins deux éléments (pour un arrêt dans un seul sens) une relation se justifie. En revanche sur un arrêt bidirectionnel, il n'y a pas forcément un poteau des deux côtés, le même poteau indicateur est valable pour les deux sens sur une rue ou route pas trè large qu'on ne veut pas encombrer pour les arrêts occasionnels à la demande. Je ne suis pas d'accord avec ça, pour une raison tout simple : les horaires de passage dans un sens et dans l'autre n'ont rien de commun. Et cela peut paraître perturbant (et même, ça ne lui viendrait pas à l'esprit) pour l'usager que de devoir aller regarder les horaires de passage sur le poteau d'en face. À ma connaissance, même les arrêts les plus minimalistes ont au moins un poteau avec un nom d'arrêt et des horaires de lignes. Le seul cas serait celui des arrêts à la demande sans poteau (autorisés souvent seulement pour la descente mais non marqués car se faisant devant une propriété privée située sur le trajet) ou juste connus à certains endroits (par exemple au stop d'un carrefour rural). Plus jeune c'est comme ça que je prenais le bus tous les jours sur une route de campagne : il fallait faire près d'un kilomètre à pied pour rejoindre l'arrêt mais le bus s'arrêtait devant chez moi à la demande, uniquement pour descendre, mais pas pour monter car il n'y avait pas de plateforme d'attente et pas moyen de se signaler assez tôt à distance ; un arrêt a été fait plus tard plus près lorsque d'autres constructions sont apparues autour. Je me demande si le schéma a prévu les arrêts interdits à la montée ou la descente (cela concerne même des arrêts avec plateforme d'attente pour d'autres lignes) : souvent en fin de ligne le bus ne prend plus personne et ce n'est pourtant pas encore le terminus, cela limite le nombre d'arrêts nécessaires quand personne ne descend là et cela accélère la desserte si seulement des passagers descendent, mais souvent il n'y a aucune plateforme d'attente sécurisée ou non gênante pour les autres piétons, ou si la plateforme est là c'est pour ceux qui attendent une autre ligne ou vont y faire une correspondance en descendant de la première ligne à descente seulement... Le 28 novembre 2012 13:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 12:13, Francescu GAROBY windu...@gmail.com a écrit : Verifier (..) qu'une relation 'stop_area' existe pour chaque arrêt, et que les éléments composant ledit arrêt (stop et platform(s)) font bien partie d'une même relation 'stop_area' ; Même s'il n'y a qu'un seul élément à mettre dans la relation ? Par exemple un arrêt dans un seul sens (voire commun aux deux sens de trajet, soit sur un espace central, soit sur une voie en circulation alternée, soit quand l'arrêt est sur un petit décrochement en Y, où le bus entre et ressort dans le même sens en faisant demi-tour, ce qui arrive assez souvent dans les centres commerciaux où un bus entre et ressort par la même voie bidirectionnelle), et sans platforme (juste le poteaux indicateur de l'arrêt, pas de plateforme d'attente, souvent même pas un abri ni aucun banc) ? Le seul noeud stop n'est-il pas suffisant par lui-même sans justifier une stop_area alors que rien n'indique clairement la zone d'arrêt qui est directement sur la voie normale et non marqué réservé pour les arrêts-minute (pas les stationnements) des bus? (ou un arrêt-minute à la demande sur certaines dessertes ferroviaires locales avec un quai peu ou pas marqué par une élévation par rapport à la voie, le train ayant un simple marche-pied, ou bien un bateau ou bac ou navette où il n'y a pas d'emplacement de quai clairement défini, le noeud étant indicatif d'une position usuelle puisque là encore c'est le bateau qui déploie sa propre passerelle ou son marche-pied devant un quai bas qui ne lui est pas
Re: [OSM-talk-fr] Fwd: [Maps-l] Wikimedia/mapping event in Europe early next year?
Je me suis inscrit sur la liste maps-I et il y a quelqu'un qui propose Berlin là-bas. Personnellement je préfèrerais que ce soit à Bruxelles. Comme ça je pourrai y aller! Polyglot 2012/11/28 Philippe Verdy verd...@wanadoo.fr Si c'est juste quelque part en Europe, ce sera dans un seule grande capitale accessible facilement depuis un autre pays voisin. Cela limite le choix à quelques grandes villes européennes bien desservies : Paris, Bruxelles, Francfort, Milan, voire même Londres (ils ont des tonnes de projets intéressants là-bas et depuis longtemps, et ils n'auront pas le soucis de la traduction immédiate et pourront même diffuser un live bien suivi par plein de monde). Sinon en France cela pourrait aussi être Nice si l'accent est mis sur WikiVoyage. L'Espagne est aussi une belle destination (Barcelone), mais elle est moins bien desservie sauf par l'avion, et moins centrale pour les voisins (hormi la France) et l'espagnol n'est pas aussi accessible et la communauté OSM espagnole n'est pas au top en ce moment. Je pense donc que ce sera plutôt Bruxelles si ce n'est pas Londres qui a tout ce qu'il faut pour organiser ça. 2012/11/28 Ab_fab gamma@gmail.com Bonjour, Wikimedia envisage de monter en début d'année prochaine un rassemblement relatif au développement de l'extension geodata quelque part en Europe ainsi que le mapping. ___ 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] OSM présent dans l'Est Républicain
Super, Ils sont dynamiques ces hauts saônois ! Sympa au passage votre appli : http://carte.museum-gray.org/ well done -- View this message in context: http://gis.19327.n5.nabble.com/OSM-present-dans-l-Est-Republicain-tp5738014p5738036.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM présent dans l'Est Républicain
sauf qu'elle disfonctionne et que je n'ai pas pris le temps de voir ce qui cloche les meilleurs exemples d'utilisation de Chimère restent à mon sens http://rennes.carte-ouverte.org/ et les cartes brestoises. Brest a d'ailleurs financé du développement (POI pouvant appartenir à plusieurs catégories et ayant une durée dans le temps) sur Chimère. Le mercredi 28 novembre 2012 à 06:47 -0800, partir-en-vtt a écrit : Super, Ils sont dynamiques ces hauts saônois ! Sympa au passage votre appli : http://carte.museum-gray.org/ well done -- View this message in context: http://gis.19327.n5.nabble.com/OSM-present-dans-l-Est-Republicain-tp5738014p5738036.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Salut, J ai recupere une copie de tous les objets OSM crees ou modifies par CEDRIC007 tels qu ils sont encore dans la base J ai aussi une liste de tous les objets qu il a cree/supprimes/modifies Cela permet d avoir une sauvegarde dans un coin des donnees au cas ou l on veuille comparer apres le passage du redaction bot. le fichier etant au format OSM il est possible de l ouvrir avec Josm, cela donne un acces facile a l historique et se supperpose facilement avec les donnees de la base, on peut imaginer de les supprimer de la sauvegarde au fur et a mesure du remapping. Il me semble que les fichiers OSM se chargent dans OpenLayers donc il y a peut etre moyen de les superposer aux tuiles OSM pour obtenir un rendu dezoome comme le propose Sly. Je les envoie en prive a Marc plutot que les mettre a disposition de tous histoire d eviter les tentations de recopi(ll)age. Julien De : Christian Quest cqu...@openstreetmap.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 28 novembre 2012 12h22 Objet : Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes Le 28 novembre 2012 12:10, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 novembre 2012 11:24, khris78 ch...@gallioz.fr a écrit : Concernant le ps: les tirades de Philippe ne me derangent pas plus que ça, et expriment souvent un point de vue intéressant. C'est justement ce point de vue que je combats ici : ce n'est pas parce que le problème a été signalé deux ans auparavant puis oublié qu'il en devient moins urgent. Je n'ai pas dit que c'était moins urgent, mais s'il y a eu 2 ans de réflexion et aucune solution, c'est d'abord parce que le problème n'était pas simple à régler et qu'aujourd'hui il n'est pas plus simple pour autant maintenant. Techniquement, le problème est beaucoup plus simple à régler aujourd'hui en utilisant une évolution du robot de rédaction. C'est cet outil qui va permettre de conserver ce qui peut l'être. Il y a deux ans, cet outil n'existait tout simplement pas (peut être même pas en rêve). Oui, il y aura des dégâts et des miettes et la meilleure chose que l'on pourra faire à mon avis sera d'utiliser HOT Task Manager pour se répartir les zones à refaire sans se marcher sur les pieds. En se concentrant tous sur cette zone ça devrait vite être réglé. Je ne vois pas comment on peut faire du nettoyage avec la situation actuelle. Cela nécessite de retrouver les objets impactés, ce qui n'est pas facile pour ceux modifiées depuis (et en 2 ans, ça doit en faire beaucoup) et on risque plus d'avoir l'effet inverse: corriger des objets qui risquent d'être détruits par le bot (expérience que je retire de juillet dernier). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Grosse suppression de données autour de valenciennes
On mercredi 28 novembre 2012, THEVENON Julien wrote: Salut, J ai recupere une copie de tous les objets OSM crees ou modifies par CEDRIC007 tels qu ils sont encore dans la base J ai aussi une liste de tous les objets qu il a cree/supprimes/modifies Super \o/ ! les perds pas ;-) Je me rappel plus trop ce qui avait été proposé comme méthode de re-mapping, mais est-ce que ça veut dire qu'on peut lancer la rédaction, pour ensuite enclencher le re-mapping des trous ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réf.: Re: Grosse suppression de données autour de valenciennes
-- Le mer. 28 nov. 2012 17:55 HNEC, sly (sylvain letuffe) a écrit : On mercredi 28 novembre 2012, THEVENON Julien wrote: Salut, J ai recupere une copie de tous les objets OSM crees ou modifies par CEDRIC007 tels qu ils sont encore dans la base J ai aussi une liste de tous les objets qu il a cree/supprimes/modifies Super \o/ ! les perds pas ;-) Je me rappel plus trop ce qui avait été proposé comme méthode de re-mapping, mais est-ce que ça veut dire qu'on peut lancer la rédaction, pour ensuite enclencher le re-mapping des trous ? Les rapports html sont complets par contre pour la partie sauvegarde de donnee j ai fait une optimisation assez aggressive sur mon code pour eviter les doublons entre objets crees et modifies pour limiter les appels a l API. vu que ca n a pris que 2h a s executer je pensais le faire retourner demain matin sans optim histoire d etre sur de l exhaustivite. Ca peut attendre jusque la ?(je peux pas le refaire tourner ce soir). Si necessaire je peux peut etre aussi dumper les objets qu il a supprime tels qu ils etaient au moment de la suppression mais je suis pas sur de l utilite Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, S'il existe des débats inter-frontaliers sur l'utilisation ou non des tirets cadratins ou semi-cadratins (et à mon avis le débat s'arrête quand on se rend compte que la désignation dépend de la langue), je suis contre l'idée de supprimer ces caractères typographiques français là où en France ils ont toute leur place, car ils ont un sens. Laissez-moi citer ces exemples de stations de métro, de gares ou d'arrêts de bus, où ce caractère désigne l'union de deux entités qui n'ont pas d'autre raison d'être liés autrement que par leur rapprochement géographique ou pour préciser une position : Sèvres — Babylone (rue de Sèvres, rue de Babylone) Réaumur — Sébastopol (rue Réaumur, boulevard de Sébastopol) Marcadet — Poissonniers (rue Marcadet, rue des Poissonniers) Palais Royal — Musée du Louvre (deux bâtiments distincts) Pierrefitte — Stains (villes proches) Le Raincy — Villemomble — Montfermeil (villes proches pouvant être rejointes par cet arrêt SNCF) Aubervilliers — Pantin — Quatre Chemins (villes proches et lieu-dit) Maisons-Alfort — Stade (dans cette ville, plus précisément près du stade) Charenton — Écoles (à Charenton-le-Pont, à proximité de l'école Aristide Briand et sans doute d'autres) alors que le trait d'union, comme son nom l'indique, unit ; notez la différence dans la lecture de ces stations : Haussmann — Saint-Lazare (boulevard Haussmann, gare Saint-Lazare) Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) Ce sont les règles édictées par l'Académie française, et reprises sur le terrain par les opérateurs dont la RATP. Et il me semble que ce qui se trouve sur le terrain fait foi dans OpenStreetMap (que l'on n'écrit pas Open Street Map ou Open-Street-Map). Si la raison de supprimer ce caractère se trouve dans un outil de recherche, alors non ! Comme dans d'autres situations, c'est à l'outil de s'adapter et de savoir remplacer un tiret par un autre pour trouver des résultats, tout comme il doit savoir remplacer un e minuscule ou majuscule par un é ou un è. Je ne suis pas favorable à cette suppression, tout comme vous n'accepteriez pas de supprimer les accents. Teuxe PS. Pour les sous-titres (Parc de la Villette, Tour Eiffel, Place Aristide Briand, etc.), j'imagine que alt_name=* fait l'affaire ? - Mail original - De: sly (sylvain letuffe) li...@letuffe.org À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mardi 27 Novembre 2012 22:20:29 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins On mardi 27 novembre 2012, Vincent de Chateau-Thierry wrote: En revanche, je suis tout à fait contre l'idée de coller un tag name à des limites administratives qui ne sont que des limites (et pas une route, ou une rivière par ex.) Pareil. Toutefois, j'entends les arguments que tu as indiqué connaître, et si je ne mettrais pas de nom, je m'abstiendrais de changer le choix des autres en l'état des outils/éditeurs. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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 des tirets cadratins
Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. A ce propos, as-tu des caractères chinois ou arabes sur ton clavier ? Dans ce cas ils n'auraient pas droit de cité dans OSM ? Teuxe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Bonsoir Je viens de tester cette application Web et je pense avoir trouvé un petit bug : - Je choisi un lieu à traduire (Par exemple Madrid) - Je commence à le traduire : je tape sur le M - Le champ me propose déjà Madrid - Je choisi la proposition - Je sauvegarde et j'envoie les données - Lorsque je vérifie la traduction, seul le M (taper à l'origine) a été sauvegardé Mon navigateur : Iceweasel (Firefox) 17.0 Pour le reste, c'est super Merci Le mardi 27 novembre 2012 à 13:04 -0800, Emmanel Dewaele a écrit : Bonsoir, Je vous présente Nomino, un modeste éditeur de données OpenStreetMap, dédié à la traduction des noms de lieux en différentes langues. Nomino en quelques points: - Une application web, sans installation et utilisable sur toutes plateformes (même si pour l'heure ça donne moyen sur téléphone et tablette) - Une application simple: l'interface se veut dépouillée et utilisable par des contributeurs débutants sans lecture de documentation préalable - Une application efficace: au lieu d'ouvrir toutes les données sur une zone, comme le font classiquement JOSM et Potlatch, on ne charge que certains objets individuellement pour éditer les tags de type name:**. Même on peut déjà s'identifier sur osm.org et d'enregistrer les modifications, l'éditeur est en version alpha, testez le à vos risques et périls. Un scénario de test: dans la boite Preferences, cliquer sur Toolserver localised maps puis choisir fr (French) dans le menu. La carte s'affiche avec les noms de lieux traduits en français, et donc des noms de lieux non traduits. Si on va par exemple en Russie ou en Ukraine, on trouve beaucoup de villes dont la forme française n'est pas renseignée, il suffit d'ouvrir l'objet et d'entrer le nom de la ville en français. On peut le trouver assez facilement par Wikipédia, en cherchant le nom de la ville dans la langue locale. L'application: http://nomino.comptoir.net Le code source: http://gitorious.org/nomino/nomino Merci beaucoup à Cyrille Giquello et sa superbe bibliothèque pour l'accès à l'API OpenStreetmap: https://github.com/Cyrille37/yapafo Emmanuel -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/28 te...@free.fr: Tu es sûr de ne pas confondre information et mise en page ? La plupart des panneaux de rues sont écrits avec des caractères en majuscule. Ca n'est pas pour autant qu'on recopie bêtement les noms de rues en majuscule (quoique, certains le font...). L'assertion le terrain fait foi a été plusieurs fois corrigé. C'est en cas de doute, le terrain fait foi. Il arrive aussi que le terrain se trompe, on en a de nombreux exemples dans les archives de cette liste (Clémenceau, par exemple, avec un é sur des arrêts de bus ou même de panneaux de rues). On a eu une discussion similaire sur l'espace dans les ref de routes. Espace, demi-espace, espace insécable, demi-insécable, pas d'espace ? Les subtilités de ces caractères typographiques spéciaux échappent à 99% des contributeurs et utilisateurs de base. Alors je sais bien qu'on peut se la jouer expert en typographie (on a même le droit d'en être un) mais OSM se construit par ou pour un public le plus large et international possible, celui qui n'a jamais entendu parlé de tiret cadratin. Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réf.: Re: Grosse suppression de données autour de valenciennes
Vous pourrez m'envoyer la liste des objets concernés (type+id) ? Je peux l'injecter dans feu le plugin licensechange pour une détection bête et méchante (par id) pour aider au remapping. Le 28 novembre 2012 18:22, sly (sylvain letuffe) li...@letuffe.org a écrit : On mercredi 28 novembre 2012, THEVENON Julien wrote: Ca peut attendre jusque la ?(je peux pas le refaire tourner ce soir). Oulla, on est plus à ça prèt ! C'est juste histoire de battre le fer quand il est chaud, ma hantise étant de voir l'effort, la motiv ou que sais-je s'éssoufler et retourner dans un état létargique. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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 des tirets cadratins
Il ne s'agit pas que d'une mise en page, j'ai précisé qu'il y a une sémantique dans le fait d'utiliser un tiret plutôt qu'un trait d'union. Les exemples me semblaient parlants. La mise en page consisterait au contraire de décider de remplacer ce tiret par un trait d'union par souci de simplicité ou de compatibilité, tout comme par simplicité dans nos e-mails on place des guillemets à l'américaine plutôt que des guillemets à la française. Il est clair que chaque contributeur apporte sa pierre à l'édifice dans la mesure de ses connaissances et de ses moyens. Mais cela ne doit pas pousser la totalité des contributeurs à se limiter au strict minimum, sous prétexte qu'une bonne partie ne soit pas en mesure de faire mieux. Il y a aussi de nombreux exemples à ça : - tous les contributeurs ne savent pas forcément s'il faut écrire D 123 ou D123 et sans doute peu y portent une réelle attention, et pourtant on ne leur interdit pas de participer, on s'arrange pour corriger ; - tous les contributeurs ne savent pas être précis dans leurs tracés, pourtant d'autres corrigent derrière ; - tous les contributeurs ne savent pas importer de cadastre, pourtant certains s'y risquent et d'autres corrigent ; - tous les contributeurs ne sont pas en mesure de faire tourner des scripts de vérifications ou de corrections par des bots (peu sont au courant que des robots font des modifications), et pourtant ces robots et ces scripts existent et sont utilisés par une minorité ; - etc. Suivant cette logique : - Placer un trait d'union est à la portée de tous, et on a le droit d'améliorer. - Placer un tiret pour améliorer le trait d'union est peut-être plus sioux et l'édition sera à la portée d'une minorité, mais volontairement le remplacer par un trait d'union serait une régression. Si on écrit Clemenceau dans la base, c'est qu'une source vérifiable (l'origine du nom propre) nous prouve cette écriture et qu'on a croisé les informations justement parce qu'on a douté. Si on n'a pas d'autre source, alors on se réfère au terrain qui est la seule preuve. Et si quelqu'un passe derrière ce premier contributeur et se rend compte de l'inexactitude, il est en droit de corriger selon ses connaissances et ses références, sans jugement légitime sur les compétences du premier. Teuxe - Mail original - De: Pieren pier...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mercredi 28 Novembre 2012 19:20:21 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins 2012/11/28 te...@free.fr: Tu es sûr de ne pas confondre information et mise en page ? La plupart des panneaux de rues sont écrits avec des caractères en majuscule. Ca n'est pas pour autant qu'on recopie bêtement les noms de rues en majuscule (quoique, certains le font...). L'assertion le terrain fait foi a été plusieurs fois corrigé. C'est en cas de doute, le terrain fait foi. Il arrive aussi que le terrain se trompe, on en a de nombreux exemples dans les archives de cette liste (Clémenceau, par exemple, avec un é sur des arrêts de bus ou même de panneaux de rues). On a eu une discussion similaire sur l'espace dans les ref de routes. Espace, demi-espace, espace insécable, demi-insécable, pas d'espace ? Les subtilités de ces caractères typographiques spéciaux échappent à 99% des contributeurs et utilisateurs de base. Alors je sais bien qu'on peut se la jouer expert en typographie (on a même le droit d'en être un) mais OSM se construit par ou pour un public le plus large et international possible, celui qui n'a jamais entendu parlé de tiret cadratin. Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). 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
[OSM-talk-fr] OpenStreetMap à l'Assemblée Nationale demain
Bonjour @tou[te]s, Je sors de mon LoOoOong tunnel professionnel :( pour vous annoncer que je présenterai les travaux de la communauté OSM à l'Assemblée Nationale demain lors des 8 èmes Rencontres de Décider ensemble. Le thème de la journée sera: Ouverture des données publiques et participation : quels enjeux démocratiques? Je serai entouré de LiberTIC et de Regards Citoyens dans des tables rondes pour sensibiliser notre public et les députés aux enjeux liés à l'OpenData. La table ronde à laquelle je participe a pour thème: Quelle appropriation par le public ? Quelles médiations ? Le programme http://fr.amiando.com/deciderensemble.html?page=846438 Je mettrai les vidéos et documents produits lors de la réflexion autour des enjeux de l'OpenData en ligne dès que j'aurai les liens. En attendant, d'ici la fin de l'année nous serons reçu par Réseau Ferré de France, SNCF TER, SNCF Transilien, la RATP quant à leur participation aux travaux de la communauté (données, financement, logiciels etc ...) Je ne manquerai pas de vous inviter ici même à ces différentes rencontres qui prouvent encore une fois la valeur de nos travaux.Il y a une grande évolution des acteurs (collectivité et entreprise) dans la coproduction des données.Il ne se contentent plus uniquement de livrer ou consommer des données OSM. Ils veulent comprendre nos motivations, orientations et dans la mesure de leur 'possibilités' ;) nous accompagner. Gaël PS: Excuses à celles et ceux à qui je n'ai pas encore répondu, je dépile encore des mails et sms. J'espère finir avant Noël pour les plus urgents. Au Charbon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pour les noms des stations de métro, je peux vous dire qu'il n'y a aucune cohérence dans les données officielles de la RATP. Les noms entre les fichiers publiés et les plans ne sont même pas cohérents alors pour la typographie je crois que c'est pas pour demain ! Lors de l'intégration du fichier opendata de la RATP, j'ai tout remis en cohérence avec espace-trait d'union-espace pour justement différencier ces rapprochements des véritables traits d'union (leur véritable nom*). Ceci a l'avantage d'être cohérent avec ce qui a été fait sur wikipédia. +1 avec Pieren sur la nécessité de rester simple et accessible au plus grand nombre de contributeurs. Il est toujours possible si l'on souhaite suivre les subtilités des règles de typographie de remplacer ces espace-tiret-espace par espace fine insécable-tiret demi cadratin-espace-espace fine insécable. On pourra aussi revoir la capitalisation des noms qui ne respecte sûrement par les règles de telle ou telle académie. * voir: http://fr.wikipedia.org/wiki/Tiret -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] OpenStreetMap à l'Assemblée Nationale demain
Et pour ma part, je serai demain aux Rencontres de l'IGN... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] OpenStreetMap à l'Assemblée Nationale demain
Salut Christian, Tu y es à partir de quelle heure ? J'y serais l'après-midi ;-) René-Luc Le 28/11/2012 20:18, Christian Quest a écrit : Et pour ma part, je serai demain aux Rencontres de l'IGN... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest http://openstreetmap.fr/u/christian-quest ___ 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] [osm-fr CA] OpenStreetMap à l'Assemblée Nationale demain
Ca démarre à 10h, j'y serai toute la journée pour avoir un maximum d'occasion de contacts... d'ailleurs, il faut que je renouvelle mon stock de cartes de visites pour demain ;) Le 28 novembre 2012 20:21, rldhont rldh...@gmail.com a écrit : Salut Christian, Tu y es à partir de quelle heure ? J'y serais l'après-midi ;-) René-Luc Le 28/11/2012 20:18, Christian Quest a écrit : Et pour ma part, je serai demain aux Rencontres de l'IGN... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] OpenStreetMap à l'Assemblée Nationale demain
Et si tu les sens rceptifs, profites en pour leur demander comment ils interprtent les termes "Open Data" concernant leurs donnes, et plus particulirement tout ce qui a un rapport avec les donnes godsiques. Bonne rencontres ! Michel Christian Quest a crit: Et pour ma part, je serai demain aux Rencontres de l'IGN... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réf.: Re: Réf.: Re: Grosse suppression de données autour de valenciennes
je viens de t envoyer l info. si il y a une mise en forme plus pratique pour toi envoie moi un fichier d exemple je pourrais peut etre te generer ca. Julien -- Le mer. 28 nov. 2012 19:30 HNEC, Vincent Privat a écrit : Vous pourrez m'envoyer la liste des objets concernés (type+id) ? Je peux l'injecter dans feu le plugin licensechange pour une détection bête et méchante (par id) pour aider au remapping. Le 28 novembre 2012 18:22, sly (sylvain letuffe) li...@letuffe.org a écrit : On mercredi 28 novembre 2012, THEVENON Julien wrote: Ca peut attendre jusque la ?(je peux pas le refaire tourner ce soir). Oulla, on est plus à ça prèt ! C'est juste histoire de battre le fer quand il est chaud, ma hantise étant de voir l'effort, la motiv ou que sais-je s'éssoufler et retourner dans un état létargique. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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] Nouvel éditeur spécialisé traduction
Bonsoir, L'anomalie est confirmée et corrigée, mais c'est dommage qu'il n'y ait pas d'outil de suivi sur Gitorious. lann wrote Bonsoir Je viens de tester cette application Web et je pense avoir trouvé un petit bug : - Je choisi un lieu à traduire (Par exemple Madrid) - Je commence à le traduire : je tape sur le M - Le champ me propose déjà Madrid - Je choisi la proposition - Je sauvegarde et j'envoie les données - Lorsque je vérifie la traduction, seul le M (taper à l'origine) a été sauvegardé Mon navigateur : Iceweasel (Firefox) 17.0 Pour le reste, c'est super Merci Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914p5738085.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment nommer simplement un groupe d'objet?
Bonjour, Voilà mon petit souci, nommer un groupe de building/parking/voie accès qui forme une résidence machin ou un groupe truc, sans qu'il y ait particulièrement d'objet englobant le tout comme un amenity=*. Pour les groupes scolaire je trouve déjà la solution du landuse pas très élégante, donc je l'exclue ici, sauf que je ne vois pas d'alternative très pertinente ... a part une relation site=housing . Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
