Re: [OSM-talk-fr] Wiki OSM : fusion des catégories FR:Randonnée et FR:Marche à pied

2017-11-20 Par sujet Jean-Christophe Becquet 
Bonjour,

Je comprends les arguments de Christian R. et Philippe donc je ne touche
pas aux catégories FR:Randonnée et FR:Marche à pied :

 https://wiki.openstreetmap.org/wiki/Category:FR:Randonn%C3%A9e
https://wiki.openstreetmap.org/wiki/Category:Hiking en anglais

 https://wiki.openstreetmap.org/wiki/Category:FR:Marche_%C3%A0_pied
https://wiki.openstreetmap.org/wiki/Category:Walking en anglais

Bonne journée

JCB
-- 
La suite bureautique Libreoffice
http://www.apitux.org/index.php?2006/07/11/3-la-suite-bureautique-libreoffice

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

2017-11-20 Par sujet François Lacombe 
Bonsoir à tous

Le 20 novembre 2017 à 18:11, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Pour la précision, FVig n’a contribué que sur le Pays de Brest (87
> communes sur 283 avant loi Notre), soit le quart NO du département.
>

Pour la double précision, il s'agit du SIGiste de Brest Métropole Océane
avec qui j'avais pu discuter lorsque j'étais dans la région.

Sur le reste, mon désaccord persiste pour les raisons évoquées.
On devrait d'ailleurs migrer ref:mhs en ref:FR:MHS, pour éviter que nos
monuments historiques soient pris pour des hôpitaux militaires américains
Je suis déjà parti en courant ;)


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

2017-11-20 Par sujet osm . sanspourriel 
Il y a aussi les remarques faites à oc-escorpion : https://www.openstreetmap.org/changeset/51312940

Que a répondu dans une langue que je ne parle pas (je comprends qu'il voulait que le nom en occitan soit visible de tous) mais qui a cessé de contribuer sous ce pseudo.

D'où l'impression de l'avoir dit depuis longtemps.

 

Jean-Yvon

 
 

Gesendet: Freitag, 17. November 2017 um 08:21 Uhr
Von: "Christian Quest - cqu...@openstreetmap.fr" 
An: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales



Si je comprends bien:

- ça fait des mois qu'on discute des contributions de cet utilisateur

- il n'y a eu que 2 changeset commentés il y a quelques jours seulement

- il y a eu plein de revert de faits

 

autre chose ? Des échanges de messages directs ?

 

C'est quand même light, non ?
 

 


 
Le 17 novembre 2017 à 04:42, Francois Gouget  a écrit :

On Thu, 16 Nov 2017, marc marc wrote:
[...]
> Du coup je comprend pas la suite de ton message.
> D'un côté tu as l'air de dire qu'on aurait du faire la procédure
> DWG + tôt (je partage ton avis), de l'autre tu as l'air de dire
> que la première étape (communiquer) est facultative.

J'ai l'impression que cet utilisateur a été largement prévenu, même si
ce n'est peut-être pas de la façon prévue par la procédure officielle.
Avec en plus le flou qui reigne on obtient cette position contradictoire
au premier abord.


> Ajouter des outils pour détecter ou rapporter ce genre de problème
> ne sert à rien si lorsqu'il est détecté, personne ne veux
> lancer la procédure nécessaire pendant des mois...

Problème de dilution des responsabilités ?

Si je comprend bien personne n'est chargé de s'occuper de ces cas là et
donc tout le monde espère que quelqu'un d'autre va s'y coller (ce qui
est bien compréhensible). Désigner à l'avance une personne à contacter
qui va coordonner / gérer ces cas pourrait faire partie des
'améliorations' dont je supputais l'existence.


--
Francois Gouget               http://fgouget.free.fr/
                  A black hole is just God dividing by zero.
___
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] [osm-grenoble] Importation des arbres municipaux de Grenoble

2017-11-20 Par sujet marc marc 
Bonsoir,

> contre le fait d'importer des tag ref dans tous les sens :
> - 4 tags ref:xxx:yyy, source:date, source, etc

Juste pour re préciser, j'ai jamais parler de plein de tag sur les objets. 
Source date etc ont leur place sur le changeset.

Pour la ref, SI il y a un usage, cela me semble utile (par exemple pour faire 
remonter les modifs osm vers la source).
Mais d'expérience, cela n'arrive pas, Voila pourquoi je le trouvais inutile. 
Mais quelqu'un d'autre semblait y voir une utilité. Pas convaincu qu'une ref 
effraye un contributeur (mais par contre pas sûr que cette ref reste pertinente 
en cas de correction de localisation).

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

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

