Re: [OSM-talk-fr] Import du bati cadastral du Pays de Romans

[Etienne Trimaille]

Un permalink pour montrer le résultat peut-être pas mal ;-)

http://www.openstreetmap.org/?lat=45.0521&lon=5.0572&zoom=14&layers=B000FTF

Beau travail :)

Le 7 juin 2010 08:34, Jeff MERCIER  a écrit :

> Voilà, l'import a été réalisé.
> Sujet clos, merci à tous!
>
>
> Jeff MERCIER a écrit :
>
>> Je venais de trouver, mais je te remercie!
>>
>> Nicolas Dumoulin a écrit :
>>
>>> Le jeudi 3 juin 2010 13:53:48 Jeff MERCIER, vous avez écrit :
>>>
>>>
 Il y a une manip particulière a effectuer, où c'est automatique?


>>>
>>> Au moment du commit, tu as un onglet « Expert » (la classe) dans la
>>> partie basse de la fenêtre, et là tu trouveras les options en questions.
>>> C'est très intuitif :-)
>>> Bon par contre, j'avais quand même dû m'y reprendre à plusieurs fois lors
>>> d'un gros commit. Tous les petits bouts ne passaient pas d'un coup, mais
>>> l'avantage que ceux qui sont passés sont ça de moins à faire.
>>>
>>>
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Jeff MERCIER
> Administrateur SIG
> Chargé de mission sentiers de randonnée
> Communauté de Communes du Pays de Romans
> 04.75.70.68.93
>
>
> ___
> 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] Import du bati cadastral du Pays de Romans

[Jeff MERCIER]

Voilà, l'import a été réalisé.
Sujet clos, merci à tous!


Jeff MERCIER a écrit :

Je venais de trouver, mais je te remercie!

Nicolas Dumoulin a écrit :

Le jeudi 3 juin 2010 13:53:48 Jeff MERCIER, vous avez écrit :
 

Il y a une manip particulière a effectuer, où c'est automatique?



Au moment du commit, tu as un onglet « Expert » (la classe) dans la 
partie basse de la fenêtre, et là tu trouveras les options en 
questions. C'est très intuitif :-)
Bon par contre, j'avais quand même dû m'y reprendre à plusieurs fois 
lors d'un gros commit. Tous les petits bouts ne passaient pas d'un 
coup, mais l'avantage que ceux qui sont passés sont ça de moins à faire.


  



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
  



--
Jeff MERCIER
Administrateur SIG
Chargé de mission sentiers de randonnée
Communauté de Communes du Pays de Romans
04.75.70.68.93

<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Vincent Pottier]

Le 06/06/2010 23:20, sylvain letuffe a écrit :
> Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit :
>> Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en
>> désigner la géométrie. Le multipolygone n'est donc pas "river" mais
>> pourrait être "river_surface".
>>  
> C'est vrai, mon exemple n'étais pas très bon, un river_surface serait un mot
> mieux choisi puisque c'est ça que ça représente.
>
>
>> relation river avec des éléments de surface et des éléments axiaux est
>> une solution relativement propre.
>>  
> Oui, ce que je trouve moyennement bien fichu c'est uniquement la partie
> description de la surface. Je ne vois pas d'inconvénients à créer une autre
> relation type=river qui contient la relation qui décrit la surface, le way (ou
> relation) qui décrit l'axe, et tout ce qu'on voudra bien y mettre (j'ai malgré
> tout un peu de mal à imaginer l'usage, mais ma foi, certain y trouverons bien
> un intérêt)
>
> Ce que je vois bien par contre, c'est qu'aujourd'hui le modèle de donnée ne me
> permet pas de construire par exemple une carte des cours d'eau français de
> longueur supérieur à X km
>
> cf l'horreur à laquelle je me suis arrété :
> http://wiki.openstreetmap.org/wiki/File:Hydro.png
>
>
>
>>> Maitrisable dans quel sens ?
>>>
>> Longueur du cours d'eau.
>> Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée.
>>
>> Si je dois m'assurer de la cohésion des 1000 km de la Loire...
>> Il y a des problèmes pour la coastline, on retrouverait ce type de
>> problème (à moindre échèle) pour les cours d'eau.
>>  
> Avec la solution du multipoly qui couvre tout le cours d'eau, une modification
> locale sur un poly valide n'a aucune raison d'entrainer une rupture 100km plus
> loin, vu que justement on n'a téléchargé que les riverbank d'une petite zone.
>
La solution est mieux, théoriquement.

Mais avec des segments, les crottes chez mon voisins n'entachent pas mon 
bac-à-sable.
C'est plus petit mais plus sur.

Et puis, je me sens le courage de cartographier 80 km du cours d'eau, 
pas 800 km. Dois-je attendre que le courage me vienne ?

La cohésion locale, je la contrôle dans JOSM, donc en direct, pas dans 
osmose, en différé.

Quand j'édite des bouts de multipolygones dans JOSM, j'ai des formes 
bizarres, pas belles, pas finies.

Bref, ta solution est mieux, théoriquement, ou à terme.

