Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-24 Par sujet thevenon . julien 
- Mail original -
De: "JB" 
> Euh, j'ai laissé tomber la lecture de threads longs, pointus et qui 
> dévient souvent. Comme celui-là en fait partie, je ne l'ai pas lu 
> jusqu'à la fin. Et l'introduction ne m'a pas appris grand chose. Tu 
> pourrais donner un exemple, qu'on voit de quoi on parle ? (Parler dans 
> le vide, ça permet de discuter longtemps, mais souvent dans le vide, 
> tiens…).

Dommage les exemples etaient a la fin de son mail ;-)

SInon globalement je suis plutot d accord avec la proposition de Marc

Julien

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-24 Par sujet JB 

Le 25/01/2018 à 00:01, marc marc a écrit :

La confusion entre nœud adresse postale et routage provoque des
problèmes parfois insolubles et de nombreux besoins sont non satisfait.
Euh, j'ai laissé tomber la lecture de threads longs, pointus et qui 
dévient souvent. Comme celui-là en fait partie, je ne l'ai pas lu 
jusqu'à la fin. Et l'introduction ne m'a pas appris grand chose. Tu 
pourrais donner un exemple, qu'on voit de quoi on parle ? (Parler dans 
le vide, ça permet de discuter longtemps, mais souvent dans le vide, 
tiens…).

JB.
PS : j'ai lu qu'on parle de tracer des routes pour ne pas avoir de 
problème de routage… ben oui, se plaindre qu'une adresse sans route à 
proximité met le foutoir… ben c'est un peu abuser, j'ai l'impression. On 
parle de contributeurs, ici ?
PS2 : oui, j'ai la super pêche, ça va ! Assez pour pouvoir râler sans 
morosité !


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

Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-24 Par sujet marc marc 
Bonsoir,

Vu que mon email est très long, je fais un résumé pour ceux
qui n'ont pas envie de tout lire :
La confusion entre nœud adresse postale et routage provoque des 
problèmes parfois insolubles et de nombreux besoins sont non satisfait.
une séparation simple entre adresse postale et routage tout en créant
un lien avec les bâtiments permet de résoudre tous ces problèmes.
Cette solution peux-être aussi simple que déplacer légèrement
le nœud adresse jusqu'à le mettre SUR ou DANS l'aire qui le concerne
et tracer les routes manquantes.
On peux bien sur imaginer une une solution + complexe pour
ceux qui ne souhaitent pas la fin de cette confusion.
Si quelqu'un trouve un défaut à la solution proposée, qu'il l'exprime.
Mais cela ne peux fonctionner que si les besoins non couvert
sont compris.

Le 22. 01. 18 à 17:45, Christian Quest a écrit :
> faire le lien avec le bâtiment est une fausse bonne idée.

Nulle part dans ton email tu n'expliques POURQUOI c'est une
fausse bonne idée ni le moindre problème de la solution proposée.
Tu te contentes de dire que c'est pas ta logique ou que
ce n'est pas ton besoin.
Ce besoin est pourtant ce que je constate de mon utilisation
mais aussi ceux des autres en ayant regardé quasi tous
les changeset de nouveaux contributeurs en France depuis 3 mois.
Tous ceux qui ont ajouté une adresse ont fait un lien
entre le bâtiment et son adresse.
La question n'est donc pas "faut-il ou pas un lien ?"
mais "si on ne le fait pas, pourquoi ? et quel autres
solutions proposes-tu pour répondre aux besoins ?"
et "s'il n'y a pas de pourquoi autre que l'habitude,
comment faire ce lien manquant harmonieusement ?"
cfr fin de message pour 10 besoins concrets.

>> ce que je propose n'a cependant rencontré aucun cas qui
>> ne fonctionne pas. et pourtant je pense avoir croisé tous les cas.
>> Faut pas s'attendre à voir une solution unique adoptée si elle casse
>> ce que l'autre solution apporte. Dire que les autres ont tord ne suffit
>> pas si on ne propose pas en même temps une solution globale aux 2 faces
>> de la même pièce.
> 
> On ne peut pas résoudre les 2 (ni 3) d'un coup sans modéliser  
> chaque type d'info à part. En voulant mélanger, 
> on ne décrit ni l'un ni l'autre  correctement.

