Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[Francois Gouget]

On Mon, 28 Aug 2017, Frédéric Rodrigo wrote:
[...]
> Le trac est vraiment en fin de vie.
> On utilise github maintenant :
> https://github.com/osm-fr/osmose-backend/issues (de préférence en anglais)

Il faudrait mettre openstreetmap.fr à jour alors car il pointe toujours 
sur trac : http://openstreetmap.fr/outils

(par contre ne me demandez pas comment retrouver cette page outils, je 
suis tombé facilement dessus la première fois et maintenant impossible 
de la trouver depuis l'accueil).

Bon j'ai recréé les bugs dans GitHub.
https://github.com/osm-fr/osmose-backend/issues/227

J'ai aussi le nouveau plugin dans ma fork de osmose-backend :
https://github.com/fgouget/osmose-backend


> Le problème n'est pas spécifique à la France.

Possible mais je ne connais pas trop le format des numéros de téĺéphone 
dans les autres pays.


-- 
Francois Gouget   http://fgouget.free.fr/
 f u kn rd ts, ur wy 2 gky 4 ur wn gd.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[marc marc]

Le 28. 08. 17 à 19:56, Francois Gouget a écrit :
> ces numéros sont faux, soit à cause du zéro en trop,
> soit parce que les numéros courts ne peuvent être utilisés depuis
> l'étranger. Mais comment les corriger de manière efficace ?
à mon avis le problème est mondial :)
vérifie sur le wiki s'il n'y a pas déjà eu un opération automatique.

Le 28. 08. 17 à 23:06, Romain MEHUT a écrit :
 > je vois souvent les numéros avec des espaces...
cela dépend de la norme. y a des espaces, des tirets ou rien.
norme en partie dépassée puis que beaucoup de pays n'ont plus
de code région vu la portabilité des numéros à l'échelle d'un pays.
De toute façon les séparateurs sont non significatif et virés
lors de la composition du numéro.
Certains font même des +33(0)123456789 alors que () n'est
prévu à ma connaissance dans aucune norme.

Pour le correctif, j'aurais tendance à faire ainsi :
d'abord chercher la cause. chercher par exemple
avec overpass les cas récemment modifiés.
http://overpass-turbo.eu/s/rjj
remplacer UneVille par un lieu (éviter de faire trop gros, c'est long)

Trouver parmi ces cas un où la modif concerne le numéro
de téléphone (clic sur le nœud pour l'ouvrir dans osm,
clic sur historique pour comparer la version actuelle avec
la précédente) (si quelqu'un sait comparer le champs phone
avec la version précédente en overpass, c'est le bienvenu)
Trouver quel app a été utilisée pour faire la modification
il serrait utile d'ouvrir un ticket pour améliorer la saisie.
ainsi les nouvelles données serraient directement bonne.
Il faudrait aussi vérifier si les pages wiki sont claire à ce sujet.
Parce que le premier exemple que j'ai trouvé utilise iD
http://www.openstreetmap.org/changeset/51465606
le 2ieme OsmAnd http://www.openstreetmap.org/changeset/50890233
Leur écrire pour voir ce qui les a inciter à faire ainsi.
Ou tester avec la même app pour voir si c'est l'app
qui incite à l'erreur

Ensuite pour ton query overpass, si tu choisis une région
à faible problème, tu peux aussi exporter cela dans josm
et les traiter un à un avec le pluging todo

Mais pour toute la France c'est 1466 nœuds, 884 chemins 35 relations.
ce serrait plus efficace de faire cela en automatique. cela implique :
0) choisir exactement les cas qu'on traire et ceux qu'on ignore
1) que la communauté valide mais je pense que ce serra le cas
2) faire une page wiki qui explique l'opération
> https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des_modifications_automatis%C3%A9es
3) faire le script. le début serra sûrement une requête overpass
Mais au lieu d'utiliser les coordonnées, il me semble plus efficace
de récupérer les id et champs phone.
Ensuite... hum.. j'ai encore jamais fait :)
Mais je suppose qu'en récupérant le xml, en y corrigeant les no,
on doit pouvoir ensuite envoyer les modifs.
Quelqu'un ayant déjà scripter ce genre de chose serra sûrement
plus efficace pour choisir la méthode la plus facile.
L'autre solution c'est de produire un fichier osc qu'on peux
ouvrir dans josm et qui contient les correctifs.

Sinon il y a aussi sur le wiki une page où demander l'aide de scripteur

Dans tout les cas ce serra d'abord à tester sur une toute petite zone

Dernier point et non des moindres, que fait-on des numéros court ?
le wiki sépare les numéros non pas sur leur longueur mais sur leur 
utilisation (local ou international).
+331234 fonctionne-t-il en local ?
je ne parle pas d'appeler un no depuis l'étranger mais localement.
a tester :) quelqu'un a un numéro court gratuit ? :-)
le wiki donne aussi phone:FR=no court ou gratuit avec 40 cas
selon taginfo (avec des fr à corriger en FR)
le wiki a même un exemple phone:FR:mobile:SFR
a voir si c'est un délire du wiki ou s'il y a réellement
une app qui sait l'utiliser

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

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[Romain MEHUT]

Bonsoir,

Le 28 août 2017 à 19:56, Francois Gouget  a écrit :

>
> Ou script du mois si quelqu'un sait faire ?
>
> J'ai trouvé qu'il y avait beaucoup de tags phone avec un numéro français
> incorrectement internationalisé.
> Par exemple :
>
>https://www.openstreetmap.org/node/2999626704
>phone=+33 02 40 xx xx xx
>

La correction donnerait +33 2 40 xx xx xx ou +33 2 40xx ? Le wiki
indique la 2ème version mais je vois souvent les numéros avec des espaces...

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

Re: [OSM-talk-fr] Demande d'avis sur une idée de "défi du mois"

[Alain VASSAULT]

Bah plus d'info courant septembre ^^

J'ai communiqué les informations de mon contact à Christian qui prendra le 
relais avec lui à la rentrée (la personne de l'IGN avait pris son mois d'août 
en vacances).

Il n'empêche que si cela vous tente de commencer avec les repères autour de 
chez vous, vous pouvez envoyer les remontées à fiches_...@tranquillement.info.
Je peut aussi vous transmettre le tableau que je lui remonte pour "formater" 
vos infos. Ainsi je verrai pour lui envoyer tout cela de façon groupé.

:-)



Le 28 août 2017 17:42:28 GMT+02:00, Francois Gouget  a écrit :
>On Wed, 9 Aug 2017, Alain VASSAULT wrote:
>[...]
>> Je suis en relation directe par courriel avec le chef de l'unité de 
>> mise à jour des fiches qui serait ravis d'une telle aide (surtout
>pour 
>> les fiches sans photos, sachant que les photos ne sont obligatoires 
>> que depuis l'année 2000).
>
>La partie photo ressemble à quelque chose pour Mapillary ou 
>OpenStreetCam... si l'IGN peut faire usage de photos sous license 
>CC-BY-SA. Il n'y aurait probablement même pas vraiment besoin d'une 
>participation active de ces projets.
>
>
>-- 
>Francois Gouget   http://fgouget.free.fr/
>   La terre est une bêta...

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] contributions peut-être à revoir

[osm . sanspourriel]

Encore une fois on part d'un sujet (le multilinguisme dans les name) et 
on dérive (ici sur les noms historiques).


Tu voulais parler de Cherbourg-en-Cotentin 
, 
comme dit Wikipédia :


/*Cherbourg-en-Cotentin*//est une commune du nord du département de la 
//Manche 
//. Elle 
est créée officiellement le //1^er //janvier 2016//^2 
 
//, par la réunion des cinq communes membres de la //communauté urbaine 
de Cherbourg 
//sous 
le statut de //commune nouvelle 
// : 
//Cherbourg-Octeville 
//(elle-même issue de 
la fusion des communes de Cherbourg et //Octeville 
//le //1^er //mars 
2000), //Équeurdreville-Hainneville 
//(issue 
de la fusion des communes d'//Équeurdreville 
//et //Hainneville 
//en 1965), //La 
Glacerie //, //Querqueville 
//et //Tourlaville 
//./


Je vois que l'admin_centre a pour name Cherbourg.

Cherbourg, c'est le nom court de Cherbourg-en-Cotentin et aussi la ville 
initiale.


À Brest il y a Brest la ville regroupant Brest, Saint-Pierre-Quilbignon, 
Lambézellec et Saint-Marc. Pour parler du centre (la ville d'origine), 
les Brestois parlent de Brest-même, c'est un loc_name.


Et je ne vois pas le rapport avec le multilinguisme.

Certains pays du Maghreb ont aussi des traditions similaires aux pays 
multilingues européens : plusieurs noms dans le name.
https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name 
a été rejeté mais ne prévoyait explicitement pas les noms multilingues 
(voir discussion).


Séverin, si tu fais des formation, et que tu ne cites pas talk-fr, les 
gens vont dire qu'il faut une liste sur les attributs. Ça ne veut pas 
dire que talk-fr ne leur conviendrait pas. Et en "déduire" que la faible 
fréquentation de [talk-fr] en est la preuve me semble plus un 
renversement de preuve.
En particulier sur le multilinguisme ne pas avoir que le point de vue 
jacobin aide.


Saint-Quentin-en-Yvelines semble exister en tant que Communauté 
d'agglomération de Saint-Quentin-en-Yvelines 
  et 
a bien son alt_name.


Le 28 août 2017 à 12:54, Christian Quest > a écrit :
/Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais 
avec intelligence...//


//Le gros avantage d'OSM c'est de permettre de mettre les noms en autant 
de langues que l'on veut avec name:xx=* et en même temps de préciser la 
langue en question, ce qu'un panneau ou une plaque dans la rue ne peut 
pas préciser./


Ce résumé me plait bien. Et je pense plus utile de travailler sur la 
représentation. Par exemple les panneaux routiers dans la Bretagne 
brittophone sont ne général bilingues. Avoir un itinéraire en breton est 
équivalent à un itinéraire en français.


/A minima, en France pour les noms de commune, on est quand même bien 
d'accord que name=* correspond au nom du Code Officiel Géographique de 
l'INSEE./

Au niveau des lieux-dits, c'est déjà plus flou.
J'ai par exemple "corrigé" un "La Mort Anglaise" en "Ar Beg Bereneg" et 
mis le "La Mort Anglaise" en alt_name.
Car si les deux se disent en français, c'est Ar Beg Bereneg qui est 
écrit sur les panneaux routiers (par contre à côté Trez-Rouz conserve 
son nom - d'où la remarque de Christian R., à ce niveau là les noms sont 
en général en breton). Il n'est pas impossible ce que soit pour ne pas 
fâcher les touristes anglais : les deux font allusion à une bataille 
perdue par les Anglais, le second nom (la plage rouge) n'étant pas 
comprise par les anglais ou les français sans explication : c'est la 
couleur du sable après l'hécatombe).
Le fait est que j'ai deux sources l'une disant "La Mort Anglaise" 
(FANTOIR) l'autre "Ar Beg Bereneg" (les panneaux routiers) ou "Bereneg" 
et du coup je me demande ce qui est name et ce qui est alt_name. 
loc_name c'est Bereneg (ou Berenec : le son en breton est entre le G et 
le C, les Français ont souvent changé des eg en ec).
C'est juste dans ce genre de cas limite qu'un double nom a un sens, 
sinon je préfère un nom de base avec l'autre nom en survol.
À mon avis il est plus efficace de travailler à rendre les rendus dans 
la langue de son choix que de multiplier les noms dans name.
Car dans le second cas on aura toujours des jacobins 