Mais les segments, c'est plus politiquement correct, plus sur, à court 
terme, plus rassurant.
> En revanche, et c'est là que je trouve que c'est pernitieux les multiples
> bouts autonomes de surface qui forment une plus grosse surface, c'est que si
> je calcul la longeur/surface d'un fleuve, une valeur me sera retournée, mais
> qui sera fausse
>
Pas à partir de ça : somme des role=waterbank

De toute façon on ne calculera que la surface 'cartographiée' du fleuve.
>
>> Le logiciel de routage ne se basera pas sur les multipolygones, les
>> plans d'eau, mais sur du filaire (le waterway)
>>  
> Certes, le principe est similaire, si mon waterway à un trou, graphiquement ça
> ne se voit que mal
voire pas du tout sous un waterbank
>   mais le routage est interompu.
>
On a le même problème que pour les routes...
On pourrait reprendre l'algorythme des bouts de train (voir un autre 
mail) et repérer les waterways cul-de-sac, qui ne sont pas la mer.
Je pense qu'il y a un tag pour les "pertes" pour éviter les faux positifs.
> Certes encore, il existe de toute façon des outils pour contrôler plus ou
> moins tout.
>
Pas encore mais ça vient !
> Je reviens un peu sur ton example du coastline, ça me donne des idées :-) La
> solution utilisée est une re-construction périodique des côtes pour qu'un
> controle semi-humain valide que tout est bien fermé avant de lancer des
> rendus/utilisations.
>
> Une bonne (peut-être ?) idée serait de faire du controle d'integrité et du
> versionning. Si la relation X qui représente un polygone ne forme plus un
> polygone, on ne fait pas la mise à jour.
>
> C'est ce que je fais en fait sans y avoir pensé ici :
> http://beta.letuffe.org/ressources/export-communes/
>
> Je ne rend disponible une mise à jour que si celle-ci est complète est valide,
> sinon je fourni la précédente
>
Ouais, il est possible que des serveurs "label qualité" vont se 
multiplier, notamment pour les collectivités, où la donnée n'est pas de 
toute première fraicheur, mais relue et filtrée.
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[sylvain letuffe]

Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit :

> L'intérêt de distinguer l'area (et les multipolygones) du way, et de
> reconstruire le tout dans un type=river, c'est qu'une rivière est un
> plan d'eau ET un cours d'eau, voire des écluses, des barrages, une
> activité économique et autres

Tout à fait. Et ces éléments peuvent être mis en relation, pourquoi pas.

> Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en
> désigner la géométrie. Le multipolygone n'est donc pas "river" mais
> pourrait être "river_surface".

C'est vrai, mon exemple n'étais pas très bon, un river_surface serait un mot 
mieux choisi puisque c'est ça que ça représente.

> relation river avec des éléments de surface et des éléments axiaux est
> une solution relativement propre.

Oui, ce que je trouve moyennement bien fichu c'est uniquement la partie 
description de la surface. Je ne vois pas d'inconvénients à créer une autre 
relation type=river qui contient la relation qui décrit la surface, le way (ou 
relation) qui décrit l'axe, et tout ce qu'on voudra bien y mettre (j'ai malgré 
tout un peu de mal à imaginer l'usage, mais ma foi, certain y trouverons bien 
un intérêt)

Ce que je vois bien par contre, c'est qu'aujourd'hui le modèle de donnée ne me 
permet pas de construire par exemple une carte des cours d'eau français de 
longueur supérieur à X km

cf l'horreur à laquelle je me suis arrété :
http://wiki.openstreetmap.org/wiki/File:Hydro.png


> > Maitrisable dans quel sens ?
> 
> Longueur du cours d'eau.
> Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée.
> 
> Si je dois m'assurer de la cohésion des 1000 km de la Loire...
> Il y a des problèmes pour la coastline, on retrouverait ce type de
> problème (à moindre échèle) pour les cours d'eau.

Avec la solution du multipoly qui couvre tout le cours d'eau, une modification 
locale sur un poly valide n'a aucune raison d'entrainer une rupture 100km plus 
loin, vu que justement on n'a téléchargé que les riverbank d'une petite zone.

En revanche, et c'est là que je trouve que c'est pernitieux les multiples 
bouts autonomes de surface qui forment une plus grosse surface, c'est que si 
je calcul la longeur/surface d'un fleuve, une valeur me sera retournée, mais 
qui sera fausse

> Le logiciel de routage ne se basera pas sur les multipolygones, les
> plans d'eau, mais sur du filaire (le waterway)

Certes, le principe est similaire, si mon waterway à un trou, graphiquement ça 
ne se voit que mal mais le routage est interompu.

Certes encore, il existe de toute façon des outils pour contrôler plus ou 
moins tout.

Je reviens un peu sur ton example du coastline, ça me donne des idées :-) La 
solution utilisée est une re-construction périodique des côtes pour qu'un 
controle semi-humain valide que tout est bien fermé avant de lancer des 
rendus/utilisations.

Une bonne (peut-être ?) idée serait de faire du controle d'integrité et du 
versionning. Si la relation X qui représente un polygone ne forme plus un 
polygone, on ne fait pas la mise à jour.

C'est ce que je fais en fait sans y avoir pensé ici :
http://beta.letuffe.org/ressources/export-communes/

