Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-07 Par sujet Ch. Rogel 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-07 Par sujet Christian Quest 

Le 07/12/2016 à 10:06, Topographe Fou a écrit :

Probablement parce que comme l'explique le Wiki un multipolygon est 
par défaut une aire (contrairement à boundary qui est une frontière, 
quelque chose de linéaire) et que si un tag manque au niveau de la 
relation il va le chercher au niveau des membres (là je suis d'accord 
avec toi : ce n'est pas normal et pousse à la surinterpretation). Il 
donne même un exemple en Allemagne ou des mp ont été massivement 
utilisés au lieu de boundary. Un multipolygon est conçu comme une 
manière de définir une aire mais en utilisant plusieurs ways au lieu 
de une.


Donc comme le rendu ne reconnaît pas cette manière de tagger un 
parcelle, il adopte son comportement par défaut qui est "c'est une 
aire" et "je cherche les tags d'abord dans la relation,  sinon dans 
les membres". Avec une boundary il ne dessine pas d'aire donc le 
glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le 
rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag 
landuse=forest à un mp de type parcel, on devrait logiquement arriver 
au même résultat et cela ne me paraît pas sémantiquement faux aussi.


Résultat un multipolygon avec que des membres highway est donc vu 
comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus 
qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception 
(à savoir la remontée de tags qui pousse à une mauvaise pratique).


Cordialement

LeTopographeFou


frontière ou surface, ça arrive dans la même table postgres via osm2pgsql...

Ensuite, le rendu se mélange forcément les pinceaux car les données dans 
la base osm2pgsql sont incohérentes mais le rendu peut soit remplir les 
surfaces des (multi)polygones soit ne tracer que leurs frontières... ce 
n'est qu'une question de feuille de style.


Le souci provient à l'origine de l'euristique d'osm2pgsql qui lorsqu'on 
utilise un type=multipolygon qui ne fait que décrire le type de 
géométrie sans décrire à quoi elle correspond va chercher à la compléter 
par l'information sémantique.


Cette euristique n'est pas parfaite... et donc il vaut mieux indiquer 
qu'on décrit bien la frontière d'une section (comme on décrit la 
frontière d'une commune) avec un type=boundary et du coup osm2pgsql ne 
cherche par à découvrir par lui même la sémantique estimant qu'elle est 
déjà décrite dans la relation.


On peut voir ça comme un bug d'osm2pgsql, mais le code ne peut pas 
toujours deviner l'intention du contributeur... il est préférable 
d'expliciter le type et en plus ça me parait cohérent en terme de tags.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-07 Par sujet david . crochet 
Bonjour

- Mail original -
De: "Topographe Fou" 

Résultat un multipolygon avec que des membres highway est donc vu comme un 
highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug 
mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de 
tags qui pousse à une mauvaise pratique). 

- Mail original -

L'une des erreurs qui sera résolu par la suite (dans 1, 10 ou 100 ans) sera de 
séparer la surface "aire boisé" du chemin puisqu'entre les deux il y a de forte 
chance d'avoir autre choses (bande herbacé, rigole d'évacuation d'eau, etc). Et 
là la relation sera inutile puisque on aura dessiné l'emprise boisée 
distinctement du/des chemins l'entourant.

Cordialement

-- 
David Crochet



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

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-07 Par sujet Topographe Fou 
  Probablement parce que comme l'explique le Wiki un multipolygon est par défaut une aire (contrairement à boundary qui est une frontière, quelque chose de linéaire) et que si un tag manque au niveau de la relation il va le chercher au niveau des membres (là je suis d'accord avec toi : ce n'est pas normal et pousse à la surinterpretation). Il donne même un exemple en Allemagne ou des mp ont été massivement utilisés au lieu de boundary. Un multipolygon est conçu comme une manière de définir une aire mais en utilisant plusieurs ways au lieu de une.Donc comme le rendu ne reconnaît pas cette manière de tagger un parcelle, il adopte son comportement par défaut qui est "c'est une aire" et "je cherche les tags d'abord dans la relation,  sinon dans les membres". Avec une boundary il ne dessine pas d'aire donc le glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag landuse=forest à un mp de type parcel, on devrait logiquement arriver au même résultat et cela ne me paraît pas sémantiquement faux aussi.Résultat un multipolygon avec que des membres highway est donc vu comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de tags qui pousse à une mauvaise pratique).Cordialement LeTopographeFouDe: verd...@wanadoo.frEnvoyé: 7 décembre 2016 1:30 AMÀ: talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières  Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l'interprétation et la "remontée" des tags des ways membres vers les relations qui les référence.Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte des critères nécessaires (tags identiques dans tous les ways membres ayant un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").En revanche remonter les "highway=*" vers la relation (peu importe que ce soit une "boundary" ou un "multipolygon") est problématique, dans les faits tous les "highway=*" sont linéaires (exceptions faite des "highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes", ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont soit linéaires, soit des noeuds isolés pour des passages piétons, priorités, stops...).Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon", d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui n'ont eux rien non plus à voir avec les "highway=*")Le 6 décembre 2016 à 23:38, LeTopographeFou <letopographe...@gmail.com> a écrit :
  

  
  

  J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme je l'avais