Re: [OSM-talk-fr] réseau de bus twisto - nouveauté pour le 01 septembre

[Noémie Lehuby]

Hello,

Il y a quelques erreurs Osmoses sur les arrêts et les lignes du réseau 
Twisto qui peuvent surement être regardées par la même occasion ;)


 * 
http://osmose.openstreetmap.fr/fr/map/#source=23850=1260=4=1260=12=49.1585=-0.3226=2
 * 
http://osmose.openstreetmap.fr/fr/map/#source=89=2140=21412=2140=12=49.1585=-0.3226=3
 * 
http://osmose.openstreetmap.fr/fr/map/#source=89=2140=21411=2140=12=49.1585=-0.3226=3


nlehuby

Le 28/08/2017 à 21:01, Jo a écrit :
oh la la, Caen, Lion-sur-Mer, j'étais là en 2011... Je n'étais pas 
encore 'investit' dans le transport publique à l'époque. Mai  je suis 
allé pour 'guider' une mapping party.


Il y quelqu'un sur cette liste qui était là aussi? C'était un des 
premiers événements en France, si je ne trompe. La nostalgie :-)


Polyglot

2017-08-28 20:22 GMT+02:00 Francescu GAROBY >:


Bonjour,
Ayant grandement contribué à cartographier le réseau Twisto  de
Caen-la-Mer, je participerai bien évidemment à cette nouvelle
évolution. On peut se répartir les tâches, si tu veux ?
Pour la page
https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun
,
c'est moi qui l'avais créée et l'avais faite évoluer, au fil des
nouvelles versions annuelles du réseau. Je pense qu'elle est à
jour, pour le réseau 2016-2017. Il ne manque normalement que les
nouveautés de cette rentrée.

Francescu

Le 28 août 2017 à 19:29, David Crochet > a écrit :

Bonjour


Le 28/08/2017 à 19:11, marc marc a écrit :

est-ce que les arrêts où sont reportés les arrêts existant
existent
déjà dans osm ?


les « arrêts de report » existent déjà.
Et a priori les bus passent déjà devant, donc je pense quand
das ces cas, ce n'est que des « stop » à retirer. Mais une rue
a une nouvelle voie de circulation à contre-sens pour les bus,
donc il vont faire un raccourci par ce chemin là et
implicitement modifier les « lanes » du chemin
ces plan de lignes sont à jour :
http://twisto.fr/997-Plans-des-lignes.html


  et les nouveaux arrêts des lignes prolongées ?


oui : http://twisto.fr/886-Plans-en-telechargement.html


Si oui je t'aide volontiers, ce serra rapide.
Sinon existe-t-il une source opendata pour les créer ?


Je les ai titiller (
https://twitter.com/Crochetdavid/status/898587291391635456
 )
mais j'ai pas eu de réponses ni de remarques

Sans cela j'ignore où positionner précisément les nouveaux
arrêts.
Mais je peux de toute façon aider pour modifier les relations

Tu as une page wiki ou un pad pour renseigner qui fait quoi
et les valeurs utilisée dans la région (network, operator,
...)


https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun
,
mais j'ai jamais fait de maintenance sur cette page.

Cordialement

-- 
David Crochet




___
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] réseau de bus twisto - nouveauté pour le 01 septembre

[Jo]

oh la la, Caen, Lion-sur-Mer, j'étais là en 2011... Je n'étais pas encore
'investit' dans le transport publique à l'époque. Mai  je suis allé pour
'guider' une mapping party.

Il y quelqu'un sur cette liste qui était là aussi? C'était un des premiers
événements en France, si je ne trompe. La nostalgie :-)

Polyglot

2017-08-28 20:22 GMT+02:00 Francescu GAROBY :

> Bonjour,
> Ayant grandement contribué à cartographier le réseau Twisto  de
> Caen-la-Mer, je participerai bien évidemment à cette nouvelle évolution. On
> peut se répartir les tâches, si tu veux ?
> Pour la page https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun,
> c'est moi qui l'avais créée et l'avais faite évoluer, au fil des nouvelles
> versions annuelles du réseau. Je pense qu'elle est à jour, pour le réseau
> 2016-2017. Il ne manque normalement que les nouveautés de cette rentrée.
>
> Francescu
>
> Le 28 août 2017 à 19:29, David Crochet  a écrit :
>
>> Bonjour
>>
>>
>> Le 28/08/2017 à 19:11, marc marc a écrit :
>>
>>> est-ce que les arrêts où sont reportés les arrêts existant existent
>>> déjà dans osm ?
>>>
>>
>> les « arrêts de report » existent déjà.
>> Et a priori les bus passent déjà devant, donc je pense quand das ces cas,
>> ce n'est que des « stop » à retirer. Mais une rue a une nouvelle voie de
>> circulation à contre-sens pour les bus, donc il vont faire un raccourci par
>> ce chemin là et implicitement modifier les « lanes » du chemin
>> ces plan de lignes sont à jour : http://twisto.fr/997-Plans-des
>> -lignes.html
>>
>>   et les nouveaux arrêts des lignes prolongées ?
>>>
>>
>> oui : http://twisto.fr/886-Plans-en-telechargement.html
>>
>> Si oui je t'aide volontiers, ce serra rapide.
>>> Sinon existe-t-il une source opendata pour les créer ?
>>>
>>
>> Je les ai titiller ( https://twitter.com/Crochetdav
>> id/status/898587291391635456 ) mais j'ai pas eu de réponses ni de
>> remarques
>>
>> Sans cela j'ignore où positionner précisément les nouveaux arrêts.
>>> Mais je peux de toute façon aider pour modifier les relations
>>>
>>> Tu as une page wiki ou un pad pour renseigner qui fait quoi
>>> et les valeurs utilisée dans la région (network, operator, ...)
>>>
>>
>> https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun, mais j'ai
>> jamais fait de maintenance sur cette page.
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>>
>> ___
>> 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] Champs phone : futur projet du mois ?

[Frédéric Rodrigo]

Le 28/08/2017 à 19:56, Francois Gouget a écrit :

Ou script du mois si quelqu'un sait faire ?

J'ai trouvé qu'il y avait beaucoup de tags phone avec un numéro français
incorrectement internationalisé.
Par exemple :

https://www.openstreetmap.org/node/2999626704
phone=+33 02 40 xx xx xx

On trouve aussi des phone=+33 3631

Dans tous les cas ces numéros sont faux, soit à cause du zéro en trop,
soit parce que les numéros courts ne peuvent être utilisés depuis
l'étranger. Mais comment les corriger de manière efficace ? J'ai bien
envoyé une proposition de plugin Osmose mais je n'ai pas la
configuration nécessaire pour la tester :

https://trac.openstreetmap.fr/ticket/815

Et peut-être que les corrections pourraient être automatisées, au moins
pour le premier round ?

Le trac est vraiment en fin de vie.
On utilise github maintenant :
https://github.com/osm-fr/osmose-backend/issues (de préférence en anglais)

Si tu ne veux pas installer un Osmose backend toi même. Tu peux utiliser 
docker ou vagrant :

https://github.com/osm-fr/osmose-backend/blob/master/Dockerfile
https://github.com/prhod/osmose-vagrant


Le problème n'est pas spécifique à la France.

Frédéric.


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

Re: [OSM-talk-fr] réseau de bus twisto - nouveauté pour le 01 septembre

[Francescu GAROBY]

Bonjour,
Ayant grandement contribué à cartographier le réseau Twisto  de
Caen-la-Mer, je participerai bien évidemment à cette nouvelle évolution. On
peut se répartir les tâches, si tu veux ?
Pour la page https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun,
c'est moi qui l'avais créée et l'avais faite évoluer, au fil des nouvelles
versions annuelles du réseau. Je pense qu'elle est à jour, pour le réseau
2016-2017. Il ne manque normalement que les nouveautés de cette rentrée.

Francescu

Le 28 août 2017 à 19:29, David Crochet  a écrit :