Je ne rend disponible une mise à jour que si celle-ci est complète est valide, 
sinon je fourni la précédente


--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Vincent Pottier]

Le 06/06/2010 22:27, sylvain letuffe a écrit :
> Mon cas pourrait s'en sortir s'il décidait d'appler un chat un chat, c'est à
> dire une rivière
> Genre :
> type=multipolygon + waterway=river (encore qu'on pourrait discuter du "way" du
> mot "waterway")
>
L'intérêt de distinguer l'area (et les multipolygones) du way, et de 
reconstruire le tout dans un type=river, c'est qu'une rivière est un 
plan d'eau ET un cours d'eau, voire des écluses, des barrages, une 
activité économique et autres
Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en 
désigner la géométrie. Le multipolygone n'est donc pas "river" mais 
pourrait être "river_surface".

En ce moment, sur la ML anglaise, il y a une discussion pour tagger les 
escaliers extra-larges. Comment cartographier une objet qui est à la 
fois une surface et un axe ? C'est la question des rivières : la 
relation river avec des éléments de surface et des éléments axiaux est 
une solution relativement propre.
Difficilement applicable à la voirie vue le nombre de routes.
Quoique, j'espère que dans quelques temps, les way:highway + 
relation:associated_street (adressage) + area:... seront regroupés dans 
une relation street (pourquoi avoir affublé la relation d'un 
associated_quelquechose ? C'est, il me semble, de la courte vue)
>> Pour fermer le multipolygone, je devrais mettre un way dans le confluent
>> du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau.
>>  
> Pas nécessairement, car tu ne tagguerais justement pas ce way en riverbank,
> mais simplement en rien du tout
>
>
On n'est pas très habitué à mettre le tag "river..." dans la relation, 
mais sur le(s) way(s) outer.
Bon je suis d'accord que la pratique pourrait changer !
>
>> Donc la solution adoptée, pragmatique, est de sectionner le fleuve et
>> d'utiliser le "riverbank" comme un area, ce qui le rend plus maitrisable
>> sur des longues distance,
>>  
> Maitrisable dans quel sens ?
>
Longueur du cours d'eau.
Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée.

Si je dois m'assurer de la cohésion des 1000 km de la Loire...
Il y a des problèmes pour la coastline, on retrouverait ce type de 
problème (à moindre échèle) pour les cours d'eau.
> J'ai envie de sortir une boutade :
> Le défaut du gros multipolygon est qu'une erreur fout tout en l'air, et
> l'avantage du gros multipolygon est que ça fout tout en l'air.
>
> Dans le sens où un trou sur le parcours est (visuellement en tout cas)
> rapidement visible, donc on sait qu'il y a une erreur.
>
> Dans le cas de multiples bouts, un petit morceau peut manquer et ça se voit
> moins.
>
> Après, si on a une logique "rendu" c'est clair, c'est con, la rivière a
> disparu.
> Maintenant si je suis conducteur de péniche et que je veux faire
> lyon->valence, c'est quand même con que mon GPS m'indique de passer par le
> canal du rhin pour revenir par la méditérané
Le logiciel de routage ne se basera pas sur les multipolygones, les 
plans d'eau, mais sur du filaire (le waterway)
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Clement Menier]

Pierre-Alain Dorange wrote:
>
> Le 6 juin 10 à 16:05, Clement Menier a écrit :
>
>>Je me rends compte suite à ta remarque que j'ai pu faire du "sale" 
>> boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites 
>> pas à corriger ce que j'ai fait ou à me demander de corriger ces zones 
>> si il y a un souci (je ne travaille pas sur ces communes en ce moment).
>
> En fait tu n'avais pas tagger les iles, j'ai fait un peu de ménage en 
> création un multipolygone sur Jarnac pour pouvoir y intégrer les îles 
> (place=island en member=inner) et j'ai ajouter les écluses.
> Pas encore totalement finit.
>
Merci pour tes corrections. En effet je ne maîtrise pas encore les 
multipolygones, mais maintenant que j'ai un exemple j'essaierai de le 
suivre si je rencontre ce type de construction.

Merci aussi pour avoir updater tes contributions dans le wiki.

Clément.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[sylvain letuffe]

Le dimanche 06 juin 2010 22:03:51, Vincent Pottier a écrit :
> Sly, tu as raison, en partie : le tag riverbank pour cartographier des
> plans d'eau tel qu'utilisés couramment n'est pas exact. Le tag devrai
> être une traduction anglaise de "plan d'eau sur rivière". Le rendu
> mapnik est celui d'un area alors que "riverbank" désigne un way. 

ça, à la limite, le nom, je m'en fiche un peu, tant pis pour la confusion, du 
moment que c'est expliqué et la page sur riverbank l'explique bien.

> Seulement... Un multypolygone "riverbank" n'est jamais fermé : il y a
> des confluents. Et au confluent, la limite du fleuve ou de la rivière
> n'est plus un "riverbank".

Tu marques un point. Mais qui confirme le choix médiocre du nom, les deux cas 
présente la même confusion d'avoir le mot "riverbank" (qui suggère donc une 
ligne) alors que nous taggons une surface. 