imaginé dans mon précédent message qui n'a visiblement pas été
lu ;)
  Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu.
  Merci.


  En terme de logique de tagging je verrai
plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble
plus grand)
boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à
l'arrache... [...]
  
  Tout là fait d'accord (sans rentrer dans la discussion ici :
  j'aime bien ta proposition, elle est plus proche de l'existant et
  donc plus naturelle que la proposition Section).
Pour info il se trouve que j'ai eu un échange de mail avec
  l'auteur de la proposition Section cet été (à propos d'un
  cimetière que je visitais/cartographiais à l'époque) et il m'a dit
  qu'il n'avait pas eu le courage pour animer sa proposition
  jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une
  contre-proposition, car il reste persuadé du besoin initial
  (parcelles forestières, sections dans un cimetière...).


  
Mais ça mérite discussion sur le wiki plutôt que d'y aller
  à l'arrache... surtout que l'import des données est pas génial
  non plus car

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-06 Par sujet Philippe Verdy 
Je ne vois pas en quoi ce changement de "multipolygon" en "boundary"
devrait avoir un impact sur l'interprétation et la "remontée" des tags des
ways membres vers les relations qui les référence.

Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte
des critères nécessaires (tags identiques dans tous les ways membres ayant
un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").

En revanche remonter les "highway=*" vers la relation (peu importe que ce
soit une "boundary" ou un "multipolygon") est problématique, dans les faits
tous les "highway=*" sont linéaires (exceptions faite des
"highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes",
ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont
soit linéaires, soit des noeuds isolés pour des passages piétons,
priorités, stops...).

Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas
pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon",
d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués
comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui
n'ont eux rien non plus à voir avec les "highway=*")



Le 6 décembre 2016 à 23:38, LeTopographeFou  a
écrit :

> J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
> dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
> visiblement pas été lu ;)
>
> Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci.
>
> En terme de logique de tagging je verrai plutôt quelque chose comme:
> type=boundary (il s'agit d'une frontière qui découpe un ensemble plus
> grand)
> boundary=forest (frontière forestière)
> forest=section (il s'agit d'une section)
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> [...]
>
> Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien
> ta proposition, elle est plus proche de l'existant et donc plus naturelle
> que la proposition Section).
>
> Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de la
> proposition Section cet été (à propos d'un cimetière que je
> visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu le
> courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à la
> retravailler voir à faire une contre-proposition, car il reste persuadé du
> besoin initial (parcelles forestières, sections dans un cimetière...).
>
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> surtout que l'import des données est pas génial non plus car les données
> d'origine ne sont pas forcément bien calées...
>
> Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#
> 18/48.53494/1.97682
>
> Alors là c'est drôle car pendant que tu changeais le type de relation je
> recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre
> quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). Donc
> en me basant sur le cadastre j'ai regroupé hier ce qui devait l'être dans
> la zone (je n'ai pas déplacé les frontières administratives mais les
> layons, chemins et bordures de forêt. Il reste encore une bonne partie du
> périmètre à recaler) et j'en avais profité pour ajouter un gros morceau de
> forêt manquant côté Yvelines (http://www.openstreetmap.org/
> relation/6770020).
>
> Bref il reste du boulot mais problème de rendu de parcelle réglé, je
> déploierai la solution sur les forêts alentours qui ont le même soucis,
> merci !
>
> Cordialement
>
> LeTopographeFou
>
> Le 05/12/2016 à 23:18, Christian Quest a écrit :
>
> J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
> dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
> visiblement pas été lu ;)
>
> Ces sections forestières sont bien des frontières et ça évite à osm2pgsql
> de chercher à savoir par une euristique imparfaite ce que sont ces
> multipolygones mystérieux...
>
> En terme de logique de tagging je verrai plutôt quelque chose comme:
> type=boundary (il s'agit d'une frontière qui découpe un ensemble plus
> grand)
> boundary=forest (frontière forestière)
> forest=section (il s'agit d'une section)
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> surtout que l'import des données est pas génial non plus car les données
> d'origine ne sont pas forcément bien calées...
>
> Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#
> 18/48.53494/1.97682
>
> Les tuiles sont en train de se remettre à jour... un peu de patience.
>
>
> Le 5 décembre 2016 à 22:17,  a écrit :
>
>> Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a
>> écrit :
>>
>> Bonsoir à tous,
>>
>> A vrai dire je croyais que le moteur ne dessinait que les objets issus
>> d'une requête (donc les objets connus) et pas tous les objets. Visiblement
>> ce n'est pas le cas.
>>
>> Jusqu'à peu

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-06 Par sujet LeTopographeFou 
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout 
rentre dans l'ordre comme je l'avais imaginé dans mon précédent 
message qui n'a visiblement pas été lu ;)

Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci.


En terme de logique de tagging je verrai plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble plus 
grand)

boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... [...]
Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien 
ta proposition, elle est plus proche de l'existant et donc plus 
naturelle que la proposition Section).


Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de 
la proposition Section cet été (à propos d'un cimetière que je 
visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu 
le courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à 
la retravailler voir à faire une contre-proposition, car il reste 
persuadé du besoin initial (parcelles forestières, sections dans un 
cimetière...).




Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... surtout que l'import des données est pas génial non plus 
car les données d'origine ne sont pas forcément bien calées...


Exemple: 
http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682
Alors là c'est drôle car pendant que tu changeais le type de relation je 
recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre 
quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). 
Donc en me basant sur le cadastre j'ai regroupé hier ce qui devait 
l'être dans la zone (je n'ai pas déplacé les frontières administratives 
mais les layons, chemins et bordures de forêt. Il reste encore une bonne 
partie du périmètre à recaler) et j'en avais profité pour ajouter un 
gros morceau de forêt manquant côté Yvelines 
(http://www.openstreetmap.org/relation/6770020).


Bref il reste du boulot mais problème de rendu de parcelle réglé, je 
déploierai la solution sur les forêts alentours qui ont le même soucis, 
merci !


Cordialement

LeTopographeFou

Le 05/12/2016 à 23:18, Christian Quest a écrit :
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout 
rentre dans l'ordre comme je l'avais imaginé dans mon précédent 
message qui n'a visiblement pas été lu ;)


Ces sections forestières sont bien des frontières et ça évite à 
osm2pgsql de chercher à savoir par une euristique imparfaite ce que 
sont ces multipolygones mystérieux...


En terme de logique de tagging je verrai plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble plus 
grand)

boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... surtout que l'import des données est pas génial non plus 
car les données d'origine ne sont pas forcément bien calées...


Exemple: 
http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682


Les tuiles sont en train de se remettre à jour... un peu de patience.


Le 5 décembre 2016 à 22:17, > a écrit :


Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com
 a écrit :


Bonsoir à tous,

A vrai dire je croyais que le moteur ne dessinait que les objets
issus d'une requête (donc les objets connus) et pas tous les
objets. Visiblement ce n'est pas le cas.


Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des
transformateurs apparaissent sur la carte.
Assez absurde pour une carte générique.


Entre nous, ce système de "je fais remonter les valeurs communes"
me parait biaisé et n'incite pas à correctement tagger. Je
préfère 100x plus un moteur de rendu stricte et exigent qui
pousse à bien faire mais dessine avec ce qu'on lui donne plutôt
qu'un qui interprète les données avec des attributs qui
n'existent pas et dessine des relations qu'il ne connait pas
(avec 50% de risque de se planter). Si le moteur ne connait pas
une relation, il devrait l'ignorer. Si il lui manque une
propriété, il devrait pouvoir faire sans. Dixit un gars qui n'a
pas sué dans le développement de ces beaux outils :-) .


Si c'est une info commune, pourquoi pas ? Je dis bien commune
c'est à dire identique dans tous les membres.
Sinon c'est éventuellement un candidat pour un outil d'assurance
qualité (que des noms identiques ou pas de noms : peut-être que
les sans noms devraient avoir le même nom, ça peut avoir du sens
pour des réseaux, des trajets tels que des pistes cyclables sans
nom connectés à d'autres pistes cyclables ayant un nom... ou une
référence).

Jean-Yvon

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-05 Par sujet Christian Quest 
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
visiblement pas été lu ;)

Ces sections forestières sont bien des frontières et ça évite à osm2pgsql
de chercher à savoir par une euristique imparfaite ce que sont ces
multipolygones mystérieux...

En terme de logique de tagging je verrai plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble plus grand)
boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
surtout que l'import des données est pas génial non plus car les données
d'origine ne sont pas forcément bien calées...

Exemple:
http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682

Les tuiles sont en train de se remettre à jour... un peu de patience.


Le 5 décembre 2016 à 22:17,  a écrit :

> Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a
> écrit :
>
> Bonsoir à tous,
>
> A vrai dire je croyais que le moteur ne dessinait que les objets issus
> d'une requête (donc les objets connus) et pas tous les objets. Visiblement
> ce n'est pas le cas.
>
> Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des
> transformateurs apparaissent sur la carte.
> Assez absurde pour une carte générique.
>
> Entre nous, ce système de "je fais remonter les valeurs communes" me
> parait biaisé et n'incite pas à correctement tagger. Je préfère 100x plus
> un moteur de rendu stricte et exigent qui pousse à bien faire mais dessine
> avec ce qu'on lui donne plutôt qu'un qui interprète les données avec des
> attributs qui n'existent pas et dessine des relations qu'il ne connait pas
> (avec 50% de risque de se planter). Si le moteur ne connait pas une
> relation, il devrait l'ignorer. Si il lui manque une propriété, il devrait
> pouvoir faire sans. Dixit un gars qui n'a pas sué dans le développement de
> ces beaux outils :-) .
>
> Si c'est une info commune, pourquoi pas ? Je dis bien commune c'est à dire
> identique dans tous les membres.
> Sinon c'est éventuellement un candidat pour un outil d'assurance qualité
> (que des noms identiques ou pas de noms : peut-être que les sans noms
> devraient avoir le même nom, ça peut avoir du sens pour des réseaux, des
> trajets tels que des pistes cyclables sans nom connectés à d'autres pistes
> cyclables ayant un nom... ou une référence).
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-05 Par sujet osm . sanspourriel 

Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a écrit :


Bonsoir à tous,

A vrai dire je croyais que le moteur ne dessinait que les objets issus 
d'une requête (donc les objets connus) et pas tous les objets. 
Visiblement ce n'est pas le cas.


Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des 
transformateurs apparaissent sur la carte.

Assez absurde pour une carte générique.

Entre nous, ce système de "je fais remonter les valeurs communes" me 
parait biaisé et n'incite pas à correctement tagger. Je préfère 100x 
plus un moteur de rendu stricte et exigent qui pousse à bien faire 
mais dessine avec ce qu'on lui donne plutôt qu'un qui interprète les 
données avec des attributs qui n'existent pas et dessine des relations 
qu'il ne connait pas (avec 50% de risque de se planter). Si le moteur 
ne connait pas une relation, il devrait l'ignorer. Si il lui manque 
une propriété, il devrait pouvoir faire sans. Dixit un gars qui n'a 
pas sué dans le développement de ces beaux outils :-) .


Si c'est une info commune, pourquoi pas ? Je dis bien commune c'est à 
dire identique dans tous les membres.
Sinon c'est éventuellement un candidat pour un outil d'assurance qualité 
(que des noms identiques ou pas de noms : peut-être que les sans noms 
devraient avoir le même nom, ça peut avoir du sens pour des réseaux, des 
trajets tels que des pistes cyclables sans nom connectés à d'autres 
pistes cyclables ayant un nom... ou une référence).


Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-05 Par sujet LeTopographeFou 

Bonsoir à tous,

Merci pour vos réponses. A l'heure actuelle le rendu est pire encore car 
j'ai (à priori) terminé de réparer les mp mal taggés. Et il apparait que 
si la précédente carte était plutôt bien dessinée, c'est plus par 
"chance" que par la qualité des mp qui existaient. Maintenant avec des 
parcelles "propres" (fermées, etc.) les bugs ressortent et... c'est 
catastrophique.


Je partage globalement ton analyse Philippe (nom sélectionné arbitraire 
et valeur par défaut supposément erronées de area). Au delà du fait que 
se soient des relations non reconnues, je pense qu'il y a un 
comportement par défaut bizarre du rendu (ou de la moulinette qui le 
nourrit). Je ferai remonter les bugs à Mapnik à l'occasion (que mes 
dernières modifs se stabilisent).


A vrai dire je croyais que le moteur ne dessinait que les objets issus 
d'une requête (donc les objets connus) et pas tous les objets. 
Visiblement ce n'est pas le cas.


Entre nous, ce système de "je fais remonter les valeurs communes" me 
parait biaisé et n'incite pas à correctement tagger. Je préfère 100x 
plus un moteur de rendu stricte et exigent qui pousse à bien faire mais 
dessine avec ce qu'on lui donne plutôt qu'un qui interprète les données 
avec des attributs qui n'existent pas et dessine des relations qu'il ne 
connait pas (avec 50% de risque de se planter). Si le moteur ne connait 
pas une relation, il devrait l'ignorer. Si il lui manque une propriété, 
il devrait pouvoir faire sans. Dixit un gars qui n'a pas sué dans le 
développement de ces beaux outils :-) .


Cordialement,

LeTopographeFou

Le 03/12/2016 à 22:17, Philippe Verdy a écrit :
Ceci dit si je prend l'exemple du triangle formé entre les carrefours 
de la Réserve, des Grès et de Madame par les trois routes forestières 
de la Fresnaye, des Grès et de Madame, il y a bien un attribut highway 
commun, mais aucun nom commun.


L'attribut highway est "remonté" au niveau de la relation mais le nom 
"Route Madame" (pioché au hasard entre les 3 possibles) n'a pas à 
l'être car il n'est pas commun: c'est bien un bogue de la conversion 
OSM-GIS.


D'autre part, remonter l'attribut highway **linéaire** (par défaut) à 
la relation ne devrait pas avoir lieu non plus (les 3 chemins sont des 
"highway=*" qui ne sont pas tagués avec "area=yes" donc à interpréter 
comme "area=no" par défaut, conformément à la documentation de 
"highway=*"). Donc là encore un bogue de la conversion OSM-GIS.



Le 3 décembre 2016 à 22:05, Philippe Verdy > a écrit :


Le rendu ne fait pas cette interprétation tout seul: il ne le fait
que si tous les chemins membres d'une même relation partagent
exactement le même attribut, et dans ce cas il rapporte cet
attribut à la relation, et seulement si cette relation décrit une
surface fermée (en un ou plusieurs anneaux s'il y a des enclaves).
Certains attributs sont exclus de ce traitement (dont highway qui
est la plupart du temps uniquement linéaire, à moins qu'il y ait
aussi sur les chemins un area=yes).

Ces cas de transformation sont détectés dans la validation de JOSM
qui indique de taguer la relation et non les chemins membres.

Ensuite si la relation n'est pas exclue comme surface par ses
attributs (dont area=no), elle peut être rendue comme une surface

Le 3 décembre 2016 à 18:52, JB > a écrit :

Oui, les multipolygones, c'est élégant d'un point de vue
intellectuel et parfois, c'est absolument impraticable dans la
réalité. Et impossible à maintenir. Pour 3 nœuds et trois
ways, pourquoi inventer un MP plutôt qu'utiliser un chemin
fermé simple ?
Sinon, je pense (à confirmer) que le rendu brun avec le nom de
rue au milieu, c'est Mapnik qui considère que le MP représente
un chemin (highway=*) : comme il ne reconnait pas le type de
multipolygone utilisé (forest=section + ref), il prend le
premier way, voit un highway=*, et considère que la surface
est un highway avec un multipolygone mal conditionné. Et hop.
Foireux pour foireux, tant qu'à faire…
JB.


Le 03/12/2016 à 18:29, LeTopographeFou a écrit :


Bonjour,

Suite à mon sujet sur les intersections en forêt j'ai essayé
de savoir pourquoi certaines parcelles et chemins en forêt de
Saint-Arnoult (mais pas que...) génèrent des soucis de dessin
alors qu'elles paraissent toutes homogènes en terme de tags
et qu'elles sont toutes fermées. Marron, gris, blanc,
transparent... ce n'est pas homogène !

A noter que je suppose que les parcelles ne sont à priori pas
dessinées (sinon on verrait son numéro, il n'y aurait pas de
statut "proposition", et le rendu serait plus homogène que cela).

Voici mes constatations :

  * Rendu

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-03 Par sujet Philippe Verdy 
Ceci dit si je prend l'exemple du triangle formé entre les carrefours de la
Réserve, des Grès et de Madame par les trois routes forestières de la
Fresnaye, des Grès et de Madame, il y a bien un attribut highway commun,
mais aucun nom commun.

L'attribut highway est "remonté" au niveau de la relation mais le nom
"Route Madame" (pioché au hasard entre les 3 possibles) n'a pas à l'être
car il n'est pas commun: c'est bien un bogue de la conversion OSM-GIS.

D'autre part, remonter l'attribut highway **linéaire** (par défaut) à la
relation ne devrait pas avoir lieu non plus (les 3 chemins sont des
"highway=*" qui ne sont pas tagués avec "area=yes" donc à interpréter comme
"area=no" par défaut, conformément à la documentation de "highway=*"). Donc
là encore un bogue de la conversion OSM-GIS.


Le 3 décembre 2016 à 22:05, Philippe Verdy  a écrit :

> Le rendu ne fait pas cette interprétation tout seul: il ne le fait que si
> tous les chemins membres d'une même relation partagent exactement le même
> attribut, et dans ce cas il rapporte cet attribut à la relation, et
> seulement si cette relation décrit une surface fermée (en un ou plusieurs
> anneaux s'il y a des enclaves). Certains attributs sont exclus de ce
> traitement (dont highway qui est la plupart du temps uniquement linéaire, à
> moins qu'il y ait aussi sur les chemins un area=yes).
>
> Ces cas de transformation sont détectés dans la validation de JOSM qui
> indique de taguer la relation et non les chemins membres.
>
> Ensuite si la relation n'est pas exclue comme surface par ses attributs
> (dont area=no), elle peut être rendue comme une surface
>
> Le 3 décembre 2016 à 18:52, JB  a écrit :
>
>> Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et
>> parfois, c'est absolument impraticable dans la réalité. Et impossible à
>> maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt
>> qu'utiliser un chemin fermé simple ?
>> Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au
>> milieu, c'est Mapnik qui considère que le MP représente un chemin
>> (highway=*) : comme il ne reconnait pas le type de multipolygone utilisé
>> (forest=section + ref), il prend le premier way, voit un highway=*, et
>> considère que la surface est un highway avec un multipolygone mal
>> conditionné. Et hop. Foireux pour foireux, tant qu'à faire…
>> JB.
>>
>>
>> Le 03/12/2016 à 18:29, LeTopographeFou a écrit :
>>
>> Bonjour,
>>
>> Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir
>> pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais pas
>> que...) génèrent des soucis de dessin alors qu'elles paraissent toutes
>> homogènes en terme de tags et qu'elles sont toutes fermées. Marron, gris,
>> blanc, transparent... ce n'est pas homogène !
>>
>> A noter que je suppose que les parcelles ne sont à priori pas dessinées
>> (sinon on verrait son numéro, il n'y aurait pas de statut "proposition", et
>> le rendu serait plus homogène que cela).
>>
>> Voici mes constatations :
>>
>>- Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
>>   - *Route de Madame* et *Route de la Lieue* ne sont pas écrits le
>>   long du chemin mais au milieu de parcelles à l'horizontal (à partir du
>>   niveau de zoom 15). En consultant les ways en question, rien à 
>> signaler.
>>   Une idée ?
>>   - Il y a des zones marrons qui correspondent bizarrement aux
>>   délimitations de certaines parcelles. Sauf que ces parcelles n'ont 
>> rien de
>>   bizarre quand on regarde les tags (elles sont bien fermées et toutes ne
>>   sont pas rendues de la même manière alors qu'elles ont des tags
>>   identiques). Exemple : http://www.openstreetmap.org/r
>>   elation/1866710 Une idée ?
>>   - Là on a carrément une parcelle grise :
>>   http://www.openstreetmap.org/relation/1853819
>>   
>>   - Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
>>récupérer un lien vers la zone consultée...)
>>   - Beaucoup plus de chemins sont tracés avec les noms au milieu des
>>   parcelles et non le long du chemin. En fait c'est comme ci le rendu
>>   dessinait les parcelles et prenait le nom du dernier élément de la 
>> relation
>>   pour lui donner un nom de relation. Une idée ?
>>   - Il y a moins de parcelles bizarrement dessinées mais il y en a
>>   qu'en même (et on notera que ce ne sont pas les mêmes que sur OSM.org).
>>   Exemple avec celle sous "Route de la jumelle" qui apparait plus claire
>>
>> Résultat : c'est moche et ca fait penser zone en construction... Je me
>> demande si la manière avec laquelle les parcelles ont été cartographiées ne
>> perturbe pas le moteur de rendu. Ou alors c'est un bug dans le moteur de
>> rendu ?
>>
>> A vous lire,
>>
>> Cordialement,
>>
>> --
>> LeTopographeFou
>>
>>
>>
>> ___

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-03 Par sujet Philippe Verdy 
Le rendu ne fait pas cette interprétation tout seul: il ne le fait que si
tous les chemins membres d'une même relation partagent exactement le même
attribut, et dans ce cas il rapporte cet attribut à la relation, et
seulement si cette relation décrit une surface fermée (en un ou plusieurs
anneaux s'il y a des enclaves). Certains attributs sont exclus de ce
traitement (dont highway qui est la plupart du temps uniquement linéaire, à
moins qu'il y ait aussi sur les chemins un area=yes).

Ces cas de transformation sont détectés dans la validation de JOSM qui
indique de taguer la relation et non les chemins membres.

Ensuite si la relation n'est pas exclue comme surface par ses attributs
(dont area=no), elle peut être rendue comme une surface

Le 3 décembre 2016 à 18:52, JB  a écrit :

> Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et
> parfois, c'est absolument impraticable dans la réalité. Et impossible à
> maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt
> qu'utiliser un chemin fermé simple ?
> Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au
> milieu, c'est Mapnik qui considère que le MP représente un chemin
> (highway=*) : comme il ne reconnait pas le type de multipolygone utilisé
> (forest=section + ref), il prend le premier way, voit un highway=*, et
> considère que la surface est un highway avec un multipolygone mal
> conditionné. Et hop. Foireux pour foireux, tant qu'à faire…
> JB.
>
>
> Le 03/12/2016 à 18:29, LeTopographeFou a écrit :
>
> Bonjour,
>
> Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir
> pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais pas
> que...) génèrent des soucis de dessin alors qu'elles paraissent toutes
> homogènes en terme de tags et qu'elles sont toutes fermées. Marron, gris,
> blanc, transparent... ce n'est pas homogène !
>
> A noter que je suppose que les parcelles ne sont à priori pas dessinées
> (sinon on verrait son numéro, il n'y aurait pas de statut "proposition", et
> le rendu serait plus homogène que cela).
>
> Voici mes constatations :
>
>- Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
>   - *Route de Madame* et *Route de la Lieue* ne sont pas écrits le
>   long du chemin mais au milieu de parcelles à l'horizontal (à partir du
>   niveau de zoom 15). En consultant les ways en question, rien à signaler.
>   Une idée ?
>   - Il y a des zones marrons qui correspondent bizarrement aux
>   délimitations de certaines parcelles. Sauf que ces parcelles n'ont rien 
> de
>   bizarre quand on regarde les tags (elles sont bien fermées et toutes ne
>   sont pas rendues de la même manière alors qu'elles ont des tags
>   identiques). Exemple : http://www.openstreetmap.org/relation/1866710
>   Une idée ?
>   - Là on a carrément une parcelle grise :
>   http://www.openstreetmap.org/relation/1853819
>   
>   - Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
>récupérer un lien vers la zone consultée...)
>   - Beaucoup plus de chemins sont tracés avec les noms au milieu des
>   parcelles et non le long du chemin. En fait c'est comme ci le rendu
>   dessinait les parcelles et prenait le nom du dernier élément de la 
> relation
>   pour lui donner un nom de relation. Une idée ?
>   - Il y a moins de parcelles bizarrement dessinées mais il y en a
>   qu'en même (et on notera que ce ne sont pas les mêmes que sur OSM.org).
>   Exemple avec celle sous "Route de la jumelle" qui apparait plus claire
>
> Résultat : c'est moche et ca fait penser zone en construction... Je me
> demande si la manière avec laquelle les parcelles ont été cartographiées ne
> perturbe pas le moteur de rendu. Ou alors c'est un bug dans le moteur de
> rendu ?
>
> A vous lire,
>
> Cordialement,
>
> --
> LeTopographeFou
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-03 Par sujet Christian Quest 
J'ai regardé dans la base postgres qui sert au rendu FR.

Ce "multipolygone" n'ayant aucun tag connu d'osm2pgsql qui corresponde à
une surface (boundary serait un bon candidat) il s'est vu récupérer le
highway=track avec le nom correspondant.

Ces multipolygones sont un peu anacrhoniques et il y a fort à parier que
mal mal d'outil réutilisant les données OSM ne savent pas quoi en faire et
ça peut donner ce genre d'effet de bord.

Un simple way fermé fera tout aussi bien l'affaire et ne posera pas ce
genre de problème.

De même, remettre chacune de ces relations 'section' dans une relation
"Forêt domaniale de Dourdan", c'est de la collectionnite.



Le 3 décembre 2016 à 18:52, JB  a écrit :

> Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et
> parfois, c'est absolument impraticable dans la réalité. Et impossible à
> maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt
> qu'utiliser un chemin fermé simple ?
> Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au
> milieu, c'est Mapnik qui considère que le MP représente un chemin
> (highway=*) : comme il ne reconnait pas le type de multipolygone utilisé
> (forest=section + ref), il prend le premier way, voit un highway=*, et
> considère que la surface est un highway avec un multipolygone mal
> conditionné. Et hop. Foireux pour foireux, tant qu'à faire…
> JB.
>
>
> Le 03/12/2016 à 18:29, LeTopographeFou a écrit :
>
> Bonjour,
>
> Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir
> pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais pas
> que...) génèrent des soucis de dessin alors qu'elles paraissent toutes
> homogènes en terme de tags et qu'elles sont toutes fermées. Marron, gris,
> blanc, transparent... ce n'est pas homogène !
>
> A noter que je suppose que les parcelles ne sont à priori pas dessinées
> (sinon on verrait son numéro, il n'y aurait pas de statut "proposition", et
> le rendu serait plus homogène que cela).
>
> Voici mes constatations :
>
>- Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
>   - *Route de Madame* et *Route de la Lieue* ne sont pas écrits le
>   long du chemin mais au milieu de parcelles à l'horizontal (à partir du
>   niveau de zoom 15). En consultant les ways en question, rien à signaler.
>   Une idée ?
>   - Il y a des zones marrons qui correspondent bizarrement aux
>   délimitations de certaines parcelles. Sauf que ces parcelles n'ont rien 
> de
>   bizarre quand on regarde les tags (elles sont bien fermées et toutes ne
>   sont pas rendues de la même manière alors qu'elles ont des tags
>   identiques). Exemple : http://www.openstreetmap.org/relation/1866710
>   Une idée ?
>   - Là on a carrément une parcelle grise :
>   http://www.openstreetmap.org/relation/1853819
>   
>   - Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
>récupérer un lien vers la zone consultée...)
>   - Beaucoup plus de chemins sont tracés avec les noms au milieu des
>   parcelles et non le long du chemin. En fait c'est comme ci le rendu
>   dessinait les parcelles et prenait le nom du dernier élément de la 
> relation
>   pour lui donner un nom de relation. Une idée ?
>   - Il y a moins de parcelles bizarrement dessinées mais il y en a
>   qu'en même (et on notera que ce ne sont pas les mêmes que sur OSM.org).
>   Exemple avec celle sous "Route de la jumelle" qui apparait plus claire
>
> Résultat : c'est moche et ca fait penser zone en construction... Je me
> demande si la manière avec laquelle les parcelles ont été cartographiées ne
> perturbe pas le moteur de rendu. Ou alors c'est un bug dans le moteur de
> rendu ?
>
> A vous lire,
>
> Cordialement,
>
> --
> LeTopographeFou
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-03 Par sujet JB 
Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et 
parfois, c'est absolument impraticable dans la réalité. Et impossible à 
maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt 
qu'utiliser un chemin fermé simple ?
Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au 
milieu, c'est Mapnik qui considère que le MP représente un chemin 
(highway=*) : comme il ne reconnait pas le type de multipolygone utilisé 
(forest=section + ref), il prend le premier way, voit un highway=*, et 
considère que la surface est un highway avec un multipolygone mal 
conditionné. Et hop. Foireux pour foireux, tant qu'à faire…

JB.

Le 03/12/2016 à 18:29, LeTopographeFou a écrit :


Bonjour,

Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir 
pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult 
(mais pas que...) génèrent des soucis de dessin alors qu'elles 
paraissent toutes homogènes en terme de tags et qu'elles sont toutes 
fermées. Marron, gris, blanc, transparent... ce n'est pas homogène !


A noter que je suppose que les parcelles ne sont à priori pas 
dessinées (sinon on verrait son numéro, il n'y aurait pas de statut 
"proposition", et le rendu serait plus homogène que cela).


Voici mes constatations :

  * Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
  o /Route de Madame/ et /Route de la Lieue/ ne sont pas écrits le
long du chemin mais au milieu de parcelles à l'horizontal (à
partir du niveau de zoom 15). En consultant les ways en
question, rien à signaler. Une idée ?
  o Il y a des zones marrons qui correspondent bizarrement aux
délimitations de certaines parcelles. Sauf que ces parcelles
n'ont rien de bizarre quand on regarde les tags (elles sont
bien fermées et toutes ne sont pas rendues de la même manière
alors qu'elles ont des tags identiques). Exemple :
http://www.openstreetmap.org/relation/1866710 Une idée ?
  o Là on a carrément une parcelle grise :
http://www.openstreetmap.org/relation/1853819
  * Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
récupérer un lien vers la zone consultée...)
  o Beaucoup plus de chemins sont tracés avec les noms au milieu
des parcelles et non le long du chemin. En fait c'est comme ci
le rendu dessinait les parcelles et prenait le nom du dernier
élément de la relation pour lui donner un nom de relation. Une
idée ?
  o Il y a moins de parcelles bizarrement dessinées mais il y en a
qu'en même (et on notera que ce ne sont pas les mêmes que sur
OSM.org). Exemple avec celle sous "Route de la jumelle" qui
apparait plus claire

Résultat : c'est moche et ca fait penser zone en construction... Je me 
demande si la manière avec laquelle les parcelles ont été 
cartographiées ne perturbe pas le moteur de rendu. Ou alors c'est un 
bug dans le moteur de rendu ?


A vous lire,

Cordialement,
--
LeTopographeFou


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


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

[OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-03 Par sujet LeTopographeFou 

Bonjour,

Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir 
pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais 
pas que...) génèrent des soucis de dessin alors qu'elles paraissent 
toutes homogènes en terme de tags et qu'elles sont toutes fermées. 
Marron, gris, blanc, transparent... ce n'est pas homogène !


A noter que je suppose que les parcelles ne sont à priori pas dessinées 
(sinon on verrait son numéro, il n'y aurait pas de statut "proposition", 
et le rendu serait plus homogène que cela).


Voici mes constatations :

 * Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
 o /Route de Madame/ et /Route de la Lieue/ ne sont pas écrits le
   long du chemin mais au milieu de parcelles à l'horizontal (à
   partir du niveau de zoom 15). En consultant les ways en
   question, rien à signaler. Une idée ?
 o Il y a des zones marrons qui correspondent bizarrement aux
   délimitations de certaines parcelles. Sauf que ces parcelles
   n'ont rien de bizarre quand on regarde les tags (elles sont bien
   fermées et toutes ne sont pas rendues de la même manière alors
   qu'elles ont des tags identiques). Exemple :
   http://www.openstreetmap.org/relation/1866710 Une idée ?
 o Là on a carrément une parcelle grise :
   http://www.openstreetmap.org/relation/1853819
 * Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
   récupérer un lien vers la zone consultée...)
 o Beaucoup plus de chemins sont tracés avec les noms au milieu des
   parcelles et non le long du chemin. En fait c'est comme ci le
   rendu dessinait les parcelles et prenait le nom du dernier
   élément de la relation pour lui donner un nom de relation. Une
   idée ?
 o Il y a moins de parcelles bizarrement dessinées mais il y en a
   qu'en même (et on notera que ce ne sont pas les mêmes que sur
   OSM.org). Exemple avec celle sous "Route de la jumelle" qui
   apparait plus claire

Résultat : c'est moche et ca fait penser zone en construction... Je me 
demande si la manière avec laquelle les parcelles ont été cartographiées 
ne perturbe pas le moteur de rendu. Ou alors c'est un bug dans le moteur 
de rendu ?


A vous lire,

Cordialement,

--
LeTopographeFou

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