> Bonjour
>
>
> Le 28/08/2017 à 19:11, marc marc a écrit :
>
>> est-ce que les arrêts où sont reportés les arrêts existant existent
>> déjà dans osm ?
>>
>
> les « arrêts de report » existent déjà.
> Et a priori les bus passent déjà devant, donc je pense quand das ces cas,
> ce n'est que des « stop » à retirer. Mais une rue a une nouvelle voie de
> circulation à contre-sens pour les bus, donc il vont faire un raccourci par
> ce chemin là et implicitement modifier les « lanes » du chemin
> ces plan de lignes sont à jour : http://twisto.fr/997-Plans-des
> -lignes.html
>
>   et les nouveaux arrêts des lignes prolongées ?
>>
>
> oui : http://twisto.fr/886-Plans-en-telechargement.html
>
> Si oui je t'aide volontiers, ce serra rapide.
>> Sinon existe-t-il une source opendata pour les créer ?
>>
>
> Je les ai titiller ( https://twitter.com/Crochetdav
> id/status/898587291391635456 ) mais j'ai pas eu de réponses ni de
> remarques
>
> Sans cela j'ignore où positionner précisément les nouveaux arrêts.
>> Mais je peux de toute façon aider pour modifier les relations
>>
>> Tu as une page wiki ou un pad pour renseigner qui fait quoi
>> et les valeurs utilisée dans la région (network, operator, ...)
>>
>
> https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun, mais j'ai
> jamais fait de maintenance sur cette page.
>
> Cordialement
>
> --
> David Crochet
>
>
>
> ___
> 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] Champs phone : futur projet du mois ?

[Francois Gouget]

Ou script du mois si quelqu'un sait faire ?

J'ai trouvé qu'il y avait beaucoup de tags phone avec un numéro français 
incorrectement internationalisé.
Par exemple :

   https://www.openstreetmap.org/node/2999626704
   phone=+33 02 40 xx xx xx

On trouve aussi des phone=+33 3631

Dans tous les cas ces numéros sont faux, soit à cause du zéro en trop, 
soit parce que les numéros courts ne peuvent être utilisés depuis 
l'étranger. Mais comment les corriger de manière efficace ? J'ai bien 
envoyé une proposition de plugin Osmose mais je n'ai pas la 
configuration nécessaire pour la tester :

   https://trac.openstreetmap.fr/ticket/815

Et peut-être que les corrections pourraient être automatisées, au moins 
pour le premier round ?


Pour mes essais j'ai utilisé http://www.overpass-api.de/query_form.html
avec comme query :

node
  ["phone"~"[+]33 0"]
  (47,-5,48,-1);
out body;

Ça me donne un fichier que je filtre pour ne garder que les lignes 
contenant les coordonnées GPS :
  sed -e 's/" lon="/,/' -e t -e d phone.txt | less

Ensuite je n'ai plus qu'à les copier dans iD et à corriger les tags 
phone de tous les magasins et restaurants des alentours (ces problèmes 
viennent généralement par grappe). Mais ce n'est quand même pas très 
efficace.


-- 
Francois Gouget   http://fgouget.free.fr/
$live{free} || die "";___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Certificat invalide sur trac.openstreetmap.fr

[Francois Gouget]

Lorsque je vais sur https://trac.openstreetmap.fr/ Firefox se plaint que 
le certificat n'est pas correct.

En effet il s'agit d'un certificat Let's Encrypt qui a expiré le 
22/08/2017.

Sachant que ces certificats sont à renouveler tous les 3 mois ce 
renouvellement est normalement fait automatiquement. Le renouvellement 
automatique serait-il lui-même buggé ?

-- 
Francois Gouget   http://fgouget.free.fr/
Indifference will certainly be the downfall of mankind, but who cares?___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[Severin Menard]

Bonjour à tous et plus particulièrement à Christian R et Marc,

Mes réponses en interlignes ci-dessous.



> Date: Sat, 26 Aug 2017 11:45:58 +0200
> From: Christian Rogel 
> To: Discussions sur OSM en français  
> Subject: Re: [OSM-talk-fr] Création de la liste OSM tagging-fr -
> communication - fragmentation
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> > Le 26 août 2017 à 04:33, Severin Menard  a
> écrit :
> > Je pensais mon courriel clair, mais apparemment il ne l'était pas, ou
> bien une réalité a pu échapper à certains. Comme je l'avais écrit, le but
> de tagging-fr est bien d'être la liste de discussion des tags en français,
> entre FRANCOPHONES, pas de la liste de discussion des tags de la communauté
> OSM française. Je l'ai nommée tagging-fr en écho à dev-fr que je pense être
> la liste francophone sur les sujets de développement logiciel. Aurais-je dû
> la nommer tagging-francophone pour lever toute ambiguïté ? Il n'est pas
> trop tard, il y a au moins une liste existante (vote) qui est indiquée
> comme n'étant plus utilisée.
> >
> > Quel que soit son nom, l'utilité de cette liste semble assez évidente
> dans la mesure où il n'y avait aucune liste dédiée aux discussions de
> tagging en français. A l'instar des nombreuses autres listes talk-*,
> talk-fr a vocation à être un lieu de discussions se rapportant à un
> territoire.
>
> Ton post manquait de clarté, parce qu'il était beaucoup trop peu précis
> sur les raisons de créer cette liste.
> Te connaissant, il n'était pas difficile de deviner que tu pensais aux
> besoins des francophones dans le monde et que tu pensais que la liste
> Talk-fr pouvait leur apparaître comme trop "française".
> Contrairement à ce que tu dis Talk-fr veut dire "Parler (d'OSM) en
> français" exactement comme Talk-en veut dire "…en anglais", puisque ce sont
> deux indicatifs de langue.
> S'il était créé une liste "française" (ce qui semble peu utile), elle
> pourrait être appelée Talk-FR (mauvais parce que tendant à la confusion) ou
> Talk-FRA.
> Les Britanniques ont bien créé une liste Talk-GB.
> Il est évident que peu de contributeurs non français postent sur Talk-fr
> (Afrique, Viet-Nam, Belgique, Canada), mais elle est, probablement lue par
> de nombreux abonnés silencieux qui ont du mal à franchir le pas de
> l'intervention publique.
>

Juste un fait : dans tous les pays africains dans lesquels je suis passé
avec d'autres faire découvrir OSM et/ou renforcer les capacités de la
communauté existante, il y a eu une demande locale de création d'une liste
pour leur pays. Regardez les listes talk existantes : c'est définitivement
une approche pays qui prévaut. Les Québécois par exemple communiquent en
français sur la liste talk-ca, dont les messages sont  pourtant
majoritairement en anglais (exemple : https://lists.openstreetmap.or
g/pipermail/talk-ca/2017-July/thread.html). Et comme je l'ai déjà dit,
c'est très bien ainsi : cela me semble essentiel qu'il y ait une liste de
référence pour les échanges sur un territoire. J'ai prévenu, sauf erreur de
ma part, toutes les listes talk francophones existantes, soient 21, de la
création de tagging-fr.

>
> L'avenir dira, si ta  proposition rencontre une attente.
> Ce qui apparaît, c'est qu'elle n'a pas été amenée dans les meilleures
> conditions :
> - pas de propos introductif argumenté
> - arrivée exactement au moment où la liste fr connaissait un trafic
> important et inhabituel sur la question du tagging, même s'il est vrai
> qu'elle ne semblait concerner que des Français et un Belge
>

Que des Français et un Belge : tout est dit...

- il y avait une vague impression que tu voulais faire du détournement,
> alors qu' en réalité, tu ne suivais pas ce que nous écrivons et tu n'avais
> pas les codes pour convaincre ceux qui doivent l'être pour participer
>

J'avoue que je n'imaginais même pas que la notion de "détournement" de
liste puisse même exister.


Ma conclusion, c'est qu'il est difficile de conclure. Wait and see.
>
> Christian R.
>
>
>
> --
>
> Message: 2
> Date: Sat, 26 Aug 2017 10:05:45 +
> From: marc marc 
> To: "talk-fr@openstreetmap.org" 
> Subject: Re: [OSM-talk-fr] harmonisation tag network Arc-en-ciel dans
> le département du Nord région Hauts-de-France
> Message-ID:
>  0.PROD.OUTLOOK.COM>
>
> Content-Type: text/plain; charset="utf-8"
>
> Le 25. 08. 17 à 21:47, osm.sanspourr...@spamgourmet.com a écrit :
> > harmoniser avec le nom officiel en espérant que ce soit
> > la valeur la plus courante ;-)
> les différences de valeurs sont cosmétiques : majuscule, tiret.
> "Arc en ciel" est le nom présent sur le site web.
> wikipedia en a un autre et je n'ai pas la connaissance
> locale pour trancher 

Re: [OSM-talk-fr] réseau de bus twisto - nouveauté pour le 01 septembre

[David Crochet]

Bonjour


Le 28/08/2017 à 19:11, marc marc a écrit :

est-ce que les arrêts où sont reportés les arrêts existant existent
déjà dans osm ?


les « arrêts de report » existent déjà.
Et a priori les bus passent déjà devant, donc je pense quand das ces 
cas, ce n'est que des « stop » à retirer. Mais une rue a une nouvelle 
voie de circulation à contre-sens pour les bus, donc il vont faire un 
raccourci par ce chemin là et implicitement modifier les « lanes » du chemin

ces plan de lignes sont à jour : http://twisto.fr/997-Plans-des-lignes.html


  et les nouveaux arrêts des lignes prolongées ?


oui : http://twisto.fr/886-Plans-en-telechargement.html


Si oui je t'aide volontiers, ce serra rapide.
Sinon existe-t-il une source opendata pour les créer ?


Je les ai titiller ( 
https://twitter.com/Crochetdavid/status/898587291391635456 ) mais j'ai 
pas eu de réponses ni de remarques



Sans cela j'ignore où positionner précisément les nouveaux arrêts.
Mais je peux de toute façon aider pour modifier les relations

Tu as une page wiki ou un pad pour renseigner qui fait quoi
et les valeurs utilisée dans la région (network, operator, ...)


https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun, mais j'ai 
jamais fait de maintenance sur cette page.


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] réseau de bus twisto - nouveauté pour le 01 septembre

[marc marc]

Le 28. 08. 17 à 18:25, David Crochet a écrit :
> Si des personnes veulent travailler avec moi sur le réseau Twisto 
> (Caen-la-Mer) le 1 septembre, il y a quelques modification à apporter : 
> http://twisto.fr/affichage.php?actu=2715_Twisto_:_Ce_qui_change_a_la_rentree
>  