Mon cas pourrait s'en sortir s'il décidait d'appler un chat un chat, c'est à 
dire une rivière
Genre : 
type=multipolygon + waterway=river (encore qu'on pourrait discuter du "way" du 
mot "waterway")

> Pour fermer le multipolygone, je devrais mettre un way dans le confluent
> du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau.

Pas nécessairement, car tu ne tagguerais justement pas ce way en riverbank, 
mais simplement en rien du tout

> (Déjà que, à Lyon, il y a quelque chose de spécifique au milieu du Rhône
> et de  la Saône au dessus de l'eau (de l'o) : un accent circonflexe)

?
 
> Donc la solution adoptée, pragmatique, est de sectionner le fleuve et
> d'utiliser le "riverbank" comme un area, ce qui le rend plus maitrisable
> sur des longues distance, 

Maitrisable dans quel sens ? 

> de le rendre moins fragile aux erreurs (la
> moindre erreur fout en l'air l'ensemble du multipolygone).

J'ai envie de sortir une boutade :
Le défaut du gros multipolygon est qu'une erreur fout tout en l'air, et 
l'avantage du gros multipolygon est que ça fout tout en l'air.

Dans le sens où un trou sur le parcours est (visuellement en tout cas) 
rapidement visible, donc on sait qu'il y a une erreur.

Dans le cas de multiples bouts, un petit morceau peut manquer et ça se voit 
moins.

Après, si on a une logique "rendu" c'est clair, c'est con, la rivière a 
disparu. 
Maintenant si je suis conducteur de péniche et que je veux faire 
lyon->valence, c'est quand même con que mon GPS m'indique de passer par le 
canal du rhin pour revenir par la méditéranée


--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Vincent Pottier]

Le 06/06/2010 12:44, sylvain letuffe a écrit :
> Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est
> l'habitude.
>
Pas seulement, voir plus loin
> Lobying contre :
>
> * Les zones d'interconnexion entre plusieurs multipolygone sont tout à fait
> arbitraire et ne correspondent à rien de réél
>
> * S'il me prend de vouloir représenter les bords du fleuve en bleu foncé, 
> c'est
> très galère car je vais introduire des coupures le long du lit de la rivière
> aux endroits "qui font le collage"
>
> * Le nom de la rivière doit être indiqué sur chaqu'un des morceaux qui la
> compose
>
> * Si je veux obtenir dans un format vectoriel la forme complète de la rivière,
> je suis obligé de récupérer à la main, tous les morceaux, faire des découpes
> et re-collage
>
> je ne suis pas seul à penser ça :
> http://lists.openstreetmap.org/pipermail/talk/2008-February/023009.html
>
> Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout
> cas) des multipolygones :
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers
> Le problème, c'est que le tout ne forme pas un multipolygon valide au sens OSM
> du terme (ni au sens GIS du terme d'ailleurs)
>
Sly, tu as raison, en partie : le tag riverbank pour cartographier des 
plans d'eau tel qu'utilisés couramment n'est pas exact. Le tag devrai 
être une traduction anglaise de "plan d'eau sur rivière". Le rendu 
mapnik est celui d'un area alors que "riverbank" désigne un way. L'usage 
du multipolygone semblerait plus exact, comme pour les "boundary"
Seulement... Un multypolygone "riverbank" n'est jamais fermé : il y a 
des confluents. Et au confluent, la limite du fleuve ou de la rivière 
n'est plus un "riverbank".
Pour fermer le multipolygone, je devrais mettre un way dans le confluent 
du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau.
(Déjà que, à Lyon, il y a quelque chose de spécifique au milieu du Rhône 
et de  la Saône au dessus de l'eau (de l'o) : un accent circonflexe)

Tout ça pour dire que la solution du multipolygone n'est pas 
complètement satisfaisante non plus, ni formellement, ni pour le rendu.

Donc la solution adoptée, pragmatique, est de sectionner le fleuve et 
d'utiliser le "riverbank" comme un area, ce qui le rend plus maitrisable 
sur des longues distance, de le rendre moins fragile aux erreurs (la 
moindre erreur fout en l'air l'ensemble du multipolygone).

Pas satisfaisant, mais plus maniable.
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu train et ferry

[Guillaume Allegre]

Le Sun 06 Jun 2010 à 21:33 +0200, Rodolphe Quiedeville a ecrit :

> > 1) Quelles unités tu utilises pour tes coordonnées ? Est-ce qu'une version 
> > en vraies lat/lon est prévue ? Je suis un grand utilisateur du Mapjumper, 
> > et là 
> > ça passe pas !
> 
> Corrigé, j'avais laissé le Permalink par défaut en 900913, c'est
> modifié, Mapjumper devrait apprécier.

merci !



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu train et ferry

[Rodolphe Quiedeville]

Guillaume Allegre a écrit :
> Le Fri 04 Jun 2010 à 15:08 +0200, Rodolphe Quiedeville a ecrit :
> 
>> http://tile.quiedeville.org/train/?zoom=10&lat=6159703.94077&lon=-425964.22107&layers=B000
>>
>> Ceci étant fait il faut encore que j'améliore mes rendus, et aussi
>> réfléchir à un algo pour trouver les portions de voies isolées.
> 
> Pas mal du tout.
> 1) Quelles unités tu utilises pour tes coordonnées ? Est-ce qu'une version 
> en vraies lat/lon est prévue ? Je suis un grand utilisateur du Mapjumper, et 
> là 
> ça passe pas !

