@Marc
>> si on ne connait pas la ref:* à mettre, on peut mettre ref
> 
> bien évidemment. mais elle serra invisible pour ceux qui ciblent les 
> ref:FR:xxx
Est-ce vraiment un problème ? Ces clés ne sont pas nécessaires selon toi ;-)

>> Les intérêts sont de lier l’objet OSM à un objet dans une base de donnée 
>> externe.
> 
> c'est tout autant lié avec ref
C’est là que ça se complique : pour moi le lien est « physique », on peut 
cliquer est arriver à l’objet en question.
Pour cela on a Tag2Link dans JOSM, et ces règles sont assez souples pour 
générer un lien à partir de plusieurs clés/valeurs.

Mais (à part Osmose) le principe n’a pas été repris dans d’autres logiciels, 
notamment le site web d’OSM.

Si de plus il manque une clé annexe, le lien n’est pas générer…

Avec des références « précises » comme par exemple ref:wmo ou ref:wigos, on 
sait construire le lien hypertexte sans ambiguïté.
Et ça fonctionne pour un radar météo, une station météo…

radar météo :
        • man_made=tower
        • tower:type=radar
        • tower:construction=dome

station météo :
        • man_made=monitoring_station
        • monitoring:weather=yes

>>  * pour un objet qui a plusieurs références, de les différencier.
> 
> hors France, il y a aussi des objets multi-référence (dont les routes)
> cela ne les empeches pas d'avoir comme règle de base d'utiliser ref
> et de préciser la clef quand il y a besoin et non comme règle de base
comment « précises » tu la clé ?

Dans le cas des marques nautiques (seamark:*), la clé seamark:reference qui a 
été créé.
A l’usage, elle contient un vrai bazar. Il est difficile de savoir de quel 
livre des feux on parle.
C’est pour cela quelle va progressivement disparaitre et sera remplacée par la 
clé ref:* dédiée.

> 
>>  * pour une machine (voir un humain), de savoir à quoi ça correspond.
>>    Référence de l’opérateur, de la commune… ?
> 
> on fait pareil avec name ? remplacer par défaut name=truc
> par name:lenomdelentitiéquiadefinitlenom=truc ?
> c'est compréhensible de vouloir être précis mais c'est nuisible d'en
> faire un règle de clef par défaut.
La question n’est pas de savoir qui a définit le nom ou la référence, mais de 
pouvoir lier de manière fiable l’objet OSM et sa version dans une base de 
donnée externe.

D’un côté on dit que des données (notamment volatiles) n’ont rien à faire dans 
OSM, il faut donc pouvoir « pointer » facilement vers la base de données qui 
les stockent.
(Au passage, ça évite de dupliquer de l’info et les problèmes de mise à jour).

De l’autre, il ne faudrait pas créer de références précises… ??

De plus, à terme on pourra avoir une vérification des valeurs (cf. propriétés 
dans wikidata)

> 
> je pense qu'il n'est pas du rôle d'osm de devoir
> connaitre qui a définit la ref lisible sur plaque comme prérequis
> pour l'ajouter correctement dans osm.

> j'en reviens avec l'analogie des routes, on utilise ref pour la
> référence principale sans se soucier si la ref a été définie
> par la commune ou par le niveau national.
cf. supra.

> Et uniquement quand il y a plusieurs ref, on fait une règle
> pour les autres ref. idem pour les noms, idem pour tout.

Si je te suis bien, tu n’es pas opposé dans l’absolu à la création de ref:*…
Mais dans le cas précis de ref:ERDF:gdo, tu n’en vois pas l’utilité, la 
nécessité ?

A ma connaissance, on ne peut pas se servir de ref:ERDF:gdo pour pointer vers 
une base de données externe. (A moins que ERDF fasse ça en interne)
ça servira peut-être un jour à rapprocher les données ouvertes d'Enedis ?

J’ai fait une recherche dans TagInfo sur les objets ayant une clé ref et une 
clé ref:ERDF:gdo.
Il y a les pylônes qui ont leur numéro dans ref, et la référence de l’organe de 
coupure dans ref:ERDF:gdo.

Le plus souvent, ref sert à décrire ce qui est écrit sur le terrain, et 
ref:ERDF:gdo à transcrire cette information de manière complète et précise :
ref="70 159"
ref:ERDF:gdo="83070P0159"
Du coup, tant que l’étiquetage sur le terrain n’est pas normalisé, ce double 
étiquetage me parait nécessaire.

—
Yves


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

Répondre à