Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
Nicolas Bouthors a écrit : > sly (sylvain letuffe) a écrit : >> [...] supposons un pays carré fait de 4 régions carrées, chacunes faites de >> 4 >> départements carrés faits de 4 communes carrées. On supprime un seul way de >> commune qui se trouve en frontière de pays [...] j'ai un département faux >> (il lui manque en effet un >> quart) > Et je rajouterais : comment un mec comme moi qui bouquinais pendans ses > cours de géo est-il capable de *détecter* la suppression ou erreur ? Le > département continuerai de "parser" dans des outils comme le beta actuel ! > > Le système actuel est certes complexe, mais au moins en cas d'erreur, on > ne peut pas passer à coté. Je ne suis pas d'accord avec cet argument. Tu détectes les erreurs aujourd'hui grace à des outils tels qu'Osmose ou Beta. Dans un autre système que l'actuel, le même type d'outils existerait pour t'aider à les détecter donc tu ne passeras pas non plus à côté des erreurs. -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
sly (sylvain letuffe) a écrit : > [...] supposons un pays carré fait de 4 régions carrées, chacunes faites de 4 > départements carrés faits de 4 communes carrées. On supprime un seul way de > commune qui se trouve en frontière de pays [...] j'ai un département faux (il > lui manque en effet un > quart) Et je rajouterais : comment un mec comme moi qui bouquinais pendans ses cours de géo est-il capable de *détecter* la suppression ou erreur ? Le département continuerai de "parser" dans des outils comme le beta actuel ! Le système actuel est certes complexe, mais au moins en cas d'erreur, on ne peut pas passer à coté. N -- Nicolas - http://www.wawoum.com/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
> Si je résume ta proposition, tu rajoutes juste un niveau dans la > pyramide. Non pas uniquement, je propose l'ajout d'un élément intermédiaire de type linéaire pour composer une frontière comme étant une somme de relation de relation de relation de ways > Effectivement, il y aura moins de membres dans les relations > (plus facile a éditer) mais il y aura plus de relations (moins facile > à suivre en mode humain). Je conviens parfaitement que ce modèle est difficile à suivre à l'heure actuelle des éditeurs et qu'il n'est qu'a l'état de réflexion > Au final, c'est juste un peu plus compliqué pour avoir des relations > moins grosses. Et pour qu'un élément (relation ou way) n'appartienne qu'a 4 éléments au maximum Comme l'idée est dure à faire passer, voici un bac à sable à copier dans JOSM "Zone de délimitation" http://www.openstreetmap.org/?lat=45.59907&lon=6.0933&zoom=15 On constate qu'un way n'appartient qu'a 2 relations au maximum (ou presque, cf la rivière), sa destruction ne nécessitera que peu de manipulations Mais évidement, un bordel innommable s'installe au niveau des relations, l'éditeur devient limitant mais le modèle de donnée est compréhensible -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
sly (sylvain letuffe) a écrit : > Dans mon modèle les surfaces ne sont composés que de très peu de relation de > type linéaire Cette solution hybride parait intéressante, en effet. À creuser... -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
2009/6/30 sly (sylvain letuffe) : > J'ai une autre idée de modèle qui est un mi-chemin des deux > (ton idée VS l'existant) > [Pieren, si tu me lis, arrête tout de suite, tu vas faire une attaque] J'ai lu et je me suis fait un massage cardiaque tout de suite après, alors ça va ;-) > On conserve une logique de frontière et non surfacique, mais on construit tout > de même une pyramide des appartenances. Si je résume ta proposition, tu rajoutes juste un niveau dans la pyramide. Effectivement, il y aura moins de membres dans les relations (plus facile a éditer) mais il y aura plus de relations (moins facile à suivre en mode humain). Au final, c'est juste un peu plus compliqué pour avoir des relations moins grosses. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
sly (sylvain letuffe) a écrit : > Dans le cas des relations administratives, j'imagine bien des contrôles de > surface car on peut supposer qu'il n'existe pas de point du territoire à > n'être "nul part", mais ce n'est pas le cas pour les autres types de > relations (fleuves, forêts, landuse, natural, etc.) et il m'apparait > fondamental pour la simplicité de compréhension du mappeur d'être sur un > système homogène a travers tous les types d'objets de surface (modèle > surfacique ou de frontière mais pas les deux) > > Aujourd'hui, les départements, régions, État sont faits (même avec les problèmes de licence qu'on sait ;-) alors que les communes ne sont pas toutes importées. Avec le modèle surfacique, il faudrait avoir fini d'entrer la dernière commune pour que le Pays soit fait ? Et le jour où on subdivise les communes par quartier, on flanque tout par terre ? J'ai fais un peu de maintenance du côté de la frontière suisse : limites de communes, département, région, état : C'est sûr que ça n'est pas facile ! Je ne suis pas sûr que le modèle surfacique eut été plus simple : si la limite de commune est fausse, le pays est faux. > Après, en reprenant mon exemple de fleuve, je constate au niveau du mapping > que c'est le modèle surfacique qui semble le plus utilisé, les longs fleuves > ressemblent à : > ___ > [___||_||___] > (surfaces fermées à intervals réguliers coupant le fleuve en morceau de > surface) > > et non à > _ > [ _ ] > (relation contenant plein de ways ne formant qu'une seule surface finale) > > Est-ce à dire que le modèle surfacique est plus simple pour le mappeur ? > > Peut-être parce que - moins risqué : on s'y noie moins (je n'ai pas résité à l'envie de la placer) si on contrôle localement l'intégrité. - un long fleuve tranquille a un rapport longueur/largeur énorme - le super-multi-polygone n'est pas encore bien répandu et la relation "river" peu démocratisée... Mais à mon avis c'est le mélange qui sera l'avenir : l'emploi du rôle dans la relation qui ajoute de la valeur sémantique. ___ || baignade | ||__| | === waterway;river | |___ ___ Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
> Oui, c'est le même boulot, la première fois que tu le fais ! Mais > réfléchissons à la maintenance. > > Quand une relation région est cassée, il faut réparer la relation > région, la relation département, la relation commune et sans doute > d'autres si on augmente la granularité du maillage (ce n'est peut être > pas toujours vrai mais je le constate très souvent). Un point pour toi, il est vrai que la suppression d'un way faisant frontière avec 8 relations va casser 8 surfaces, là où on aurait pu tomber à 2 seulement. > Dans un modèle "surface", une relation région ne serait jamais cassée > car son contenu (des relations) ne bougerait pas, à priori. Pareille > pour un département, un canton etc... Là je ne suis pas d'accord et je vois d'ailleurs un premier point plus clair qui me semble représenter plus de risque de "cassage" Attachez vos ceintures, prenez un crayon car un dessin est plus parlant : supposons un pays carré fait de 4 régions carrées, chacunes faites de 4 départements carrés faits de 4 communes carrées. On supprime un seul way de commune qui se trouve en frontière de pays. - La commune ne forme plus une surface, elle est donc "non valide" (tant pis pour elle) tout traitement qui va tenter de "construire" la surface ou la frontière du département (par calcul du polygone externe, c'est la seule solution) auquel elle appartient va être composé de 3 communes et former un L, si je dois dessiner ce département ou faire des traitements d'appartenance, de surface, etc. ça va merder car j'ai un département faux (il lui manque en effet un quart) Idem pour région et pays Donc on peut avoir l'illusion que ça va (on arrive à construire des surfaces), mais elles sonts "légèrement erronées" Cas plus dommage encore avec une logique surfacique au lieu de frontière : Si je casse le way d'une commune se trouvant à l'intérieur d'un département sans pour autant être en bordure, en construisant mon département j'ai un trou (une enclave ?) et mon département reconstruit devient faux à son tour. > Je n'ai pas la prétention d'imposer un changement :), je cherche juste à > comprendre pour l'instant (je ne suis sûr de rien non plus) Pareil, je réfléchis à ta remarque sensée qui dit "on va perdre du temps" J'ai une autre idée de modèle qui est un mi-chemin des deux (ton idée VS l'existant) [Pieren, si tu me lis, arrête tout de suite, tu vas faire une attaque] On conserve une logique de frontière et non surfacique, mais on construit tout de même une pyramide des appartenances. J'avais déjà tenté ce mécanisme pour construire la frontière de la france, non pour simplifier, mais parce qu'elle devenait trop grosse d'un seul tenant (raison stupidement technique, mais qui s'avéra finalement plus sympa à manipuler) Maestro, crayon ! (et cas concret) : Soit la france, rhone alpes, la savoie et une commune X de bordure La commune X dispose disons de 2 ways en frontière de pays (ben oui, les italiens ont aussi leurs communes et pas de chance, ça tombe pas "en face") (En poussant à l'extrème :) On créer une relation pour regrouper ces 2 ways (cette relation est de type linear et non une surface) La commune X est donc composée de cette relation, et disons d'une ou deux autres représentant des objets linéaires On créer ensuite une autre relation de type linear qui contient tous mes groupes de 2 ways et qui couvre la frontière entre savoie et italie Ma relation savoie de type surface sera alors composée de cette relation et de 3 ou 4 autres de même types etc.. La rupture d'un seul way entraîne toujours la non validité de l'ensemble (comme aujourd'hui) mais la réparation consiste à créer le way et l'ajouter à ma relation de bordure de commune du départ, et tout rentre dans l'ordre Bilan : un way (du modèle OSM) n'appartient qu'a 2 relations au max (des types linear de chaque coté du way) Chaque relation de type linéaire n'appartient qu'a 4 relations au max (aux deux surfaces qu'elle borde et au deux autre relations linéaire qu'elle compose) Dans mon modèle les surfaces ne sont composés que de très peu de relation de type linéaire -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
2009/6/30 Yoann ARNAUD : Pas sûr que modèle "surface" soit plus simple. D'abord, comme dit Sly, on doit ajouter toutes les communes alors que sinon, on ne colle que les ways extérieurs. Ensuite, comment traiteras-tu les enclaves/exclaves ? Et les différents admin_level sur les ways ? Bien-sûr, on pourrait tout mettre dans les relations et laisser les ways sans tags et définir les rôles inner/outer sur les relations de communes (est-ce que ça marche à tous les coups ?). L'avantage du modèle actuel est qu'il est documenté et adopté ainsi par tous les pays. Quand à la maintenance, ça ne serait pas plus simple car il déplace la maintenance des ways vers celle des relations. Si la relation communale est faussée (un way hors de la relation commune par ex.), toutes les autres relations en dépendant seront aussi cassées. Recréer une relation commune obligera à mettre à jour la relation supérieure. Au final, le gain n'est pas si évident même si l'alternative est intéressante. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
sly (sylvain letuffe) a écrit : > Lorsque tu devra ajouter les 350 communes d'un département à ta > relation "département" es-tu sûr que ce sera plus rapide que les ~150 ways > qui en font le tour ? > > A vu de nez, je dirais que ça représente a peu prêt le même boulot. Oui, c'est le même boulot, la première fois que tu le fais ! Mais réfléchissons à la maintenance. Quand une relation région est cassée, il faut réparer la relation région, la relation département, la relation commune et sans doute d'autres si on augmente la granularité du maillage (ce n'est peut être pas toujours vrai mais je le constate très souvent). Dans un modèle "surface", une relation région ne serait jamais cassée car son contenu (des relations) ne bougerait pas, à priori. Pareille pour un département, un canton etc... Jusqu'à maintenant, nous ne réfléchissions, je pense, qu'à l'ajout de données (c'est la croissance exponentielle du projet qui veut ça). Nous allons progressivement migrer vers une situation où il faudra corriger de plus en plus d'erreurs (il suffit de regarder osmose pour se rendre compte du boulot qu'il y a juste avec qqes erreurs basiques) >> implication" : un way qui délimite plein de chose n'appartient qu'à >> une relation (ou deux, en fait les plus petites sous-régions que l'on >> peut construire) > Pour les ways communs à plusieurs niveaux administratifs, c'est vrai que ça > semble mieux. > > > ... et cela serait quand même vachement plus simple à manipuler (si vous >> voulez en être convaincu, je vous invite à corriger qqes relations ;) ) > > Dans le modèle actuel, je ne trouve pas ça "impossible" il faudrait que je > tente sur un modèle surfacique pour voir si c'est plus mieux bien. > > Le truc c'est qu'on est parti comme ça, changer le modèle prendrait peut-être > plus de temps d'apprentissage que de finir comme ça... Je n'ai pas la prétention d'imposer un changement :), je cherche juste à comprendre pour l'instant (je ne suis sûr de rien non plus) -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
> Inutiles, OK. Mais "trop", je ne sais pas si c'est un problème, je pense > même que non. (...) > Peut-être, j'ai un peu de mal à évaluer comme ça la complexité d'une > requête. Laissons la technique aux techniciens, je doute que ce soit bien plus compliqué que ce qui est fait actuellement, il me parait plus judicieux de faire simple pour celui qui fourni la donnée "data is king" disait un spécialiste en SIG > Alors que des ways bidouillés qui cassent plein de relations d'un coup, > ça, on en aura toujours ! non ? Mmm, si quelqu'un retire une relation de niveau n, on aura pas "cassé" la fermeture des relations de niveau >n mais on les aura rendues toutes fausses, c'est peut-être pas mieux et plus dur à contrôler. Dans le cas des relations administratives, j'imagine bien des contrôles de surface car on peut supposer qu'il n'existe pas de point du territoire à n'être "nul part", mais ce n'est pas le cas pour les autres types de relations (fleuves, forêts, landuse, natural, etc.) et il m'apparait fondamental pour la simplicité de compréhension du mappeur d'être sur un système homogène a travers tous les types d'objets de surface (modèle surfacique ou de frontière mais pas les deux) Après, en reprenant mon exemple de fleuve, je constate au niveau du mapping que c'est le modèle surfacique qui semble le plus utilisé, les longs fleuves ressemblent à : ___ [___||_||___] (surfaces fermées à intervals réguliers coupant le fleuve en morceau de surface) et non à _ [ _ ] (relation contenant plein de ways ne formant qu'une seule surface finale) Est-ce à dire que le modèle surfacique est plus simple pour le mappeur ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
Dominique Rousseau a écrit : > Ben, il y aurait bien trop d'infos inutiles, dans cette "super > relation". Inutiles, OK. Mais "trop", je ne sais pas si c'est un problème, je pense même que non. > On parle de la délimitation du département|région. Il n'y a donc que les > morceaux de limites de communes qui se trouvent en limite de > département|région qui soient concernées. > Il est plus simple, je pense, de faire une requete demandant « quels > sont les polygones communes contenus dans le plygone département » que > de déterminer quelles sont les limites extérieures d'un maillage qui > contiendrait toutes les communes. Peut-être, j'ai un peu de mal à évaluer comme ça la complexité d'une requête. En tout cas, ça ne me parait pas infaisable. Mais bon, une requête, une fois qu'elle est écrite et qu'elle marche bien, c'est réglé on en parle plus. Alors que des ways bidouillés qui cassent plein de relations d'un coup, ça, on en aura toujours ! non ? -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
> Je demandais plutôt pourquoi un autre modèle de type "surface" ne serait > pas utilisé car beaucoup simple à manipuler pour les mappeurs que nous > sommes ? Moi j'ai bien compris, je me suis posé la même question et je tente d'y répondre en disant toujours : "au plus simple pour le mappeur" Et donc, est-ce bien sûr que c'est plus simple à manipuler ? (je ne suis sûr de rien, je réfléchis avec vous à la question) Lorsque tu devra ajouter les 350 communes d'un département à ta relation "département" es-tu sûr que ce sera plus rapide que les ~150 ways qui en font le tour ? Ou alors ne placerait-t-on que les communes qui en font le tour, mais bon, ça ressemble un peu à la même chose... A vu de nez, je dirais que ça représente a peu prêt le même boulot. > implication" : un way qui délimite plein de chose n'appartient qu'à > une relation (ou deux, en fait les plus petites sous-régions que l'on > peut construire) Pour les ways communs à plusieurs niveaux administratifs, c'est vrai que ça semble mieux. > ... et cela serait quand même vachement plus simple à manipuler (si vous > voulez en être convaincu, je vous invite à corriger qqes relations ;) ) Dans le modèle actuel, je ne trouve pas ça "impossible" il faudrait que je tente sur un modèle surfacique pour voir si c'est plus mieux bien. Le truc c'est qu'on est parti comme ça, changer le modèle prendrait peut-être plus de temps d'apprentissage que de finir comme ça... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
Le mardi 30 juin 2009 à 13:55 +0200, Yoann ARNAUD a écrit : > Bonjour tout le monde, > > Une question existentielle me taraude l'esprit depuis un moment, surtout > depuis que je corrige des relations cassées (du côté d'Orléans, l'import > est vraiment crade [1]). Pourquoi taggons-nous les boundary > administrative de façon si compliquée ? Je m'explique : > Je m'occupe d'Orléans, et plaide non coupable ;-) en réalité je ne suis pas responsable des ways en double, ceci ayant été réalisé par un autre contributeur, mais je comptais mettre la main à la pate une fois sur que toutes les communes y étaient. J'ai commencé à faire le "ménage" et il reste encore 86 communes à saisir pour que le 45 soit complet (d'après l'import cadastral). Si besoin d'aide pour les réparations, on peut peut-être se coordonner. Désolé pour le HS, mais je profitais que le sujet soit abordé ; -- Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
THEVENON Julien a écrit : > je pense que c est tout simplement parce que seule une partie de la > delimitation de la commune appartient au departement. > De meme seule une seule partie du contour du departement appartient au > contour de la region Oui j'ai bien assimilé ceci. Mais là tu es train de me justifier le principe par l'implication qui en résulte. Pour résumer, nous suivons dans le modèle suivant : Modèle "contours": principe : "le modèle consiste à représenter une région par l'ensemble des ways qui constituent le contour" implication : "un way est suceptible d'appartenir à plein de relations s'il délimite plein de régions" Je demandais plutôt pourquoi un autre modèle de type "surface" ne serait pas utilisé car beaucoup simple à manipuler pour les mappeurs que nous sommes ? Modèle "surface": principe : "le modèle consiste à représenter une région par la surface qu'elle occupe, une région qui contient plusieurs sous-région est l'union de ces sous-régions" implication" : un way qui délimite plein de chose n'appartient qu'à une relation (ou deux, en fait les plus petites sous-régions que l'on peut construire) ... et cela serait quand même vachement plus simple à manipuler (si vous voulez en être convaincu, je vous invite à corriger qqes relations ;) ) J'espère que j'ai été un peu plus clair. -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
Le Tue, Jun 30, 2009 at 01:55:38PM +0200, Yoann ARNAUD [yarn...@crans.org] a écrit: > Bonjour tout le monde, > > Une question existentielle me taraude l'esprit depuis un moment, surtout > depuis que je corrige des relations cassées (du côté d'Orléans, l'import > est vraiment crade [1]). Pourquoi taggons-nous les boundary > administrative de façon si compliquée ? Je m'explique : > > Un way qui délimite une commune appartient à une relation commune ET une > relation département ET une relation région etc... > > Pourquoi ne pas plus simplement opter pour un modèle où ce way > appartient à une relation commune seulement, puis cette relation commune > appartient à une relation département, puis cette relation département à > une relation région etc... > > Cela pose-t-il un problème particulier que je n'ai pas encore saisi ou > est-ce un modèle qui a emmergé du temps où les relations de relations > n'étaient pas encore apparues ? Ben, il y aurait bien trop d'infos inutiles, dans cette "super relation". On parle de la délimitation du département|région. Il n'y a donc que les morceaux de limites de communes qui se trouvent en limite de département|région qui soient concernées. Il est plus simple, je pense, de faire une requete demandant « quels sont les polygones communes contenus dans le plygone département » que de déterminer quelles sont les limites extérieures d'un maillage qui contiendrait toutes les communes. -- Dominique Rousseau Si cinquante millions de gens disent une sottise, ça n'en reste pas moins une sottise. -- Anatole France ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pourquoi ne pas tagger les boundary administrative en relations de relations ???
Bonjour tout le monde, Une question existentielle me taraude l'esprit depuis un moment, surtout depuis que je corrige des relations cassées (du côté d'Orléans, l'import est vraiment crade [1]). Pourquoi taggons-nous les boundary administrative de façon si compliquée ? Je m'explique : Un way qui délimite une commune appartient à une relation commune ET une relation département ET une relation région etc... Pourquoi ne pas plus simplement opter pour un modèle où ce way appartient à une relation commune seulement, puis cette relation commune appartient à une relation département, puis cette relation département à une relation région etc... Cela pose-t-il un problème particulier que je n'ai pas encore saisi ou est-ce un modèle qui a emmergé du temps où les relations de relations n'étaient pas encore apparues ? Merci d'avance de m'éclairer. [1] : http://osmose.openstreetmap.fr/map/cgi-bin/index.py?zoom=10&lat=48.01915&lon=2.02628&layers=B00FFFTT&ch=111,500 -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