Corrigé, j'avais laissé le Permalink par défaut en 900913, c'est
modifié, Mapjumper devrait apprécier.

> 2) Pourrais-tu ajouter les highway=preserved ? Peut-être dans une autre 
> couleur ?
> Par exemple celui-ci (petit train de la Mure, Isère) :
> http://www.openstreetmap.org/?mlat=44.9687&mlon=5.6907&zoom=14&layers=B000FTF


Je vais regarder cela.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Le 6 juin 10 à 16:05, Clement Menier a écrit :


   Je me rends compte suite à ta remarque que j'ai pu faire du "sale"
boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites
pas à corriger ce que j'ai fait ou à me demander de corriger ces zones
si il y a un souci (je ne travaille pas sur ces communes en ce  
moment).



En fait tu n'avais pas tagger les iles, j'ai fait un peu de ménage en  
création un multipolygone sur Jarnac pour pouvoir y intégrer les îles  
(place=island en member=inner) et j'ai ajouter les écluses.

Pas encore totalement finit.

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[sylvain letuffe]

Le dimanche 06 juin 2010 17:53:48, Pierre-Alain Dorange a écrit :
> > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers
> 
> Je comprend pas la technique... un exemple ?

Honte sur moi, j'ai copié ce lien sur la base uniquement de l'image mais je 
n'avais pas vu la description complètement tirée par les cheveux et obsolète.

Mon explication est donc bien là :
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[sylvain letuffe]

Le dimanche 06 juin 2010 17:53:48, Pierre-Alain Dorange a écrit :
> > Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs
> > en tout
> > cas) des multipolygones :
> > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers
> 
> Je comprend pas la technique... un exemple ?

Tu peux pas mieux tomber, ton message m'a rappelé que je n'avais pas avancé 
depuis quelques temps le tracé de l'Isère (savoie) et j'ai pas mal avancé et 
collé des morceaux

La méthode que j'utilise est décrite ici (avant qu'on me taxe de baratineur 
;-), je précise que c'est moi qui est écrit cette documentation il y a pas 
plus tard qu'après ton 1er mail) :

http://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank

Le résultat appliqué à l'Isère donne ça :
http://www.openstreetmap.org/browse/relation/278498

On peut dès lors la visualiser facilement, et d'un seul tenant avec l'outil 
magnifique qu'on ne site plus :

http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=278498

Et profiter ensuite de la ribambelle d'outils qui peuvent convertir ça dans 
tous les sens, contrairement, bien sûr à la méthode traditionnelle (j'en fais 
trop ?)

par là : (export de L'isère au format GPX)
http://betaplace.emaitie.de/webapps.relation-
analyzer/downloadServlet/gpx/278498

La doc générale des multipolygon est là :
http://wiki.openstreetmap.org/wiki/Relation:multipolygon


Certes, ça demande un peu de s'y plonger, et je pense que c'est pour ça 
qu'elle est considérée comme "hardue" ou "complexe", mais sitôt qu'il faudra 
mettre une île, il faudra de toute façon l'utiliser, alors !

En plus JOSM commence vraiment bien gérer les relations en indiquant les îles 
(role=inner) si il n'y a pas de trous, etc.

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Le 6 juin 10 à 12:44, sylvain letuffe a écrit :


Un autre avis ;-)


C'est une liste de discussion ;-)


Le dimanche 06 juin 2010 12:27:12, Pierre-Alain Dorange a écrit :

Par contre intellectuellement ça m'apparaît peu satisfaisant de voir
des "rivernak" qui coupe le fleuve en deux, ça me fait penser "a
tagger pour le rendu"


C'est un bon résumé, c'est (était?) une solution pour contourner le  
problème
des rendus classiques qui ne géraient pas bien les relations  
multipolygone.


Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce  
n'est

l'habitude.

Lobying contre :


Je suis en phase avec l'argumentaire.

Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs  
en tout

cas) des multipolygones :
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers


Je comprend pas la technique... un exemple ?

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Le 6 juin 10 à 16:05, Clement Menier a écrit :


Salut Pierre-Alain,


Salut,


   Je me rends compte suite à ta remarque que j'ai pu faire du "sale"
boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites
pas à corriger ce que j'ai fait ou à me demander de corriger ces zones
si il y a un souci (je ne travaille pas sur ces communes en ce  
moment).


Pour l'instant j'ai juste fait le raccord avec ton boulot sur le  
fleuve à Jarnac.
J'ai remarqué 2/3 trucs bizarre mais j'ai pas encore regardé en  
détail...



   Concernant le cours d'eau (waterway=river) qui devrait si j'ai bien
compris correspondre au trajet "principal" de la Charente, j'ai repéré
des trucs assez étranges au niveau de Bassac. N'ayant que le  
cadastre et

des photos pour source d'information, je n'ai pas corrigé, mais si tu
connais le trajet "principal" on pourrait corriger cela aussi par la
même occasion.


Je ne connais pas le cours principal du coté de Bassac et ça doit être  
très compliqué vu comment c'est sur le terrain...

