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

2017-11-18 Par sujet François Lacombe 
Le 19 novembre 2017 à 00:21, marc marc  a écrit :

> Bonsoir François,
>


> C'est comme si on créait des ref:SNCFxx par département.
> Et malgré tout cela, les ref TEC ne contiennent pas ":BE:"
> Et si c'était le cas, cela ne changerait rien puis qu'elles
> sont toutes en Belgique, toutes dans la même région.

Mon propos n'était pas de pointer un problème en Belgique mais bien avec le
reste du monde.
Si il y a un autre organisme ou référentiel sous ces noms TECx, il y aura
collision.



> >> L'argument anti-collision n'en est pas un quand il n'y a
> >> pas de collision.
> > Là dessus, qui peut en être sûr ?
>
> A la création de la page wiki, si les ref:INSEE concernent toute
> la France, c'est donc le seul sens et donc il n'y a pas de collision
> en disant que ref:INSEE = la référence de l'organisme public français.
> Cela n’empêche pas qu'un jour un autre INSEE puis exister qui utilisera
> une autre clef.
>

Le problèmes c'est "une autre clé".
L'ordre dans lequel les clés sont documentées ne présage pas de leur
importance.
Ainsi je ne vois pas pourquoi l'INSEE Français devrait avoir une clé moins
localisée qu'un autre organisme du même nom (qu'il existe ou pas en fait).

Il y a un cas du même tonneau que j'ai moi-même initié : ref:ERDF:gdo
Le distributeur d'électricité ERDF n'existe plus aujourd'hui, mais il y a
l'European Regional Development Fund.
Même sans en avoir connaissance j'aurais vraiment du créer la clé
ref:FR:erdf_gdo (à minima ref:FR:gdo) dès le départ pour pas avoir à la
changer ensuite (pour l'instant pas prévu, mais il faudrait bien)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande de vérification d'une modification (lignes de bus)

2017-11-18 Par sujet Sébastien Dinot 
Bonjour,

Antoine Riche a écrit :
> Si on peut passer à vélo ou à pied, ce serait mieux de relier le
> chemin et d'y ajouter une barrière : placer un node sur le way avec le
> tag barrier=block et bicycle=yes par exemple.

Mouais... Je ne suis pas convaincu que ce soit pertinent dans le cas
présent. Je vais attendre de voir comment évolue la zone car la route
a été ouverte à la circulation mais ni le revêtement, ni les abords ne
sont terminés. De même, j'ai donné à la nouvelle voie le nom de « Chemin
Carrosse » car elle prolonge la voie éponyme mais un autre contributeur
m'a fait remarquer que, du coup, deux voies différentes (la nouvelle et
le tronçon désormais isolé de l'ancienne) portaient le même nom et qu'il
était peu probable que les choses restent en l'état. Du coup, cette zone
méritera une seconde passe lorsque les travaux seront terminés et je
verrai à ce moment-là si une liaison entre l'ancienne et la nouvelle
voies se justifie.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

___
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-18 Par sujet marc marc 
Bonsoir François,

Le 18. 11. 17 à 21:11, François Lacombe a écrit :
>> Je n'ai rien contre l'ajout du FR mais le seul bon argument est
>> l'harmonie avec les autres ref nationale en France (qu'on peux tout
>> aussi rendre harmonieux en virant le FR comme fait le reste du monde)
> Ce qui pose un soucis, notamment pour les amis Belges avec leurs TECL, 
> TECN, TECB, TECH

Tous ces pages wiki ne sont l’œuvre que d'une personne.
Tous ces TEC sont pour l'usager "la TEC"
Toutes les valeurs sont uniques et pourraient donc être dans ref:TEC 
(toutes les ref TECL commence par L, les TECN par N, ...)
Une recherche d'une ref sur le site infotec.be ne retourne rien.
Je ne suis même pas sur qu'il y ai une utilisation de ces clefs.
Avis personnel, c'est l'exemple typique de l'over-tagging.
C'est comme si on créait des ref:SNCFxx par département.
Et malgré tout cela, les ref TEC ne contiennent pas ":BE:"
Et si c'était le cas, cela ne changerait rien puis qu'elles
sont toutes en Belgique, toutes dans la même région.
Donc la précaution d'ajouter un préfix pays n'aurait pas
permis d’empêcher cette collision théorique.
Ajouter une préfix région non plus.

On peux aussi spéculer sur un code INSEE attribué par la France à une 
entité à l'étranger qui rentrerait en collision avec un INSEE attribué 
par cet autre pays comme Philippe le développe.
Avis personnel, prévoir ce genre de cas est aussi de l’excès.
Il y a UNE page wiki ref:INSEE donc UN sens documenté.

>> L'argument anti-collision n'en est pas un quand il n'y a 
>> pas de collision.
> Là dessus, qui peut en être sûr ?

A la création de la page wiki, si les ref:INSEE concernent toute
la France, c'est donc le seul sens et donc il n'y a pas de collision
en disant que ref:INSEE = la référence de l'organisme public français.
Cela n’empêche pas qu'un jour un autre INSEE puis exister qui utilisera 
une autre clef.

Harmoniser pour améliorer la qualité ou l'utilisation des données me motive.
Mais faire modifier x programmes pour prévenir une collision qui 
n'arrivera peut-être jamais, cela ne me branche pas, il y a + utile à 
mes yeux.

Mais libre bien sur à quelqu'un d'autre de porter ce projet chronophage.

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

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

2017-11-18 Par sujet Philippe Verdy 
L'INSEE a des identifiants faisant référence pour l'admisnitration
française mais des objets situés hors de France. De même l'INSEE a une
activité internationale et produit des identifiants à destination de pays
ou orgnisations clientes hors de France (et il n'y a pas toujours
d'équivalent normalisé dans un autre pays faisant référence au même objet,
des tas de pays en développement n'ayant pas encore de système de référence
national, il y a des efforts de codification venant de plusieurs
prestataires étrangers).