Justement tu mélange dans ton explication adresse et routage.
Je propose à l'inverse de faire une différence entre l'adresse,
le bâtiment et le routage tout en créant les liens évidents
qui les unissent.
- Si tu veux modéliser un bâtiment, fait un bâtiment.
- Si tu veux router un endroit, trace une ou des routes.
le lien entre adresse et routage n'est pas 1-1 comme tu penses mais 1-x,
tu peux avoir plusieurs point d'entré sur la parcelle, parfois plusieurs 
pour un même profil (un site universitaire avec plusieurs routes), 
parfois des entrées différentiées selon le profil (voiture <> piéton). 
ta confusion entre l'adresse du lieu et son point d'entrée est un 
handicap sérieux au routage de qualité. si tu comprend la confusion,
tu facilites ces routages multiples et différentiée (prendre l'entrée 
nord si tu arrives par le nord, prend l'entrée sud si tu arrives du sud, 
prendre l'accès piéton parfois + proche au lieu de marcher jusqu'à la 
route d'accès) tout cela implique que si tu veux router vers une 
adresse, celle ci doit être situé vers le milieu de la zone concernée
et non pas sur une entrée arbitraire que ta méthode va privilégier au 
détriment des autres entrées.
- Si tu veux modéliser la limite de la parcelle, fais une parcelle au 
lieu de mélanger cette info dans la position du nœud. ceci sans compter 
les nombreux cas oü il est impossible sur le terrain de voir cette info.
Ceci sans juger du fait que ce niveau de détail me parait - important
vu que des besoins + important sont loin d'être couvert à 100%.
Mais je respecte sans soucis ceux qui trouve que c'est important.
- Si tu veux mettre une adresse postale, ce n'est pas une cordonnée gps, 
elle a un lien avec d'autres objets osm.
De la même manière on trace des polygones pour les communes,
on ne se contente pas d'un nœud en disant "c'est environ par là"
Il faudrait qu'il y a un lien avec ce quelque chose. cela peux être
un bâtiment/entrée/surface des écoles pour les cas les plus simple
et majoritaires.
bref tout SAUF "adresse = point de routage sans lien avec le reste"

>> Pour rappel ma solution simple :
>> Le lien addr-bâtiment pourrait se faire au choix :
>> - soit en positionnant le nœud sur ou dans le contour du bâtiment (comme
>> cela se fait déjà pour les maisons mitoyennes en zone urbaine dense...
>> parfois ce n'est qu'une question de cm pour avoir ce lien !)
> Tu veux parler des maisons sur rues, avec la façade en bord de parcelle 
> ? Elle ne sont pas forcément mitoyennes... et le point d'accès au 
> domaine privé, n'est pas forcément sur la façade du bâtiment.

Oui je parle de ce genre de cas.
Mais l'accès n'est pas forcément unique (un site universitaire entre
4 rues en ville, cela existe), ce que ta solution ne gère pas.
Et l'accès

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Philippe Verdy 
Ou la version lisible aussi sur Wikipedia de la liste complète (générée par
bot depuis la même source, intégrée aussi à Wikidata contenant de nombreux
noms de langues traduits, intégrée aussi aux modules Lua de langues et de
traductions de Wikipedia, Commons et MetaWiki)

https://en.wikipedia.org/wiki/List_of_ISO_639-3_codes

On en a aussi une version sur le Wiktionnaire francophone (intégrée dans
les listes de labels de localisation BCP 47)

https://fr.wiktionary.org/wiki/Wiktionnaire:BCP_47

Cependant il peut encore manquer des ajouts plus récents, mais la date de
mises à jour est indiquée dans les tableaux. Ceci provbient non pas de
l'ISO 639-3 (dont certains codes sont exclus de BCP 47) mais du registre
IANA.

Le 24 janvier 2018 à 19:16,  a écrit :

> Une autre solution pour trouver le code langue ffr c'est de regarder la
> version publique de l'ISO639-3 :
>
> http://www-01.sil.org/iso639-3/codes.asp?order=reference_name=%25
>
> Jean-Yvon
>
> Le 24/01/2018 à 12:30, Francescu GAROBY - windu...@gmail.com a écrit :
>
> En cherchant "frr" dans Wikipedia, on arrive sur cette page de résultats
> .
>
>
> Francescu
>
> Le 24 janvier 2018 à 12:24, Charles MILLET  a
> écrit :
>
>> Merci Francescu pour l'info. Je suis curieux de savoir comment tu as
>> trouvé la référence au code, je ne l'ai pas vue dans la page
>> https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages
>> internet dédiées aux codes (peut-être trop orientées pays).
>>
>
>
> ___
> 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] positionnement des adresses et ménage