Je m'y baigne de temps en temps, c'est tout.

Je compte dessiner la fleuve à moyen terme mais il me faudra des infos  
de terrains en plus, si tu en as je suis preneur évidemment.
Mon beau père connais bien le coin (Cognac-Saint-Simon), il y a fait  
pas mal de plongées archéologiques et à des cartes et une mémoire qui  
pourrait être utile.



   Sur un sujet légèrement différent, j'ai commencé à répertorier les
avancées des travaux dans les régions voisines de Cognac sur le wiki
(principalement les cantons/communes que j'ai mappé).


Bonne idée, je compléterai pour ma partie.


Tu peux y rajouter
bien volontiers tes contributions pour que l'on ait un tableau le  
plus à

jour possible


Bien sur.


(juste pour information je suis en train de fabriquer un
template pour faciliter l'enregistrement de ces informations mais cela
va prendre encore un peu de temps).



OK

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Le 6 juin 10 à 17:19, Pieren a écrit :

Par contre intellectuellement ça m'apparaît peu satisfaisant de voir  
des "rivernak" qui coupe le fleuve en deux, ça me fait penser "a  
tagger pour le rendu"



Heureusement que les fleuves sont découpés en morceaux (ainsi que  
les autoroutes ou les lignes de chemins de fers) sinon on se  
retrouverait avec d'énormes relations comme Sly les aime puisqu'il a  
fait la proposition de les supprimer pour les limites  
administratives de la France... ;-)



Je comprend et ça semble en effet la bonne manière de faire...  
Toutefois j'aimerai une solution plus "logique" que ce "charcutage",  
mais en attendant d'autres possibilités...


--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pieren]

2010/6/6 Pierre-Alain Dorange 

> Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des
> "rivernak" qui coupe le fleuve en deux, ça me fait penser "a tagger pour le
> rendu"
>
>
Heureusement que les fleuves sont découpés en morceaux (ainsi que les
autoroutes ou les lignes de chemins de fers) sinon on se retrouverait avec
d'énormes relations comme Sly les aime puisqu'il a fait la proposition de
les supprimer pour les limites administratives de la France... ;-)

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Clement Menier]

Salut Pierre-Alain,

Je me rends compte suite à ta remarque que j'ai pu faire du "sale" 
boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites 
pas à corriger ce que j'ai fait ou à me demander de corriger ces zones 
si il y a un souci (je ne travaille pas sur ces communes en ce moment).

Concernant le cours d'eau (waterway=river) qui devrait si j'ai bien 
compris correspondre au trajet "principal" de la Charente, j'ai repéré 
des trucs assez étranges au niveau de Bassac. N'ayant que le cadastre et 
des photos pour source d'information, je n'ai pas corrigé, mais si tu 
connais le trajet "principal" on pourrait corriger cela aussi par la 
même occasion.

Sur un sujet légèrement différent, j'ai commencé à répertorier les 
avancées des travaux dans les régions voisines de Cognac sur le wiki 
(principalement les cantons/communes que j'ai mappé). Tu peux y rajouter 
bien volontiers tes contributions pour que l'on ait un tableau le plus à 
jour possible (juste pour information je suis en train de fabriquer un 
template pour faciliter l'enregistrement de ces informations mais cela 
va prendre encore un peu de temps).

Bon courage,
Clément
   


Pierre-Alain Dorange wrote:
> Bonjour,
>
> Mappant autour de Cognac, je retravaille actuellement le fleuve 
> Charente dans ce coin.
> En effet le fleuve Charente est actuellement composé de petits 
> polygones issus d'un import 'PGS" (?) non contiguë (voir exemple (1))
>
> J'ai donc commencé a reconstruire "correctement" le fleuve à Cognac en 
> traçant le centre du fleuve avec un way (waterway=river) et en 
> transformant les petits polygones isolés en riverbank en traçant les 
> rives du fleuve avec un polygone fermé et en mettant les îles, le tout 
> dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça 
> commence a être lourd maintenant de j'étend ce schéma au delà de la 
> ville de Cognac (2)
>
> Donc :
> les rives en way (name=La Charente, waterway=water_bank et natural=water)
> les iles en way (place=island)
> le tout regroupé en relation type=multipolygon et les rives en outer, 
> les iles en inner.
>
> Mon soucis est donc que maintenant le multipolygon commence a devenir 
> grand et que si je continu ce schéma pour tout le fleuve je sais pas 
> trop comment ça va se passer avec JOSM...
>
> Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le 
> pourtour, c'est étrange et pas très lisible (2).
>
> (1) 
>   
> >
> (2) 
>   
> >
> -- 
> Pierre-Alain Dorange, 
> Blog Citoyen de Cognac : 
> Twitter :  - Facebook : 
> 
>
> 
>
> ___
> 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] géoréférencer un cadastre

[Vincent de Chateau-Thierry]

Bonjour,