Les collisions de code existent un peu partout (pas que pour codifier les
collectivités locales ou subdivisions adminsitratives). Ajoutons les
identifiants venant de diverses normes internationales ou de diverses
organisations (y compris l'Union européenne), la solution des suffixes de
tag par pays (code noramelemnt en capitales) existe. Mais on n'est pas
cohérent partout et parfois on trouve des préfixes en minuscules avec un
"_" séparateur.

Je n'aime pas la réponse "il suffit de" quand une recherche limitée par une
frontière très complexe est particulièrement lourde (et encore plus quand
on sait qu'il y a des conflits territoriaux entre pays) alors que c'est
tellement plus simple de dire clairement d'où provient le code sans
ambiguïté avec quelques caractères.

Sinon pourquoi on met "direction=*" dans OSM quand on pourrait utiliser
"dir=*", ou pourquoi on doit mettre "noexit=yes" quand ça pourrait être
"noexit=y" ? La question de longueur ne joue pas du tout, on a choisi la
clarté d'abord avant d'utiliser des abbréviatons en excès avec trop de
collisions nécessitant des requêtes complexes (et parfois pas résolues
facilement) ! C'est très lourd de distinguer les pays notamment pour des
objets dans les zones frontalières et d'autant plus que les frontières sont
souvent instables et facilement brisées.


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

>
>
> Le 18 novembre 2017 à 20:01, François Lacombe 
> a écrit :
>
>> Bonsoir Jérôme,
>>
>> Le 18 novembre 2017 à 19:50, Jérôme Amagat  a
>> écrit :
>>
>>> Je suis pour garder ref:INSEE le plus utilisé, celui qui est documenter
>>> dans le wiki et le tag historique.
>>> et en plus regarder où est utiliser le tag ref:FR:INSEE :
>>> http://overpass-turbo.eu/s/t4D
>>> IL y a une grande majorité de ses utilisation dans le Finistère sur des
>>> hameaux et autres lieux dit et sur des rues.
>>> Il y a aussi des relations de rues à bordeaux avec ce tag.
>>> Si on enlève le Finistère et Bordeaux il ne reste plus grand chose comme
>>> tag ref:FR:INSEE.
>>>
>>
>> Je ne suis pas d'accord avec ce raisonnement : si on ne garde que les
>> tags historiques et plus utilisés, la qualité sémantique ne progresse pas.
>> A l'origine, il n'y avait pas de tags historiques à conserver puisqu'OSM
>> est parti d'une feuille blanche.
>> Et aussi parce que le référentiel se construit progressivement, donc il
>> faut pouvoir faire évoluer les clés/valeurs.
>>
>> Le fait que ce soit le tag "historique" (utilisé depuis longtemps, le
> seul pour indiqué ce numéro INSEE pendant très longtemps) fait que il y a
> beaucoup de gens (des gens qui lissent cette liste et d'autres non) qui
> utilisent ce tag et pas l'autre. de supprimé ref:INSEE pourrait poser
> problème à des gens qui utilisent les données osm.
>
>
>
>> Ainsi, je trouve plus que souhaitable de privilégier la qualité, le sens
>> et la cohérence avec les autres tags qui ont été construits de la même
>> manière.
>> Quitte à voir la nouvelle clé s'établir avec le temps ou cohabiter avec
>> l'ancienne pour préserver le fonctionnement des outils existants.
>>
>> Dans le cas qui nous intéresse, la non collision avec d'autres références
>> au niveau mondial est un argument important.
>>
>> regardez sur taginfo, https://taginfo.openstreetmap.org/search?q=ref%3A
> et vous verrez qu'il n'y a qu'en France que ce code "FR" (ou l’équivalent
> pour d'autre pays :) ) apparaît dans les tag "ref:".
> Donc pour être cohérence au niveau français peut être mais c'est tout les
> tag *:FR:* qui sont incohérent au niveau mondial.
> Et le problème de collision n'existe pas il suffit de limiter sa recherche
> à la France.
>
>
>
>
>> François
>>
>>
>> ___
>> 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] Importation des arbres municipaux de Grenoble

2017-11-18 Par sujet Vincent Frison 
Le 18 novembre 2017 à 18:03, marc marc  a écrit :

> Peux-tu isoler le cas où plusieurs arbres sont dans ton rayon
> de sécurité de 5m ?

est-ce que ce sont des espèces différentes ou identique ?
>

Oui ces cas sont isolés mais actuellement l'algo ne regarde que la
distance. C'est vrai qu'il pourrait aussi prendre en compte le genre/espèce
même si dans la majorité des cas les arbres existants n'ont pas ces
attributs malheureusement. Mais c'est une idée intéressante pour une
évolution future.

Sinon je me rend compte que j'avais mis 3 mètres comme rayon de
correspondance alors que j'avais mis 5 mètres pour Nice. Clairement autant
élargir à 5 mètres car de toute façon ça sera toujours l'arbre le plus
proche qui sera mis à jour mais au moins ça permet de "récupérer" un peu
plus d'arbres placés un peu trop grossièrement.
___
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-18 Par sujet François Lacombe 
Bonsoir Marc,

Le 18 novembre 2017 à 20:50, marc marc  a écrit :

> Je n'ai rien contre l'ajout du FR mais le seul bon argument est
> l'harmonie avec les autres ref nationale en France (qu'on peux tout
> aussi rendre harmonieux en virant le FR comme fait le reste du monde)
>

Ce qui pose un soucis, notamment pour les amis Belges avec leurs TECL,
TECN, TECB, TECH


>
> L'argument anti-collision n'en est pas un quand il n'y a pas de
> collision.


Là dessus, qui peut en être sûr ?
Et surtout on ne peut pas prévoir l'avenir. Créer des clés zonées, c'est
aussi être sympa pour les autres en leur laissant de la place.


> Il n'y a qu'une page wiki ref:INSEE qui document l'unique
> usage (et un éventuel autre INSEE pourait lui être préfixé).
> Sinon il faudrait aussi changer les ref:Grenoble en ref:FR:38:Grenoble
> et rajouter le nom de la base de donnée à Grenoble au cas où un jour
> quelqu'un en crée une 2ieme.
>

Généralement il est bien de préciser le périmètre de la clé qu'on utilise.
Et tout aussi généralement ref:%pays/region%:%referentiel% suffit, même si
on ne fera pas baisser le risque à 0.


> Ceci dit, modifier la valeur la plus courante utilisée est une autre
> paire de manche. il faut laisser du temps pour que chacun s'exprime,
> si une majorité importante est pour (dont je ne fais déjà pas partie),
> il faudra dupliquer les 2 clefs pendant une période de transition
> de x mois afin que les différents outils s'adaptent, répéter cette copie
> à intervalle régulier pendant la période de transition et puis nettoyer.
> Ou alors il faut faire l'inverse : annoncer une date de migration dans
> x mois, modifier les outils pour qu'ils testent les 2 valeurs, migrer.
> Mais il ne suffit sûrement pas de modifier le wiki en se disant "yaka"
> être au courant.
>

Il n'a jamais été question du contraire.
Cependant ne pas négliger la palette d'outil à notre disposition en plus du
wiki malgré le refus de faire du massEdit :
- Osmose
- Validation JOSM
- Taginfo (qui relaye le wiki, ok)
- Communication / présentation / bouche à oreille / rabachage

On a un super retour d'expérience sur power=sub_station vs power=substation
Le remplacement s'étale maintenant sur plusieurs années, mais non seulement
le niveau de sub_station a énormément baissé et en plus la nouvelle clé a
dépassé le niveau le plus haut atteint par l'ancienne.
Oui, ça marche et ça marche très bien


François
___
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-18 Par sujet Jérôme Villafruela 

Le 18/11/2017 à 16:14, Paul Desgranges a écrit :
J'ai passé un petit moment à comparer les données de tes fichiers avec 
les données existantes (couche de données OSM et couche photo aérienne 
BdOrtho IGN) , et ceci aussi dans des quartiers que je connais, et ce 
que tu as fait a l'air vraiment bien ! Evidemment je n'ai pas contrôlé 
chacun des 24 000 arbres nx, ni les 6000 arbres modifiés, mais 100% de 
ceux que j'ai vus étaient bons !


J'ai fait ce matin un rapide contrôle dans mon quartier et tout ce que 
j'ai vu était bon (notamment la place St-Bruno). J'étais dubitatif sur 
les deux ajouts en 45.18521/5.71342 mais il y a bien 4 arbres en carré.


- le fichier genfile-for-creation.osm.xml contient bien des arbres 
nouveaux
- le fichier genfile-for-modification.osm.xml précise bien les tags 
'genus' et species' pour des nœuds qui étaient des simples 'natural=tree'
- pour le fichier genfile-for-non-markable-elements.osm.xml, il 
faudrait corriger à la main qq petits trucs pour pouvoir importer le 
fichier : corriger le tracé d'un building, ou d'un abribus qui englobe 
à qq centimètres près un arbre à créer, ou supprimer un building qui 
n'existe plus (pas visible sur photoaérienne), etc. Et je veux bien me 
charger de ces corrections si cela peut t'aider (et pour que 
osm-grenoble en fasse aussi un peu) : c'est à dire déplacer un 
building ou abribus de qq centimètres, etc. avant d'importer le fichier.
Il vaudrait peut être mieux ajuster la position des arbres avant 
l'import, notamment pour ceux devant le silo à vélos ouest de la gare, 
le modifier le rendrait désynchronisé du cadastre.
@Paul : je veux bien t'aider sur ce coup-là. De toute façon on en 
parlera lors de la prochaine réunion du groupe local, le 4 décembre.