est-ce que les arrêts où sont reportés les arrêts existant existent
déjà dans osm ? et les nouveaux arrêts des lignes prolongées ?
Si oui je t'aide volontiers, ce serra rapide.
Sinon existe-t-il une source opendata pour les créer ?
Sans cela j'ignore où positionner précisément les nouveaux arrêts.
Mais je peux de toute façon aider pour modifier les relations

Tu as une page wiki ou un pad pour renseigner qui fait quoi
et les valeurs utilisée dans la région (network, operator, ...)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] réseau de bus twisto - nouveauté pour le 01 septembre

[Jo]

Je veux bien faire un hangout pour te montrer comment utiliser PT_Assistant
et JOSM pour rendre ton travail au plus efficace le possible.

Jo

2017-08-28 18:25 GMT+02:00 David Crochet :

> Bonjour
>
> Si des personnes veulent travailler avec moi sur le réseau Twisto
> (Caen-la-Mer) le 1 septembre, il y a quelques modification à apporter :
> http://twisto.fr/affichage.php?actu=2715_Twisto_:_Ce_
> qui_change_a_la_rentree
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] réseau de bus twisto - nouveauté pour le 01 septembre

[David Crochet]

Bonjour

Si des personnes veulent travailler avec moi sur le réseau Twisto 
(Caen-la-Mer) le 1 septembre, il y a quelques modification à apporter : 
http://twisto.fr/affichage.php?actu=2715_Twisto_:_Ce_qui_change_a_la_rentree


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Demande d'avis sur une idée de "défi du mois"

[Francois Gouget]

On Wed, 9 Aug 2017, Alain VASSAULT wrote:
[...]
> Je suis en relation directe par courriel avec le chef de l'unité de 
> mise à jour des fiches qui serait ravis d'une telle aide (surtout pour 
> les fiches sans photos, sachant que les photos ne sont obligatoires 
> que depuis l'année 2000).

La partie photo ressemble à quelque chose pour Mapillary ou 
OpenStreetCam... si l'IGN peut faire usage de photos sous license 
CC-BY-SA. Il n'y aurait probablement même pas vraiment besoin d'une 
participation active de ces projets.


-- 
Francois Gouget   http://fgouget.free.fr/
   La terre est une bêta...___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] ancien et nouveau overpass osm-fr

[marc marc]

Bonjour,

Pour ceux qui ont suivit, Rodolphe est entrain de terminer
le nouveau serveur overpass osm-fr, il reste quelques détails
à peaufiner avant sa réouverture officielle.
Et les pages wiki a mettre à jour.

Je profite de l'occasion pour créer de la surveillance
supplémentaire afin de détecter au plutôt les problèmes.
Quelqu'un se souvient de ce qui n'allait plus précisément
sur l'ancien serveur ?
un exemple de requête par exemple.

Je profite de l'occasion pour remercier
- Sylvain pour ces années passées à maintenir le serveur
et sa précieuse doc
- Rodolphe qui a fait 99% du boulot d'installation
du nouveau serveur, voir + :)
- Jocelyn aussi tapis dans l'ombre qu'on oublie
trop souvent :)

PS: cela ne concerne PAS la fonction proxy api qui n'est pour le moment 
PAS réinstallé, on verra cela après. exprimez-vous si vous l'utilisiez.

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

Re: [OSM-talk-fr] contributions peut-être à revoir

[Bruno]

Le 28/08/2017 à 14:30, Christian Rogel a écrit :

Le 28 août 2017 à 12:54, Christian Quest  a écrit :

Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais avec 
intelligence...

C'est ce que j'applique en disant que si le nom autre ("alternatif") n'est pas 
juridiquement consolidé, il doit forcément passer sur une autre ligne (alt, name:{lg}…).
J'interroge le cas rarissime d'une intentionalité de la décision de l'autorité 
compétente.


Le gros avantage d'OSM c'est de permettre de mettre les noms en autant de 
langues que l'on veut avec name:xx=* et en même temps de préciser la langue en 
question, ce qu'un panneau ou une plaque dans la rue ne peut pas préciser.

Ceci permet aussi au réutilisateur des données de faire son choix dans les 
langues qu'il veut mettre en avant (le rendu FR utilisera par exemple name:fr 
en priorité).

Pour le name=*, la convention sur OSM c'est de mettre la langue officielle du 
pays, donc en France le français (ou autre si il n'y a pas de version du nom en 
français).

Un nom de lieu ou de rue validé n'a pas de version en français, il se suffit à 
lui-même. Je suis étonné que toi-aussi tu ne saisisse pas que, si une version 
est officielle dans un contexte plurilingue, elle perd sa référence à une 
langue, fût-elle hégémonique, puisqu'elle peut accueillir toute les nuances de 
l'arc-en-ciel linguistique.
Les pays dont les inscriptions publiques sont officiellement plurilingues ne 
font qu'une application spécifique du principe.

Il y a des exceptions à cette règle pour les pays/régions/communes 
multilingues: Bruxelles, mais aussi la Suisse... qui compte 4 langues 
officielles. Là pour ne pas favoriser une langue par rapport à d'autres, on les 
met toutes.

Il ne s'agit que de mettre au jour l'usage des communautés linguistiques, mais 
pas leurs langues en elles-mêmes. Elles peuvent chacune emprunter des éléments 
à d'autres langues.
On permet de mettre au jour l'usage des communautés linguistiques par le 
champ name:xx ou alt_name etc..

Supposons que les noms soient translittérés (runes, oghams, cyrilliques, 
katakana, morse, etc…), on voit qu'il y a un niveau ne mettant pas en jeu le 
bilinguisme et, pour OSM, la solution serait du même ordre.


Christian R.



___
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] Création de la liste OSM tagging-fr - communication - fragmentation

[marc marc]

Le 28. 08. 17 à 14:28, Martin Noblecourt a écrit :
> la discussion sur la fragmentation des canaux 
> de communication mérite d'être posée 

> En effet la liste talk-fr est très difficile à suivre
> il est quasi-impossible d'y retrouver des 
> informations si on ne les a pas suivi au fur et à mesure.
Est-ce le temps de lecture de tout les détails qui pose problème ?
Si oui, je vois mal comment résoudre cet aspect là de choses.

Ou est-ce l'absence de possibilité de passer les détails
pour ne lire qu'un résumé voir la conclusion ?
Si oui, est-ce que poster un résumé de la conversation comme j'ai essayé 
de le faire pour le sujet network est-il une partie de la solution ?
faudrait-il un sujet particulier pour permettre à ceux qui le souhaite 
de passer les discussions mais pouvoir lire les résumés/conclusions ?
Et/ou penses-tu qu'il faudrait inclure la conclusion des discussions
dans la version françaises du mailing mensuel ?

> A mon humble avis le meilleur endroit pour discuter tagging 
> (et même technique en général) reste le Wiki, avec ses  
> conversations en un lieu unique
le wiki a le grand avantage d'être modifiable après coup pour 
s'améliorer de version en version mais à mon avis à 3 gros défauts :
1) il est impossible de suivre "tout le wiki fr", sauf à aller mettre
des "suivre la page" sur toutes les pages en question. Je ne parle
même pas du côté inadapté d'une notification pour une discussion.
2) il n'est à ma connaissance pas possible non plus d'être prévenu
d'une nouvelle page. d'ailleurs le wiki lui-même renvois aux mailing 
pour les annonces.
3) c'est encore un endroit supplémentaire où un nouveau doit s'inscrire 
(je n'ai jamais compris pq le login osm n'était pas aussi valable sur
le wiki), encore une technologie différente des mails (même s'il y
a un éditeur graphique), c'est peu intégré à l'éditeur iD (du moins
pour la partie "poser une question"), c'est souvent invisible
depuis les applications axé "édition simplifié" genre maps.me
Je ne suis pas sur que discuter sur le wiki soie une solution pour
un débutant. je parle même pas du côté indigeste si le wiki contenait 
toutes l'historique de toute les conversations d'un sujet donné,
je pense qu'on s'y noierait également.

Par contre le wiki impose une certains discipline, on ne parle pas
de pommes sur la page des poires, on fractionne en sujet.
C'est peut-être cela aussi qui nous manque, séparer les sujets qui 
méritent de l'être afin à la fois d'éviter de se noyer et d'aboutir.

> perdre l'archive de la discussion peut faire perdre des 
> subtilités/explications 
> de pourquoi les décisions ont été prises ainsi.

rien n'empêche de mettre un lien vers l'archive, je pensais le faire
pour les changeset où il y a eu discussion mais c'est aussi possible
d'inclure ce lien sur le wiki
> De plus, les mailing lists restant un outil peu attractif (il suffirait 
> de compter les messages de plusieurs membres éminents de la communauté, 
> qui sont pourtant loin d'être inactifs sur le projet OSM mais sont 
> quasi-absents ici...) et le forum pas beaucoup plus,
Quels moyens utilisent ces personnes pour discuter collectivement ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] contributions peut-être à revoir

[Christian Quest]

Ces noms sont tous officiels... ce n'est que la portée qui a changé dans 
le temps.


Il y a bien un Cherbourg dans OSM, même si ce n'est plus une commune 
aujourd'hui (suite à une fusion en 2 étapes)


https://www.openstreetmap.org/node/26691942#map=13/49.6397/-1.6258