2017-11-20 Par sujet JB 

Le 19/11/2017 à 14:46, Jérôme Villafruela a écrit :

Je pense qu'il faudrait ajouter le tag ref (champ BIEN_REFERENCE) :
Mon avis doit commencer à être minoritaire par ici, mais j'en profite 
pour le rappeler : contre le fait d'importer des tag ref dans tous les 
sens :
 - ça effraie le nouveau contributeur : si un objet a un tag 
natural=tree, il n'hésitera pas à le modifier. Vous ajoutez 4 tags 
ref:xxx:yyy, source:date, source, etc…, il y réfléchira à trois fois 
avant d'y toucher.
 - si vous n'êtes pas capable de faire une repasse sur ces objets sans 
ce tag ref, est-ce que l'import était vraiment justifié ? Qualité, 
nécessité ?

JB.

PS : et pour vous dire, même moi après plusieurs années, j'hésite 
toujours à toucher à ces objets multiréférencés. Ça veut dire qu'une 
passe algorithmique est possible et qu'on aura d'autant plus de facilité 
à me tomber dessus si je fais une boulette ou ce que quelqu'un estime 
être une boulette. (Du genre : « bordel, j'ai bien indiqué que c'était 
un chemin/track lors de l'import, c'est vérifiable dans le fichier 
d'origine, alors pourquoi tu l'as passé en sentier ? »).



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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

2017-11-20 Par sujet Christian Rogel 

> 
> Le 20 novembre 2017 à 00:43, Philippe Verdy  > a écrit :
> 
> 
> Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en 
> 2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec 
> comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre qui 
> sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout depuis en 
> ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le 
> ref:FR:INSEE et resté.
> 
> A mettre à jour... en ref:FR:FANTOIR=ref:FR:INSEE+ref:FR:fantoir et supprimer 
> les ref:FR:INSEE et ref:FR:fantoir
>  

Pour la précision, FVig n’a contribué que sur le Pays de Brest (87 communes sur 
283 avant loi Notre), soit le quart NO du département.

Christian R.

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

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

2017-11-20 Par sujet Philippe Verdy 
Le 20 novembre 2017 à 08:12, Christian Quest  a
écrit :

> genus + species ?
>
> Le wiki indique que genus=* est inutile si on renseigne species=*
>
> "The biological classification system is hierarchical. You should use the
> most specific taxon that you know, but there is no need to tag all the
> implicit taxonomic ranks as well. E.g. if you already have tagged a species
> you won't tag the genus as well." (https://wiki.openstreetmap.
> org/wiki/Key:species)
>

C'est à moitié vrai car les reclassifications de genres sont monnaies
courantes et des tas d'espèces conservent leur ancien nom binomial même si
un nouveau nom utilisant le nouveau genre est défini. La taxonomie est un
gros chantier en constante évolution et il y a conflit entre la taxonomie
classique et pluseurs classifications phylogénbétiques qui changent sans
arrêt ou ne sont pas pleinement confirmées (sans compter les cas nombreux
de croisements génétiques au delà des barrières d'espèces conduisant à des
hybrides viables dont il est difficile de déterminer quel est le taxon
parent qud il y en a deux ou plus (rien qu'une cellule animale quelconque
contient plusieurs codes génétiques pour des espèces historiques autrefois
parasitaires et devenues endosymbiotiques et qui ne survivraient plus hors
de leur hôte qui lui non plus ne survivrait pas sans leur "parasite", ce
qui est le cas de tous les animaux).
La classification "phylogénétique" se voudrait purement hiérarchique mais
elle ne cesse d'ajouter des niveaux intermédiaires (et bon nombre ne sont
que des hypothèses car on ne connait pas tout le vivant).
Bref comme il faut bien des points de repère, on a des taxons de genres
clés en classification classique dont on devrait affubler toutes les
espèces, sous-espèces, variétés et cultivars.

Mais concernant les plantations humaines (nos arbres) on a des situations
bien plus complexes aujourd'hui à cause des manipulations génétiques et des
hybrides de plus en plus fréquents (pas toujours viables car inféconds) et
qui n'entrent pas du tout dans le moule de la taxonomie classique. Bref de
nouveaux noms apparaissent qui sont des pseudo-espèces d'un ou plusieurs
genres, et le genre est remplacé par un nom déposé d'hybride. Si on lit un
peu les documents on voit des tonnes de renvois d'un genre à l'autre et des
noms multiples pour une même "espèce" dont le genre est incertain, mais un
nom fait référence en agriculture et n'est pas toujours le taxon
phylogénétique. Il se conserve comme il est même si un nouveau nom
systématique lui a été attribué (qui changera encore quand les recherches
génétiques avanceront...) et qui a déjà changé souvent plusieurs fois en
classification classique.