Ce qui manque c'est de citer la source sur chacun des nœud ? Et 
pourquoi ne pas rajouter la start_date effectivement si tu as cette 
info ?

Oui, on l'a dans le champ ANNEEDEPLANTATION

Bravo en tout cas !

Je plussoie !

--
Jérôme
(Crossposté sur talk-fr et local-grenoble. Followup sur talk-fr)



___
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-18 Par sujet marc marc 
Je n'ai rien contre l'ajout du FR mais le seul bon argument est 
l'harmonie avec les autres ref nationale en France (qu'on peux tout 
aussi rendre harmonieux en virant le FR comme fait le reste du monde)

L'argument anti-collision n'en est pas un quand il n'y a pas de 
collision. Il n'y a qu'une page wiki ref:INSEE qui document l'unique 
usage (et un éventuel autre INSEE pourait lui être préfixé).
Sinon il faudrait aussi changer les ref:Grenoble en ref:FR:38:Grenoble 
et rajouter le nom de la base de donnée à Grenoble au cas où un jour 
quelqu'un en crée une 2ieme.

Ceci dit, modifier la valeur la plus courante utilisée est une autre 
paire de manche. il faut laisser du temps pour que chacun s'exprime,
si une majorité importante est pour (dont je ne fais déjà pas partie), 
il faudra dupliquer les 2 clefs pendant une période de transition
de x mois afin que les différents outils s'adaptent, répéter cette copie 
à intervalle régulier pendant la période de transition et puis nettoyer.
Ou alors il faut faire l'inverse : annoncer une date de migration dans
x mois, modifier les outils pour qu'ils testent les 2 valeurs, migrer.
Mais il ne suffit sûrement pas de modifier le wiki en se disant "yaka" 
être au courant.

Le 18. 11. 17 à 19:50, Jérôme Amagat a écrit :
> dans le Finistère sur des hameaux et autres lieux dit et sur des rues.
> rues à bordeaux

Peut-être en effet serrait-il utile de commencer par un grand nettoyage.
Il faudra vérifier que chacun de ces objets se trouve bien dans une 
"area" communale reprenant le code INSEE.
Il serrait utile d'impliquer les communautés régionales concernées.
Et surtout, il faudrait se mettre d'accord sur quel objet ce tag
a du sens. sur la relation ou chemin fermé d'une commune assurément.
sur le noeud admin_center j'en suis moins sur.
le code d'une commune sur des "sous-lieux" et rues probablement non.

Le 18. 11. 17 à 19:50, Jérôme Amagat a écrit :
> addr:postcode=* a t il sa place sur les relations des communes

non c'est une erreur en France, le bon tag pour définir le code postale 
qui s'applique a toute une commune est postal_code
C'est ce que Nominatim par exemple utilise.
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code

Bref je proposais une opération d'harmonisation fait en 5 min.
Là on est parti sur un projet de fond en mois...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2017-11-18 Par sujet Vincent Frison 
Merci beaucoup pour vos retours !