maur...@mboucher.info a écrit :
> Bonjour,
>
> Je suis incapable de géoréférencé une commune voisine : Le Sap dans
> l'Orne (61). Il s'agit d'un plan image et la feuille AB contient les
> croisillons ad-hoc mais les cotes sont du genre 1xxx pour le nord et
> 45xx pour l'est.
>
> Dans la foulée j'ai tenté une autre commune avec des coordonnées à six
> chiffres, et j'ai réussi le géoréférencement en toute précision sans
> aucun problème.
>
> J'insiste sur les coordonnées parce que j'y vois la cause de mon échec ??
>
> Une idée ?
En effet, en supposant que la commune est en zone Lambert I, il manque 
quelques chiffres à ces coordonnées.
La récupération des coordonnées projetées du repère géodésique de la 
base du clocher (node_id : 670188590) te donnent une idée des 
coordonnées qu'il faudrait retrouver :
X : 453615
Y : 134625

L'église est sur la planche AB, approximativement en X:5000 et Y:1000 
dans le système de la planche AB. Tu peux donc essayer de géoréférencer 
la planche en ajoutant aux chiffres des croisillons autour de 448615 en 
X, et 133625 en Y, dans un premier temps. Ta planche sera orientée au 
Nord et à la bonne échelle. Ensuite, à l'aide de l'outil d'ajustement de 
la position du calque dans JOSM (3e outil sous la loupe, panneau de 
gauche), tu peux ajuster la position de la planche en fonction de tes 
tracés et des repères géodésiques.

Bon courage, et merci aux repères géodésiques :-)

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] géoréférencer un cadastre

[maurice]

Bonjour,

Je suis incapable de géoréférencé une commune voisine : Le Sap dans
l'Orne (61). Il s'agit d'un plan image et la feuille AB contient les
croisillons ad-hoc mais les cotes sont du genre 1xxx pour le nord et
45xx pour l'est.

Dans la foulée j'ai tenté une autre commune avec des coordonnées à six
chiffres, et j'ai réussi le géoréférencement en toute précision sans
aucun problème.

J'insiste sur les coordonnées parce que j'y vois la cause de mon échec ??

Une idée ?
 
Maurice Boucher

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[sylvain letuffe]

Un autre avis ;-)

Le dimanche 06 juin 2010 12:27:12, Pierre-Alain Dorange a écrit :
> Par contre intellectuellement ça m'apparaît peu satisfaisant de voir
> des "rivernak" qui coupe le fleuve en deux, ça me fait penser "a
> tagger pour le rendu"

C'est un bon résumé, c'est (était?) une solution pour contourner le problème 
des rendus classiques qui ne géraient pas bien les relations multipolygone.

Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est 
l'habitude.

Lobying contre :

* Les zones d'interconnexion entre plusieurs multipolygone sont tout à fait 
arbitraire et ne correspondent à rien de réél

* S'il me prend de vouloir représenter les bords du fleuve en bleu foncé, c'est 
très galère car je vais introduire des coupures le long du lit de la rivière 
aux endroits "qui font le collage"

* Le nom de la rivière doit être indiqué sur chaqu'un des morceaux qui la 
compose

* Si je veux obtenir dans un format vectoriel la forme complète de la rivière, 
je suis obligé de récupérer à la main, tous les morceaux, faire des découpes 
et re-collage

je ne suis pas seul à penser ça :
http://lists.openstreetmap.org/pipermail/talk/2008-February/023009.html

Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout 
cas) des multipolygones :
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers

 
> > Ensuite tu peux rassembler les différents éléments du fleuve dans un
> > autre
> > relation de type=waterway

Le problème, c'est que le tout ne forme pas un multipolygon valide au sens OSM 
du terme (ni au sens GIS du terme d'ailleurs) 

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Le 6 juin 10 à 11:30, Frédéric Rodrigo a écrit :

J'ai donc commencé a reconstruire "correctement" le fleuve à Cognac  
en

traçant le centre du fleuve avec un way (waterway=river) et en
transformant les petits polygones isolés en riverbank en traçant les
rives du fleuve avec un polygone fermé et en mettant les îles, le  
tout

dans une relation multipolygone.

Il y a de quoi s'amuser ! ;)


En effet.


Ca fonctionne plutôt bien, mais ça
commence a être lourd maintenant de j'étend ce schéma au delà de la
ville de Cognac (2)
Les multipolygons sont là pour faire du multipolygon... et pas le  
fleuve lui
même. Donc il faut l'utiliser pour les îles. Mais tu peux faire  
plusieurs

multipolygon pour le même fleuve.


En effet, je comprend. Je viens de regarder comment était fait la  
Gironde (autour de Bordeaux) et je m'aperçois qu'il y a en effet  
plusieurs way fermés pour constituer les rives du fleuve. Ca resoud  
mon soucis de voir le way grandir-grandir...
Par contre intellectuellement ça m'apparaît peu satisfaisant de voir  
des "rivernak" qui coupe le fleuve en deux, ça me fait penser "a  
tagger pour le rendu"


Ensuite tu peux rassembler les différents éléments du fleuve dans un  
autre

relation de type=waterway

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau


OK, j'avais pas vu (le wiki est riche mais l'organisation est assez  
anarchique, on trouve pas toujours facilement les choses).

Merci.


Donc :
les rives en way (name=La Charente, waterway=water_bank et
natural=water)

Non, il ne faut pas de natural=water, pour un fleuve c'est du
waterway=riverbank