2018-01-24 Par sujet osm . sanspourriel 

Le 22/01/2018 à 17:45, Christian Quest - cqu...@openstreetmap.fr a écrit :


Le 22/01/2018 à 12:48, marc marc a écrit :

Le 22. 01. 18 à 11:32, Cyrille37 OSM a écrit :

Le résumé de Christian pourrait être déposé délicatement,
mais très visiblement, sur le wiki.openstreetmap.org ?

L’existence d'une relation x-y entre les adresses et les bâtiments
est déjà écrit sur la page wiki des adresses.
Je veux bien me charger de mieux rédiger les arguments de ceux qui
tagent pour le routing et de ceux qui tager pour le lien avec les 
bâtiments.


J'étais visiblement pas assez clair... vouloir faire le lien avec le 
bâtiment est une fausse bonne idée.
On voit un bâtiment, on veut savoir son adresse, ça ne me semble pas 
stupide.
Ou on nous dit que tel POI est à telle adresse et on veut savoir quels 
sont les bâtiments potentiellement concernés, ça ne me semble pas non 
plus stupide.



Cependant, j'aurais aimé naïvement que les partisans de la position
en bord de parcelle prennent en compte le revers de la médaille :
l'absence de lien entre le(s) bâtiment(s) et leur(s) adresse(s).
Cela aurait permit de mettre en place une solution qui résout les 2
problèmes au lieu d'avoir 2 version qui ne résolvent que la moitié
du problème.
Je comprend d'autant moins qu'avec un (maigre) millier d'adresses
à mon actif, ce que je propose n'a cependant rencontré aucun cas qui
ne fonctionne pas. et pourtant je pense avoir croisé tous les cas.
Faut pas s'attendre à voir une solution unique adoptée si elle casse
ce que l'autre solution apporte. Dire que les autres ont tord ne suffit
pas si on ne propose pas en même temps une solution globale aux 2 faces
de la même pièce.


C'est parce que la pièce à 3 faces... et même pas deux: adresses, 
parcelles, bâtiments.

Comme dans OSM on ne met pas les parcelles... 3-1=2 CQFD ;-).

On ne peut pas résoudre les 2 (ni 3) d'un coup sans modéliser chaque 
type d'info à part. En voulant mélanger, on ne décrit ni l'un ni 
l'autre correctement.
Concrètement tu veux mettre l'adresse quasiment sur la voie et des 
contact:addr sur les bâtiments même sans POI ?

Pour rappel ma solution simple :
Le lien addr-bâtiment pourrait se faire au choix :
- soit en positionnant le nœud sur ou dans le contour du bâtiment (comme
cela se fait déjà pour les maisons mitoyennes en zone urbaine dense...
parfois ce n'est qu'une question de cm pour avoir ce lien !)


Tu veux parler des maisons sur rues, avec la façade en bord de 
parcelle ? Elle ne sont pas forcément mitoyennes... et le point 
d'accès au domaine privé, n'est pas forcément sur la façade du bâtiment.
non mais si elles sont non mitoyennes tu peux mettre le nœud au niveau 
de l'entrée (partie non bâtie).
- ou de l'aire concernée (comme cela se fait déjà souvent pour les 
écoles)
En bord d'aire ? Au point d'accès donc entre domaine public et 
privé... on y revient ;)