Au final je vais donc ne pas rajouter de tag ref et je vais toujours
renseigner genus ET species (s'il y a une valeur bien sûr).

J'ai corrigé le coup des espèces/genres qui pouvaient ne pas avoir de
valeur ainsi que le problème de l'UTF-8 (une nouvelle version est
disponible ici: https://files.fm/u/ct7mm6dk).

@Paul: à vrai dire vu le faible nombre d'arbres "non makable" je comptais
les ignorer complètement et donc ne rien faire avec... mais n'hésites
surtout pas à utiliser le fichier si tu te sens de supprimer ou corriger
des bâtiments qui seraient inexacts !





Le 18 novembre 2017 à 18:03, marc marc  a écrit :

> Peux-tu isoler le cas où plusieurs arbres sont dans ton rayon
> de sécurité de 5m ?
> est-ce que ce sont des espèces différentes ou identique ?
>
> > - est ce que cela vaut la peine de rajouter un tag ref:FR:Grenoble:trees
> > jour je n'en aurais pas vraiment besoin).
> Si tu n'en as besoin pour un prochain import, alors c'est probablement
> inutile de l'ajouter.
> la seule utilité que je vois serrait de pouvoir remonter à Grenoble un
> éventuel problème de localisation d'un arbre ou abattage.
> Mais les arbres ont-il la ref sur eux ? sinon c'est même pas sur qu'un
> déplacement d'un noeud osm correspond toujours au même arbre
>
> > - pour le tag genus/species: dans leur fichier JSON il y a 2 champs
> > séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour
> > remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour le
> > tag species je concatène
> > la valeur des 2 champs. Du coup ça vaut quand même la peine que je mette
> > le tag genus (sachant qu'il est déjà "inclus" dans le champ species) ?
>
> Genus donnant la catégorie globale, je trouve que c'est pratique
> de  l'ajouter même quand on connaît l'espèce précise.
> Mais en voyant la différence d'occurence entre les 2, certains pensent
> le contraire.
>
> > dois je annoncer à chaque fois mes importations
>
> Selon moi, une annonce par type d'import me semble suffisant quitte à
> annoncer que l'import concernera d'autres villes française et mettre à
> jour la page wiki au fur et à mesure des différentes villes.
> Il peux aussi être utile d'ajouter un tag website sur le changeset
> vers la page de l'import.
>
> > très faible nombre d'imports annoncés.
>
> nombreux ne sont en effet pas annoncés.
> j'en croise des problématiques tous les mois :(
> je trouve cela domage car discuter d'un import est un moyen pratique
> d'éviter les éventuels problèmes de qualité.
>
> ___
> 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] ref:INSEE <> ref:FR:INSEE

2017-11-18 Par sujet Jérôme Amagat 
Le 18 novembre 2017 à 20:01, François Lacombe  a
écrit :

> Bonsoir Jérôme,
>
> Le 18 novembre 2017 à 19:50, Jérôme Amagat  a
> écrit :
>
>> Je suis pour garder ref:INSEE le plus utilisé, celui qui est documenter
>> dans le wiki et le tag historique.
>> et en plus regarder où est utiliser le tag ref:FR:INSEE :
>> http://overpass-turbo.eu/s/t4D
>> IL y a une grande majorité de ses utilisation dans le Finistère sur des
>> hameaux et autres lieux dit et sur des rues.
>> Il y a aussi des relations de rues à bordeaux avec ce tag.
>> Si on enlève le Finistère et Bordeaux il ne reste plus grand chose comme
>> tag ref:FR:INSEE.
>>
>
> Je ne suis pas d'accord avec ce raisonnement : si on ne garde que les tags
> historiques et plus utilisés, la qualité sémantique ne progresse pas.
> A l'origine, il n'y avait pas de tags historiques à conserver puisqu'OSM
> est parti d'une feuille blanche.
> Et aussi parce que le référentiel se construit progressivement, donc il
> faut pouvoir faire évoluer les clés/valeurs.
>
> Le fait que ce soit le tag "historique" (utilisé depuis longtemps, le seul
pour indiqué ce numéro INSEE pendant très longtemps) fait que il y a
beaucoup de gens (des gens qui lissent cette liste et d'autres non) qui
utilisent ce tag et pas l'autre. de supprimé ref:INSEE pourrait poser
problème à des gens qui utilisent les données osm.



> Ainsi, je trouve plus que souhaitable de privilégier la qualité, le sens
> et la cohérence avec les autres tags qui ont été construits de la même
> manière.
> Quitte à voir la nouvelle clé s'établir avec le temps ou cohabiter avec
> l'ancienne pour préserver le fonctionnement des outils existants.
>
> Dans le cas qui nous intéresse, la non collision avec d'autres références
> au niveau mondial est un argument important.
>
> regardez sur taginfo, https://taginfo.openstreetmap.org/search?q=ref%3A
et vous verrez qu'il n'y a qu'en France que ce code "FR" (ou l’équivalent
pour d'autre pays :) ) apparaît dans les tag "ref:".
Donc pour être cohérence au niveau français peut être mais c'est tout les
tag *:FR:* qui sont incohérent au niveau mondial.
Et le problème de collision n'existe pas il suffit de limiter sa recherche
à la France.




> François
>
>
> ___
> 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] ref:INSEE <> ref:FR:INSEE

2017-11-18 Par sujet Philippe Verdy 
Il y a surtout qu'un outil voyant une clé "ref:FR:*" peut choisir de
l'ignorer directement sans même savoir ce que signifie "INSEE", dont le nom
peut apparaître aussi dans des références internationales (pas qu'en
France) mais uniquement pour un usage par l'administration française et
aucune administration locale.

Cela permettrait par exemple dans une carte allemande de ne pas afficher
des infos franco-françaises tout en affichant le reste des infos
pertinentes pour une carte allemande.

La cohérence globale voudrait qu'on évite de tenter les autres pays de
mettre leurs clés locales sans préfixe de code pays, et aussi de savoir
quel groupe local s'occupe de gérer ces références et d'où ça vient pour
des utilisateurs non francophones (pas au courant de nos discussions) et
même pour des francophones non situés en France.
Enfin l'acronyme "INSEE" ressemble trop fortement à d'autres acronymes
d'organismes similaires y compris en Europe, et un préfixe "FR:" évite une
saisie intempestive. Ce tag pourrait alors facilement être reconnu dans des
"presets" spécifiques à la France plus faciles aussi à administrer dans
leur signification, codification et usage (le préfixe impose de suivre une
norme française et pas une norme étrangère). On évite des tas de problèmes
potentiels et on facilmite grandement la réutilisation même pour la France
seule, sans avoir nécessairement à ajouter des restrictions territoriales
(bbox ou frontière parfois instable)


Le 18 novembre 2017 à 20:01, François Lacombe  a
écrit :

> Bonsoir Jérôme,
>
> Le 18 novembre 2017 à 19:50, Jérôme Amagat  a
> écrit :
>
>> Je suis pour garder ref:INSEE le plus utilisé, celui qui est documenter
>> dans le wiki et le tag historique.
>> et en plus regarder où est utiliser le tag ref:FR:INSEE :
>> http://overpass-turbo.eu/s/t4D
>> IL y a une grande majorité de ses utilisation dans le Finistère sur des
>> hameaux et autres lieux dit et sur des rues.
>> Il y a aussi des relations de rues à bordeaux avec ce tag.
>> Si on enlève le Finistère et Bordeaux il ne reste plus grand chose comme
>> tag ref:FR:INSEE.
>>
>
> Je ne suis pas d'accord avec ce raisonnement : si on ne garde que les tags
> historiques et plus utilisés, la qualité sémantique ne progresse pas.
> A l'origine, il n'y avait pas de tags historiques à conserver puisqu'OSM
> est parti d'une feuille blanche.
> Et aussi parce que le référentiel se construit progressivement, donc il
> faut pouvoir faire évoluer les clés/valeurs.
>
> Ainsi, je trouve plus que souhaitable de privilégier la qualité, le sens
> et la cohérence avec les autres tags qui ont été construits de la même
> manière.
> Quitte à voir la nouvelle clé s'établir avec le temps ou cohabiter avec
> l'ancienne pour préserver le fonctionnement des outils existants.
>
> Dans le cas qui nous intéresse, la non collision avec d'autres références
> au niveau mondial est un argument important.
>
> François
>
>
> ___
> 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] ref:INSEE <> ref:FR:INSEE

2017-11-18 Par sujet François Lacombe 
Bonsoir Jérôme,

Le 18 novembre 2017 à 19:50, Jérôme Amagat  a
écrit :

> Je suis pour garder ref:INSEE le plus utilisé, celui qui est documenter
> dans le wiki et le tag historique.
> et en plus regarder où est utiliser le tag ref:FR:INSEE :
> http://overpass-turbo.eu/s/t4D
> IL y a une grande majorité de ses utilisation dans le Finistère sur des
> hameaux et autres lieux dit et sur des rues.
> Il y a aussi des relations de rues à bordeaux avec ce tag.
> Si on enlève le Finistère et Bordeaux il ne reste plus grand chose comme
> tag ref:FR:INSEE.
>

Je ne suis pas d'accord avec ce raisonnement : si on ne garde que les tags
historiques et plus utilisés, la qualité sémantique ne progresse pas.
A l'origine, il n'y avait pas de tags historiques à conserver puisqu'OSM
est parti d'une feuille blanche.
Et aussi parce que le référentiel se construit progressivement, donc il
faut pouvoir faire évoluer les clés/valeurs.

Ainsi, je trouve plus que souhaitable de privilégier la qualité, le sens et
la cohérence avec les autres tags qui ont été construits de la même manière.
Quitte à voir la nouvelle clé s'établir avec le temps ou cohabiter avec
l'ancienne pour préserver le fonctionnement des outils existants.

Dans le cas qui nous intéresse, la non collision avec d'autres références
au niveau mondial est un argument important.

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

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

2017-11-18 Par sujet Jérôme Amagat 
Je suis pour garder ref:INSEE le plus utilisé, celui qui est documenter
dans le wiki et le tag historique.
et en plus regarder où est utiliser le tag ref:FR:INSEE :
http://overpass-turbo.eu/s/t4D
IL y a une grande majorité de ses utilisation dans le Finistère sur des
hameaux et autres lieux dit et sur des rues.
Il y a aussi des relations de rues à bordeaux avec ce tag.
Si on enlève le Finistère et Bordeaux il ne reste plus grand chose comme
tag ref:FR:INSEE.

Je pense qu'il faut aussi se poser la question de où le numéro INSEE à son
utilité. est ce qu'il sert a quelque chose sur une rue ou un hameau qui
n'est pas admin_centre de sa commune.

Il y a aussi le cas des communes qui ont disparu : faut il garder le
ref:INSEE sur l'ancien admin_centre.
Il y a aussi souvent ce ref:INSEE sur la relation de la commune et sur
l'admin_centre. sur la relation je pense qu'il n'y a pas de problème il a
sa place mais sur l'admin_centre c'est moins sur, surtout quand la commune
n'a pas le même nom que cet admin_centre, ça pourrait porter a confusion :
c'est le code INSEE de la commune ou de la ville ou village. (c’est le même
problème pour la valeur de population, le siren , siret).

Si je continu dans cette direction :) :
wikipedia=* et wikidata=*  sur la relation sur le place=* ou les 2 ?
addr:postcode=* a t il sa place sur les relations des communes : josm donne
toujours une erreur :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2017-11-18 Par sujet Philippe Verdy 
Concernant la documentation rien n'interdit de renommer la page
"Key:ref:INSEE" du wiki vers  "Key:ref:FR:INSEE", (et aussi
"FR:Key:ref:INSEE" vers  "FR:Key:ref:FR:INSEE" pour la version en français:
le renommage préserve un lien de redirection depuis l'ancien nom) tout en
ajoutant la mention de l'ancien tag déprécié. Moi aussi je serais en faveur
du changement  avec le code "ref:FR:" pour la France (et non le français)
puisque c'est une référence strictement pour l'usage par l'administration
française.
Ceci dit c'est assez rapide à faire, 77000 clés environ à changer sur OSM,
divisé par environ 100 départements ça donne 770 clés par département en
moyenne, à faire en une centaine de changesets vite exécuté. Un tel
renommage en masse est permis si cela a été discuté et approuvé par la
communauté (et surtout si on a gardé les redirections wiki et inclus la
mention de l'ancienne façon de taguer sans le code pays "FR:").
Cependant quelques outils de recherche et divers liens peuvent encore
utiliser l'ancienne clé et ne trouveront plus rien (par exemple par
Overpass) et il peut y avoir des presets encore dans les plugins ou
éditeurs à changer avant de faire le renommage massif pour qu'ils ne se
retrouvent pas du jour au lendemain sans aucune données à afficher.
Commençons donc d'abord par la doc du wiki, puis laissons un peu de temps
pour que les outils tiers s'y retrouvent et changent leur code, et ensuite
on peut renommer département par département.


Le 18 novembre 2017 à 18:54, François Lacombe  a
écrit :

> Hello,
>
> Il m'est souvenir d'une discussion où les ref nationales devaient migrer
> vers ref:FR
> A mon avis, l'usage correct est ref:FR:INSEE et ref:INSEE est l'historique.
> https://wiki.openstreetmap.org/wiki/Talk:WikiProject_
> France/Liste_des_r%C3%A9f%C3%A9rences_nationales
>
> En tout cas je suis clairement plus en faveur de ref:FR:INSEE
>
> Et le temps manque aussi
>
> François
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 18 novembre 2017 à 18:44, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> J'en fais un sujet séparé pour gagner en lisibilité :
>> 77 505 occurrences de ref:INSEE, clef documenté dans le wiki
>> 18 072 occurrences de ref:FR:INSEE, clef non documenté. typo
>> ou des outils l'utilisent ?
>>
>> Si aucun usage n'est connu, je propose de faire une édition de masse
>> afin d'harmoniser en modifiant ref:FR:INSEE en ref:INSEE
>>
>> Cordialement,
>> Marc
>> ___
>> 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] Utilisation du tag 'name' avec les langues régionales

2017-11-18 Par sujet Jérôme Amagat 
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.

>
> 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.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2017-11-18 Par sujet François Lacombe 
Hello,

Il m'est souvenir d'une discussion où les ref nationales devaient migrer
vers ref:FR
A mon avis, l'usage correct est ref:FR:INSEE et ref:INSEE est l'historique.
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

En tout cas je suis clairement plus en faveur de ref:FR:INSEE

Et le temps manque aussi

François

*François Lacombe*

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

Le 18 novembre 2017 à 18:44, marc marc  a écrit :

> Bonjour,
>
> J'en fais un sujet séparé pour gagner en lisibilité :
> 77 505 occurrences de ref:INSEE, clef documenté dans le wiki
> 18 072 occurrences de ref:FR:INSEE, clef non documenté. typo
> ou des outils l'utilisent ?
>
> Si aucun usage n'est connu, je propose de faire une édition de masse
> afin d'harmoniser en modifiant ref:FR:INSEE en ref:INSEE
>
> Cordialement,
> Marc
> ___
> 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-18 Par sujet Christian Quest 

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


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 !


Le 18/11/2017 à 11:18, marc marc a écrit :

c'est moi qui suit mal réveillé
la ) ferme le début de la liste
lenom de la commune est en erreur parce qu'elle contient un espace
dans son nom.
l'insee donne comme nom "Saint-Ours

Le 18. 11. 17 à 11:10, marc marc a écrit :

Je pense qu'il y a une typo dans la dernière partie de ta regex
qui impose une ")" au début d'un nom.
Il détecte en erreur
https://www.openstreetmap.org/node/1721429280
nameSaint-Ours les Roches

En passant, tag2link ne propose pas la recherche insee du nom de la commune


Le 18. 11. 17 à 10:03, Christian Quest a écrit :

J'ai fait une petite requête overpass qui repère les name=* non
conformes aux règles de toponymie (donc au passage les noms
multilingues) sur les noeuds avec ref:INSEE

http://overpass-turbo.eu/s/t44

On détecte au passage des objets où des ref:INSEE sont ajoutés, mais qui
n'ont rien à voir avec des communes... adresses, mairies, hydrants,
bornes géodésiques.


Le 17 novembre 2017 à 13:14, Vincent Bergeot > a écrit :

  Et je l'ai fait en Français car Izpura est le nom basque de la ville
  d'Ispoure, proche de Saint-Jean-Pied-de-Port
  (http://www.openstreetmap.org/relation/168245#map=14/43.1849/-1.2386
  ),
  j'ai supposé donc un bilinguisme franco-basque, et je ne parle pas
  basque !

  Si quelqu'un sait traduire en basque :)



  Le 17/11/2017 à 13:10, Vincent Bergeot a écrit :

  Le 17/11/2017 à 08:21, Christian Quest a écrit :

  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 ?

  Bonjour,
  en privé le 17 octobre, sans aucune réponse de sa part (copie
  d'écran en PJ):
  "Ajout des noms basques ou carte en Basque ?
  izpura
  17 octobre 2017 à 10h54

  Bonjour, je me permets de venir vers vous car j'ai l'impression
  qu'il y a une bataille d'édition sur le contenu du tag name.

  Plutôt que la bataille d'édition, ne faut-il pas envisager un
  rendu cartographique en basque, comme les bretons par exemple ont
  pu le faire ici.

  Je n'ai pas les compétences techniques, mais dispo pour en
  discuter, voire trouver les compétences techniques !!!

  Bonne journée"

  à plus







  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.

___
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

[OSM-talk-fr] ref:INSEE <> ref:FR:INSEE

2017-11-18 Par sujet marc marc 
Bonjour,

J'en fais un sujet séparé pour gagner en lisibilité :
77 505 occurrences de ref:INSEE, clef documenté dans le wiki
18 072 occurrences de ref:FR:INSEE, clef non documenté. typo
ou des outils l'utilisent ?

Si aucun usage n'est connu, je propose de faire une édition de masse 
afin d'harmoniser en modifiant ref:FR:INSEE en ref:INSEE

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

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

2017-11-18 Par sujet marc marc 
Peux-tu isoler le cas où plusieurs arbres sont dans ton rayon
de sécurité de 5m ?
est-ce que ce sont des espèces différentes ou identique ?

> - est ce que cela vaut la peine de rajouter un tag ref:FR:Grenoble:trees > 
> jour je n'en aurais pas vraiment besoin).
Si tu n'en as besoin pour un prochain import, alors c'est probablement 
inutile de l'ajouter.
la seule utilité que je vois serrait de pouvoir remonter à Grenoble un 
éventuel problème de localisation d'un arbre ou abattage.
Mais les arbres ont-il la ref sur eux ? sinon c'est même pas sur qu'un 
déplacement d'un noeud osm correspond toujours au même arbre

> - pour le tag genus/species: dans leur fichier JSON il y a 2 champs 
> séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour 
> remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour le 
> tag species je concatène
> la valeur des 2 champs. Du coup ça vaut quand même la peine que je mette 
> le tag genus (sachant qu'il est déjà "inclus" dans le champ species) ?

Genus donnant la catégorie globale, je trouve que c'est pratique
de  l'ajouter même quand on connaît l'espèce précise.
Mais en voyant la différence d'occurence entre les 2, certains pensent 
le contraire.

> dois je annoncer à chaque fois mes importations

Selon moi, une annonce par type d'import me semble suffisant quitte à 
annoncer que l'import concernera d'autres villes française et mettre à 
jour la page wiki au fur et à mesure des différentes villes.
Il peux aussi être utile d'ajouter un tag website sur le changeset
vers la page de l'import.

> très faible nombre d'imports annoncés.

nombreux ne sont en effet pas annoncés.
j'en croise des problématiques tous les mois :(
je trouve cela domage car discuter d'un import est un moyen pratique 
d'éviter les éventuels problèmes de qualité.

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

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

2017-11-18 Par sujet Paul Desgranges 

J'avais pas vu ta réponse du jour avant d'envoyer la mienne aujourd'hui
Je rajoute ceci : qd le champ ESPECE n'existe pas, c'est concaténé avec 
la chaîne "null" et on a en final 3290 arbres en création et 517 en 
modification avec une species du genre"Tilia null" "Acer null" etc

Merci
Paul



Le 18/11/2017 à 14:47, Vincent Frison a écrit :

Merci Sly pour ton retour.

Bien vu pour l'erreur d'encodage UTF-8 !

Sinon 2 petites questions:

- est ce que cela vaut la peine de rajouter un 
tag ref:FR:Grenoble:trees avec comme valeur une référence interne 
(utilisée dans le fichier JSON) ? J'avais cru comprendre que c'était 
une bonne pratique mais que finalement c'était pas souhaitable. 
Personnellement je pense pas que ça soit super utile (par ex. si je 
devais refaire un import pour mise à jour je n'en aurais pas vraiment 
besoin).


- pour le tag genus/species: dans leur fichier JSON il y a 2 champs 
séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour 
remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour 
le tag species je concatène
la valeur des 2 champs. Du coup ça vaut quand même la peine que je 
mette le tag genus (sachant qu'il est déjà "inclus" dans le champ 
species) ?


Enfin pour respecter la procédure j'ai commencé à créer une page wiki 
mais dois je annoncer à chaque fois mes importations sur 
impo...@openstreetmap.org  ? En fait 
cela ne me dérange pas mais ce qui m'étonne c'est de voir le très 
faible nombre d'imports annoncés. Sur le catalogue 
 on peut voir 
que sur les 3 derniers mois il n'y a eu que 3 imports et ce sont les 
miens ! Cela voudrait dire que pas mal d'imports se font "à la douce" ?


Merci, Vincent.




Le 17 novembre 2017 à 22:06, sly (sylvain letuffe) > a écrit :


Vincent Frison wrote
> Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz

J'ai fais de nombreux sondages aléatoires à l'aide des photos
aériennes
récentes et ça à l'air de la bonne qualité, très cohérent avec
l'existant,
et sans doublons trouvés.
Je ne passe toutefois pas assez souvent sur Grenoble pour tenter
une vérif
"in situ".

L'algo a donc l'air de bien bosser en plus d'une donnée source de
bonne
qualité, c'est tout bon !

Note: Il semble qu'un double encodage UTF-8 se soit glissé dans
l'incorporation des genus/species
Fichier genfile-for-creation.osm ligne 1670 par exemple :
   








-
--
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


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

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

2017-11-18 Par sujet Paul Desgranges 
J'ai passé un petit moment à comparer les données de tes fichiers avec 
les données existantes (couche de données OSM et couche photo aérienne 
BdOrtho IGN) , et ceci aussi dans des quartiers que je connais, et ce 
que tu as fait a l'air vraiment bien ! Evidemment je n'ai pas contrôlé 
chacun des 24 000 arbres nx, ni les 6000 arbres modifiés, mais 100% de 
ceux que j'ai vus étaient bons !

- le fichier genfile-for-creation.osm.xml contient bien des arbres nouveaux
- le fichier genfile-for-modification.osm.xml précise bien les tags 
'genus' et species' pour des nœuds qui étaient des simples 'natural=tree'
- pour le fichier genfile-for-non-markable-elements.osm.xml, il faudrait 
corriger à la main qq petits trucs pour pouvoir importer le fichier : 
corriger le tracé d'un building, ou d'un abribus qui englobe à qq 
centimètres près un arbre à créer, ou supprimer un building qui n'existe 
plus (pas visible sur photoaérienne), etc. Et je veux bien me charger de 
ces corrections si cela peut t'aider (et pour que osm-grenoble en fasse 
aussi un peu) : c'est à dire déplacer un building ou abribus de qq 
centimètres, etc. avant d'importer le fichier.
Ce qui manque c'est de citer la source sur chacun des nœud ? Et pourquoi 
ne pas rajouter la start_date effectivement si tu as cette info ?

Bravo en tout cas !
Paul




Le 17/11/2017 à 22:49, Paul Desgranges a écrit :
Hello, merci, je regarderai moi aussi ce week-end les trois fichiers 
que tu as fourni, pour te donner un avis en plus

Paul


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


Vincent Frison wrote

Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz

J'ai fais de nombreux sondages aléatoires à l'aide des photos aériennes
récentes et ça à l'air de la bonne qualité, très cohérent avec 
l'existant,

et sans doublons trouvés.
Je ne passe toutefois pas assez souvent sur Grenoble pour tenter une 
vérif

"in situ".

L'algo a donc l'air de bien bosser en plus d'une donnée source de bonne
qualité, c'est tout bon !

Note: Il semble qu'un double encodage UTF-8 se soit glissé dans
l'incorporation des genus/species
Fichier genfile-for-creation.osm ligne 1670 par exemple :

 






-





___
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-18 Par sujet Philippe Verdy 
[place!~"suburb"] ne marche pas seul il faut ajouter:

[place][place!~"suburb"]

sinon ça matche un peu trop de choses qui ne sont même PAS tagués comme
"place=*" mais pourtant nommés correctement (sans forcément des traits
d'union partout hormi l'article initial). Si le but est de corriger la
toponymie (name=*) je ne vois pas en quoi c'est significatif. Cependant ça
détecte les cas où des noeuds (non "place=*") ont un ref:INSEE

A voir aussi : ne peut-on pas uniformiser "ref:INSEE" et "ref:FR:INSEE" (en
faveur du premier qui est largement le plus utilisé, même si à côté on
devrait aussi renseigner ref:FR:SIREN pour la commune)

Le 18 novembre 2017 à 10:03, Christian Quest  a
écrit :

> J'ai fait une petite requête overpass qui repère les name=* non conformes
> aux règles de toponymie (donc au passage les noms multilingues) sur les
> noeuds avec ref:INSEE
>
> http://overpass-turbo.eu/s/t44
>
> On détecte au passage des objets où des ref:INSEE sont ajoutés, mais qui
> n'ont rien à voir avec des communes... adresses, mairies, hydrants, bornes
> géodésiques.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2017-11-18 Par sujet Vincent Frison 
Merci Sly pour ton retour.

Bien vu pour l'erreur d'encodage UTF-8 !

Sinon 2 petites questions:

- est ce que cela vaut la peine de rajouter un tag ref:FR:Grenoble:trees
avec comme valeur une référence interne (utilisée dans le fichier JSON) ?
J'avais cru comprendre que c'était une bonne pratique mais que finalement
c'était pas souhaitable. Personnellement je pense pas que ça soit super
utile (par ex. si je devais refaire un import pour mise à jour je n'en
aurais pas vraiment besoin).

- pour le tag genus/species: dans leur fichier JSON il y a 2 champs
séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour
remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour le
tag species je concatène
la valeur des 2 champs. Du coup ça vaut quand même la peine que je mette le
tag genus (sachant qu'il est déjà "inclus" dans le champ species) ?

Enfin pour respecter la procédure j'ai commencé à créer une page wiki mais
dois je annoncer à chaque fois mes importations sur
impo...@openstreetmap.org ? En fait cela ne me dérange pas mais ce qui
m'étonne c'est de voir le très faible nombre d'imports annoncés. Sur le
catalogue  on peut
voir que sur les 3 derniers mois il n'y a eu que 3 imports et ce sont les
miens ! Cela voudrait dire que pas mal d'imports se font "à la douce" ?

Merci, Vincent.




Le 17 novembre 2017 à 22:06, sly (sylvain letuffe)  a
écrit :

> Vincent Frison wrote
> > Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz
>
> J'ai fais de nombreux sondages aléatoires à l'aide des photos aériennes
> récentes et ça à l'air de la bonne qualité, très cohérent avec l'existant,
> et sans doublons trouvés.
> Je ne passe toutefois pas assez souvent sur Grenoble pour tenter une vérif
> "in situ".
>
> L'algo a donc l'air de bien bosser en plus d'une donnée source de bonne
> qualité, c'est tout bon !
>
> Note: Il semble qu'un double encodage UTF-8 se soit glissé dans
> l'incorporation des genus/species
> Fichier genfile-for-creation.osm ligne 1670 par exemple :
>
> 
>
>
>
>
>
>
>
> -
> --
> 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] Utilisation du tag 'name' avec les langues régionales

2017-11-18 Par sujet marc marc 
c'est moi qui suit mal réveillé
la ) ferme le début de la liste
lenom de la commune est en erreur parce qu'elle contient un espace
dans son nom.
l'insee donne comme nom "Saint-Ours

Le 18. 11. 17 à 11:10, marc marc a écrit :
> Je pense qu'il y a une typo dans la dernière partie de ta regex
> qui impose une ")" au début d'un nom.
> Il détecte en erreur
> https://www.openstreetmap.org/node/1721429280
> name  Saint-Ours les Roches
> 
> En passant, tag2link ne propose pas la recherche insee du nom de la commune
> 
> 
> Le 18. 11. 17 à 10:03, Christian Quest a écrit :
>> J'ai fait une petite requête overpass qui repère les name=* non
>> conformes aux règles de toponymie (donc au passage les noms
>> multilingues) sur les noeuds avec ref:INSEE
>>
>> http://overpass-turbo.eu/s/t44
>>
>> On détecte au passage des objets où des ref:INSEE sont ajoutés, mais qui
>> n'ont rien à voir avec des communes... adresses, mairies, hydrants,
>> bornes géodésiques.
>>
>>
>> Le 17 novembre 2017 à 13:14, Vincent Bergeot > > a écrit :
>>
>>  Et je l'ai fait en Français car Izpura est le nom basque de la ville
>>  d'Ispoure, proche de Saint-Jean-Pied-de-Port
>>  (http://www.openstreetmap.org/relation/168245#map=14/43.1849/-1.2386
>>  ),
>>  j'ai supposé donc un bilinguisme franco-basque, et je ne parle pas
>>  basque !
>>
>>  Si quelqu'un sait traduire en basque :)
>>
>>
>>
>>  Le 17/11/2017 à 13:10, Vincent Bergeot a écrit :
>>>
>>>  Le 17/11/2017 à 08:21, Christian Quest a écrit :
  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 ?
>>>
>>>  Bonjour,
>>>  en privé le 17 octobre, sans aucune réponse de sa part (copie
>>>  d'écran en PJ):
>>>  "Ajout des noms basques ou carte en Basque ?
>>>  izpura
>>>  17 octobre 2017 à 10h54
>>>
>>>  Bonjour, je me permets de venir vers vous car j'ai l'impression
>>>  qu'il y a une bataille d'édition sur le contenu du tag name.
>>>
>>>  Plutôt que la bataille d'édition, ne faut-il pas envisager un
>>>  rendu cartographique en basque, comme les bretons par exemple ont
>>>  pu le faire ici.
>>>
>>>  Je n'ai pas les compétences techniques, mais dispo pour en
>>>  discuter, voire trouver les compétences techniques !!!
>>>
>>>  Bonne journée"
>>>
>>>  à plus
>>>
>>>
>>>
>>>
>>>
>>>

  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.
___
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-18 Par sujet marc marc 
Je pense qu'il y a une typo dans la dernière partie de ta regex
qui impose une ")" au début d'un nom.
Il détecte en erreur
https://www.openstreetmap.org/node/1721429280
nameSaint-Ours les Roches

En passant, tag2link ne propose pas la recherche insee du nom de la commune


Le 18. 11. 17 à 10:03, Christian Quest a écrit :
> J'ai fait une petite requête overpass qui repère les name=* non 
> conformes aux règles de toponymie (donc au passage les noms 
> multilingues) sur les noeuds avec ref:INSEE
> 
> http://overpass-turbo.eu/s/t44
> 
> On détecte au passage des objets où des ref:INSEE sont ajoutés, mais qui 
> n'ont rien à voir avec des communes... adresses, mairies, hydrants, 
> bornes géodésiques.
> 
> 
> Le 17 novembre 2017 à 13:14, Vincent Bergeot  > a écrit :
> 
> Et je l'ai fait en Français car Izpura est le nom basque de la ville
> d'Ispoure, proche de Saint-Jean-Pied-de-Port
> (http://www.openstreetmap.org/relation/168245#map=14/43.1849/-1.2386
> ),
> j'ai supposé donc un bilinguisme franco-basque, et je ne parle pas
> basque !
> 
> Si quelqu'un sait traduire en basque :)
> 
> 
> 
> Le 17/11/2017 à 13:10, Vincent Bergeot a écrit :
>>
>> Le 17/11/2017 à 08:21, Christian Quest a écrit :
>>> 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 ?
>>
>> Bonjour,
>> en privé le 17 octobre, sans aucune réponse de sa part (copie
>> d'écran en PJ):
>> "Ajout des noms basques ou carte en Basque ?
>> izpura
>> 17 octobre 2017 à 10h54
>>
>> Bonjour, je me permets de venir vers vous car j'ai l'impression
>> qu'il y a une bataille d'édition sur le contenu du tag name.
>>
>> Plutôt que la bataille d'édition, ne faut-il pas envisager un
>> rendu cartographique en basque, comme les bretons par exemple ont
>> pu le faire ici.
>>
>> Je n'ai pas les compétences techniques, mais dispo pour en
>> discuter, voire trouver les compétences techniques !!!
>>
>> Bonne journée"
>>
>> à plus
>>
>>
>>
>>
>>
>>
>>>
>>> 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 
>>

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

2017-11-18 Par sujet marc marc 
Le 18. 11. 17 à 10:01, emeric Prouteau a écrit :
> Le tag inscription me semble une bonne idée

cela me semble aussi un bon choix

 > Par contre il faudrait peu être mettre à jour le wiki
 > car j'observe d'autre guide poste avec un name.
 > D'autant que JOSM propose le name en prereglage lors de l'ajout.

J'ai posé la question sur la mailing mondiale...
Parce que faire une spécificité franco-française serrait pire
qu'un tag imparfait
___
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-18 Par sujet Christian Quest 
J'ai fait une petite requête overpass qui repère les name=* non conformes
aux règles de toponymie (donc au passage les noms multilingues) sur les
noeuds avec ref:INSEE

http://overpass-turbo.eu/s/t44

On détecte au passage des objets où des ref:INSEE sont ajoutés, mais qui
n'ont rien à voir avec des communes... adresses, mairies, hydrants, bornes
géodésiques.


Le 17 novembre 2017 à 13:14, Vincent Bergeot  a écrit :

> Et je l'ai fait en Français car Izpura est le nom basque de la ville
> d'Ispoure, proche de Saint-Jean-Pied-de-Port (
> http://www.openstreetmap.org/relation/168245#map=14/43.1849/-1.2386),
> j'ai supposé donc un bilinguisme franco-basque, et je ne parle pas basque !
>
> Si quelqu'un sait traduire en basque :)
>
>
>
> Le 17/11/2017 à 13:10, Vincent Bergeot a écrit :
>
>
> Le 17/11/2017 à 08:21, Christian Quest a écrit :
>
> 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 ?
>
>
> Bonjour,
> en privé le 17 octobre, sans aucune réponse de sa part (copie d'écran en
> PJ):
> "Ajout des noms basques ou carte en Basque ?
> izpura
> 17 octobre 2017 à 10h54
>
> Bonjour, je me permets de venir vers vous car j'ai l'impression qu'il y a
> une bataille d'édition sur le contenu du tag name.
>
> Plutôt que la bataille d'édition, ne faut-il pas envisager un rendu
> cartographique en basque, comme les bretons par exemple ont pu le faire ici.
>
> Je n'ai pas les compétences techniques, mais dispo pour en discuter, voire
> trouver les compétences techniques !!!
>
> Bonne journée"
>
> à plus
>
>
>
>
>
>
>
> 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 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

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

2017-11-18 Par sujet emeric Prouteau 
Le tag inscription me semble une bonne idée si le champ n'est pas approprié en 
effet. Par contre il faudrait peu être mettre à jour le wiki car j'observe 
d'autre guide poste avec un name. D'autant que JOSM propose le name en 
prereglage lors de l'ajout. 

***
Emeric Prouteau

> Le 17 nov. 2017 à 16:09, JB  a écrit :
> 
>> Le 17/11/2017 à 09:36, Christian Quest a écrit :
>> Ces poteaux matérialisent des itinéraires... ont ils été mappés dans une 
>> relation ?
> Pas forcément. Selon les régions, il peut y avoir simplement de la 
> signalisation de croisement à croisement, des directions vers des points 
> d'intérêt, ou des itinéraires plus ou moins long.
> 
> ___
> 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