<div dir="ltr">En Belgique on utilise route_ref pour indiquer quelles lignes desservent un arrêt. C'est facile à ajouter pendant le 'survey'. Et ça peut aider pour vérification une fois que l'on commence à créer des relations route.<div><br></div><div>Polyglot</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-22 17:56 GMT+02:00 Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Déjà les "bus_stop" (ancienne version) devraient correspondent point par point aux nouveaux objets "public_transport:platform" s'ils ne sont pas sur le chemin mais doivent servir à indiquer les abris, les bancs ou l'accessibilité et la zone d'attente (ou le poteau indicateur)<div><br></div><div>S'ils sont sur le chemin (donc sans indication du côté) ce sont des "public_transport:stop_<wbr>position" (et il n'y a pas d'attributs pour les bancs, abris et l'accessibilité).</div><div><br></div><div>Selon que c'est un type ou l'autre tu en déduis le rôle qu'il faut mettre dans la relation route. Idéalement on devrait avoir deux rôles pour chaque arrêt: stop et platform</div><div><br></div><div>Les "route segments" (proposés) sont une autre problématique liée à la topologie des chemins, et la multiplicité des variantes qui empruntent des sections communes. Mais ils sont surtout nécessaire pour lever les ambiguités de parcours sur les chemins quand ils ne forment pas une ligne continue sans intersection, car dans l'immédiat on est amené à devoir mettre tous les ways membres dans l'ordre, y compris avec des doublons pour les segments communs, et il n'est pas facile de déterminer un ordre des segments quand il y a des intersections, même sur une seule route et après avoir séparé chaque direction et chaque variante de la ligne dans des relations "route" séparées mais regroupées dans un "route_master"<br></div><div><br></div><div>Quand on a compris tout ça, on peut faire une appli qui saura distinguer les vrais "stop_position" des "plateform" (c'est facile: le "stop" est sur le chemin, mais pas la "plateform"), ce que "bus_stop" ne sait pas classer correctement. Juste faire ça fera beaucoup avancer les choses.</div><div><br></div><div>----</div><div><br></div><div><div>Pour aller au delà avec les "stop_area" par exemple pour regrouper différents arrêts et plateformes de différentes lignes destinées à la correspondance directe ou même pour revenir en arrière sur la même ligne mais par une autre route), c'est un autre travail à faire: celui de vérifier et assurer les correspondances.</div><div><br></div><div>De même que les objets "station" qui sont des regroupements plus large comprenant plusieurs "stop_area", des batiments, des accès (escaliers, portes, ascenseurs...) où la correspondance est plus complexe (et où on peut avoir des services annexes (comme la vente des billets et abonnements) et peut grouper des réseaux de nature différente et différents opérateurs pour l'intermodalité (exemple: les gares routières et gares ferroviaires)</div></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">Le 22 octobre 2016 à 12:10, Florian LAINEZ <span dir="ltr"><<a href="mailto:winnerflo@free.fr" target="_blank">winnerflo@free.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Si on propose ce que l'on sait déjà de l'arrêt et qu'on propose de
confirmer/infirmer/ne pas se prononcer, on gagne des possibilités de
réponse rapide.</blockquote></span><div>tout à fait, je pense à de l'autocomplétion avec la meilleure proposition mise en avant le cas échéant.<span><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Peut-être que si on laisse la personne dessiner le trajet (juste en
chaînant les arrêts) on a pas mal de matière.<br>
Ensuite un moteur de calcul de trajet (favorisant les rues larges et
droites) peut être utilisé côté serveur pour avoir un trajet
vraisemblable. Trajet à valider bien-sûr.</blockquote></span><div> C'est à peu près ça que j'ai en tête. Avec la possibilité de drag&drop le chemin pour le replacer (du style de ce que propose OSRM sur <a href="http://osm.org" target="_blank">osm.org</a>) sans avoir à gérer des way un par un.<br><br></div><div>@philippe tout ceci est passionnant mais ce sont des problématiques complexes, or mon appli est vraiment focalisée sur la simplicité. D'où le parti pris de ne gérer que les highway=bus_stop (ou son équivalent public_transport=platform).<br><br>Mon idée est bien de pouvoir gérer les deux modèles, ancien et nouveau, de manière transparente pour l'utilisateur.<br>Charge aux mappeurs expérimentés de compléter le travail avec des outils plus classiques.<br><br></div></div></div><div class="m_7252923238287612944HOEnZb"><div class="m_7252923238287612944h5"><div class="gmail_extra"><br><div class="gmail_quote">Le 21 octobre 2016 à 22:26, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Les tags "from=*", "via=*" et "to=*" sont plutôt destinés à un utilisateur humain qu'à subir un vrai rapprochement avec un arrêt.<div><br></div><div>Dans le shéma actuel ("public_transport:version=2" dans les relations "route"), ce sont les noeuds membres (posés sur un les ways membres) ayant un rôle "stop" qui servent à ça, le premier noeud (from) devrait être de rôle "stop_enter_only", le dernier de rôle "stop_exit_only". La direction de la ligne devrait s'en déduire.... L'ennui c'est qu'il existe parfois des stations intermédiaires qui n'autorisent que la descente ou que la montée, ayant ces même rôles (c'est rare...). On n'a en fait rien de clair pour indiquer réellement quels arrêts (noeuds de rôle "stop") sont les deux terminus (l'idéal serait d'ajouter un suffixe ":start" ou ":end" à ces rôles)</div><div><br></div><div>On peut ajouter aussi les plateformes (noeuds, lines ou polygones) en membres de rôle "platform" (avec "platform_enter_only", "platform_exit_only" pour le premier et le dernier arrêt, mais cela me semble inutile si on a identifié clairement les deux noeuds "stop" de départ et d'arrivée: le rôle "platform" suffit à lui seul; ces rôles variantes sont plutôt destinés à combler des données manquantes quand il manque des noeuds "stop", mais les plateformees sont pas faciles du tout à gérer et associer avec le parcours de la ligne sans un noeud "stop" correspondant).</div><div><br></div><div>Il reste cependant le cas des lignes circulaires dont le départ et l'arrivée sont au même point: si ce point n'est pas sur un way en sens unique (par exemple une petite voie de service latérale à la chaussée), là on a bsoin que ce premier chemin ait un rôle "forward" ou "backward" (je ne vois pas comment faire autrement) pour indiquer le sens de la ligne. L'autre solution serait d'utiliser deux noeuds très proches mais séparés pour distinguer le départ et l'arrivée (mais sans mettre alors dans la "route" le segment qui les relie ! Ces noeuds étant cependant associés à la même plateforme.</div><div><br></div><div>Les chemins sont ensuite parcours dans le sens indiqués par leur jonction, mais il reste la difficulté des lignes dont l'itinéraire repasse plusieurs fois par le même noeud (voire même par un même chemin en cas de détour, et pas non plus forcément en sens opposé si ce détour fait une boucle): là encore les chemins doivent être orientés pour réduire (avec backward ou forward) le nombre de possibilités de succession des chemins, mais il peut rester des ambiguités.</div><div><br></div><div>Pour éliminer totalement ces ambiguïtés, il a été proposé de créer des relation "route" avec un tag "segment=yes", où les chemins forment une ligne ininterrompue et ne repassant jamais par un même noeud ou chemin, puis d'inclure ces segments de routes en tant que membres d'une relation "route" normale. Mais ce n'est pas encore mis en oeuvre.</div><div><br></div><div>En attendant, on a encore besoin que les relations "route" mentionnent la liste des arrêts ("stop") dans l'ordre exact. Et il est impératif d'utiliser des noeuds rôle "stop" (tagués "public_transport=stop_positio<wbr>n" + "bus=yes") sur les chemins. Ces noeuds n'ont aucun tag pour les abris, poubelles, accès handicap, etc. qui sont à mettre plutôt sur les objets "public_transport=platform".</div><div><br></div><div>Le nouveau schéma recommande même de placer dans l'ordre dans la relation les noeuds "stop" suivis immédiatement de l'objet "platform" auquel il se réfère; la liste des chemins se met plutôt ensuite après (avec des chemins en doublons parfois, faute de prise en charge pour l'instant des "segments" de route).</div><div><br></div><div>Noter que les chemins peuvent aller commencer et aller plus loin que le premier et le dernier arrêt (généralement on inclue dans une route aussi les éléments de chemins qui raccorde une route pour un sens à l'autre route dans l'autre sens dans la même ligne.</div><div><br></div><div>Le plus compliqué est de réviser les "bus_stop" qui ont été placés un peu n'importe où (sur les chemins ou pas) et tagués de façon hybride comme des "stop" ou des "platform", et ensuite repris indifféremment avec le même rôle "platform" dans les relations "route" ; il faut:</div><div>- enlever les "highway=bus_stop" sur les noeuds, mettre "public_transport:version=2" sur les noeuds,</div><div>- doublonner ces noeuds s'il y a des "shelter ou wheelchair", en placer un sur le chemin, l'autre à côté pour la station du bon côté,</div><div>- en mettre un avec "public_transport=stop" (celui sur le chemin), l'autre avec "public_transport=platform"<br></div><div>- ne garder les tags "shelter=yes" ou "wheelchair=yes" que sur la plateforme,</div><div>- mettre le tag "bus=yes" sur le stop</div><div>- reprendre la relation "route" et placer les deux noeuds (le "stop" d'abord suivi de la platforme)</div><div>- vérifier l'ordre de succession des stop/platform dans la liste</div><div>- la route ensuite peut avoir des ""from=*", "via=*" et "from=*" mais ils ne sont pas obligés de mentionner le nom exact local de l'arrêt (figurant sur place)</div><div><br></div><div>La "description=*" de la route peut avoir besoin d'indiquer en plus du numéro (commercial) de ligne la direction mais pas nécessairement le nom du dernier arrêt, elle peut mentionner juste le nom simplifié dans "to", ou bien lui ajouter une désambiguisation "Commune (arrêt)", par exemple "Trifouillis-lès-Oies (Mairie)", même si l'arrêt sur place s'appelle seulement "Mairie": sur une même ligne les noms d'arrêts sont le plus souvent simplifiés, de même la direction d'une ligne affichée sur les bus, quu peut être juste le nom de la commune suivante, les bus pouvant maintenant changer dynamiquement cet affichage au cours de son parcours, au début ils vont mentionner le nom d'une commune, puis le nom d'un quartier, puis le nom de l'arrêt final, ce qui faciliter la vie pour les usagers qui peuvent confondre les numéros de lignes)</div><div><br></div><div><div>Quand on a pu enfin construire correctement toutes les routes (une par direction et par variante d'itinéraire), on peut les réunir dans une relation "route_master" (pas besoin de rôle spécifique, ni même de préciser la version du schéma de transport).</div></div><div><br></div><div>Puis rassembler toutes les lignes (relations "route_master") dans une relation "network".</div><div><br></div><div>----</div><div><br></div><div>Noter aussi que la proposition des "segments de route" devrait aussi permettre de prendre en compte des lignes qui partagent en partie certains bus sous plusieurs numéros de lignes (parfois pour des réseaux différents): une "route" en revanche ne doit concerner qu'un seul numéro de ligne sur un seul réseau: ce cas est courant pour les liaisons longue distance dont une partie seulement est prise en charge par une collectivité ou un EPCI dans son réseau de transport: on a des cas de partages de lignes interrégionaux, intercommunaux, inter-EPCI, et des cas même où une liaison n'est pas entièrement publique mais fait partie d'une offre d'un transport privé, qui n'est sous contrat avec la collectivité que dans son secteur et pas sur le reste.</div><div><br></div><div>Ces partages de liaisons (pour plusieurs lignes diférentes) existent aussi bien pour les bus, que le train, exactement comme dans le transport aérien (où cela se pratique tous les jours entre affrêteurs d'avions, compagnies aériennes et agences de voyage), du fait que pour les transports publics les territoires (le plus souvent les EPCI aujourd'hui ou des syndicats mixtes groupant plusieurs EPCI) ont obtenu des monopoles et une compétence exclusive (qui interdisent aux autres collectivités sur leur territoire de négocier ou subventionner individuellement<wbr> des transports avec des opérateurs privés).</div><div><br></div></div><div class="m_7252923238287612944m_1382024672190119697HOEnZb"><div class="m_7252923238287612944m_1382024672190119697h5"><div class="gmail_extra"><br><div class="gmail_quote">Le 21 octobre 2016 à 18:03, Florian LAINEZ <span dir="ltr"><<a href="mailto:winnerflo@free.fr" target="_blank">winnerflo@free.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Merci encore pour vos réponses, j'ai affiné ma présentation en intégrant vos différentes idées <a href="https://slides.com/overflorian/busstopcollector/" target="_blank">https://slides.com/overflorian<wbr>/busstopcollector/</a><span><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Tu veux intégrer de l'OCR (reconnaissance optique de caractères)
pour avoir les noms des arrêts ? ;-).<br></blockquote></span><div>je garde l'idée pour la v10 ! Plus sérieusement tes suggestions concernant la collecte de GPX / photos sont très pertinentes.<span><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pas mis à jour depuis longtemps mais cette application avait la vocation de mapper les arrêts de transport <a href="http://makinacorpus.github.io/osm-transport-editor/#/" target="_blank">http://makinacorpus.github.io/<wbr>osm-transport-editor/#/</a></blockquote></span><div>J'avais déjà vu passé ça mais j'avais oublié son existence ! Je vais contacter le développeur pour lui faire part de mon projet, merci<span><br><br><blockquote><span class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535gmail-im"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote" type="cite">Dans ta "présentation tu parles "Edit bus stops details: name,
direction, bus line". Bus_line et direction sont tagués sur le
bus_stop ? Je ne trouve rien sur le wiki, j'ai raté des choses je
pense !</blockquote></span><br><span class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535gmail-im"><blockquote type="cite">
</blockquote></span>
+1<br>
la ligne est portée par la ou les relations (<tt>"</tt><font face="Courier New, Courier, monospace">name</font>" ou "<font face="Courier New, Courier, monospace">ref</font><tt>"</tt>) ainsi
que la direction ("<font face="Courier New, Courier, monospace">to</font><tt>"</tt>)
<br>
<br><tt>
"</tt><font face="Courier New, Courier, monospace">highway=bus_stop</font><tt>"</tt>
fait partie de l'ancien modèle, il me semble qu'il vaut mieux
utiliser le nouveau <tt>"</tt><font face="Courier New, Courier,
monospace">public_transport=stop_positio<wbr>n</font><tt>" </tt><br><tt>
</tt><br><tt>
</tt>Si on regarde le Schéma :
<a href="https://wiki.openstreetmap.org/wiki/FR:Key:public_transport#Sch.C3.A9ma_en_bref" class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535gmail-m_-8856915843308003017moz-txt-link-freetext" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/FR:Key:public_transport#<wbr>Sch.C3.A9ma_en_bref</a>
- si on reste dans le bus, on va tagger uniquement l'endroit où
s’arrête le bus "<font face="Courier New, Courier, monospace">stop_position</font><tt><tt>"</tt></tt>
ou l'endroit où attendent les passagers "<font face="Courier New,
Courier, monospace">platform</font>" qui n'est pas forcément à la
hauteur de là où s'est arrête le bus<tt><tt>.</tt></tt> <br></blockquote></span></div>Je détaille bien dans ma présentation le fait que je m'intéresse pour l'instant aux points d'attente des passagers et que le point d'arrêt du bus viendra peut-être plus tard.<br><br></div><div>Concernant les tags à utiliser, je pense qu'il est prématuré d'en parler, je ne suis qu'à débroussailler ce que pourrait être l'appli pour l'instant. Ceci dit je suis tout à fait au fait de la problématique ancien modèle VS nouveau modèle public_transport.<br><br></div><div>D'autres idées / remarques ?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_7252923238287612944m_1382024672190119697m_4783812222037671928h5">Le 21 octobre 2016 à 10:14, lenny.libre <span dir="ltr"><<a href="mailto:lenny.libre@orange.fr" target="_blank">lenny.libre@orange.fr</a>></span> a écrit :<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_7252923238287612944m_1382024672190119697m_4783812222037671928h5">
<div bgcolor="#FFFFFF" text="#000000"><span>
<p><br>
</p>
<div class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017moz-cite-prefix">Le 21/10/2016 à 08:45, Vincent Bergeot
a écrit :<br>
</div>
<blockquote type="cite">
<div class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017moz-cite-prefix">Le 20/10/2016 à 11:26, Florian LAINEZ
a écrit :<br>
</div>
<blockquote type="cite"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017gmail-m_-3709271182548517216gmail-im"> </span> dans
le bus je me sers d'un thème quasi identique à celui là :<a class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017gmail-m_-3709271182548517216gmail-m_6614267883671053409moz-txt-link-freetext" href="https://www.cartes.xyz/t/04e491-Arrets_de_bus__Florian#" target="_blank">https://www.cartes.xyz/t/04e4<wbr>91-Arrets_de_bus__Florian#</a></blockquote>
<div>@vincent tu m'as bien compris, c'est exactement ce que
j'aimerai faire avec un interface pour les débutants. Il
manque aussi à ton outil la gestion des lignes : il est
difficile de voir quels arrêts sont sur la même ligne, or ça
me parait être clef pour la simplicité de contribution.</div>
</blockquote>
yep, je crois comprendre.<br>
Cela devient plus une question de "rendu" que de données si je
comprends bien. Imaginer les couleurs correspondantes aux lignes
et les arrêts associés.<br>
Effectivement, en mettant le rendu transport sur le thème
précédent, c'est déjà un peu plus clair.<br>
<br>
Dans ta "présentation tu parles "Edit bus stops details: name,
direction, bus line". Bus_line et direction sont tagués sur le
bus_stop ? Je ne trouve rien sur le wiki, j'ai raté des choses je
pense !<br>
</blockquote></span>
+1<br>
la ligne est portée par la ou les relations (<tt>"</tt><font face="Courier New, Courier, monospace">name</font>" ou "<font face="Courier New, Courier, monospace">ref</font><tt>"</tt>) ainsi
que la direction ("<font face="Courier New, Courier, monospace">to</font><tt>"</tt>)
<br>
<tt><br>
"</tt><font face="Courier New, Courier, monospace">highway=bus_stop</font><tt>"</tt>
fait partie de l'ancien modèle, il me semble qu'il vaut mieux
utiliser le nouveau <tt>"</tt><font face="Courier New, Courier,
monospace">public_transport=stop_positio<wbr>n</font><tt>" <br>
<br>
</tt>Si on regarde le Schéma :
<a class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/FR:Key:public_transport#Sch.C3.A9ma_en_bref" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/FR:Key:public_transport#<wbr>Sch.C3.A9ma_en_bref</a>
- si on reste dans le bus, on va tagger uniquement l'endroit où
s’arrête le bus "<font face="Courier New, Courier, monospace">stop_position</font><tt><tt>"</tt></tt>
ou l'endroit où attendent les passagers "<font face="Courier New,
Courier, monospace">platform</font>" qui n'est pas forcément à la
hauteur de là où s'est arrête le bus<tt><tt>.<br>
<br>
</tt><br>
</tt><span>
<blockquote type="cite"> <br>
Et pour les relations, à voir avec la requête overpass qui le fait
!<br>
<br>
PS : je suis conscient que cela ne correspond pas à certaines de
tes attentes (off-line, interface plus simple, android, ...) mais
cela me permet aussi d'avancer sur un thème arrêt de bus pour que
ta mère puisse s'en servir une fois qu'elle aura commencé avec ton
idée d'application :)<br>
<br>
<pre class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535m_-8856915843308003017moz-signature" cols="72">--
Vincent Bergeot
</pre>
<br>
</blockquote>
<br>
</span></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br></span></blockquote></div><span><br><br clear="all"><br>-- <br><div class="m_7252923238287612944m_1382024672190119697m_4783812222037671928m_3211548340745527535gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
<p style="margin-bottom:0cm">
</p><p style="margin-bottom:0cm"><font color="#333333"><font face="arial, helvetica, sans-serif"><font style="font-size:11pt" size="2"><b>Florian
Lainez</b></font></font><br></font></p><img src="http://twitter.com/favicon.ico"><a href="http://twitter.com/overflorian" target="_blank">@overflorian</a><br></div></div>
</span></div>
<br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="m_7252923238287612944m_1382024672190119697gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
<p style="margin-bottom:0cm">
</p><p style="margin-bottom:0cm"><font color="#333333"><font face="arial, helvetica, sans-serif"><font style="font-size:11pt" size="2"><b>Florian
Lainez</b></font></font><br></font></p><img src="http://twitter.com/favicon.ico"><a href="http://twitter.com/overflorian" target="_blank">@overflorian</a><br></div></div>
</div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>