OK

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Christophe Merlet]

Le dimanche 06 juin 2010 à 11:02 +0200, Pierre-Alain Dorange a écrit :
> Bonjour,
> 
> 
> Mappant autour de Cognac, je retravaille actuellement le fleuve
> Charente dans ce coin.
> En effet le fleuve Charente est actuellement composé de petits
> polygones issus d'un import 'PGS" (?) non contiguë (voir exemple (1))
> 
> 
> J'ai donc commencé a reconstruire "correctement" le fleuve à Cognac en
> traçant le centre du fleuve avec un way (waterway=river) et en
> transformant les petits polygones isolés en riverbank en traçant les
> rives du fleuve avec un polygone fermé et en mettant les îles, le tout
> dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça
> commence a être lourd maintenant de j'étend ce schéma au delà de la
> ville de Cognac (2)
> 
> 
> Donc :
> les rives en way (name=La Charente, waterway=water_bank et
> natural=water)
> les iles en way (place=island)
> le tout regroupé en relation type=multipolygon et les rives en outer,
> les iles en inner.
> 
> 
> Mon soucis est donc que maintenant le multipolygon commence a devenir
> grand et que si je continu ce schéma pour tout le fleuve je sais pas
> trop comment ça va se passer avec JOSM...
> 
> 
> Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le
> pourtour, c'est étrange et pas très lisible (2).


Le lit des fleuves et rivières en waterway=river + name
Les rives en *plusieurs* polygones waterway=riverbank (sans nom) de
taille raisonnable.
Les "îles" en multipolygone inner associé au riverbank en rôle outer

Le nom de l'île qui s'affiche sur le contour est peut-être un bug de
rendu lié a l'absence de balise natural ou landuse.
Peut-être vaut il mieux mettre le nom sur un *nœud* place...

Par ailleurs, je n'aime pas voir les rivières en layer=-1, ça ne me
parait pas correspondre à la réalité.


Librement,


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Frédéric Rodrigo]

Le dimanche 06 juin 2010 11:02:49, Pierre-Alain Dorange a écrit :
> Bonjour,
> 
> Mappant autour de Cognac, je retravaille actuellement le fleuve
> Charente dans ce coin.
> En effet le fleuve Charente est actuellement composé de petits
> polygones issus d'un import 'PGS" (?) non contiguë (voir exemple (1))
> 
> J'ai donc commencé a reconstruire "correctement" le fleuve à Cognac en
> traçant le centre du fleuve avec un way (waterway=river) et en
> transformant les petits polygones isolés en riverbank en traçant les
> rives du fleuve avec un polygone fermé et en mettant les îles, le tout
> dans une relation multipolygone. 
Il y a de quoi s'amuser ! ;)
> Ca fonctionne plutôt bien, mais ça
> commence a être lourd maintenant de j'étend ce schéma au delà de la
> ville de Cognac (2)
Les multipolygons sont là pour faire du multipolygon... et pas le fleuve lui 
même. Donc il faut l'utiliser pour les îles. Mais tu peux faire plusieurs 
multipolygon pour le même fleuve.
Ensuite tu peux rassembler les différents éléments du fleuve dans un autre 
relation de type=waterway

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau

> Donc :
> les rives en way (name=La Charente, waterway=water_bank et
> natural=water)
Non, il ne faut pas de natural=water, pour un fleuve c'est du 
waterway=riverbank
> les iles en way (place=island)
Tu peux  aussi rajouter des natural= ou des landuse= et tout ce qui peut être 
intéressant.
> le tout regroupé en relation type=multipolygon et les rives en outer,
> les iles en inner.
Ok

> Mon soucis est donc que maintenant le multipolygon commence a devenir
> grand et que si je continu ce schéma pour tout le fleuve je sais pas
> trop comment ça va se passer avec JOSM...
Diviser pour régner

> Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le
> pourtour, c'est étrange et pas très lisible (2).

Regardes ta relation là, il te manques des îles :
http://www.openstreetmap.org/browse/relation/398715

Fred

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

[Pierre-Alain Dorange]

Bonjour,

Mappant autour de Cognac, je retravaille actuellement le fleuve  
Charente dans ce coin.
En effet le fleuve Charente est actuellement composé de petits  
polygones issus d'un import 'PGS" (?) non contiguë (voir exemple (1))


J'ai donc commencé a reconstruire "correctement" le fleuve à Cognac en  
traçant le centre du fleuve avec un way (waterway=river) et en  
transformant les petits polygones isolés en riverbank en traçant les  
rives du fleuve avec un polygone fermé et en mettant les îles, le tout  
dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça  
commence a être lourd maintenant de j'étend ce schéma au delà de la  
ville de Cognac (2)


Donc :
les rives en way (name=La Charente, waterway=water_bank et  
natural=water)

les iles en way (place=island)
le tout regroupé en relation type=multipolygon et les rives en outer,  
les iles en inner.


Mon soucis est donc que maintenant le multipolygon commence a devenir  
grand et que si je continu ce schéma pour tout le fleuve je sais pas  
trop comment ça va se passer avec JOSM...


Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le  
pourtour, c'est étrange et pas très lisible (2).


(1) 
(2) 

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr