Re: [OSM-talk-fr] Solution pour surveiller les gros changeset ou potentiellement problématiques
Le 24/01/2013 20:50, partir-en-vtt a écrit : Ou alors que le peu de personnes débattant sur le sujet ont tous la même conception du sujet débattu sauf un... Dans tous les cas, on va devoir attendre que le fil s'étoffe un peu... L'espoir fait vivre. -- Marc Sibertmailto:m...@sibert.fr m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modifications en cours sur le tag Power
2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Toute autre clé est dépréciée (notamment power=station) et sont donc appelées à être remplacées au fil de l'eau. http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station Je ne veux pas casser ce bel enthousiasme mais cette décision a déjà été prise une première fois en janvier 2010 ;-) http://lists.openstreetmap.org/pipermail/tagging/2010-January/001146.html Mais c'est comme ça dans OSM. Retirer un ancien tag est toujours une tâche de longue haleine. Le tag power=station est un bon exemple de tag introduit par une communauté locale (les allemands) qui n'avaient pas saisis l'ambiguité de cette mauvaise traduction. D'où l'utilité de passer autant que possible par ces phases de discussions internationales. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 25 janvier 2013 07:33, Art Penteur art.pent...@gmail.com a écrit : Sans ironie, cette fois : Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? oneway=no - risque d'être faux oneway=unknown - ça devrait être une absence de tag oneway fixme:oneway=unknown - pourquoi pas, c'est le moins pire je pense -- 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] Modifications en cours sur le tag Power
Bonjour Pieren :) C'est une bonne indication ça, merci. Une définition assez sérieuse est donnée dans le message suivant. http://lists.openstreetmap.org/pipermail/tagging/2010-January/001148.html En fait, je me demande du coup pourquoi ça n'a pas disparu du wiki à partir de ce moment là (pour la carte on est d'accord que c'est autre chose). On a eu un avis contraire hier soir encore, alors que l'affaire semblait effectivement réglée depuis un certain temps. http://lists.openstreetmap.org/pipermail/tagging/2013-January/012733.html Le modèle ayant déjà quelques années derrière lui, je me suis pour l'instant concentré sur l'actuel. Reprendre tout l'historique reste fastidieux même si chaque tag à sa raison d'être (ou l'a eu à un moment donné). J'en profite également pour signaler l'ajout tu tag circuits=* par polderrunner plus tôt cette semaine. Il permet de lever l’ambiguïté entres cables=* et wires=* en donnant directement le nombre de circuits d'une ligne à haute tension. C'est surtout utile dans le cas de lignes enterrées, où le nombre apparent de câble ne laisse pas voir le nombre de conducteurs et donc le nombre éventuel de circuits. L'information est alors accessible dans les dossiers de d'enquête publique (consultables en mairie en France) ainsi que les tracés précis d'ailleurs. http://wiki.openstreetmap.org/wiki/Key:circuits Cables est là pour donner le nombre de câbles de phase alors que wires donne le nombre de conducteur par phase. http://wiki.openstreetmap.org/wiki/Key:cables http://wiki.openstreetmap.org/wiki/Key:wires Bonne journée, Le 25 janvier 2013 09:51, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Toute autre clé est dépréciée (notamment power=station) et sont donc appelées à être remplacées au fil de l'eau. http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station Je ne veux pas casser ce bel enthousiasme mais cette décision a déjà été prise une première fois en janvier 2010 ;-) http://lists.openstreetmap.org/pipermail/tagging/2010-January/001146.html Mais c'est comme ça dans OSM. Retirer un ancien tag est toujours une tâche de longue haleine. Le tag power=station est un bon exemple de tag introduit par une communauté locale (les allemands) qui n'avaient pas saisis l'ambiguité de cette mauvaise traduction. D'où l'utilité de passer autant que possible par ces phases de discussions internationales. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référencer les entreprises autres consultants sur le site openstreetmap.fr
+1 c'est toujours une bonne chose et une preuve de sérieux que de voir des entreprise utiliser les données OSM de manière professionnelle ! Comme déjà dis il existe plusieurs pages qui listent déjà ce genre d'entreprises, mais l'avantage clair d'en avoir une sur le site osm-fr, c'est qu'elle ne listera que des gens qui travaillent avec les données osm (donc moins de dilution par rapport à l'annuaire du georézo), et à priori qui sont sur la zone géographique france (donc plus ciblé que la liste du wiki) ... Sylvain Le 24 janvier 2013 15:47, partir-en-vtt ad...@partir-en-vtt.com a écrit : Si je comprends bien c'est promouvoir les entreprises qui utilisent/améliorent... les données OSM ? Ça me paraît être une bonne idée étant donné que la licence permet de faire de business. Ce répertoire sera pratique pour les personnes ou instances ayants besoin de ce genre de services. Et vu que le site openstreetmap.fr parle de tout ce qui gravite autour du projet OSM, cela me semble d'autant plus opportun. -- View this message in context: http://gis.19327.n5.nabble.com/Referencer-les-entreprises-autres-consultants-sur-le-site-openstreetmap-fr-tp5746101p5746224.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] OpenStreetMap modélisation et segmentation dynamique
2013/1/24 Arnaud arnaud@gmail.com: Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? Il y a une méthode encore plus simple : représenter le pont lui-même sans toucher à la route. Il y a la méthode du simple way superposé à la route mais c'est mal suporté par les éditeurs (et les contributeurs qui ne les voient pas). Il y a alors la méthode de tracer le tablier du pont avec un polygone. C'est plus facile depuis qu'on dispose d'images aériennes en haute résolution. Mais ça n'est pas le cas partout. L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent mal aux tunnels qui, eux, nécessitent pratiquement toujours une segmentation du highway pour identifier les changements d'attributs comme maxspeed et/ou maxheight. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Dans le doute, abstiens-toi... de mettre un tag Pythagore aurait pu terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren pier...@gmail.com a écrit : 2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) -- 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] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 10:37, Pieren pier...@gmail.com a écrit : L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent mal aux tunnels qui, eux, nécessitent pratiquement toujours une segmentation du highway pour identifier les changements d'attributs comme maxspeed et/ou maxheight. Tout comme certains ponts nécessitent une segmentation pour un changement de PTAC max ou un changement de largeur de la chaussée (généralement un rétrécissement). Je suis plutôt de l'avis de Philippe, utiliser des relations pour mettre en correspondance plusieurs éléments me semble plus accessible que de mettre plusieurs segments l'un sur l'autre. Il faut qu'il y ai une liaison entre ces composants au niveau de la base de données, sinon rien n'indiquera que la route passe effectivement sur le pont. -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
OK. Donc je n'aurais pas du associer le oneway=no au acces=yes. Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. Doit-on, peut-on aller en discuter sur d'autres mailing-listes, modifier la page wiki/Key:oneway pour que cela soit plus clairement dit, et traduire cette page en Français ? Art. Le 25 janvier 2013 10:50, Christian Quest cqu...@openstreetmap.fr a écrit : Dans le doute, abstiens-toi... de mettre un tag Pythagore aurait pu terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren pier...@gmail.com a écrit : 2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) -- 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] OpenStreetMap modélisation et segmentation dynamique
2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Il faut qu'il y ai une liaison entre ces composants au niveau de la base de données, sinon rien n'indiquera que la route passe effectivement sur le pont. Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Quant à la remarque de Philippe, je suis désolé, je n'ai pas compris (comme souvent). Ou alors, c'est lui qui n'a toujours pas compris la distinction entre 'roles' et 'tags' dans les relations. Les roles 'from', 'to' sont déjà couramment utilisés dans les turn_restrictions... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référencer les entreprises autres consultants sur le site openstreetmap.fr
Bon, vu les avis unanimes, je commence une page pour les Partenaires d'OSM. Je proposerais au CA d'indiquer le soutient à l'asso dans un second temps. Par défaut, je classe par ordre alphabétique. Il s'agit d'une démarche volontaire de la part des partenaires intéressés, je n'irais pas gonfler la page avec des info prises sur vos sites pro ou sur le wiki. Si vous êtes d'accord, merci de me transmettre, Nom de l'entreprise (le libellé de l'activité ou autres) L'adresse postale tel / fax / mail (publics) site web un logo pas trop gros (env 100 à 200/300 px de coté) Une profession de foi (si possible en html de base pour l'intégration) Envoyez moi tout ça à msib...@openstreetmap.fr que j'intègre. A+ Le 24 janvier 2013 10:52, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Je profite de ma propre création d'activité pro (EIRL) pour lancer la question de la publicité des entrepreneurs français autour d'OSM. En clair : peut-on ajouter une page sur le site openstreetmap.fr avec la liste des professionnels qui travaillent avec/autour d'OSM avec pour chacun d'eux une sorte de profession de foi. Je sais que pour certains, le mélange asso / pro, projet libre / business peut soulever des questions, je préféré donc lancer un mini débat sur le sujet. Note : je suis à même de maintenir la page. A+ -- Marc Sibert m...@sibert.fr -- Marc Sibert msib...@openstreetmap.fr (en plus ça marche, hé, hé, merci Christian) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
2013/1/25 Art Penteur art.pent...@gmail.com: Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. On revient à la discussion d'il y a 9 mois (avec le même initiateur ;-) Pour motorway, il n'y a pas consensus. C'est pourquoi le wiki donne le oneway=yes comme valeur implicite ET comme 'usefull combination' (résultat d'une guerre d'édition sur le wiki et aux particularismes de certains pays). En fait, il n'y a consensus que pour les roundabout. L'absence de tag crée un doute mais le doute doit profiter à l'accusé. On part du principe général que tout ce qui n'est pas interdit est autorisé (principe qui ne s'applique pas dans quelques pays malheureusement). Et en général, les panneaux routiers s'appliquent surtout à nous indiquer ce qui est interdit (il y a très peu de panneaux 'oneway=no' ou 'motor_vehicle=yes'). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] Re: Référencer les entreprises autres consultants sur le site openstreetmap.fr
Je pense qu'il faut avoir une liste très neutre et light. Pour moi; - nom, coordonnées (avec lien site web/mail) - éventuellement le type de presta proposée et encore Ni logo, ni profession de foi ou autre, ça c'est à mettre sur le site de l'entreprise. Ca serait tomber plus ou moins dans de la publicité alors que je pense qu'il faut rester au niveau de l'information: il y a des entreprises, les voici, contactez-les pour plus de renseignements. Le 25 janvier 2013 11:38, Marc SIBERT m...@sibert.fr a écrit : Bon, vu les avis unanimes, je commence une page pour les Partenaires d'OSM. Je proposerais au CA d'indiquer le soutient à l'asso dans un second temps. Par défaut, je classe par ordre alphabétique. Il s'agit d'une démarche volontaire de la part des partenaires intéressés, je n'irais pas gonfler la page avec des info prises sur vos sites pro ou sur le wiki. Si vous êtes d'accord, merci de me transmettre, Nom de l'entreprise (le libellé de l'activité ou autres) L'adresse postale tel / fax / mail (publics) site web un logo pas trop gros (env 100 à 200/300 px de coté) Une profession de foi (si possible en html de base pour l'intégration) Envoyez moi tout ça à msib...@openstreetmap.fr que j'intègre. A+ Le 24 janvier 2013 10:52, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Je profite de ma propre création d'activité pro (EIRL) pour lancer la question de la publicité des entrepreneurs français autour d'OSM. En clair : peut-on ajouter une page sur le site openstreetmap.fr avec la liste des professionnels qui travaillent avec/autour d'OSM avec pour chacun d'eux une sorte de profession de foi. Je sais que pour certains, le mélange asso / pro, projet libre / business peut soulever des questions, je préféré donc lancer un mini débat sur le sujet. Note : je suis à même de maintenir la page. A+ -- Marc Sibert m...@sibert.fr -- Marc Sibert msib...@openstreetmap.fr (en plus ça marche, hé, hé, merci Christian) -- 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] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 05:31, Philippe Verdy verd...@wanadoo.fr a écrit : Le 24 janvier 2013 21:20, Arnaud arnaud@gmail.com a écrit : Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? Je m'explique, en gardant le modèle précédent : N1 - N2 - N3 N4 Relation tunnel : yes from : N2 to : N3 Les avantages sont une cohérence des attributs génériques à la route (nom, type, etc.), un objet géographique unique (plus grande rapidité de traitement?), une maintenance attributaire et géographique facilitée. Les inconvénients sont, je pense, un modèle peu compréhensible pour les débutants ainsi que logiquement une augmentation des relations. L'ennui c'est comment représenter et *stabiliser* les deux tags from=N2 et to=N3 : comment désigner les noeuds si ce ne peut pas être un rang dans le chemin ? Il faudrait alors nommer les noeuds ou utiliser leurs IDs. Et il n'y aura aucune vérification de cela. La segmentation n'est pas réellement un problème : on a des relations pour rassembler les fragments de chemin ensembles et de façon stable. Je n'ai peut-être pas bien compris tes remarques, mais tu penses qu'il faudrait utiliser l'ID des nodes pour les désigner aux tags from et to ? C'est pas déjà ce qu'on fait dans je-ne-sais-combien de types de relations ? Comme stop_areahttps://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Après, tu parles de stabilisation. Si tu veux dire par là qu'un tel système est à la merci d'une suppression du node qui servait de 'from' ou de 'to', je suis d'accord avec toi, mais le même problème se pose avec des relations composées de bouts de ways : il suffit quelqu'un fusionne 2 ways contiguës pour que la relation soit cassée (cas fréquent pour les frontières). Francescu ___ 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs
Le vendredi 25 janvier 2013 08:51:56, Fabien a écrit : Bonjour, Salut, Je ne sais pas si c'est le bon endroit pour demander mais j'aurais bien vu les tags tourism=artwork affichés sur cette carte. Si on fait ça sur cette liste, ça pourrait devenir ingérable et surtout, je vais les oublier ;-) Le mieux c'est donc d'aller ici pour le faire : https://github.com/osm-fr/2u/issues (la création d'un compte est rapide) Puis d'être assez précis+aider pour que ça ait des chances d'être fait : - lien vers le wiki qui décrit le truc - proposition d'une icone s'il y a lieu (même type de format/taille que trouvé ici : https://github.com/osm- fr/2u/tree/master/symbols ) - lien vers la carte où se trouve un élément pour que le développeur puisse tester le résultat avant de le valider En clair, plus on simplifie le travail du développeur, et plus on a de chance qu'il le fasse, car le développeur est un feignant ! -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ 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] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Comme le rappelle Pieren, le seul oneway implicite est sur les round_about D'ailleurs, dans JOSM, celui-ci est bien signalé par les flèches du sens de circulation, alors que sur une motorway sans tag oneway il n'y a pas les flèches du sens de circulation vu que ce n'est pas implicite. En France, on a des oneway=yes sur tout les tracés d'autoroute (sauf erreur), ça permet d'ailleurs de faire des calculs de cumul en tenant compte des doubles tracés. Suite de discussion dans tagging@ ou sur la page de discussion du wiki (anglaise) ? Je vois aussi sur le wiki les valeurs 0/1... ça vaudrait le coup d'harmoniser avec les no/yes, non ? Le 25 janvier 2013 11:14, Art Penteur art.pent...@gmail.com a écrit : OK. Donc je n'aurais pas du associer le oneway=no au acces=yes. Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. Doit-on, peut-on aller en discuter sur d'autres mailing-listes, modifier la page wiki/Key:oneway pour que cela soit plus clairement dit, et traduire cette page en Français ? Art. -- 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] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Je suis le seul à râler contre le sur-taggage ? Innocemment, il n'y a pas très longtemps, j'ai supprimé sans penser mal faire des oneway=no sur des tronçons où ça me semblait évident, et en pensant qu'ils avaient été ajoutés par l'utilisation des cases à cocher JOSM (celles que je n'utilise jamais…). Oneway=no, je le réserve à quelques cas particuliers (la seule voie de parking à double sens de tout un parking, certaines pistes cyclables présentes des deux cotés de la route, dont une bidirectionnelle…). Ailleurs, ça me semble être du bruit, et fait ressortir comme louche le cas des voies sans oneway*. EST-CE QU'ON VISE RÉELLEMENT À TERME D'AVOIR UN TAG ONEWAY* POUR TOUTES LES HIGHWAY ?? Après, les fixme:oneway (apparemment pas les oneway=unknown, mais je l'ai peut-être commis…), je plussoie, c'est top… JB. Le 25.01.2013 11:14, Art Penteur a écrit : OK. Donc je n'aurais pas du associer le oneway=no au acces=yes. Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. Doit-on, peut-on aller en discuter sur d'autres mailing-listes, modifier la page wiki/Key:oneway pour que cela soit plus clairement dit, et traduire cette page en Français ? Art. Le 25 janvier 2013 10:50, Christian Quest cqu...@openstreetmap.fr a écrit : Dans le doute, abstiens-toi... de mettre un tag Pythagore aurait pu terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren pier...@gmail.com a écrit : 2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest [1] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [2] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://openstreetmap.fr/u/cquest [2] 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs
Le 25 janvier 2013 11:52, sly (sylvain letuffe) li...@letuffe.org a écrit : Le vendredi 25 janvier 2013 08:51:56, Fabien a écrit : Bonjour, Salut, Je ne sais pas si c'est le bon endroit pour demander mais j'aurais bien vu les tags tourism=artwork affichés sur cette carte. Si on fait ça sur cette liste, ça pourrait devenir ingérable et surtout, je vais les oublier ;-) Le mieux c'est donc d'aller ici pour le faire : https://github.com/osm-fr/2u/issues (la création d'un compte est rapide) Puis d'être assez précis+aider pour que ça ait des chances d'être fait : - lien vers le wiki qui décrit le truc - proposition d'une icone s'il y a lieu (même type de format/taille que trouvé ici : https://github.com/osm- fr/2u/tree/master/symbols ) - lien vers la carte où se trouve un élément pour que le développeur puisse tester le résultat avant de le valider En clair, plus on simplifie le travail du développeur, et plus on a de chance qu'il le fasse, car le développeur est un feignant ! -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr J'avais pas percuté que c'était sur un github, j'avais juste le lien layers qui ressortait en lisant... Soumis : https://github.com/osm-fr/2u/issues/2 Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 25 janvier 2013 12:57, JB jb...@mailoo.org a écrit : ** Je suis le seul à râler contre le sur-taggage ? Non, je te rejoins sur ce point. Innocemment, il n'y a pas très longtemps, j'ai supprimé sans penser mal faire des oneway=no sur des tronçons où ça me semblait évident, et en pensant qu'ils avaient été ajoutés par l'utilisation des cases à cocher JOSM (celles que je n'utilise jamais…). Je fais pareil, quand je tombe dessus : je supprime le oneway=no, parce qu'il me parait redondant avec la valeur implicite. Et pourquoi pas des 'lane=1' partout ? On peut aller loin, comme ça... Autre argument : quelle quantité de données supplémentaire cela représenterait-il de mettre des 'oneway=no' partout (ou des lane=1, ou...) ? Pour un gain absolument nul, au final. Sachant qu'il y en a déjà 851.000, pour 60.000.000 de highway... Francescu Oneway=no, je le réserve à quelques cas particuliers (la seule voie de parking à double sens de tout un parking, certaines pistes cyclables présentes des deux cotés de la route, dont une bidirectionnelle…). Ailleurs, ça me semble être du bruit, et fait ressortir comme louche le cas des voies sans oneway*. *Est-ce qu'on vise réellement à terme d'avoir un tag oneway* pour toutes les highway ??* Après, les fixme:oneway (apparemment pas les oneway=unknown, mais je l'ai peut-être commis…), je plussoie, c'est top… JB. Le 25.01.2013 11:14, Art Penteur a écrit : OK. Donc je n'aurais pas du associer le oneway=no au acces=yes. Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. Doit-on, peut-on aller en discuter sur d'autres mailing-listes, modifier la page wiki/Key:oneway pour que cela soit plus clairement dit, et traduire cette page en Français ? Art. Le 25 janvier 2013 10:50, Christian Quest cqu...@openstreetmap.fr a écrit : Dans le doute, abstiens-toi... de mettre un tag Pythagore aurait pu terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren pier...@gmail.com a écrit : 2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) -- 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 listTalk-fr@openstreetmap.orghttp://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] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 25 janvier 2013 13:12, Francescu GAROBY windu...@gmail.com a écrit : Le 25 janvier 2013 12:57, JB jb...@mailoo.org a écrit : Je suis le seul à râler contre le sur-taggage ? Non, je te rejoins sur ce point. Innocemment, il n'y a pas très longtemps, j'ai supprimé sans penser mal faire des oneway=no sur des tronçons où ça me semblait évident, et en pensant qu'ils avaient été ajoutés par l'utilisation des cases à cocher JOSM (celles que je n'utilise jamais…). Je fais pareil, quand je tombe dessus : je supprime le oneway=no, parce qu'il me parait redondant avec la valeur implicite. Et pourquoi pas des 'lane=1' partout ? On peut aller loin, comme ça... Autre argument : quelle quantité de données supplémentaire cela représenterait-il de mettre des 'oneway=no' partout (ou des lane=1, ou...) ? Perso, j'ai déjà mis des lane=1 à des endroits pour spécifier que c'est une seule voie contrairement à ce que montre Bing. Par exemple là : http://www.openstreetmap.org/?mlat=43.303285mlon=5.39749zoom=18layers=Q Après il est vrai que dès que Bing aura fait sa mise à jour après travaux de la rue on verra bien le une seule voie mais en attendant... Pour un gain absolument nul, au final. Sachant qu'il y en a déjà 851.000, pour 60.000.000 de highway... Francescu Oneway=no, je le réserve à quelques cas particuliers (la seule voie de parking à double sens de tout un parking, certaines pistes cyclables présentes des deux cotés de la route, dont une bidirectionnelle…). Ailleurs, ça me semble être du bruit, et fait ressortir comme louche le cas des voies sans oneway*. Est-ce qu'on vise réellement à terme d'avoir un tag oneway* pour toutes les highway ?? Après, les fixme:oneway (apparemment pas les oneway=unknown, mais je l'ai peut-être commis…), je plussoie, c'est top… JB. Le 25.01.2013 11:14, Art Penteur a écrit : OK. Donc je n'aurais pas du associer le oneway=no au acces=yes. Pour oneway, on arrive au consensus: oneway= yes : sens unique vérifié. oneway= no : double sens vérifié. pas de oneway : en général, doute. Exception pour roundabout et motorway,: sens unique pas défaut sans spécifier oneway=yes. Doit-on, peut-on aller en discuter sur d'autres mailing-listes, modifier la page wiki/Key:oneway pour que cela soit plus clairement dit, et traduire cette page en Français ? Art. Le 25 janvier 2013 10:50, Christian Quest cqu...@openstreetmap.fr a écrit : Dans le doute, abstiens-toi... de mettre un tag Pythagore aurait pu terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren pier...@gmail.com a écrit : 2013/1/25 Art Penteur art.pent...@gmail.com: Vaut-il mieux un oneway=no généralisé, ou un oneway=unkown (ou fixme:oneway=unknow) pour les cas de chair mapping ? Si on ajoute des oneway=unknown, je pense qu'il faut aussi un horse=unknown et snowmobile=unknown. Il n'y a pas de raison que le doute ne soit permis que pour les sens de circulation. Sans ironie ;-) -- 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 ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le vendredi 25 janvier 2013 12:57:15, JB a écrit : Je suis le seul à râler contre le sur-taggage ? non non, moi aussi. Bien que je sois moins catégorique sur certains cas. Exemple : Au centre ville par chez moi, dont 80% des voies sont en sens unique, je place un oneway=no sur les 20% restants, ça me permet de différencier le : - je n'ai pas encore vérifié de - oui, c'est bien double sens Après, les fixme:oneway, je plussoie, c'est top… ? Allons bon ? contre le sur tagging de oneway, mais no problem pour rajouter un fixme:oneway=à vérifier ? ça me semble contradictoire non ? ou alors je n'ai pas bien compris à quel usage cela était destiné -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com mailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
2013/1/25 sly (sylvain letuffe) li...@letuffe.org: non non, moi aussi. haha. Je me souviens d'un petit nouveau qui voulait mettre des oneway partout :-)) Comme quoi, il n'y a que les imbéciles qui ne changent pas d'avis. Au fait, comment fonctionne le calque Pas de oneway sur layers.osm.fr ? http://layers.openstreetmap.fr/?zoom=15lat=48.86862lon=2.38446layers=BFTFF C'est l'absence totale de oneway ou juste oneway=yes ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
C'est une modélisation très intéressante, mais malheureusement sûrement complexe à appréhender par une majorité de contributeurs. Elle me semble intéressante car elle permet d'avoir une sorte de mise en hiérarchie des détails, alors qu'aujourd'hui on a tendance à multiplier les objets pour permettre d'indiquer de plus en plus de détails et du coup il y a un gros manque de hiérarchie dans les données OSM ce qui oblige à repartir dans l'autre sens: regrouper des objets pour avoir une vue plus globale. Je pense que quel que soit le modèle adopté, ce sont aux outils d'édition de masquer le modèle de donné utilisé ce qui n'est pas le cas aujourd'hui. Le modèle se complique petit à petit dans pas mal de domaines (le premier qui me vient à l'esprit est le public_transport), et les outils d'éditions ne sont pas vraiment là. Du coup, on casse facilement des relations surtout quand elles sont complexes. Serait-il possible d'avoir des extensions à JOSM qui s'occuperaient de maintenir la cohérence de tel ou tel modèle ? Imaginez une extension frontière qui feraient automatiquement les vérifications et effectuerai les éventuelles remises en cohérence dès qu'on touche à une limite administrative... Imaginez une extension landuse qui dès qu'on coupe en deux un polygone créerait un multipolygone et y reporterai les tags... Imaginez une extension coastline qui empêcherai de casser par mégarde la pointe bretonne ;) C'est au moment même d'une édition qu'il faut faire les vérifications et signaler les problèmes éventuels créés, peut être qu'une petite modification du fonctionnement du validator pour qu'il agisse plus en live pourrait être un premier pas. Ca vaut peut être un autre sujet de discussion... Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d’éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L’idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d’événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d’où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Oui tout à fait, on pourrait ainsi mieux gérer certains éventements ponctuels (ex, travaux en cours, immobilisation temporaire de la rue, etc.). Le désavantage de cette solution étant une modélisation très fortement basée sur les relations. Or celles-ci sont encore assez mal représentées dans les éditeurs. Mais rien n'empêche de les faire évoluer. Ex, dans JOSM, un point de couleur (ex, vert, rouge) pour identifier les noeuds d'un from - to. Ou même une représentation spécifique quand une partie, ou un objet complet est associe a une relation. Mais bon, la je m'écarte du sujet... Après, je n'ai pas une vision aussi complete que certains d'entre vous sur les concepts d'OSM. Il se peut donc que le modèle proposé, soit partiel ou contraire à certains préceptes d'OSM. Arnaud On 13-01-25 09:36 AM, Francescu GAROBY wrote: Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com mailto:arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Si je comprends bien, on pourrait même imaginer activer des évènements du point N1 au point N2 , sans avoir du coup besoin de redécouper le tronçon à ces 2 points ? Juste en ajoutant une ligne dans la table complémentaire d'évènements ? Et inversement lors de la désactivation de l'évènement ? Ceci limiterait en effet grandement le hachage que subissent certaines ways (entre le nombre de voies qui changent, les bouts empruntés par un itinéraire de bus, les bouts qui servent de frontières, ...). Ce qui permettrait de prendre en compte des évènements ponctuels, courts et à très brève échéance (voire déjà en cours), tels qu'un accident sur une autoroute, qui immobilise une voie. Francescu Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com mailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 14:06, Francescu GAROBY windu...@gmail.com a écrit : les bouts qui servent de frontières, ...). Non, pas coller ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le vendredi 25 janvier 2013 13:41:23, Pieren a écrit : 2013/1/25 sly (sylvain letuffe) li...@letuffe.org: non non, moi aussi. haha. Je me souviens d'un petit nouveau qui voulait mettre des oneway partout :-)) Arf, y'avais que toi d'assez *vieux* (dans osm) pour me prendre en flagrant délit de changement d'avis. En effet, j'ai revu mon idée de petit jeune de l'époque ;-) Si certains veulent faire un retour de 4 ans dans le passé : https://wiki.openstreetmap.org/wiki/Trying_to_find_a_solution_for_country_specific_and_defaults_values On notera donc que le débat en cours est loin d'être nouveau, que de nombreuses tentatives ont existées, et que dès fin 2008 j'avais déjà changé d'avis ;-p Au fait, comment fonctionne le calque Pas de oneway sur layers.osm.fr ? http://layers.openstreetmap.fr/?zoom=15lat=48.86862lon=2.38446layers=B00 00FTFF C'est l'absence totale de oneway ou juste oneway=yes ? l'absence de oneway. Si on a oneway=no ou oneway=yes alors le chemin ne s'affiche pas. Ce qui sous-entends que je reste le cul entre deux chaises et que, dès la présentation de ce calque, j'avais insisté sur son utilité en ville, et pas sur une départementale de campagne -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Carte OuVerte dans 60 millions de consommateurs
Bonjour, Le numéro de janvier 2013 du magazine 60 millions de consommateurs consacre un article à la Carte OuVerte de Rennes réalisée grâce au logiciel Chimère. D'ailleurs, on n'a pas beaucoup de news autour du projet Chimère? C'est pourtant un excellent exemple de mise en valeur d'OSM... L'article est en partage icihttps://docs.google.com/file/d/0B-VTP3CNuo8TQ3BaZXZiM0lJR0k/edit . Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Je commence à m'intéresser sérieusement à la segmentation dynamique dans le domaine de l'infra ferroviaire où l'on raisonne essentiellement en termes de PK (pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK début/Pk fin pour les événements linéaires (ouvrages d'art, chantiers, électrification, ...). Je confirme mon intérêt pour cette démarche ! Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la consistance sémantique serait assurée par des relations. Exemple pour un pont-rail Relation X Required Type=ouvrage_art Required Description=pont-rail Optional source=RFF Optional material=metal Optional length=xxx Optional height=xxx Optional name=blabla Required Members : a rôle « from » Required Members : b rôle « to » Required Members : c rôle « on » Optional members : d rôle « under » a=id du point début du pont (son PK debut) b=id du point fin du pont (son PK fin) c=id du tronçon de voie supportant la relation d=id du tronçon de la voie traversée (rivière, chemin, route, ...) C'est clair qu'il y a du boulot pour des applications pour transformer ces relations en objets découpés suivant les pointillés. Denis De : Arnaud [mailto:arnaud@gmail.com] Envoyé : vendredi 25 janvier 2013 13:40 À : talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eumailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.commailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eumailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- François Lacombe francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto: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] Carte OuVerte dans 60 millions de consommateurs
Et hop: http://openstreetmap.fr/60millions-janvier-2013 Le 25 janvier 2013 15:42, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Le numéro de janvier 2013 du magazine 60 millions de consommateurs consacre un article à la Carte OuVerte de Rennes réalisée grâce au logiciel Chimère. D'ailleurs, on n'a pas beaucoup de news autour du projet Chimère? C'est pourtant un excellent exemple de mise en valeur d'OSM... L'article est en partage icihttps://docs.google.com/file/d/0B-VTP3CNuo8TQ3BaZXZiM0lJR0k/edit . Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://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] Carte OuVerte dans 60 millions de consommateurs
Il gobe tout ce mek. Il faudrait lui trouver un nom approprié :) Cette carte communautaire est un exemple très concret de l'utilité de OSM, de comment l'utiliser localement. Par contre, il semble y avoir un gros moteur turbo à maitriser avec le logiciel Chimère. Pierre De : Christian Quest cqu...@openstreetmap.fr Et hop: http://openstreetmap.fr/60millions-janvier-2013 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Bonsoir Bonsoir !
Le message suivant de : ## Bonjour, Je m'appel MrBibendum je vous ai découvert grace à un ami vététiste et j'ai plein de questions parce que il y a plein de choses compliquées pour quelqu'un qui n'est pas très doué comme moi :D Je vais d'abord chercher et ensuite interroger Merci à bientot a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=10t=483 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleures réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonsoir, Le 25/01/2013 15:44, HELFER Denis a écrit : Je commence à m’intéresser sérieusement à la segmentation dynamique dans le domaine de l’infra ferroviaire où l’on raisonne essentiellement en termes de PK (pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK début/Pk fin pour les événements linéaires (ouvrages d’art, chantiers, électrification, …). Je confirme mon intérêt pour cette démarche ! Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la consistance sémantique serait assurée par des relations. Exemple pour un pont-rail Relation X Required Type=ouvrage_art Required Description=pont-rail Optional source=RFF Optional material=metal Optional length=xxx Optional height=xxx Optional name=blabla Required Members : a rôle « from » Required Members : b rôle « to » Required Members : c rôle « on » Optional members : d rôle « under » a=id du point début du pont (son PK debut) b=id du point fin du pont (son PK fin) c=id du tronçon de voie supportant la relation d=id du tronçon de la voie traversée (rivière, chemin, route, …) C’est clair qu’il y a du boulot pour des applications pour transformer ces relations en objets découpés suivant les pointillés. Dans ton exemple, la portion de voie ferrée de type pont-rail est définie par ses bornes, sous forme de nodes : a et b. Une autre manière, même sans node, consiste à définir le pont avec 2 abscisses curvilignes, à partir d'un way dont une extrémité serait le PK 0. Dans ce cas, on pourrait dire : le pont rail commence au PK 7.5 et se termine au PK 7.6, c'est à dire : le pont rail commence à 7.5km du début du way et mesure 100m. Ces 2 manières de dire la même chose souffrent du même bémol : il ne faut pas que la référence (le way) bouge, sinon l'objet pont-rail bouge aussi. Dans le premier modèle, il suffit de bouger par exemple le node a pour déplacer le début du pont-rail. Dans le second, si je raffine la courbure de la voie ferrée, j'augmente la longueur du way, et je déplace l'endroit situé à 7.5 km du début. Dans les deux cas on est face à, j'ai l'impression, une contradiction : la segmentation dynamique requiert une stabilité du référentiel géométrique pour que les objets définis relativement à cette géométrie soient stables, et à l'inverse, dans OSM, chacun est libre de modifier tous les objets, rien n'est figé/vérouillé. Du coup est-ce compatible, au stade des contributions ? C'est différent au stade de la réutilisation, où chacun est libre de définir des objets (des 'évènements') relativement au graphe OSM, dès lors que celui-ci a été extrait une fois et figé pour servir de référence. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 11:51, Francescu GAROBY windu...@gmail.com a écrit : Comme stop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Non c'est différent car les noeuds des stop-position sont ceux qui portent le tag du stop-position. On ne tague pas la relation ou le chemin référençant le noeud en mettant un tag stop_position=id. Les ids sont destinés à servir de références internes à la base pas dans des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune signification par eux-mêmes et ne sont jamais stables (ce qui est stable ce sont les ref:*=*). Et non je n'ai rien confondu entre tag (couple d'un nom et d'une valeur formant un attribut/une propriété de n'importe quel objet) et rôle (les rôles permettent de créer des listes de membres multiples ayant des usages différents, le même rôle servant à un ou plusieurs membres en principe, sauf que souvent on a un rôle par défaut qui est équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce que j'ai écris tu comprendras, je penses que c'est bien toi qui interprète mal ou veut interpréter ma phrase comme si j'avais fait la confusion des termes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 21:36, Philippe Verdy verd...@wanadoo.fr a écrit : Le 25 janvier 2013 11:51, Francescu GAROBY windu...@gmail.com a écrit : Comme stop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Non c'est différent car les noeuds des stop-position sont ceux qui portent le tag du stop-position. On ne tague pas la relation ou le chemin référençant le noeud en mettant un tag stop_position=id. Les ids sont destinés à servir de références internes à la base pas dans des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune signification par eux-mêmes et ne sont jamais stables (ce qui est stable ce sont les ref:*=*). Mais quand Arnaud dit from : N2, to : N3, il faut (je suppose) comprendre que ces 2 rôles pointeront vers les nodes dont l'id est respectivement N2 et N3. Pas sur la valeur de ces id proprement dits (donc comme dans mon exemple de stop_area). Et non je n'ai rien confondu entre tag (couple d'un nom et d'une valeur formant un attribut/une propriété de n'importe quel objet) et rôle (les rôles permettent de créer des listes de membres multiples ayant des usages différents, le même rôle servant à un ou plusieurs membres en principe, sauf que souvent on a un rôle par défaut qui est équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce que j'ai écris tu comprendras, je penses que c'est bien toi qui interprète mal ou veut interpréter ma phrase comme si j'avais fait la confusion des termes. ___ 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] OpenStreetMap modélisation et segmentation dynamique
Ce ne sera possible qu'à condition de donner un attribut stable aux noeuds (un nom, une ref, sous la forme d'un tag explicite, mais pas en se contentant de leur ID. Si on veut donc désigner une paire de noeud on pourrait indiquer que sur une route les sections entre les noeuds A et B, ou C et D sont un pont. L'ennui c'est comment s'assurer que les noms utilisés dans le chemin resteront uniques : à la première fusion de deux chemins ce n'est plus garanti. On pourrait utiliser la numérotation du bornage kilométrique (ou hectométrique) sur les routes longues, mais on n'en trouve pas dans les zones urbaines avec des carrefours. En revacnhe en ville on peut mettre les numéros des adresses. Ensuite alors on peut mettre un maxspeed=50; maxspeed:exception=30 pour la limitation temporaire des sections indiquées par exceptions:maxspeed=A B;C D (les espaces sont pour les intervalles, les point-virgules séparent les entrées ponctuelles ou intervalles). L'ennui c'est que le moteur de navigation va devoir chercher les références indiques dans des listes assez longues... Finalement ce sont les relations qui évitent les complications et ambiguités, et problèmes d'homonymies). Les relations n'offrent pas plus de complication, mais elles sont stables et on peut facilement retrouver dans une relation un intervalle de membres entre deux bornes, pour faire des sélections multiples servant à construire d'autres relations. Le 25 janvier 2013 14:06, Francescu GAROBY windu...@gmail.com a écrit : Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d’éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L’idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d’événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d’où le nom du concept). Si je comprends bien, on pourrait même imaginer activer des évènements du point N1 au point N2 , sans avoir du coup besoin de redécouper le tronçon à ces 2 points ? Juste en ajoutant une ligne dans la table complémentaire d'évènements ? Et inversement lors de la désactivation de l'évènement ? Ceci limiterait en effet grandement le hachage que subissent certaines ways (entre le nombre de voies qui changent, les bouts empruntés par un itinéraire de bus, les bouts qui servent de frontières, ...). Ce qui permettrait de prendre en compte des évènements ponctuels, courts et à très brève échéance (voire déjà en cours), tels qu'un accident sur une autoroute, qui immobilise une voie. Francescu Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se
Re: [OSM-talk-fr] http://www.tuugo.fr semble ne pas respecter la licence osm
Tuugo.fr m'a répondu et a fait les changements demandés. Par exemple: http://www.tuugo.fr/Companies/marylene31/0120004890035 (bref c'est bon aussi bien pour les carte OSM... qui ne sont plus utilisées ! que pour les cartes Google Maps qui les ont remplacées et qui mentionnent les attributions et licences requises par Google) Problème réglé. Avant de remettre OSM, il va falloir qu'il se monte d'abord son serveur de tuiles car il a compris le problème du SLA non garanti par le serveur de tuiles d'OSM (d'autant plus qu'il n'en mesure pas l'usage alors que Google Maps lui fournit les outils : il pourra faire une mesure d'usage et d'audience s'il monte son serveur de tuiles avec un frontal Squid, qui a déjà tout ce qu'il faut comme outils d'analyse de ses jouranux pour mesurer les bandes passantes et accès). Le 24 janvier 2013 03:32, Philippe Verdy verd...@wanadoo.fr a écrit : Je lai ai contacté via leur formulaire de contact en bas de page en mentionnant les deux points (attributions et licence obligatoires, et serveur de tuiles autonome hautement recommandé pour ne pas abuser les accès et la bande passante sur le TMS d'OSM) Le 24 janvier 2013 03:06, Philippe Verdy verd...@wanadoo.fr a écrit : Le 24 janvier 2013 03:04, Philippe Verdy verd...@wanadoo.fr a écrit : Et pas seulement pour géolocaliser les visiteurs dans leur compte personnel local, mais pour les minicartes des entrerprises référencées (ce n'est pas encore le plus méchant en bande passante), mais surtout pour la recherche géographique avec une grande carte on peut commencer à l'échelle de la région ou département et zoomer/glisser partout avant de cliquer un lieu de recherche, et là ce n'est plus un usage anecdotique). Sur certaines pages cependant ils utilisent GoogleMap (avec les attributions et copyrights de Google et de ses fournisseurs). Pourquoi ils ne le font pas quand ils utilisent OSM ? Visiblement ils ont trop utilisé Google Maps et ne veulent plus payer pour les affichages ; du coup ils passent à OSM en partie, mais ne veulent pas mentionner l'attribution affichée sur les minicartes ou dessous, c'est donc une démarche volontaire clairement abusive). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] région de Kidal au nord du Mali
salut à tous je me suis mis à participer à la cartographie de la région de Kidal au nord du Mali (je me demande pourquoi!) il existe une couverture Bing HR assez intéressante bien que partielle mais la couverture basse résolution montre vraisemblablement les zones de paturages en saison des pluies ce qui est pas mal pour l'occupation du sol j'ai fait un test sur la zone http://www.openstreetmap.org/?lat=19.505lon=0.976zoom=10layers=M je me pose 2 questions -heath est il le bon tag, je n'ai rien trouvé pour des paturages temporaires (la haute résol qui est très certainement prise en saison sèche montre bien qu'il n'y a quasiment plus rien. meadow pe semble un peu inadapté) -pour les oueds c'est un peu pareil faut-il cartographier waterway=river ou stream avec intermittent=yes sachant qu'il est fort possible que l'intermitence dure plusieurs années. quant à leurs noms n'en parlons pas, quelques villages m'ont déjà donné du fil à retordre. enfin une dernière question a propos des routes qu'il n'y a pas. je constate que de nombreux contributeurs surclasse (à mon sens) des routes qui ne sont que des pistes. est-ce logique ou simplement un effet collatéral du moteur de rendu. si on taggue en track, aux grandes échelles rien n'apparait alors on taggue en highway primary ou secondary pour dire de voir apparaitre qqchose sur la carte. I. Pour info un lien avec un pdf dans lequel il y a quelques mauvaises images de cartes mais qui permet cependant de comprendre cette région http://www.region-kidal.org/spip.php?article16 peut-être qu'au passage l'ONG Action contre la Faim libèrerait ces jeux de données ? en tout cas avant de continuer davantage j'aimerais quelques avis de la communauté jeff ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation de 2u, un rendu alternatif déstiné aux contributeurs
Hello, J'ai plein d'idées. Le 24 janvier 2013 14:39, sly (sylvain letuffe) li...@letuffe.org a écrit : Les idées sont bien sûr les bienvenues, mais clairement, les patchs avec la correction qui ne reste plus qu'a intégrer sont largement plus bienvenus et ont plus de chance d'être intégrées direct Ca me dirait bien de bidouiller le rendu, mais comment est-ce qu'on peut faire des tests ? Quel logiciel installé ? Est-ce qu'on doit passé par l'installation d'un serveur de tuile ou il y a plus simple ? Cdt Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] région de Kidal au nord du Mali
Une piste si elle est la route principale a de bonnes raison d'être tagguée en primary, non ? Ensuite les tag de surface, grade ou autre peuvent expliciter son état autant qu'on puisse en juger vu du dessus. Le 26 janvier 2013 00:05, Jean-François Gaffard jean-francois.gaff...@laposte.net a écrit : enfin une dernière question a propos des routes qu'il n'y a pas. je constate que de nombreux contributeurs surclasse (à mon sens) des routes qui ne sont que des pistes. est-ce logique ou simplement un effet collatéral du moteur de rendu. si on taggue en track, aux grandes échelles rien n'apparait alors on taggue en highway primary ou secondary pour dire de voir apparaitre qqchose sur la carte. -- 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs
Avec Tilemill et une connexion à une base osm2pgsql, tu peux avoir le rendu en live de tes modifs sur le style. http://mapbox.com/tilemill/ Le 26 janvier 2013 00:12, Black Myst black.m...@free.fr a écrit : Hello, J'ai plein d'idées. Le 24 janvier 2013 14:39, sly (sylvain letuffe) li...@letuffe.org a écrit : Les idées sont bien sûr les bienvenues, mais clairement, les patchs avec la correction qui ne reste plus qu'a intégrer sont largement plus bienvenus et ont plus de chance d'être intégrées direct Ca me dirait bien de bidouiller le rendu, mais comment est-ce qu'on peut faire des tests ? Quel logiciel installé ? Est-ce qu'on doit passé par l'installation d'un serveur de tuile ou il y a plus simple ? Cdt Black Myst ___ 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs
Le 26 janvier 2013 00:22, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Avec Tilemill et une connexion à une base osm2pgsql, tu peux avoir le rendu en live de tes modifs sur le style. http://mapbox.com/tilemill/ Nickel, merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OSM-Watch a disparu
Ce lien est actuellement inopérant. Le sous-répertoire watch a disparu de l'écran radar. http://osm102.openstreetmap.fr/~zorglub/watch/ Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] région de Kidal au nord du Mali
Bonsoir Jean-François, Tes coordonnées pointent sur la ville d'Aguelock où il que de l'imagerie Bing basse définition. Je suis incapable de tirer des conclusions sur l'état des lieux à partir d'une imagerie de basse résolution. Dans le delta du Niger, les contributeurs avaient identifiés d'immenses lacs à partir de l'imagerie basse résolution. Avec l'imagerie haute résolution, nous devons maintenant corriger cette information et indiquer les fermes, villages et routes qui sont en zone inondée à la période des pluies. Je t'invite plutôt à venir collaborer avec l'équipe humanitarie HOT. Frédéric Bonifas et moi coordonnons actuellement la cartographie pour l'ensemble du Mali à partir des priorités des humanitaires au Mali. Nous identifions les endroits où il y a de l'imagerie Haute définition disponible et donnons les instructions pour cartographier ces endroits. Je t'invites aussi à suivre le fil de discussion HOT pour avoir des infos sur la coordination des activités de cartographie au Mali. Si les contributeurs français le désirent, nous pourrons aussi donner ces instructions en français sur la liste talk-fr. http://lists.openstreetmap.org/listinfo/hot page de coordination http://wiki.openstreetmap.org/wiki/2012_Mali_Crisis Gestionnaire de tâches http://tasks.hotosm.org/#all/Mali Pierre De : Jean-François Gaffard jean-francois.gaff...@laposte.net À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Vendredi 25 janvier 2013 18h05 Objet : [OSM-talk-fr] région de Kidal au nord du Mali salut à tous je me suis mis à participer à la cartographie de la région de Kidal au nord du Mali (je me demande pourquoi!) il existe une couverture Bing HR assez intéressante bien que partielle mais la couverture basse résolution montre vraisemblablement les zones de paturages en saison des pluies ce qui est pas mal pour l'occupation du sol j'ai fait un test sur la zone http://www.openstreetmap.org/?lat=19.505lon=0.976zoom=10layers=M je me pose 2 questions -heath est il le bon tag, je n'ai rien trouvé pour des paturages temporaires (la haute résol qui est très certainement prise en saison sèche montre bien qu'il n'y a quasiment plus rien. meadow pe semble un peu inadapté) -pour les oueds c'est un peu pareil faut-il cartographier waterway=river ou stream avec intermittent=yes sachant qu'il est fort possible que l'intermitence dure plusieurs années. quant à leurs noms n'en parlons pas, quelques villages m'ont déjà donné du fil à retordre. enfin une dernière question a propos des routes qu'il n'y a pas. je constate que de nombreux contributeurs surclasse (à mon sens) des routes qui ne sont que des pistes. est-ce logique ou simplement un effet collatéral du moteur de rendu. si on taggue en track, aux grandes échelles rien n'apparait alors on taggue en highway primary ou secondary pour dire de voir apparaitre qqchose sur la carte. I. Pour info un lien avec un pdf dans lequel il y a quelques mauvaises images de cartes mais qui permet cependant de comprendre cette région http://www.region-kidal.org/spip.php?article16 peut-être qu'au passage l'ONG Action contre la Faim libèrerait ces jeux de données ? en tout cas avant de continuer davantage j'aimerais quelques avis de la communauté jeff ___ 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] Tr : [OSM-talk] overpass turbo - a web GUI for Overpass-API
Martin Raifer annonce une version graphique de Overpass-API. C'est super. Il a ajouté une carte d'où il est possible de sélectionner le bbox délimitant la zone de recherche. Pour les nodes, le résultat est retourné directement sur cette carte. Pour les autres éléments, seul le fichier OSM est accessible. De plus, lors de mes tests le délai d'attente étaient très courts. Pierre - Mail transféré - De : Martin Raifer tyr@gmail.com À : t...@openstreetmap.org Envoyé le : Vendredi 25 janvier 2013 17h10 Objet : [OSM-talk] overpass turbo - a web GUI for Overpass-API Hello, I'm happy to present you *overpass turbo* [1], a web based graphical user interface for Overpass API. I've always thought, that the Overpass API can be a great tool for mappers and developers (for example for its powerfulness in data filtering). However, there was no easy way to quickly run an Overpass query and inspect the results in a user friendly manner, until now: With overpass turbo you can run Overpass API queries and analyze the resulting OpenStreetMap data interactively on a map. Here are some use cases where overpass turbo can come in handy: * Searching for (rare) spelling mistakes or breaks with naming conventions, which are not yet covered by any QA tool. * Showing and inspecting spacially large features (boundaries, rivers, complete motorways, PT-networks, ...). * Always when you only need a filtered portion of OSM data. * Testing and developing more or less complicated Overpass API queries. * Creating mock-ups of clickable or static maps highlighting selected OSM features. http://overpass-turbo.eu This is the url where you can find overpass turbo [1] (alternatively, there is also an installation on overpass-api.de [2]). You need a somewhat recent web browser for using overpass turbo. Opera, Chrome and Firefox have been tested and work (IE 10 should be fine, too). More information, screenshots, examples, etc. can be found on the OSM-wiki [3] or on its github repository [4]. Have fun :) Martin / tyr_asd [1] http://overpass-turbo.eu [2] http://overpass-api.de/turbo/ [3] http://wiki.openstreetmap.org/wiki/Overpass_turbo [4] https://github.com/tyrasd/overpass-ide ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