On ne peut pas demander aux mappeurs de connaitre les détails de ces
recherches: tout le monde utilise les noms visibles dans les offres
commerciales et échanges sylvicoles et si on demande à une municipalité
quels arbres elle a planté, son service technique se fiera aux étiquettes
des vendeurs ou aux indications de leurs cultivateurs de plants...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

2017-11-20 Par sujet Christian Quest 
Le 20 novembre 2017 à 16:35, Jérôme Amagat  a
écrit :

>
>
> Le 20 novembre 2017 à 00:43, Philippe Verdy  a écrit :
>
>>
>>
>> Le 19 novembre 2017 à 14:32, marc marc  a
>> écrit :
>>
>>> @Vincent @Philippe et donc que proposez-vous concrètement ?
>>> Parce que changer une clef majoritaire qui 'a pas de collision pour une
>>> autre clef qui n'évite pas non plus la collision mais qui ne fait que la
>>> diminuer, c'est un travail de titan pour un gain... très théorique.
>>> Et surtout, faut que quelqu'un s'y mette.
>>
>>
>> Pourtant il faudra bien s'y mettre  car les deux sont très peuplées.
>> Alors modifier +1 ou +7 clés c'est tout de même une modification de
>> masse, autant le faire une fois dans le bon sens...
>> De toute façon des outils sont déjà impactés par l'existence des deux
>> clés, on cassera forcément l'un au détriment de l'autre, mais je ne vois
>> aucun intérêt de garder les deux, ce qui ne rend service à personne !
>>
>
> Pour ref:FR:INSEE, je vient de regarder, il y en a :
> - sur des lieu dit dans le Finistère : + de 1
> - sur des relation associatedStreet autour de Bordeaux : une 60ene
> - une dizaine d'autres
>
> Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en
> 2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec
> comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre
> qui sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout
> depuis en ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le
> ref:FR:INSEE et resté.
>

A mettre à jour... en ref:FR:FANTOIR=ref:FR:INSEE+ref:FR:fantoir et
supprimer les ref:FR:INSEE et ref:FR:fantoir


> Pour Bordeaux, ça représente une toute petite partie des relation
> associatedStreet des différentes communes et je ne vois pas a quoi ça sert.
>

A rien... juste à apporter de la confusion... donc pour moi c'est à
supprimer.



> Après tout ça, il ne reste pas grands chose...
>
> D’après moi, tous les ref:FR:INSEE doivent disparaissent...
>
>
+1 ce sont des résidus d'imports incorrects, ils n'auraient jamais dû
exister.


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

2017-11-20 Par sujet Christian Quest 
Et si... il manque le trait d'union.

J'ai envoyé un message à la pref pour qu'ils publient un arrêté
rectificatif... et lien vers la circulaire de la DGCL à ce sujet:
http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf

Le 20 novembre 2017 à 16:17, Jérôme Amagat  a
écrit :

>
>
> Le 19 novembre 2017 à 16:04, Christian Quest  a
> écrit :
>
>> Le 18/11/2017 à 19:20, Jérôme Amagat a écrit :
>>
>>
>>
>> Le 18 novembre 2017 à 18:45, Christian Quest  a
>> écrit :
>>
>>> La règle de toponymie pour les noms officiels est simple...
>>>
>>> Pas d'espace, uniquement des traits d'union, sauf pour l'espace qui suit
>>> l'article en début de nom, exemple:
>>>
>>> La Celle-Saint-Cloud
>>>
>>> La règle est simple... oui mais n'a pas toujours été respecté lors des
>> créations de communes nouvelles ces dernières années. Dans les décision des
>> conseils municipaux et dans les arrêtés préfectoraux il n'y a des espaces
>> donc des communes ont un nom officiel officiel qui ne respectent pas cette
>> règle.
>>
>>
>> Je sais, j'ai même saisit la commission nationale de toponymie sur le
>> sujet et en principe les rectificatifs sont en cours car ces noms sont des
>> erreurs.
>>
>> Autant mettre les noms corrects dans OSM, il me semble que la règle de
>> toponymie est à privilégier pour cohérence.
>> Les préfectures n'ont pas fait leur boulot, l'INSEE non plus, c'est à
>> dire signaler au plus tôt que les noms étaient incorrects et devaient être
>> rectifiés.
>>
>>
>>> Pour Saint-Ours, on a une différence entre le nom sur le noeud place=*
>>> et la relation. Il y a d'autres cas comme cela, je n'y ai pas touché.
>>>
>>> Ceci dit, la regex n'est peut être pas parfaite et améliorable !
>>>
>>>
>> J'ai fait une modification pour Château-Chinon. il y a 2 communes
>> Château-Chinon (ville) et Château-Chinon (Campagne) et il y avait 2 node
>> pour 2 place=village que j'ai fusionné et changé le nom en
>> "Château-Chinon". Les 2 communes ont leur mairie très proche dans la
>> ville avec la mairie de Château-Chinon (Campagne) hors de sa commune. Il me
>> semble logique de faire ce changement : il y a 2 communes mais il n'y a
>> qu'un village (place=village) qui est admin_centre des 2 communes.
>>
>> Christian,
>> Dans le rendu fr il n'y a plus les noms des communes quand il est
>> différent du nom de l'admin_centre pourquoi l'avoir enlevé, je trouvais ça
>> bien.
>>
>>
>>
>> Je ne crois pas que la requête vérifie si le nom est différent. De
>> mémoire, elle ne vérifie que la présence d'un admin_centre. Je peux
>> l'améliorer...
>>
>
> Je pensais que c’était lié aux noms...
> Donc si des noms de communes apparaissaient c'est parce que les communes
> nouvelles n'avait pas encore d'admin_centre dans leur relation et
> maintenant que la plupart l'on ça n’apparaît plus...
> ça doit être beaucoup plus compliqué de comparer les noms des commune et
> admin_centre...
>
> Il y a beaucoup moins de communes nouvelles prévu pour le 1er janvier 2018
> que les années précédentes d’après wikipedia :
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_créées_en_2018
> Il y avait une incitation financière qui n'existe plus il me semble.
> Par contre je vois dans la liste "Val d'Épy", il ne manquerait pas un
> tiret :)
>
>
>> --
>> 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
>
>


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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

2017-11-20 Par sujet Jérôme Amagat 
Le 20 novembre 2017 à 00:43, Philippe Verdy  a écrit :

>
>
> Le 19 novembre 2017 à 14:32, marc marc  a
> écrit :
>
>> @Vincent @Philippe et donc que proposez-vous concrètement ?
>> Parce que changer une clef majoritaire qui 'a pas de collision pour une
>> autre clef qui n'évite pas non plus la collision mais qui ne fait que la
>> diminuer, c'est un travail de titan pour un gain... très théorique.
>> Et surtout, faut que quelqu'un s'y mette.
>
>
> Pourtant il faudra bien s'y mettre  car les deux sont très peuplées. Alors
> modifier +1 ou +7 clés c'est tout de même une modification de
> masse, autant le faire une fois dans le bon sens...
> De toute façon des outils sont déjà impactés par l'existence des deux
> clés, on cassera forcément l'un au détriment de l'autre, mais je ne vois
> aucun intérêt de garder les deux, ce qui ne rend service à personne !
>

Pour ref:FR:INSEE, je vient de regarder, il y en a :
- sur des lieu dit dans le Finistère : + de 1
- sur des relation associatedStreet autour de Bordeaux : une 60ene
- une dizaine d'autres

Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en
2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec
comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre
qui sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout
depuis en ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le
ref:FR:INSEE et resté.
Pour Bordeaux, ça représente une toute petite partie des relation
associatedStreet des différentes communes et je ne vois pas a quoi ça sert.
Après tout ça, il ne reste pas grands chose...

D’après moi, tous les ref:FR:INSEE doivent disparaissent...


> ___
> 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] Utilisation du tag 'name' avec les langues régionales

2017-11-20 Par sujet Jérôme Amagat 
Le 19 novembre 2017 à 16:04, Christian Quest  a
écrit :

> Le 18/11/2017 à 19:20, Jérôme Amagat a écrit :
>
>
>
> Le 18 novembre 2017 à 18:45, Christian Quest  a
> écrit :
>
>> La règle de toponymie pour les noms officiels est simple...
>>
>> Pas d'espace, uniquement des traits d'union, sauf pour l'espace qui suit
>> l'article en début de nom, exemple:
>>
>> La Celle-Saint-Cloud
>>
>> La règle est simple... oui mais n'a pas toujours été respecté lors des
> créations de communes nouvelles ces dernières années. Dans les décision des
> conseils municipaux et dans les arrêtés préfectoraux il n'y a des espaces
> donc des communes ont un nom officiel officiel qui ne respectent pas cette
> règle.
>
>
> Je sais, j'ai même saisit la commission nationale de toponymie sur le
> sujet et en principe les rectificatifs sont en cours car ces noms sont des
> erreurs.
>
> Autant mettre les noms corrects dans OSM, il me semble que la règle de
> toponymie est à privilégier pour cohérence.
> Les préfectures n'ont pas fait leur boulot, l'INSEE non plus, c'est à dire
> signaler au plus tôt que les noms étaient incorrects et devaient être
> rectifiés.
>
>
>> Pour Saint-Ours, on a une différence entre le nom sur le noeud place=* et
>> la relation. Il y a d'autres cas comme cela, je n'y ai pas touché.
>>
>> Ceci dit, la regex n'est peut être pas parfaite et améliorable !
>>
>>
> J'ai fait une modification pour Château-Chinon. il y a 2 communes
> Château-Chinon (ville) et Château-Chinon (Campagne) et il y avait 2 node
> pour 2 place=village que j'ai fusionné et changé le nom en
> "Château-Chinon". Les 2 communes ont leur mairie très proche dans la ville
> avec la mairie de Château-Chinon (Campagne) hors de sa commune. Il me
> semble logique de faire ce changement : il y a 2 communes mais il n'y a
> qu'un village (place=village) qui est admin_centre des 2 communes.
>
> Christian,
> Dans le rendu fr il n'y a plus les noms des communes quand il est
> différent du nom de l'admin_centre pourquoi l'avoir enlevé, je trouvais ça
> bien.
>
>
>
> Je ne crois pas que la requête vérifie si le nom est différent. De
> mémoire, elle ne vérifie que la présence d'un admin_centre. Je peux
> l'améliorer...
>

Je pensais que c’était lié aux noms...
Donc si des noms de communes apparaissaient c'est parce que les communes
nouvelles n'avait pas encore d'admin_centre dans leur relation et
maintenant que la plupart l'on ça n’apparaît plus...
ça doit être beaucoup plus compliqué de comparer les noms des commune et
admin_centre...

Il y a beaucoup moins de communes nouvelles prévu pour le 1er janvier 2018
que les années précédentes d’après wikipedia :
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_créées_en_2018
Il y avait une incitation financière qui n'existe plus il me semble.
Par contre je vois dans la liste "Val d'Épy", il ne manquerait pas un tiret
:)


> --
> 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] Stats serveurs de tuiles OSM-FR...

2017-11-20 Par sujet Philippe Verdy 
On peut voir que le réseau Mondial Relay consomme à lui tout seul pas mal
de bande passante pour localiser ses points de livraison colis via les
sites marchands.
Idem pour rail.cc.

Il faudrait peut-être voir à les informer qu'on ne peut pas assurer la
qualité de bande passante et de temps de réponse, et qu'ils devraient
utiliser leur propre proxy cache sur pour leur réseau s'ils ne veulent pas
monter leur serveur de tuiles. Ca leur coûterait tellement cher de mettre
un ou deux serveurs Squid pour leur service je ne sais pas si au passage
ils ne participent pas au financement à hauteur du service qu'ils en
attendent, ce qui serait aussi une alternative pour permettre de monter
plus de redondance et de qualité de service pour tous) ?