Saint-Quentin-en-Yvelines est une communauté d'agglomération depuis 2004 
qui avant était un SAN (Syndicat d'Agglomération Nouvelle), et encore 
avant un SCAAN (Syndicat communautaire d’aménagement de l’agglomération 
nouvelle). Son périmètre a changé en 1983 et 2016.




Le 28/08/2017 à 13:17, djakk djakk a écrit :
Je ne suis pas fan des sources officielles, bon dans la majorité des 
cas ça coïncide avec l'usage, mais j'ai 2 contre-exemples :
• Saint-Quentin-en-Yvelines n'est plus officiellement une ville 
nouvelle (?), mais reste représentée par le nom de l'université, ou 
par le nom de la gare … est-ce que dans l'usage on utilise 
encore Saint-Quentin-en-Yvelines ? Si oui, il faudrait un nœud 
"place=city" pour la ville non-officielle de Saint-Quentin-en-Yvelines
• Cherbourg-Octeville : je ne sais pas où ça en est, je suppose que le 
nom officiel est passé Cherbourg-Octeville, mais on utilise Cherbourg 
y compris sur les panneaux de signalisation directionnelle verts et je 
suppose que l'usage a toujours été "Cherbourg"


Le 28 août 2017 à 12:54, Christian Quest > a écrit :


Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui,
mais avec intelligence...

Le gros avantage d'OSM c'est de permettre de mettre les noms en
autant de langues que l'on veut avec name:xx=* et en même temps de
préciser la langue en question, ce qu'un panneau ou une plaque
dans la rue ne peut pas préciser.

Ceci permet aussi au réutilisateur des données de faire son choix
dans les langues qu'il veut mettre en avant (le rendu FR utilisera
par exemple name:fr en priorité).

Pour le name=*, la convention sur OSM c'est de mettre la langue
officielle du pays, donc en France le français (ou autre si il n'y
a pas de version du nom en français).

Il y a des exceptions à cette règle pour les pays/régions/communes
multilingues: Bruxelles, mais aussi la Suisse... qui compte 4
langues officielles. Là pour ne pas favoriser une langue par
rapport à d'autres, on les met toutes.


A minima, en France pour les noms de commune, on est quand même
bien d'accord que name=* correspond au nom du Code Officiel
Géographique de l'INSEE.



Le 28/08/2017 à 11:50, Christian Rogel a écrit :

Le 28 août 2017 à 07:53, Bruno > a écrit :

Le 27/08/2017 à 22:05, Christian Rogel a écrit :

Le 27 août 2017 à 17:04, Bruno > a écrit :

En gros, il y a un conflit théorique entre deux
sources de légitimité : ce qu'on voit et ce que
l'autorité compétente a voulu signifier.

Pour moi aucune complexité,
Il me semble que l'on voit sur la plaque le nom d'une rue
dans deux langues  , il n'y a pas de conflit.
Le champ name contient le nom dans une langue , et name:xx
dans une autre, c'est fait pour ça.

C'est pourtant contraire à un principe cardinal d'OSM :
représenter ce qu'il sur le terrain.
L'exemple bruxellois montre qu'on peut faire autrement tout en
donnant leur place aux suffixes de langue.
Même si un nombre infinitésimal de communes a choisi de placer
les deux noms  sur un même niveau juridique, l'effacer dans la
représentation du terrain est une voie de fait, puisque c'est
nier la décision d'un corps élu.

Si il pouvait y avoir conflit c'est sur le choix de la
langue dans l'un ou l'autre champ , mais en France il n'y
a pas d'ambiguité, pas de bilinguisme en métropole.


Là, tu introduis un argument non plus technique, mais
politique, donc renversable par nature. Pas de question de
bilinguisme en jeu, il suffirait que le Parlement prescrive
qu'aucun élément d'une plaque de rue ne soit laissé de côté.

Christian R.

___
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





___
Talk-fr mailing list

Re: [OSM-talk-fr] contributions peut-être à revoir

[Christian Rogel]

> Le 28 août 2017 à 12:54, Christian Quest  a écrit :
> 
> Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais avec 
> intelligence...

C'est ce que j'applique en disant que si le nom autre ("alternatif") n'est pas 
juridiquement consolidé, il doit forcément passer sur une autre ligne (alt, 
name:{lg}…).
J'interroge le cas rarissime d'une intentionalité de la décision de l'autorité 
compétente.

> Le gros avantage d'OSM c'est de permettre de mettre les noms en autant de 
> langues que l'on veut avec name:xx=* et en même temps de préciser la langue 
> en question, ce qu'un panneau ou une plaque dans la rue ne peut pas préciser.
> 
> Ceci permet aussi au réutilisateur des données de faire son choix dans les 
> langues qu'il veut mettre en avant (le rendu FR utilisera par exemple name:fr 
> en priorité).
> 
> Pour le name=*, la convention sur OSM c'est de mettre la langue officielle du 
> pays, donc en France le français (ou autre si il n'y a pas de version du nom 
> en français).

Un nom de lieu ou de rue validé n'a pas de version en français, il se suffit à 
lui-même. Je suis étonné que toi-aussi tu ne saisisse pas que, si une version 
est officielle dans un contexte plurilingue, elle perd sa référence à une 
langue, fût-elle hégémonique, puisqu'elle peut accueillir toute les nuances de 
l'arc-en-ciel linguistique.
Les pays dont les inscriptions publiques sont officiellement plurilingues ne 
font qu'une application spécifique du principe.
> 
> Il y a des exceptions à cette règle pour les pays/régions/communes 
> multilingues: Bruxelles, mais aussi la Suisse... qui compte 4 langues 
> officielles. Là pour ne pas favoriser une langue par rapport à d'autres, on 
> les met toutes.

Il ne s'agit que de mettre au jour l'usage des communautés linguistiques, mais 
pas leurs langues en elles-mêmes. Elles peuvent chacune emprunter des éléments 
à d'autres langues.
Supposons que les noms soient translittérés (runes, oghams, cyrilliques, 
katakana, morse, etc…), on voit qu'il y a un niveau ne mettant pas en jeu le 
bilinguisme et, pour OSM, la solution serait du même ordre.


Christian R.



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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[Martin Noblecourt]

Bonjour à tous,

Quoique cette liste présente en effet toute son utilité comme l'a 
parfaitement expliqué Séverin, je pense que la discussion sur la 
fragmentation des canaux de communication mérite d'être posée (au-delà 
de la liste ici en question).


En effet la liste talk-fr est très difficile à suivre, à part pour des 
passionnés (rien que de lire le sommaire des messages et les 2/3 fils 
qui me concernent au retour d'une semaine de voyage m'a pris un temps 
significatif...), et il est quasi-impossible d'y retrouver des 
informations si on ne les a pas suivi au fur et à mesure. Je ne suis pas 
sûr que la division en listes thématiques aidera, entre les fils 
multi-thématiques et les nouveaux (ou non) arrivants qui se tromperont 
de liste/ne souhaiteront pas s'abonner à une liste spécialisée pour une 
simple question...


A mon humble avis le meilleur endroit pour discuter tagging (et même 
technique en général) reste le Wiki, avec ses conversations en un lieu 
unique, stockées en permanence, réorganisables/archivables, et 
traduisibles en chaque langue du Wiki. J'imagine que les principales 
conclusions des discussions sur talk-fr sont ensuite reportées dans le 
wiki lui-même de toute façon, mais perdre l'archive de la discussion 
peut faire perdre des subtilités/explications de pourquoi les décisions 
ont été prises ainsi.


De plus, les mailing lists restant un outil peu attractif (il suffirait 
de compter les messages de plusieurs membres éminents de la communauté, 
qui sont pourtant loin d'être inactifs sur le projet OSM mais sont 
quasi-absents ici...) et le forum pas beaucoup plus, il y a une vraie 
question sur la circulation de l'info dans la communauté française, 
francophone, et mondiale (cf. la mailing list de la Fondation qui est 
elle même très peu active). Le nouveau tasking manager va intégrer un 
outil de chat par projet qui était une demande de longue date, mais cela 
ne résoudra pas les problèmes des zones comme la France qui n'ont pas 
besoin de cet outil. J'éviterais le traditionnel "il faut lancer un 
Slack/Mattermost/équivalent" qui ne résoudra pas le problème si on ne se 
pose pas d'autres questions derrières.


Je pense également que cette question des outils de communication est 
fortement liée à l'ouverture à un public de contributeurs plus 
diversifié. C'est d'ailleurs un enjeu qui se pose aujourd'hui à 
énormément de structures. Peut-être un sujet de discussion au prochain 
SOTM ?


Cordialement,

Martin



On 26/08/2017 04:33, talk-fr-requ...@openstreetmap.org wrote:

Subject:
[OSM-talk-fr] Création de la liste OSM tagging-fr - communication - 
fragmentation

From:
Severin Menard 
Date:
26/08/2017 04:33

To:
Discussions sur OSM en français 


Bonsoir à tous,

Désolé de ne pas avoir répondu plus tôt. La France représente moins de 
1% du total de mes contributions 
(https://www.openstreetmap.org/user/sev_osm) notamment parce que je 
n'y suis pas souvent - mais j'ai néanmoins peuplé de POI quelques 
centres-villes et fait sortir du presque néant quelques communes du 
Lot. Je suis inscrit sur cette liste depuis pas mal de temps, mais au 
vu du très grand nombre de messages publiés, je l'ai filtrée hors de 
ma boite de réception principale, ce qui me permet de pouvoir faire 
des recherches si besoin dans les échanges. Pour autant, je vous 
assure qu'il est encore possible de parler ici de moi à la deuxième 
personne et non la troisième, je peux répondre, la preuve. :)


Je pensais mon courriel clair, mais apparemment il ne l'était pas, ou 
bien une réalité a pu échapper à certains. Comme je l'avais écrit, le 
but de tagging-fr est bien d'être la liste de discussion des tags en 
français, entre FRANCOPHONES, pas de la liste de discussion des tags 
de la communauté OSM française. Je l'ai nommée tagging-fr en écho à 
dev-fr que je pense être la liste francophone sur les sujets de 
développement logiciel. Aurais-je dû la nommer tagging-francophone 
pour lever toute ambiguïté ? Il n'est pas trop tard, il y a au moins 
une liste existante (vote) qui est indiquée comme n'étant plus utilisée.


Quel que soit son nom, l'utilité de cette liste semble assez évidente 
dans la mesure où il n'y avait aucune liste dédiée aux discussions de 
tagging en français. A l'instar des nombreuses autres listes talk-*, 
talk-fr a vocation à être un lieu de discussions se rapportant à un 
territoire. Une rapide analyse des fils de discussion montre que les 
sujets relèvent en gros de trois catégories :
- des sujets franco-français. Et c'est très bien ainsi, c'est fait 
justement pour cela.
- des questions techniques. Cela serait sans doute mieux au sein du 
forum pour que les échanges puissent être facilement retrouvés et que 
la question ne revienne pas quelques mois plus tard, mais après tout 
pourquoi pas
- des discussions sur des points de tagging, certains franco-français, 
mais pas mal à vocation générique. Là c'est dommage, car elles vont 

Re: [OSM-talk-fr] contributions peut-être à revoir

[David Crochet]

Bonjour


Le 28/08/2017 à 07:53, Bruno a écrit :
Si il pouvait y avoir conflit c'est sur le choix de la langue dans 
l'un ou l'autre champ , mais en France il n'y a pas d'ambiguité, pas 
de bilinguisme en métropole.


+1 : « name:*=* » et «*_name = » sont là pour cela

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] contributions peut-être à revoir

[djakk djakk]

Je ne suis pas fan des sources officielles, bon dans la majorité des cas ça
coïncide avec l'usage, mais j'ai 2 contre-exemples :
• Saint-Quentin-en-Yvelines n'est plus officiellement une ville nouvelle
(?), mais reste représentée par le nom de l'université, ou par le nom de la
gare … est-ce que dans l'usage on utilise
encore Saint-Quentin-en-Yvelines ? Si oui, il faudrait un nœud "place=city"
pour la ville non-officielle de Saint-Quentin-en-Yvelines
• Cherbourg-Octeville : je ne sais pas où ça en est, je suppose que le nom
officiel est passé Cherbourg-Octeville, mais on utilise Cherbourg y compris
sur les panneaux de signalisation directionnelle verts et je suppose que
l'usage a toujours été "Cherbourg"

Le 28 août 2017 à 12:54, Christian Quest  a écrit :

> Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais
> avec intelligence...
>
> Le gros avantage d'OSM c'est de permettre de mettre les noms en autant de
> langues que l'on veut avec name:xx=* et en même temps de préciser la langue
> en question, ce qu'un panneau ou une plaque dans la rue ne peut pas
> préciser.
>
> Ceci permet aussi au réutilisateur des données de faire son choix dans les
> langues qu'il veut mettre en avant (le rendu FR utilisera par exemple
> name:fr en priorité).
>
> Pour le name=*, la convention sur OSM c'est de mettre la langue officielle
> du pays, donc en France le français (ou autre si il n'y a pas de version du
> nom en français).
>
> Il y a des exceptions à cette règle pour les pays/régions/communes
> multilingues: Bruxelles, mais aussi la Suisse... qui compte 4 langues
> officielles. Là pour ne pas favoriser une langue par rapport à d'autres, on
> les met toutes.
>
>
> A minima, en France pour les noms de commune, on est quand même bien
> d'accord que name=* correspond au nom du Code Officiel Géographique de
> l'INSEE.
>
>
>
> Le 28/08/2017 à 11:50, Christian Rogel a écrit :
>
>> Le 28 août 2017 à 07:53, Bruno  a écrit :
>>>
>>> Le 27/08/2017 à 22:05, Christian Rogel a écrit :
>>>
 Le 27 août 2017 à 17:04, Bruno  a écrit :
>
 En gros, il y a un conflit théorique entre deux sources de légitimité :
 ce qu'on voit et ce que l'autorité compétente a voulu signifier.

>>> Pour moi aucune complexité,
>>> Il me semble que l'on voit sur la plaque le nom d'une rue dans deux
>>> langues  , il n'y a pas de conflit.
>>> Le champ name contient le nom dans une langue , et name:xx dans une
>>> autre, c'est fait pour ça.
>>>
>> C'est pourtant contraire à un principe cardinal d'OSM : représenter ce
>> qu'il sur le terrain.
>> L'exemple bruxellois montre qu'on peut faire autrement tout en donnant
>> leur place aux suffixes de langue.
>> Même si un nombre infinitésimal de communes a choisi de placer les deux
>> noms  sur un même niveau juridique, l'effacer dans la représentation du
>> terrain est une voie de fait, puisque c'est nier la décision d'un corps élu.
>>
>> Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un
>>> ou l'autre champ , mais en France il n'y a pas d'ambiguité, pas de
>>> bilinguisme en métropole.
>>>
>>
>> Là, tu introduis un argument non plus technique, mais politique, donc
>> renversable par nature. Pas de question de bilinguisme en jeu, il suffirait
>> que le Parlement prescrive qu'aucun élément d'une plaque de rue ne soit
>> laissé de côté.
>>
>> Christian R.
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] contributions peut-être à revoir

[Bruno]

Le 28/08/2017 à 11:50, Christian Rogel a écrit :

Le 28 août 2017 à 07:53, Bruno  a écrit :

Le 27/08/2017 à 22:05, Christian Rogel a écrit :

Le 27 août 2017 à 17:04, Bruno  a écrit :

En gros, il y a un conflit théorique entre deux sources de légitimité : ce 
qu'on voit et ce que l'autorité compétente a voulu signifier.

Pour moi aucune complexité,
Il me semble que l'on voit sur la plaque le nom d'une rue dans deux langues  , 
il n'y a pas de conflit.
Le champ name contient le nom dans une langue , et name:xx dans une autre, 
c'est fait pour ça.

C'est pourtant contraire à un principe cardinal d'OSM : représenter ce qu'il 
sur le terrain.
L'exemple bruxellois montre qu'on peut faire autrement tout en donnant leur 
place aux suffixes de langue.
Même si un nombre infinitésimal de communes a choisi de placer les deux noms  
sur un même niveau juridique, l'effacer dans la représentation du terrain est 
une voie de fait, puisque c'est nier la décision d'un corps élu.

La Belgique a plusieurs langues officielles.

Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un ou 
l'autre champ , mais en France il n'y a pas d'ambiguité, pas de bilinguisme en 
métropole.


Là, tu introduis un argument non plus technique, mais politique, donc 
renversable par nature. Pas de question de bilinguisme en jeu, il suffirait que 
le Parlement prescrive qu'aucun élément d'une plaque de rue ne soit laissé de 
côté.

Christian R.

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


Aucun élément politique dans ce que je dis , c'est juste un fait , sur 
lequel je n'apporte pas de jugement de valeur d'ailleurs.


"il suffirait que le parlement prescrive" oui, mais en attendant ce 
n'est pas le cas, une seule langue officielle.




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

Re: [OSM-talk-fr] contributions peut-être à revoir

[Christian Quest]

Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais 
avec intelligence...


Le gros avantage d'OSM c'est de permettre de mettre les noms en autant 
de langues que l'on veut avec name:xx=* et en même temps de préciser la 
langue en question, ce qu'un panneau ou une plaque dans la rue ne peut 
pas préciser.


Ceci permet aussi au réutilisateur des données de faire son choix dans 
les langues qu'il veut mettre en avant (le rendu FR utilisera par 
exemple name:fr en priorité).


Pour le name=*, la convention sur OSM c'est de mettre la langue 
officielle du pays, donc en France le français (ou autre si il n'y a pas 
de version du nom en français).


Il y a des exceptions à cette règle pour les pays/régions/communes 
multilingues: Bruxelles, mais aussi la Suisse... qui compte 4 langues 
officielles. Là pour ne pas favoriser une langue par rapport à d'autres, 
on les met toutes.



A minima, en France pour les noms de commune, on est quand même bien 
d'accord que name=* correspond au nom du Code Officiel Géographique de 
l'INSEE.



Le 28/08/2017 à 11:50, Christian Rogel a écrit :

Le 28 août 2017 à 07:53, Bruno  a écrit :

Le 27/08/2017 à 22:05, Christian Rogel a écrit :

Le 27 août 2017 à 17:04, Bruno  a écrit :

En gros, il y a un conflit théorique entre deux sources de légitimité : ce 
qu'on voit et ce que l'autorité compétente a voulu signifier.

Pour moi aucune complexité,
Il me semble que l'on voit sur la plaque le nom d'une rue dans deux langues  , 
il n'y a pas de conflit.
Le champ name contient le nom dans une langue , et name:xx dans une autre, 
c'est fait pour ça.

C'est pourtant contraire à un principe cardinal d'OSM : représenter ce qu'il 
sur le terrain.
L'exemple bruxellois montre qu'on peut faire autrement tout en donnant leur 
place aux suffixes de langue.
Même si un nombre infinitésimal de communes a choisi de placer les deux noms  
sur un même niveau juridique, l'effacer dans la représentation du terrain est 
une voie de fait, puisque c'est nier la décision d'un corps élu.


Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un ou 
l'autre champ , mais en France il n'y a pas d'ambiguité, pas de bilinguisme en 
métropole.


Là, tu introduis un argument non plus technique, mais politique, donc 
renversable par nature. Pas de question de bilinguisme en jeu, il suffirait que 
le Parlement prescrive qu'aucun élément d'une plaque de rue ne soit laissé de 
côté.

Christian R.

___
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] Manque un feu tricolore : volontaire?

[Thomas Ruchin]

J'ai un peu travaillé sur ce secteur. Et comme je n'ai strictement aucun
intérêt pour les feux tricolores, je n'ai ni vérifié, ni amélioré la
donnée...
C'est le principe d'OSM, chacun améliore les données en fonction de ses
envies et centres d'intérêt.

Thomas

Le 21 août 2017 à 14:29, Christian Quest  a écrit :

> C'est bien plus courant qu'on ne pense, j'en ajoute encore beaucoup
> partout où je passe et sur des endroits très urbanisés?
>
> Il y a beaucoup de détails de ce type qui manquent, mais leur absence
> n'est pas si visible dans les données, alors qu'une route manquante, un nom
> de rue manquant ça se voir bien plus vite sur les rendus et autres usages.
>
>
> Le 18/08/2017 à 23:30, Shohreh a écrit :
>
>> Merci pour les infos.
>>
>> En cherchant ailleurs dans le coin, je me rends compte qu'il y a d'autres
>> carrefours où il n'y a carrément /aucun/ feu tricolore dans OSM :
>>
>> http://www.openstreetmap.org/?mlat=48.83436=2.31362#map
>> =18/48.83446/2.31405
>>
>> Je m'étonne que personne n'ait entré ces feux tricolores dans un coin
>> pourtant hyper-urbanisé et hyper-renseigné par ailleurs. Comment se
>> fait-ce
>> ?
>>
>>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> 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] pistes cyclables à paris

[Thomas Ruchin]

J'ai constaté, les données dans OSM sont d'aussi bonne qualité que les
données publiées par la ville de Paris, tout simplement parce que les
données OSM sont mises à jour plus "régulièrement".
NB : ne pas oublier par ailleurs que les jeux de donnée officiels peuvent
comporter des erreurs et omissions.

J'avais préparé la nouvelle piste cyclable sur les quais en la passant en
"highway=construction" et "construction=cycleway". A ma connaissance, ce
nouvel aménagement bien que praticable n'est pas encore ouvert
officiellement aux cyclistes, mais quelqu'un a déjà fait l'ouverture dans
OSM...

Thomas

Le 24 août 2017 à 14:12, Nicolas Bétheuil  a écrit :

> J'ai initalisé un map contrib pour comparer OSM & l'open data
> https://www.mapcontrib.xyz/t/841cf5-Reseau_cyclable_Paris
>
> Qu'ai-je mis de trop pour que sur le layer OSM (overpass) ? j'ai des
> bulles de POI : il n'y a que des ways, ni node, ni relations.
>
> Merci
>
> Le 24 août 2017 à 13:35, Nicolas Bétheuil  a écrit :
>
>> Hello rogelio,
>>
>> En fait il y a de l'open data sur les pistes cyclables de Paris. Je viens
>> de rechercher & trouver ça https://opendata.paris.fr/expl
>> ore/dataset/reseau-cyclable
>> Vais demander en interne comment je peux faire ça.
>>
>> Des reco les mappeurs sur la manière de procéder ?
>> osmose pourrait aider pour partager le travail ?
>>
>> Le 23 août 2017 à 19:59, Rogelio Canedo  a
>> écrit :
>>
>>> Salut Nico,
>>> Je ne suis pas certain que les données de Paris vélo soient en open
>>> data. Mappy a mis à disposition sur Mapillary toutes les images de la
>>> collecte 2017 et de mémoire il y a Paris. Tu peux donc faire l'intégration
>>> via josm en mode manuel :) N'hésite pas à demander un coup de main à Gilles
>>> où Ulrich si tu galère avec l'outil.
>>> C'est peut être aussi l'occasion d'organiser un mapathon chez Mappy? Non?
>>>
>>> @++
>>>
>>>
>>> Le 23 août 2017 3:02 PM, "Nicolas Bétheuil"  a
>>> écrit :
>>>
>>> Bonjour,
>>>
>>> Comment sont gérées les pistes cyclables avec la mairie de paris ?
>>> Il y en a beaucoup qui ne sont pas dans OSM
>>> ex : http://www.parisavelo.net/carte-imprimable-pistes-cyclables.jpg
>>>
>>> il y en a de nouvelles https://twitter.com/latruelle/
>>> status/900078511536386050
>>>
>>> C'est aussi de l'ajout manuel ?
>>> Comment on peut procéder ?
>>>
>>> merci
>>>
>>> ___
>>> 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] contributions peut-être à revoir

[Jo]

J'habite dans une ville à 30km de Bruxelles, néerlandophone. Il y a quelque
rues dans ma ville qui ont de noms en bilingue, le deuxième le dialecte
local.

Même si c'est signé comme cela, je ne considérait jamais d'ajouter le nom
en dialecte au tag name. C'est plutôt quelque chose de 'folklorique'.

Il y a même quelques rues où on trouve un nom en français, d'une autre
époque. Bien sûr ces noms en français n'iront jamais dans le tag name. Ici
c'est monolingue néerlandais.

Dans la région en France où ce fil de conversation a commencé, il me semble
que name contient le nom en français, puis je le répéterais en name:fr,
puis la traduction peut aller en name:oc et peut-être loc_name.

La région bruxelloise est relativement unique et là il me semble tout à
fait normal d'avoir les deux langues en name. Même s'il y a de moins en
moins de gens qui parlent encore le néerlandais là-bas. Le dialecte des
Bruxellois d'origine a depuis très longtemps été un mélange de néerlandais
et français. Ils changent continuellement de langue aussi dans la même
phrase. A moi ça ne me plaît pas trop, mais pour eux, c'est normal.

Jo

2017-08-28 12:06 GMT+02:00 marc marc :

> Le 28. 08. 17 à 11:30, Christian Rogel a écrit :
> > En Bretagne, des quartiers entiers ont comme adresse "Hent ar (i.e.
> Chemin de) X" ou "Alez Y" (Allée Y).
> Quand tu dis qu'ils ont cette adresse, c'est basé sur quelle critère ?
> sur la plaque de rue avec le nom en français ?
> ou c'est leur adresse officielle tel que présente
> sur leur feuille d’impôt ?
> parce qu'il y a peut-être 70 dialectes en France mais je doute
> que beaucoup d'entre eux aie une utilisation "officielle".
> En tout cas aucun des 4 dialectes utilisés dans ma famille.
> c'est même le propre d'un dialecte que d'être différent de
> la langue officielle crée pour permettre à un toulousain
> de pouvoir communiquer avec un breton.
> On en perd d'ailleurs un peu l'objectif d'une carte.
> Avant d'avoir une carte en dialecte, ce serrait utile d'avoir
> une carte tout court, avec 100% des routes et adresses.
>
> > Pour mettre les points sur les i, Paris est en celtiqueje pense que ce
> genre de point sur les i n'a aucune importance.
> Paris est un mot entré dans le langage français.
> peu importe son origine, vu que la lange officielle et
> des panneaux à Paris est le français, il est utilisé dans name
> De la même manière, à Bruxelles, name ne contient PAS les noms
> en bruxellois.
> J'aime d'ailleurs en ce sens le compromis à la Belge :
> personne n'est content mais au moins il y une situation à l'équilibre.
> et on peux passer à autre chose qu'argumenter à chaque fois
> que le cas se représente.
> Un changement unilatéral est même la-bas considéré comme du vandalisme.
> ___
> 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] quadruple no 46 à Rennes

[marc marc]

Bonjour Maël,

Merci pour cette analyse.
Il y a donc eu un problème à l'import parce que les lettres
n'ont pas été importée.
Je vous laisse corriger les 3 autres ?
Potentielement il faudra vérifier/corriger toutes les occurences.

Cordialement,
Marc

Le 28. 08. 17 à 10:05, REBOUX Maël a écrit :
> Bonjour Marc.
> 
> Tout est normal : il y 4 adresses à cet endroit :
> 
> 46 A
> 
> 46 B
> 
> 46 C
> 
> 46 D
> 
> https://data.rennesmetropole.fr/explore/dataset/adresses-du-referentiel-voies-et-adresses-de-rennes-metropole/map/?location=19,48.08982,-1.63288=233af6
> 
> C’est « juste » la base OSM qui n’est pas à jour.
> 
> Cdt,
> 
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
> 
> 02 99 86 63 71
> 
> Twitter : @mael_reboux_ig 
> 
> A votre disposition :
> 
> - des *plans* *pdf de l'agglomération et de ses communes* 
> téléchargeables 
> 
>  
> et imprimables
> 
> - un *plan interactif * de Rennes Métropole
> 
> - des *données publiques ouvertes *
> 
> 
> 
> ___
> 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] contributions peut-être à revoir

[marc marc]

Le 28. 08. 17 à 11:30, Christian Rogel a écrit :
> En Bretagne, des quartiers entiers ont comme adresse "Hent ar (i.e. Chemin 
> de) X" ou "Alez Y" (Allée Y).
Quand tu dis qu'ils ont cette adresse, c'est basé sur quelle critère ?
sur la plaque de rue avec le nom en français ?
ou c'est leur adresse officielle tel que présente
sur leur feuille d’impôt ?
parce qu'il y a peut-être 70 dialectes en France mais je doute
que beaucoup d'entre eux aie une utilisation "officielle".
En tout cas aucun des 4 dialectes utilisés dans ma famille.
c'est même le propre d'un dialecte que d'être différent de
la langue officielle crée pour permettre à un toulousain
de pouvoir communiquer avec un breton.
On en perd d'ailleurs un peu l'objectif d'une carte.
Avant d'avoir une carte en dialecte, ce serrait utile d'avoir
une carte tout court, avec 100% des routes et adresses.

> Pour mettre les points sur les i, Paris est en celtiqueje pense que ce genre 
> de point sur les i n'a aucune importance.
Paris est un mot entré dans le langage français.
peu importe son origine, vu que la lange officielle et
des panneaux à Paris est le français, il est utilisé dans name
De la même manière, à Bruxelles, name ne contient PAS les noms
en bruxellois.
J'aime d'ailleurs en ce sens le compromis à la Belge :
personne n'est content mais au moins il y une situation à l'équilibre.
et on peux passer à autre chose qu'argumenter à chaque fois
que le cas se représente.
Un changement unilatéral est même la-bas considéré comme du vandalisme.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] contributions peut-être à revoir

[Christian Rogel]

> Le 28 août 2017 à 07:53, Bruno  a écrit :
> 
> Le 27/08/2017 à 22:05, Christian Rogel a écrit :
>>> Le 27 août 2017 à 17:04, Bruno  a écrit :
>> En gros, il y a un conflit théorique entre deux sources de légitimité : ce 
>> qu'on voit et ce que l'autorité compétente a voulu signifier.
> 
> Pour moi aucune complexité,
> Il me semble que l'on voit sur la plaque le nom d'une rue dans deux langues  
> , il n'y a pas de conflit.
> Le champ name contient le nom dans une langue , et name:xx dans une autre, 
> c'est fait pour ça.

C'est pourtant contraire à un principe cardinal d'OSM : représenter ce qu'il 
sur le terrain.
L'exemple bruxellois montre qu'on peut faire autrement tout en donnant leur 
place aux suffixes de langue.
Même si un nombre infinitésimal de communes a choisi de placer les deux noms  
sur un même niveau juridique, l'effacer dans la représentation du terrain est 
une voie de fait, puisque c'est nier la décision d'un corps élu.

> Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un ou 
> l'autre champ , mais en France il n'y a pas d'ambiguité, pas de bilinguisme 
> en métropole.


Là, tu introduis un argument non plus technique, mais politique, donc 
renversable par nature. Pas de question de bilinguisme en jeu, il suffirait que 
le Parlement prescrive qu'aucun élément d'une plaque de rue ne soit laissé de 
côté.

Christian R.

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 28. 08. 17 à 08:39, François Lacombe a écrit :

> > Viking émet l'idée intéressante que les usages de capacity:* donnent  
> des volumes statiques (des places de parking, de banc, ...) et 
> qu'il faudrait plutôt adopter une clé qui donne un volume variable 
> dans le temps (des m3/s, m3/h, l/min...).
Je trouve que ce n'est pas exact.
capacity indique le maximum possible pour une infrastructure.
le chiffre indiqué sur une borne incendie n'est pas son débit
variable dans le temps (celui là ne dépend que du pompier)
mais le débit maximum dont la borne est capable.

On fait quoi pour la séparation pressurisé <> non pressurisé ?
j'argumente une dernière fois avec le fait que 10% des bornes françaises 
vont se trouver dans un état indéterminée pas d'info pour les classer ?
et surtout quid à l'avenir du gars qui rencontre une borne
sans plaque de pression... il doit choisir l'une des 2 catégories,

 > attends tu l'avis Bhynoteam ?
 >
 > Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait
 > rédigé en 2015
 > https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655
J'ai lu son document.
ä un endroit il dit qu'il n'est pas pour type=pond
ä un autre il propose l'ajout de type=dry_hydrant qui n'est
cependant pas en jaune comme le reste des nouveauté proposé.
je ne sais pas si l'un est un remplacement de l'autre.
En fin de pdf, il utilise donne des exemples de bornes sans pression :
emergency = fire_hydrant
fire_hydrant:type = pillar
fire_hydrant:pressure = suction
Donc j'en déduit que selon lui, il faudrait aussi supprimer le "pond" 
mais que le critère d'uneborne n'est pas la pression
il ne compte pas participer au débat ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] contributions peut-être à revoir

[Christian Rogel]

> Le 28 août 2017 à 08:42, Alain VASSAULT  
> a écrit :
> 
> Même si je ne suis pas concerné dans mon secteur (du moins je crois ^^) et 
> que je ne me suis pas penché sur le wiki j'aurai tagger ainsi personnellement 
> :
> name="nom en langue officielle, français"
> name:xx="nom dans la langue spécifiée hors langue officielle"
> alt_name="nom secondaire ajouté"
> note:name="annotations dans le nom de la rue sans être un nom alternatifs"
> 
> Il me semble avoir compris que le name en France implique automatiquement un 
> name:fr-FR si lu depuis un autre pays. Idem dans les autres pays avec leur 
> langue Local officielle.

Justement, il y a un petit point que tu n'as pas saisi : le "name" peut être 
intégralement dans l'une des 70 langues parlées dans la République française.
En Bretagne, des quartiers entiers ont comme adresse "Hent ar (i.e. Chemin de) 
X" ou "Alez Y" (Allée Y).
C'est pourquoi j'ajoute au "name:br" "source:name:br= copied from name", valeur 
dont je suis l'initiateur, lorsque le nom en breton ne figure pas en doublon 
sur la plaque (rassure-toi, c'est toujours le cas).

Donc, on ne peut pas écrire comme tu l'as fait : name="nom en langue 
officielle, français".

Principe simple : Aucun nom de lieu n'a de forme "française" officielle, il ne 
s'agit que d'usage historique et l'hétérogénéité linguistique est le constat 
courant.
Pour mettre les points sur les i, Paris est en celtique (ou pré-celtique), 
Marseille, en grec et la rue de la Guadeloupe du franco-espagnol.

Christian R.

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

Re: [OSM-talk-fr] quadruple no 46 à Rennes

[REBOUX Maël]

Bonjour Marc.

Tout est normal : il y 4 adresses à cet endroit :
46 A
46 B
46 C
46 D

https://data.rennesmetropole.fr/explore/dataset/adresses-du-referentiel-voies-et-adresses-de-rennes-metropole/map/?location=19,48.08982,-1.63288=233af6

C'est « juste » la base OSM qui n'est pas à jour.

Cdt,

Maël REBOUX
Service Information Géographique Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
Twitter : @mael_reboux_ig

A votre disposition :
-   des plans pdf de l'agglomération et de ses communes 
téléchargeables
 et imprimables
-   un plan interactif de Rennes 
Métropole
-   des données publiques ouvertes

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

Re: [OSM-talk-fr] contributions peut-être à revoir

[Alain VASSAULT]

Même si je ne suis pas concerné dans mon secteur (du moins je crois ^^) et que 
je ne me suis pas penché sur le wiki j'aurai tagger ainsi personnellement :
   name="nom en langue officielle, français"
   name:xx="nom dans la langue spécifiée hors langue officielle"
   alt_name="nom secondaire ajouté"
   note:name="annotations dans le nom de la rue sans être un nom 
alternatifs"

Il me semble avoir compris que le name en France implique automatiquement un 
name:fr-FR si lu depuis un autre pays. Idem dans les autres pays avec leur 
langue Local officielle.


Le 28 août 2017 07:53:27 GMT+02:00, Bruno  a écrit :
>Le 27/08/2017 à 22:05, Christian Rogel a écrit :
>>> Le 27 août 2017 à 17:04, Bruno  a écrit :
>>>
>>> Je me réponds moi-même :
>>>
>>> Dans le wiki il faudrait peut-être préciser que en cas de désaccord
>sur un nom on peut se référer aux plaques de rues pour vérifier les
>champs name ou name:xx pour celles qui sont multilingues.
>>>
>>> En aucun cas le wiki ne devrait laisser penser que l'on doit remplir
>le champs name avec la totalité de ce qu'indique la plaque..
>>> Bref la plaque indique un nom en Français, officiel (name), et un
>nom dans une autre langue(name:xx)
>> Pour moi, la question est légèrement plus complexe.
>> En gros, il y a un conflit théorique entre deux sources de légitimité
>: ce qu'on voit et ce que l'autorité compétente a voulu signifier.
>> Éliminons un sujet adventice : les noms dont l'Etat s'estime
>responsable, via l'INSEE (entités administratives + gros écarts
>habités) et doivent obligatoirement être mis seuls dans le "name".
>> Pour les noms, dont sont responsables les communes, on peut
>s'interroger :
>> 1 On se fie au wiki OSM qui ne prévoit des "alternatives" que si on
>est en zone disputée.
>> Il ne me semble pas que cela s'applique à la RF (démentez-moi, ça me
>fera plaisir ;-) )
>> 2 On recopie ce qu'on voit sur le terrain
>> Come je l'ai souvent dit, il y a deux types d'arrêtés municipaux de
>nommage : l'immense majorité qui ne légifère que sur le rajout d'un (ou
>deux) nom  sur les plaques, sans mettre en cause la primauté légale du
>premier nom et l'extrême minorité qui met deux noms sur un même plan.
>> Je n'en connais qu'un cas.
>> Si on applique le 2, on peut n'être pas raccord avec les intentions
>de l'autorité légale.
>> En fait, notre occitaniste, s'il a connaissance d'un décision de
>bilinguisme total pour les noms de voie et les noms de hameau, pourrait
>avoir raison.
>> Pour les noms de commune et de gros hameaux répertoriés par l'Etat,
>il aurait toujours tort.
>>
>> Christian R.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>Pour moi aucune complexité,
>
>Il me semble que l'on voit sur la plaque le nom d'une rue dans deux 
>langues  , il n'y a pas de conflit.
>
>Le champ name contient le nom dans une langue , et name:xx dans une 
>autre, c'est fait pour ça.
>
>Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un
>
>ou l'autre champ , mais en France il n'y a pas d'ambiguité, pas de 
>bilinguisme en métropole.
>
>Bruno
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Hello,

Viking émet l'idée intéressante que les usages de capacity:* donnent des
volumes statiques (des places de parking, de banc, ...) et qu'il faudrait
plutôt adopter une clé qui donne un volume variable dans le temps (des
m3/s, m3/h, l/min...).

Ainsi je pense à la clé rating=* qui est utilisée pour l'instant sur les
transfos électriques, pour donner la quantité d'énergie qui peut les
traverser.
Vu qu'une proposition est en cours sur les transfos électriques, et que la
clé rating est utilisée moins de 10 000 fois, il serait plus ou moins
facile de la remplacer par rating:intensity. Nous pourrions introduire
ensuite rating:water pour tout ce qui fait transiter de l'eau.

Ca donnerait deux clés bien génériques, capacity pour les volumes (il
faudra penser à éviter volume=* pour les cuves de fluides du coup) et
rating=* pour les flux.


J'attends son retour sur cette proposition

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 24 août 2017 à 11:54, François Lacombe  a
écrit :

>
> Le 23 août 2017 à 23:29, marc marc  a écrit :
>
>>
>> oui, comme je disais : vas-y ! ou attends tu l'avis Bhynoteam ?
>>
> C'est envoyé : https://wiki.openstreetmap.org/wiki/Talk:Proposed_
> features/Fire_Hydrant_Extensions#Flow_and_pipes_capacity
>
> Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait rédigé
> en 2015
> https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655
>
> Il y a certains points en commun avec la proposition... d'autres un peu
> moins.
>
>
>> et c'est là que emporté par le mouvement, tu vas rajouter une modif du
>> tag pression parce que lui aussi n’aucune raison d'être préfixé.
>> pressure sur une borne, c'est aussi précis que fire_hydrant:pressure
>>
>
> +1 Il faudrait que j'ajoute également un sujet sur la suppression des
> namespaces.
>
> François
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr