Et plutôt que de regarder avec des bistrots, j'ai regardé avec les
boîtes aux lettres vu l'autre sujet.
Je vois
Vespucci <http://taginfo.openstreetmap.org/projects/vespucci>
ref <http://taginfo.openstreetmap.org/keys/ref>=*
yes no no no
Facilities/Facilities/Post Box
mais je maintiens ;-) : si on veut du contrôle de validité,
d'intégration, de complétion, des outils de mise à jours ...
Sachant que moi aussi j'ai commencé avec des ref.
Avec seulement ref tu regardes quoi ? Si le operator=La Poste, si non si
l'objet est un Q49844 (amenity=post_box pour les cartographe à
l'ancienne ;-)) en France.
Comme précisé par Christian, en cas de valeurs multiples, c'est
carrément indémerdable.
Sauf à écrire ref=FR:LaPoste:id1;FR:OpenData2:id2 (mettre le référentiel
dans la valeur, je te dis pas la saisie, on va avoir besoin d'Adrien
pour nous faire une saisie ergonomique ;-)).
Ref est pour le moment un fourre-tout donc difficilement exploitable.
J'entends bien qu'avoir un ref:pays:operateur n'est pas génial non plus.
Ici l'outil Vespucci est un éditeur Android. Donc on a la position, la
langue, etc...
Il devrait pouvoir ajouter ce tag ref:FR:LaPoste sans trop de soucis.
Bien sûr on pourrait faire un ref:<CodeWididata> (ref:Q373724) pour La
Poste.
Si l'utilisateur a déjà renseigné l'operator, et que dans la base wiki
on a associé les tags ref relatifs (pas besoin de dire plus d'un point
de vue utilisateur : on utilise une référence La Poste) ou le brand
(Chronopost, ref:Q2967313).
En plus clair : l'utilisateur veut entrer une boîte aux lettres, il
choisit l'opérateur La Poste et donc on lui propose d'entrer la
référence La Poste.
En interne on aura
operator=Q373724
ref:operator=trucmuch
Parce que quelque part on aura :
wikidata=Q373724
has_ref=yes
value_operator:amenity:post_box=yes
value_operator:amenity:post_office=yes
(on dit que La Poste gère des bàl et des guichets)
Peut-être des infos donnant la zone géographique ?
Et a mon avis aussi pour limiter les interdépendances :
name=La Poste
int_name=La Poste
et sans doute les autres champs wikidata qui ont un sens.
*Pour afficher correctement*
Opérateur=La Poste
Référence=trucmuch
Il suffit de regarder si Q373724 est un objet wikidata et si oui de
chercher son nom (ou stocker :Q373724 pour éviter les conflits avec de
vrais noms Qxxxxxx?)
*Pour entrer une boîte aux lettres*
L'éditeur sait (comment ? dans le wikidata correspondant ?) que les
amenity=post_box ont un nom un opérateur et une référence.
Pour les opérateurs il cherche les wikidata avec
value_operator:amenity:post_box=yes, propose intelligemment la liste (en
fonction des voisins ?) de wikidata ayant
value_operator:amenity:post_box=yes
Du côté des îles anglo-normandes il proposerait sans doute La Poste et
Royal Mail.
Si quelqu'un tape, alors on cherche si un wikidata correspond. Si oui on
remplace en interne par son code.
Maintenant qu'on a l'opérateur, que ce wikidata a has_ref=yes, on peut
proposer d'entrer la référence.
Et la sauver le cas échéant en ref:operator=trucmuch
Si vous pensez qu'on peur avoir des ref multiples, alors il vaut mieux
avoir ref:Q373724=trucmuch.
Pour les règles de validation c'est aussi plus simple.
*Pour valider une référence**
*Frédéric ajoute ref_validation:osmose=yes et hop la règle ref:Q373724
d'osmose est appelée sur l'objet ;-).
ref_validation:rex pourrait définir une expression régulière
ref_validation:url une url à appeler avec substitution des arguments k
et v (ou ?k=ref:Q373724&v=...)
.... gérer les retours (OK, WARN, ERROR...)
Donc je suis vraiment pour créer des objets Wikidata sans doute avec
gestion de version comme dit par ailleurs. Et tous les problèmes et
solutions qui vont avec (fusion, gestion de version, etc) ?
Car on peut comme avec Fantoir, le Cadastre, etc... avoir des problèmes
avec l'existant.
En intégrant j'ai la possibilité de faire des fusions partielles. OK, un
merge partiel, ça se fait.
> En tous cas, il faudra le tester sur des clés factices (test) pour
vérifier son bon fonctionnement vu qu'osm ne dispose pas de serveur "bac
à sable"
ou comme je disais hier sur ces clés mais *dans un bac à sable* de
opengeofiction.net (c'est un écosystème basé sur OpenStreetMap avec deux
différences majeures : les données sont fictives et la licence n'est pas
OdbL - ne pas importer de données OSM). A-t-on des participants sur la
liste ? Sinon il faut créer des compte et au bout d'une semaine on peut
demander un territoire. Il faudra se faire des villes closes pour éviter
que d'autres ne travaillent sur nos zones ou qu'on détruise ailleurs. Je
propose de nommer ce territoire OnSaiMe voir mieux OnSèMe car ici on
sème pour le futur d'OSM et d'OGF.
Ça demande de créer un village.
Pour le moment je n'utilise Wikidata qu'en tant qu'humain.
C'est grave docteur ?
Mais pour des besoins spécifiques (traduction contextuelle principalement).
J'aime la présentation de Wikipedia : on voit la page pour un humain
normal ;-) et pour les geeks et autres tarés (je postule pour la
dernière catégorie) il y a un lien wikidata.
Un grand merci à Nicolas qui a éclairci indirectement un lien qui
m'échappait (les hyperliens vers les pages d'aides localisée dans les
noms de tag d'openstreetmap.org quand on requête un objet). On voit
qu'on retombe sur ce cher Jochen Topf.
Le 2016-06-08 à 00:25, François Lacombe - fl.infosrese...@gmail.com a
écrit :
Globalement on pourrait supprimer tous les noms propres de la base !
Comme dit implicitement précédemment : non, la base OSM est bien plus
riche en termes de noms. *Pour les name:pays, tu as raison*.
Mais Wikidata est une source de noms, il y en a d'autres (je pense à
IATE
<http://iate.europa.eu/SearchByQuery.do?method=search&query=operator&sourceLanguage=en&&targetLanguages=fr&domain=0&matching=&typeOfSearch=s&start=10&next=1>,
attention au copyright - mais il y a 2 Go de dictionnaire comprimé,
http://iate.europa.eu/tbxPageDownload.do dans certains cas on peut
préférer une autre traduction que celle de wikidata sans vouloir
modifier wikidata). Là je suis plus au niveau des concepts (operator...)
que des objets classiques d'OSM.
Je dirais plutôt pour rester indépendant intégrer les noms wikidata en
suggérant de modifier la source si besoin ou en corrigeant dans OSM et à
la manière de Fantoir dire qu'il y a divergence (après on peut avoir des
outils pour remonter vers Wikidata).
Mais tous *les short_name, old_name, alt_name n'ont pas d'équivalent
dans Wikidata* ou je dis une connerie ?
Dans la pratique les noms autres que les noms standard me semblent mieux
définis par OSM. Wikidata se "contente" d'un *AKA *(also known as, aussi
connu sous le nom) plus (trop ?) vague.
Dans OSM la clé contextualise (shop=, amenity=), le nom ne doit pas
avoir ce contexte. Je n'ai pas besoin de distinguer Brest la commune et
Brest le traité de paix.
Pas Brest (France) de Brest (Belarus) (tiens il manque un
old_name:fr=Brest-Litovsk).
Wikidata en prenant les bonnes données fait pareil (pas Wikipédia).
Peut-être créer des objets spéciaux car les Wikidata sont en CC0 pas en
OdbL. Ou préciser que les noms des Wikidata sont en CC0 dans les termes
d'OSM.
Pour MLTVULCA merci pour les explications.
Tu veux dire qu'il manque un nom et un website sur le bâtiment au sud ;-).
Je suis allé regarder sur les vues de BigBrother, c'est un petit poste
de quartier, pas lié à http://www.mltvulca.com/presentation.htm
La suite, que je disais cabalistique, est effectivement en général une
suite de caractères permettant de voir où c'est.
Car ce n'est pas un poste privé mais un poste pour cette boîte et
quelques maisons.
Manque donc substation=minor_distribution et il faut mettre
operator=Enedis (à la place d'EDF).
Donc on devrait avoir un ref:ERDF:GDO (si ce ne me trompe) qui ne serait
pas MLTVULCA.
Normalement un nom se prononce, ici (postes Enedis) c'est souvent des
abréviations. Dans OSM on ne met pas de noms abrégés dans name, pour ça
il y a short_name (quoique).
Ici c'est une référence locale, un libellé. Si on parle du poste, on
parlera du poste de MLT Vulca, donc le nom est MLT Vulca (que qui est
mauvais car ce n'est pas la société, c'est juste un poste public
fournissant essentiellement cette entreprise).
J'avais viré le name car ce n'est pas un nom. Si on considère que le
libellé doit être dans le champ name, je pense qu'il faut améliorer le
wiki sur ce point.
Le wiki power=substation
<http://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dsubstation> dit :
name <http://wiki.openstreetmap.org/wiki/Key:name> <name> Le nom
d'usage du poste électrique recommandé
operator <http://wiki.openstreetmap.org/wiki/Key:operator> <exploitant>
Nom de l'exploitant du poste électrique optionnel
ref <http://wiki.openstreetmap.org/wiki/Key:ref> <reference>
Identifiant unique du poste électrique optionnel
Trop vague. Pour moi la suite de caractère est la référence sur un plan,
pour Enedis sur la commune.
S'il y a un problème sur le poste, qu'on appelle Enedis je suppose que
s'il n'y a pas de GDO de lisible, on parle du poste de MLT Vulca ou on
dit qu'il y a écrit MLTVULCA. Le non d'usage c'est MLT Vulca.
Si initialement j'avais supprimé le doublon nom/ref c'est qu'Osmose
braillait, à mon avis avec raison, contre ces noms TOUT EN MAJUSCULES.
http://wiki.openstreetmap.org/w/images/b/b4/French_power_substation_code5d.jpeg
: son nom est à mon avis Viking, peut-être Viking 10829, pas VIKING ou
VIKING 10829.
C'est par contre dit assez clairement sur FR:Key:ref:ERDF:gdo
<http://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo> qu'on prend le
nom tel quel... et qu'on utilise pas ref.
C'est à dire que pour savoir remplir un power=substation
<http://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dsubstation> *il faut
aller sur une page non référencée dessus !*
Je m'étais contenté de la page en question et survolé la partie name du
ref:ERDF:gdo <http://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo>
Bien sûr, on va remplacer la clé ref:ERDF:gdo par ref:Q3587594 -et la
boucle est bouclée ;-)
*
**Donc : doit-on mettre le nom *TOUT EN MAJUSCULE et éliminer le test
pour les power=substation*ou *les mettre proprement (ici MVT Vulca,
Viking) ?
Jean-Yvon
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