Je ne sais pas si on peut limiter l'usage par "referer" à une limite
raisonnable. Mais là je pense que les deux sites font trop confiance à
cette ressources gratuite. S'ils ne veulent pas payer d'abonnement chez
Google ou MapBox, un serveur Squid est tout de même le minimum qu'on peut
leur demander (et qui leur assurera aussi un bon temps de réponse, surtout
que leur réseau ne couvre pas tant de territoire que ça, et qu'ils n'ont
pas forcément besoin de zoomer sur toute la planète mais uniquement sur les
points de livraison (ils peuvent désactiver le zoom/panning dynamique et
mettre quelques tuiles basse résolution et des tuiles uniquement dans les
zones couvertes et permettant de distinguer les points de livraison très
locaux).

Pour rail.cc, comme ils demandent à faire des itinéraires, ce sont en
général des grandes distances et les niveaux de zoom élevés ne sont pas
forcément essentiels.

Mais dans les deux cas un proxy cache transparent soulagerait notre service
même si au passage ils participent au financement (matériels à ajouter,
maintenance, frais d'exploitation divers: domaines, certificats, frais de
location et d'accès aux espaces de colocations, factures d'énergie,
sécurité, frais administratifs, participation aux frais de communication,
frais de campagne et de promotion, frais de déplacements...).


Le 19 novembre 2017 à 21:25, Christian Quest  a
écrit :

> J'ai généré des statistiques sur l'usage de 2 serveurs de tuiles maintenus
> par OSM-France depuis le mois de janvier.
>
> Il s'agit d'osm13 et osm25 qui s'occupent principalement des tuiles HOT et
> FR.
>
> Ces stats sont celles du cache de tuiles, qui est hébergé à Lyon par
> Rezopole pour OSM-France (ne pas confondre avec le cache de tuiles pour
> osm.org hébergé aussi par Rezopole à Lyon). L'avantage de Rezopole est
> que ce cache est situé physiquement sur un noeud d'interconnexion, ce qui
> réduit les temps d'accès depuis de nombreux opérateurs et fait aussi que la
> bande passante a un coût nul.
>
> Donc depuis janvier, ce cache a distribué plus de 2,5 milliards de tuiles,
> ce qui représente plus de 38To de données utiles.
> Record le 6 octobre dernier avec 23.8M de tuiles dans la journée !
>
> Les tuiles les plus demandées sont celle du zoom 15 HOT, puis du zoom 18
> FR.
>
> uMap génère 17% des demandes, puis 10.7% pour osm.org (qui permet
> d'afficher le rendu HOT).
>
>
> Le détail est sur http://osm13.openstreetmap.fr/~cquest/report.html
>
> Je vais ajouter une mise à jour si possible quotidienne... et oui, il
> manque quelques jours de stats (disque plein car les logs sont
> volumineux... mais maintenant c'est réglé).
>
> --
> 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] Erreur de limite admin sur l'ile de la réunion ?

2017-11-20 Par sujet Jérôme Amagat 
Ces quartiers sont ils seulement des noms de 'lieux dit", des noms utilisés
dans les adresses ou par la population ou alors la mairie s'en sert pour
des conseil de quartier ou autre chose du même genre qui aurait un certain
pouvoir sur leur quartier, avis ou décision?
Si c'est juste des noms de lieu je ne crois pas qu'il faille utiliser des
relation type=boundary boundary=administrative admin_level=10 mais
seulement un place=* sur une relation type multipolygone si les frontières
sont claires ou sur un node. dans ce cas, la "hiérarchie" des quartiers
peut apparaître dans le place=* avec place=suburb plus grand que
place=quarter.
SI il y a des "conseil de quartier", je ne pense pas qu'il faut modifié les
relations qui existent a part peut être enlever les place=* dans les
relation et les mettre sur des node en plus des relations.

Il faudrait peut être prendre contact avec la personne qui a créé ces
relations pour savoir d'où elles arrivent. d’après l'historique des
relations c'est https://www.openstreetmap.org/user/arnaud_mapali qui semble
encore contribuer régulièrement (mais ne doit pas lire cette liste).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur de limite admin sur l'ile de la réunion ?

2017-11-20 Par sujet Stéphane Péneau 
Ma "source" locale m'indique que "La Bretagne" fait bien partie du 
quartier Sainte-Clotilde.


Sauf avis contraire, je ferai la modif bientôt.

Stf

Le 17/11/2017 à 22:36, PanierAvide a écrit :

Bonsoir,

Il semblerait, de source locale, que ce soit bien le cas. La résidence 
ici [1] comporte dans son adresse postale la mention du quartier 
Sainte-Clotilde [2]. Ce serait donc vrai pour Le Moufia, et à priori 
le Chaudron. La Bretagne aucune idée.


Cordialement,

Adrien.

[1] http://www.openstreetmap.org/way/147328121
[2] http://www.crous-reunion.fr/logement/cite-louis-timagene-houat/

Le 16/11/2017 à 22:05, Stéphane Péneau a écrit :

Hello !

A priori, la limite administrative du "quartier" Sainte-Clotilde, sur 
l'ile de la Réunion, serait bien plus petite dans Osm qu'elle ne 
l'est en réalité.

http://www.openstreetmap.org/relation/3107586

Selon Wikipédia,  ce quartier en englobe d'autres, comme Le Chaudron, 
La Bretagne, Le Moufia.

https://fr.wikipedia.org/wiki/Sainte-Clotilde_(La_R%C3%A9union)

Est-ce que quelqu'un connait suffisamment la région pour m'éclairer ?

Stf


___
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] Stats serveurs de tuiles OSM-FR...

2017-11-20 Par sujet Christian Quest 
goaccess génère un fichier html (ou csv ou json) depuis les logs du serveur
http (nginx dans notre cas). Il n'est pas vraiment prévu pour requêter dans
les logs, restreindre à une période, etc.

L'avantage c'est qu'il ne dépend d'aucun autre outil, il stocke juste dans
des fichiers intermédiaire son état pour juste ajouter des logs au fil de
leur arrivée.

Pour les referer j'ai limité au domaine, histoire de regrouper par site
appelant, plutôt que par page, mais je peux regarder les logs pour avoir
la/les page(s) en question.

Dans les regroupements, j'ai aussi simplifié les URL demandées pour ne
garder que rendu/zoom et pas rendu/zoom/x/y.png


Le 20 novembre 2017 à 14:19, Vincent Frison  a
écrit :

> Effectivement c'est sexy !
>
> Je suis étonné de voir que sur 38 TB seulement 15 viendrait de la France...
>
>
> Le 20 novembre 2017 à 13:38, sly (sylvain letuffe)  a
> écrit :
>
>> Il est très sexy ce goaccess, mais si on gratte, il manque quand même
>> quelques trucs bien utiles (c'est p'tet un truc qui s'active) :
>>
>> Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller
>> tout
>> leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
>> ( Referrers URLs: If the host in question accessed the site via another
>> resource, or was linked/diverted to you from another host, the URL they
>> were
>> referred from will be provided in this panel. See `--ignore-panel` in your
>> configuration file to enable it. (disabled by default) )
>>
>> Y'a un truc pour changer la période d'analyse ?
>> Là on a 31/Dec/2016 — 20/Nov/2017
>> Mais si je veux savoir comment a évolué la provenance des internautes
>> entre
>> décembre 2016 et décembre 2017 ?
>>
>>
>>
>>
>>
>>
>> -
>> --
>> sly, contact direct : sylvain /a\ letuffe o r g
>> http://wiki.openstreetmap.org/wiki/User:Sletuffe
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

2017-11-20 Par sujet Vincent Frison 
Effectivement c'est sexy !

Je suis étonné de voir que sur 38 TB seulement 15 viendrait de la France...


Le 20 novembre 2017 à 13:38, sly (sylvain letuffe)  a
écrit :

> Il est très sexy ce goaccess, mais si on gratte, il manque quand même
> quelques trucs bien utiles (c'est p'tet un truc qui s'active) :
>
> Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller
> tout
> leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
> ( Referrers URLs: If the host in question accessed the site via another
> resource, or was linked/diverted to you from another host, the URL they
> were
> referred from will be provided in this panel. See `--ignore-panel` in your
> configuration file to enable it. (disabled by default) )
>
> Y'a un truc pour changer la période d'analyse ?
> Là on a 31/Dec/2016 — 20/Nov/2017
> Mais si je veux savoir comment a évolué la provenance des internautes entre
> décembre 2016 et décembre 2017 ?
>
>
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Stats serveurs de tuiles OSM-FR...

2017-11-20 Par sujet sly (sylvain letuffe) 
Il est très sexy ce goaccess, mais si on gratte, il manque quand même
quelques trucs bien utiles (c'est p'tet un truc qui s'active) :

Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller tout
leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
( Referrers URLs: If the host in question accessed the site via another
resource, or was linked/diverted to you from another host, the URL they were
referred from will be provided in this panel. See `--ignore-panel` in your
configuration file to enable it. (disabled by default) )

Y'a un truc pour changer la période d'analyse ?
Là on a 31/Dec/2016 — 20/Nov/2017
Mais si je veux savoir comment a évolué la provenance des internautes entre
décembre 2016 et décembre 2017 ?






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-20 Par sujet sly (sylvain letuffe) 
Nicolas Dumoulin-2 wrote
> Quelques exemples ici :

Et ben mon vieux ! Tu nous illustres le fait de tagguer "name" sur les
panneaux de rando et on a un contre jour, un flou, et un arraché.
Pas évident de juger de la pertinence du "name" sur tes exemples :-)
Mais je suppose que ceux qui participent au débat ici on bien en tête ce
qu'est un panneaux de rando avec un nom indiqué dessus.


Nicolas Dumoulin-2 wrote
> En effet, il s'agit ici du nom du "nœud" dans le réseau de randonnée.
> (...)
> (Exemple avec) le nom des gares ou des arrêts de bus reprenant les
> toponyme.

Je n'avais pas pensé à cette manière de voir les panneaux de rando comme "un
réseau interconnecté".
Dans cette optique là, en effet, un panneaux pourrait avoir un nom du "point
du réseau" même s'il est éventuellement identique à celui du truc réél non
loin.
Ainsi, comme pour les lignes de Bus/métro/.., lorsque l'on considère
l'ensemble des arrêts d'une ligne, au sein de cette ligne, chacun à un nom.
Mouais.
Je pourrais me laisser convaincre par cette argumentation, si ce n'est que
je n'ai pas l'impression, quand je fais mes rando de voir "des lignes ou
réseau de panneaux".
Il m'arrive de croiser des "bout de carte" qui décrivent des randos
suggérées (des itinéraires quoi), mais je doute que tous les panneaux y
figurent, et j'ai plus l'impression qu'on me pointe les éléments du terrains
plutôt que des panneaux de repérage.


Nicolas Dumoulin-2 wrote
> Par rapport à l'exemple du col, dont on ne préciserait pas le nom car un 
> poteau avec le nom du col existe déjà : j'ai un peu envie de dire que 
> c'est la faute du rendu ou de l'outil. Si on affiche "panneau indicateur 
> 'col truc'", ça lève un peu l'ambiguïté. 

Comme je disais, je pense que les outils d'usage finiront par ignorer les
name des panneaux pour éviter la confusion et les doublons, donc ce
désagrément devrait être réduit. Par contre, les outils d'édition eux ont
pour rôle de montrer ce qui est dans la base, donc ils devaient logiquement
continuer à indiquer "col truc" sur le panneau et, j'en ai peur, dissuader
de l'ajouter.
D'où ma dernière suggestion sur le wiki, de bien indiquer que le nom sur le
panneaux ne remplace pas le nom sur le point réél, et espérer que les
éditeurs auront une démarche visant à réduire les risques d'oubli
("panneau du col truc", "icône en gros", "texte en petit", que sais-je
d'autre comme bonne idée)




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

2017-11-20 Par sujet Vincent Frison 
Ok pour virer le tag genus (si species est présent) et pour attendre la fin
de la semaine avant de faire l'import...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-20 Par sujet Nicolas Dumoulin 

Bonjour,


Le 15/11/2017 à 22:48, sly (sylvain letuffe) a écrit :

Une parenthèse en passant : A mon avis, c'est une mauvaise idée que de
mettre le nom indiqué sur le poteaux sur le noeud information=guidepost
J'ai détaillé mon opinion ici :
https://wiki.openstreetmap.org/wiki/Talk:Tag:information%3Dguidepost#a_guidepost.27s_name_.3F
J'ai cartographié certains de ces panneaux autour de Clermont-Ferrand. 
Il y a un réseau de tronçons balisés, et je dis bien tronçons pour 
répondre à la suggestion de relation "route". On a donc en fait des 
"nœuds" matérialisés par ces poteaux avec les différentes directions 
signalées

Quelques exemples ici :
https://www.mapillary.com/app/?lat=45.73689613526574&lng=3.0893634079975527&z=17&pKey=lBs6sFoRJ8n5jlFZi17wAA&focus=photo
https://www.mapillary.com/app/?lat=45.74679336529732&lng=3.086961960901931&z=16.422394175832178&pKey=7QEeug6EhjHytbRRAX4E0Q&focus=photo
Et celui-ci un peu amoché :
https://www.mapillary.com/app/?lat=45.72985877980119&lng=3.079483604202551&z=17&pKey=PeEZOnzBXSX2NgaGboaVwg&focus=photo

Voici comment j'ai cartographié le premier :
https://www.openstreetmap.org/node/3692819556
J'ai mis le nom du poteau comme "name" et ça me semble correspondre à la 
description du terrain. En effet, il s'agit ici du nom du "nœud" dans le 
réseau de randonnée.
Donc par rapport à l'exemple du bois de Sly, ici il me semble y avoir 
une cohérence sur le nommage de ces nœuds et les distances associées le 
sont aussi de par mon expérience.
Par rapport à l'exemple du col, dont on ne préciserait pas le nom car un 
poteau avec le nom du col existe déjà : j'ai un peu envie de dire que 
c'est la faute du rendu ou de l'outil. Si on affiche "panneau indicateur 
'col truc'", ça lève un peu l'ambiguïté. Et en raisonnant par l'absurde, 
ton raisonnement demanderait aussi d'enlever du "name" le nom des gares 
ou des arrêts de bus reprenant les toponyme.


Je conçois que c'est délicat, qu'il peut y avoir confusion, et que le 
nommage de ces poteaux n'est peut-être pas toujours génial. Mais je ne 
vois pas pour l'instant d'autre solution satisfaisante et homogène.

À vous lire :-)

--
Nicolas Dumoulin


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