- soit en travaillant sur une relation style associatedAddr.
Le routage est fait avec les routes (donc si on a un problème de routing
pour se rendre à un bâtiment, on trace la route de déserte manquante).


Je ne comprends pas ce besoin qui me semble purement théorique.

Pour le routage, on rentre quoi comme info ? Une adresse... et une 
adresse n'est pas un identifiant de bâtiment (chose qui n'existe pas 
vraiment actuellement).
Je crois que c'est ce que veut dire Marc : créer ce lien quand il n'est 
pas trivial entre adresses et bâtiments.


N. B. : je rappelle qu'en mettant l'adresse à la limite public/privé on 
obtient un rendu assez mauvais car les numéros sont mangés par les 
routes. Pourquoi pas, il "suffit" d'améliorer le moteur de rendu.

En poussant les numéros au niveaux des bâtiments par exemple ;-).

Je signale que dans associatedStreet, house est ce qui est raccroché à 
l'adresse.
Si ça s'appelle house et non number, il y a peut-être une raison (qui 
peut-être mauvaise).


Si on met les adresses au bord des routes, à quoi bon mettre une 
associatedStreet, la rue la plus proche doit être la bonne.


Car s'il n'y a pas les bâtiments et pas les accès privés non plus reste 
juste une arrête de poisson avec une rue et les points de part et 
d'autre. Bon, c'est plus une branche avec des boutons ;-).


N. B. : question bête, le bon endroit pour l'adresse n'est ce pas là où 
est affiché le numéro ?


Bref, alors que je suis assez d'accord avec Christian sur les adresses, 
je ne vois pas l'intérêt de ne pas mettre les adresses "sur" les 
bâtiments (nœuds distincts) quand on a N adresses pour un bâtiment.
Voici l'Allée des Glénans reprise : 
https://www.openstreetmap.org/#map=19/48.37355/-4.58535


1 adresse pour M bâtiments, ça ne marche pas, on s'arrête au niveau de 
la rue publique ?
Ça ne marche pas non plus toujours : 
https://www.openstreetmap.org/#map=18/48.09952/-1.61681
Là c'est un gros b... : le 40 c'est tout ce qui est desservi par les 
deux voies au sud de la rue du Bignon.
Pour simplifier le tout, les rues à l'intérieur du Forum de la Rocade 
(c'est le nom de ce b...) n'ont pas de

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet osm . sanspourriel 
Une autre solution pour trouver le code langue ffr c'est de regarder la 
version publique de l'ISO639-3 :


http://www-01.sil.org/iso639-3/codes.asp?order=reference_name=%25

Jean-Yvon


Le 24/01/2018 à 12:30, Francescu GAROBY - windu...@gmail.com a écrit :
En cherchant "frr" dans Wikipedia, on arrive sur cette page de 
résultats .



Francescu

Le 24 janvier 2018 à 12:24, Charles MILLET > a écrit :


Merci Francescu pour l'info. Je suis curieux de savoir comment tu
as trouvé la référence au code, je ne l'ai pas vue dans la page
https://wiki.openstreetmap.org/wiki/Multilingual_names
 et
d'autre pages internet dédiées aux codes (peut-être trop orientées
pays).



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

Re: [OSM-talk-fr] Fwd: [OSM-Science] Openstreetmap background in scientific paper

2018-01-24 Par sujet Christian Quest 
La notion de produced work est valable dans le cadre de l'ODbL, donc vis 
à vis des données.


En tout cas, il est faux de dire "OpenStreetMap derived products should 
be released under a CC-BY-SA licence"


Si je fais un rendu des données OSM sous licence ODbL, je fais un 
produced work, je peux le mettre dans n'importe quelle licence car on 
n'est plus dans le cadre d'une database.


Donc oui, c'est la licence choisie pour le rendu qui importe si c'est ça 
sur quoi tu t'appuie dans ta publication.


Si il est en CC-by-SA, ça coince effectivement... sauf si on considère 
que ce n'est qu'une citation (car ce n'est pas une copie complète du 
rendu qui couvre sûrement le monde entier sur de multiples zoom).


De quel rendu s'agit-il ? Il est aussi possible de demander à son auteur 
de faire jouer cette possibilité de citation.



Il y a quand même beaucoup de publication qui ne se sont pas embarrassée 
de ce genre de chose, et côté OSM, on est plutôt très content de voir 
des cartes OSM dans des publications scientifiques !




Le 24/01/2018 à 15:56, Vincent Bergeot a écrit :


Bonjour,

occasion de diffuser l'info concernant cette nouvelle liste de 
discussion (scie...@openstreetmap.org : 
https://lists.openstreetmap.org/listinfo/science)


Et avoir votre avis ? J'ai tendance à penser que cela dépend de la 
licence sur le rendu du fond qu'ils ont utilisé ?




 Message transféré 
Sujet : [OSM-Science] Openstreetmap background in scientific paper

Dear all,
I hope this my first question is pertinent to this new OSM list...
We have recently submitted a scientific paper to an open access 
journal. One figure has an OpenStreetMap background, correctly attributed.
One reviewer has argued that that figure can't be included in the 
paper because OpenStreetMap derived products should be released under 
a CC-BY-SA licence, while the paper will be released with a CC-BY licence.
My point is to consider a figure with OSM background as a Produced 
work 
(https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline) 
and so not bounded to the SA condition.

What are your experiences and suggestions with this (or similar) issue?



--
Christian Quest - OpenStreetMap France

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

[OSM-talk-fr] Fwd: [OSM-Science] Openstreetmap background in scientific paper

2018-01-24 Par sujet Vincent Bergeot 

Bonjour,

occasion de diffuser l'info concernant cette nouvelle liste de 
discussion (scie...@openstreetmap.org : 
https://lists.openstreetmap.org/listinfo/science)


Et avoir votre avis ? J'ai tendance à penser que cela dépend de la 
licence sur le rendu du fond qu'ils ont utilisé ?




 Message transféré 
Sujet : [OSM-Science] Openstreetmap background in scientific paper

Dear all,
I hope this my first question is pertinent to this new OSM list...
We have recently submitted a scientific paper to an open access journal. 
One figure has an OpenStreetMap background, correctly attributed.
One reviewer has argued that that figure can't be included in the paper 
because OpenStreetMap derived products should be released under a 
CC-BY-SA licence, while the paper will be released with a CC-BY licence.
My point is to consider a figure with OSM background as a Produced work 
(https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline) 
and so not bounded to the SA condition.

What are your experiences and suggestions with this (or similar) issue?


Merci

--
Vincent Bergeot

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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Erwan Salomon 

> Le 24 janv. 2018 à 12:11, marc marc  a écrit :
> 
> 
> surtout pour maps.me qui est connu pour gérer que partiellement
> les polygones.
> 

Je viens de vérifier
il se trouve que maps.me s’en sort bien cette fois ci
il affiche la relation avec « Mer Noire » 
et un peu plus bas le nœud avec « Black Sea » 
du coup ça fait bien doublon
passer le nœud en label pourrait être une solution, mais il semble que les 
relations multipolygones proscrivent l’usage des nœuds (je passe la mains aux 
habitués des relations) 

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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Charles MILLET 
C'était bien le nœud il semble car sur www.mapcat.com on voit bien Mer 
Noire. Merci encore marc marc.


On 24/01/2018 12:31, Charles MILLET wrote:
Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com ), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est 
bien

 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je 
pense
 que le problème d'affichage du nom en français vient peut-être 
de la

 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


___
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



___
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] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Charles MILLET 
Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* "name:fr"...

Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com ), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est bien
 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je pense
 que le problème d'affichage du nom en français vient peut-être de la
 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


___
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



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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Francescu GAROBY 
En cherchant "frr" dans Wikipedia, on arrive sur cette page de résultats
.


Francescu

Le 24 janvier 2018 à 12:24, Charles MILLET  a écrit :

> Merci Francescu pour l'info. Je suis curieux de savoir comment tu as
> trouvé la référence au code, je ne l'ai pas vue dans la page
> https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages
> internet dédiées aux codes (peut-être trop orientées pays).
>
> Concernant le problème d'affiche, j'avais imaginé la même hypothèse que
> toi... mais marc marc a remarqué que le nœud en doublon n'avait pas la clé
> name:fr
>
>
> On 24/01/2018 11:52, Francescu GAROBY wrote:
>
> Bonjour,
> "frr" est le code pour le frison septentrional
> , une langue
> d'Allemagne.
> Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
> "name:frr" devraient être traités distinctement. Sauf à penser que le code
> qui recherche la langue recherche une clé *commençant par* "name:fr"...
>
> Francescu
>
> Le 24 janvier 2018 à 11:45, Charles MILLET  a
> écrit :
>
>> Bonjour,
>>
>> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié
>> aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français
>> alors que la clé name:fr est bien renseignée. Par contre il y a le tag
>> name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je n'ai
>> rien trouvé. Je pense que le problème d'affichage du nom en français vient
>> peut-être de la présence de cette clé mais je n'ai pas de piste pour
>> corriger le problème sans me mettre à dos tout un pays... Si quelqu'un a
>> une idée je suis preneur.
>>
>> Bonne journée.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Francescu
>
>
> ___
> 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
>
>


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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Charles MILLET 
Merci Francescu pour l'info. Je suis curieux de savoir comment tu as 
trouvé la référence au code, je ne l'ai pas vue dans la page 
https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages 
internet dédiées aux codes (peut-être trop orientées pays).


Concernant le problème d'affiche, j'avais imaginé la même hypothèse que 
toi... mais marc marc a remarqué que le nœud en doublon n'avait pas la 
clé name:fr



On 24/01/2018 11:52, Francescu GAROBY wrote:

Bonjour,
"frr" est le code pour le frison septentrional 
, une langue 
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et 
"name:frr" devraient être traités distinctement. Sauf à penser que le 
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :


Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
vérifié aussi sur www.mapcat.com ), la Mer
Noire n'est pas nommée en français alors que la clé name:fr est
bien renseignée. Par contre il y a le tag name:frr=Suart Sia. Et
j'ai cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je
pense que le problème d'affichage du nom en français vient
peut-être de la présence de cette clé mais je n'ai pas de piste
pour corriger le problème sans me mettre à dos tout un pays... Si
quelqu'un a une idée je suis preneur.

Bonne journée.


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





--
Francescu


___
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] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet marc marc 
Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :
> Bonjour,
> "frr" est le code pour le frison septentrional 
> , une langue 
> d'Allemagne.
> Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et 
> "name:frr" devraient être traités distinctement. Sauf à penser que le 
> code qui recherche la langue recherche une clé *commençant par* "name:fr"...
> 
> Francescu
> 
> Le 24 janvier 2018 à 11:45, Charles MILLET  > a écrit :
> 
> Bonjour,
> 
> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
> vérifié aussi sur www.mapcat.com ), la Mer
> Noire n'est pas nommée en français alors que la clé name:fr est bien
> renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
> cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je pense
> que le problème d'affichage du nom en français vient peut-être de la
> présence de cette clé mais je n'ai pas de piste pour corriger le
> problème sans me mettre à dos tout un pays... Si quelqu'un a une
> idée je suis preneur.
> 
> Bonne journée.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Francescu
> 
> 
> ___
> 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] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Francescu GAROBY 
Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le code
qui recherche la langue recherche une clé *commençant par* "name:fr"...

Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET  a écrit :

> Bonjour,
>
> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié
> aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français
> alors que la clé name:fr est bien renseignée. Par contre il y a le tag
> name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je n'ai
> rien trouvé. Je pense que le problème d'affichage du nom en français vient
> peut-être de la présence de cette clé mais je n'ai pas de piste pour
> corriger le problème sans me mettre à dos tout un pays... Si quelqu'un a
> une idée je suis preneur.
>
> Bonne journée.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

2018-01-24 Par sujet Charles MILLET 

Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié 
aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français 
alors que la clé name:fr est bien renseignée. Par contre il y a le tag 
name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je 
n'ai rien trouvé. Je pense que le problème d'affichage du nom en 
français vient peut-être de la présence de cette clé mais je n'ai pas de 
piste pour corriger le problème sans me mettre à dos tout un pays... Si 
quelqu'un a une idée je suis preneur.


Bonne journée.


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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

2018-01-24 Par sujet Jean-Claude Repetto 
Le 24/01/2018 à 09:11, Gwenrannad a écrit :
> 
>  -> Pour la représentation de la voie :
> Le tag "highway=unclassified" est effectivement trop contraignant car il
> fait disparaitre le graphisme de la voie et qu'il serait préférable de
> lui affecter un tag de type "highway=path" de manière temporaire jusqu'à
> l'ouverture officielle de la voie avec un "access=no" pour éviter le
> routage .

Bonjour,

Tu veux dire que highway=unclassified ferait disparaître la voie de la
carte ? Si oui, pourquoi ?
highway=path ne me paraît pas adapté, car cela correspond à un sentier
(voie trop étroite pour permettre le passage d'un véhicule).

Jean-Claude

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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

2018-01-24 Par sujet marc marc 
Bonjour,

Pour son baptême du feu, on a aussi oublié de lui dire que parfois
on aime bien les complications :)

je pense qu'il faut faire simple, et documenter les faits
pour essayer d'être le moins subjectif

accès : il y a 2 panneaux B1 ? donc légalement on ne peux plus passer
access=no
foot=yes
note:access=panneaux B1 à chaque extrémité de la route
source:access=survey
et si on veux vraiment documenté cette situation changeante 
survey:date=la date à laquelle quelqu'un les a vu
et si on veux faciliter la stabilité, je met parfois sur le changeset
website=https://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France
Celui qui lit la modif et n'est pas d'accord peux d'un clic voir que 
c'est pourtant ce qui est documenté pour le moment sur le wiki.
Même si le cas du double sens-unique est évidement pas sur le wiki,
on peux cependant comprendre que cela se tag comme un accès interdit.

En passant envoi d'un petit email au responsable panneau
pour lui signaler qu'il a confondu B0 et B1 :)

type de highway :
pour rappel, tertiaire c'est un état en fonction des panneaux
est-ce que les panneaux route départementale 281 ont été supprimé ?
si oui on peux dégrader la classe de la route.
highway=unclassified (j'ai beaucoup de mal à imaginer
qu'on considère une route encombrée comme un chemin)
note:highway=les panneaux D281 ne sont plus là
et changer ref en old_ref.
Mais je n'ai pas l'impression que cela soie le cas.
Si c'est une route départementale temporairement fermée,
mais qui est toujours départementale.
highway=tertiary
note:highway=les panneaux D281 sont toujours là

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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

2018-01-24 Par sujet Gwenrannad 
Bonjour à tous :) 

Merci à vous pour tous vos retours et c'est pour un moi un sacré baptême de 
discussion :) 
J'ai pris bonne note de toutes vos remarques relatives à vos différentes 
sensibilités et je vous propose maintenant de conclure cet échange, riche en 
temps de lecture ;) 

-> Pour la dénomination : 
Comme le précise Mathieu, il a un consensus sur le alt_name="Route des 
Chicanes" 

-> Pour la représentation de la voie : 
Le tag "highway=unclassified" est effectivement trop contraignant car il fait 
disparaitre le graphisme de la voie et qu'il serait préférable de lui affecter 
un tag de type "highway=path" de manière temporaire jusqu'à l'ouverture 
officielle de la voie avec un "access=no" pour éviter le routage . L'ajout 
d'une note expliquant l’affectation de ces tags temporaires permettra 
d'éclairer ce choix et de préciser que ces tags évolueront en fonction de 
l'actualité de la voie. 
Cette note serait un peu à l'image des alertes wikipedia sur les articles qui 
font l'objet d'une actualité récente ou en cours. 

Encore merci pour le temps que vous m'avez consacré et pour vos éclairages. 
Tout ceci m'a permis de revoir ma manière de contribuer et de gagner encore 
plus de justesse. 

Stéphane alias Gwenrannad 

PS: Je vais vite vous solliciter de nouveau à propos des PDIPR mais ça c’est 
une autre histoire :D 

- Mail original -

De: "Mathieu"  
À: "Discussions sur OSM en français"  
Cc: gwenran...@free.fr 
Envoyé: Mercredi 24 Janvier 2018 05:05:15 
Objet: Re: [OSM-talk-fr] D281 en Loire-Atlantique 

Bonjour à tous, 

(et enchanté, c'est aussi ma première discussion ici !) 

Tout d'abord merci à tous pour ces échanges, et en particulier à 
Stéphane. C'est effectivement agréable de pouvoir discuter de ces 
sujets "sensibles" sans rentrer dans des guerres d'édition. 

C'est moi qui avait mis le nom "name=Route des Chicanes" dans 
https://www.openstreetmap.org/changeset/52404728, pour décrire la 
situation sur le terrain et le nom utilisé médiatiquement. Je n'avais 
pas connaissance à l'époque du nom officiel. Je pense aussi que OSM 
doit pouvoir retrouver cette appellation. 

En tout cas, au vu des précédents messages, en particulier ceux de 
Christian et Jean-Yvon, "alt_name" (ou bien "loc_name") semble faire 
consensus, en particulier dans la proposition "name=Route de la 
Pâquelais, alt_name=Route des Chicanes" qui me semble effectivement 
non polémique (bien que "name=Route des Chicanes, official_name=Route 
de la Pâquelais" pourrait aussi se défendre). 

Je viens donc de mettre ces noms dans 
https://www.openstreetmap.org/changeset/55701254. Je me suis permis au 
passage de changer la "note" pour faire référence à cette discussion 
plutôt de laisser penser que les modifications sont "réservées" à un 
utilisateur particulier. Je n'ai pas touché au statut de la route 
"abandonned" (qui en plus évolue rapidement). 

Mathieu (magiraud) 

2018-01-23 23:02 GMT+01:00 : 
> Antoine, merci pour ces précisions même si Stéphane s'est très bien défendu 
> tout seul et a bien vu le soucis (approche : l'administration décide) alors 
> que ses arguments sont parfaitement rationnels. 
> 
> Ce qu'il pense de l'Ayrault-port, peu m'importe, il y a des manières de 
> taguer qui sont assez neutres et oui entre militant et salarié il peut être 
> utile d'avoir 2 comptes. Ça m'a permis de dire du bien du travail fait par 
> Charles à Charles sans savoir que c'était la même personne ;-). 
> 
> Ceci dit j'attends que l'un comme l'autre trouvent des manières de taguer 
> compatibles avec les autres points de vue. 
> 
> name 
> Route des Chicanes pour moi (et je précise comme vous vous en doutez que je 
> suis content que le gouvernement ait abandonné un projet vieux d'un 
> demi-siècle prévu pour le Concorde) c'est un loc_name, un alt_name, pas un 
> name. 
> 
> Stéphane, fais la requête qui n'est pas politiquement correcte La Bite à 
> Mathon : tu tombes sur le monument aux morts de Brest, appelé ainsi par les 
> Brestois à cause de sa forme et de l'architecte ayant reconstruit la ville. 
> 
> Et oui, lors d'une manif les Brestois se donnent rendez-vous au pied de la 
> bite à Mathon, pas au pied du monument aux morts. Je vais peut-être 
> susciter des vocations pour le nom alternatif d'une sculpture à Vénissieux. 
> 
> C'est un alt_name, ça aurait pu être un loc_name. 
> 
> C'est ce qui met de la souplesse. Regarde l'historique : la toute première 
> fois que le monument a été décrit il comportait déjà ce second nom. 
> 
> Je ne dis pas name car a priori on met des noms officiels (ou affichés sur 
> le terrain), ce qui ne me semble pas être le cas et comme dans le 
> laboratoire de qualification du sous-sol de Bure pour en faire une poubelle 
> nucléaire (ce qui aurait été une description neutre ;-)), mettre en name un 
> nom potentiellement polémique, autant éviter. 
> 
> Route de la ZAD aurait été sans doute plus neutre